-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
ospfd: Improve OSPF neighbor retransmission list granularity and prec…
…ision The current OSPF neighbor retransmission operates on a single per-neighbor periodic timer that sends all LSAs on the list when it expires. Additionally, since it skips the first retransmission of received LSAs so that at least the retransmission interval (resulting in a delay of between the retransmission interval and twice the interval. In environments where the links are lossy on P2MP networks with "delay-reflood" configured (which relies on neighbor retransmission in partial meshs), the implementation is sub-optimal (to say the least). This commit reimplements OSPF neighbor retransmission as follows: 1. A new data structure making use the application managed linklist.c library functions implements an OSPF temporal list where each node includes a timestamp. 2. The existing neighbor LS retransmission LSDB data structure is augmented with a pointer to the list node on the temporal list to faciliate O(1) removal when the LSA is acknowledged. 3. The neighbor LS retransmission timer is set to the expiration timer of the LSA at the top of the list. 4. When the timer expires, LSAs are retransmitted that within the window of the current time and a small dela (20 milli-secs). The LSAs that are retransmited are given an updated retransmissionn time and moved to the end of the list. 5. Neighbor and interface LSA retransmission counters are added to provide insight into the lossiness of the links. However, these will increment quickly on non-fully meshed P2MP networks with "delay-reflood" configured. 6. Added a topotest to exercise the implementation on a non-fully meshed P2MP network with "delay-reflood" configured. The alternative was to use existing mechanisms to instroduce loss but these seem less determistic in a topotest. Signed-off-by: Acee Lindem <[email protected]>
- Loading branch information
1 parent
db1e2a0
commit 2c1a581
Showing
24 changed files
with
626 additions
and
113 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,69 @@ | ||
OSPF Neighor Retransmission List | ||
================================ | ||
|
||
Overview | ||
-------- | ||
|
||
OSPF neighbor link-state retransmission lists are implemented using | ||
both a sparse Link State Database (LSDB) and a doubly-linked list. | ||
Rather than previous per-neighbor periodic timer, a per-neighbor | ||
timer is set to the expiration time of the next scheduled LSA | ||
retransmission. | ||
|
||
Sparse Link State Database (LSDB) | ||
--------------------------------- | ||
|
||
When an explicit or implied acknowledgment is recieved from a | ||
neighbor in 2-way state or higher, the acknowledge LSA must be | ||
removed from the neighbor's link state retransmission list. In order | ||
to do this efficiently, a sparse LSDB is utilized. LSDB entries also | ||
include a pointer to the corresponding list entry so that it may be | ||
efficiently removed from the doubly-linked list. | ||
|
||
The sparse LSDB is implemented using the OSPF functions is | ||
ospf_lsdb.[c,h]. OSPF LSDBs are implemented as an array of route | ||
tables (lib/table.[c,h]). What is unique of the LS Retransmission | ||
list LSDB is that each entry also has a pointer into the doubly-linked | ||
list to facilitate fast deletions. | ||
|
||
Doubly-Linked List | ||
------------------ | ||
|
||
In addition to the sparse LSDB, LSAs on a neighbor LS retransmission | ||
list are also maintained in a linked-list order chronologically | ||
with the LSA scheduled for the next retransmission at the head of | ||
the list. | ||
|
||
The doubly-link list is implemented using the dlist macros in | ||
lib/typesafe.h. | ||
|
||
LSA LS Retransmission List Addition | ||
------------------------------------ | ||
|
||
When an LSA is added to a neighbor retransmission list, it is | ||
added to both the sparse LSDB and the doubly-linked list with a pointer | ||
in the LSDB route-table node to the list entry. The LSA is added to | ||
the tail of the list with the expiration time set to the current time | ||
with the retransmission interval added. If the neighbor retransmission | ||
timer is not set, it is set to expire at the time of the newly added | ||
LSA. | ||
|
||
LSA LS Retransmission List Deletion | ||
----------------------------------- | ||
|
||
When an LSA is deleted from a neighbor retransmission list, it is | ||
deleted from eboth the sparse LSDB and the doubly-linked list with the | ||
pointer the LSDB route-table node used to efficiently delete the entry | ||
from the list. If the LSA at the head of the list was removed, then | ||
the neighbor retransmission timer is reset to the expiration of the | ||
LSA at the head of the list or canceled if the list is empty. | ||
|
||
Neighbor LS Retransmission List Expiration | ||
------------------------------------------ | ||
|
||
When the neighbor retransmission timer expires, the LSA at the top of | ||
list and any in a configured window (e.g., 50 milliseconds) are | ||
retransmitted. The LSAs that have been retransmitted are removed from | ||
the list and readded to the tail of the list with a new expiration time | ||
which is retransmit-interval seconds in the future. | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8,6 +8,7 @@ OSPFD | |
:maxdepth: 2 | ||
|
||
ospf-api | ||
ospf-ls-retrans | ||
ospf-sr | ||
cspf | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.