From 37c3e558ab31a5e6088cef063dcd1e267238be74 Mon Sep 17 00:00:00 2001 From: Ondrej Filip Date: Wed, 7 Jun 2000 23:05:32 +0000 Subject: Simple explanation, how LSA are kept in database. --- proto/ospf/ospf.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'proto') diff --git a/proto/ospf/ospf.c b/proto/ospf/ospf.c index 9eec3092..a7fb650e 100644 --- a/proto/ospf/ospf.c +++ b/proto/ospf/ospf.c @@ -29,7 +29,8 @@ * adding and deleting them, there are also functions for originating * various types of LSA. (router lsa, net lsa, external lsa) |Rt.c| * contains routins for calculating of routing table. |Lsalib.c| is a set - * of various functions for work with LSAs. + * of various functions for work with LSAs. (Endianity transformations, + * checksum calculation etc.) * * Just one instance of protocol is able to hold LSA databases for * multiple OSPF areas and exhange routing information between @@ -38,7 +39,10 @@ * &ospf_iface are connected. To &ospf_area is connected * &top_hash_graph, which is a dynamic hashing structure that * describes link-state database. It allows fast search, adding - * and deleting. Every area has it's own area_disp() that is + * and deleting. LSA is kept in two pieces: header and body. Both of them are + * kept in endianity of CPU. + * + * Every area has it's own area_disp() that is * responsible for late originating of router LSA, calcutating * of routing table and it also ages and flushes LSA database. This * function is called in regular intervals. -- cgit v1.2.3