Revision 725270cb proto/ospf/ospf.c

View differences:

proto/ospf/ospf.c
9 9
/**
10 10
 * DOC: Open Shortest Path First (OSPF)
11 11
 * 
12
 * As OSPF protocol is quite complicated and complex implemenation is
13
 * split into many files. In |ospf.c| you can find mostly interfaces
14
 * for communication with nest. (E.g. reconfiguration hooks, shutdown
15
 * and inicialisation and so on.) In |packet.c| you can find various
16
 * functions for sending and receiving generic OSPF packet. There are
17
 * also routins for autentications, checksumming. |Iface.c| contains
18
 * interface state machine, allocation and deallocation of OSPF's
19
 * interface data structures. |Neighbor.c| includes neighbor state
20
 * machine and function for election of Designed Router and Backup
21
 * Designed router. In |hello.c| there are routines for sending
22
 * and receiving hello packets as well as functions for maintaining
23
 * wait times and inactivity timer. |Lsreq.c|, |lsack.c|, |dbdes.c|
24
 * contains functions for sending and receiving link-state request,
25
 * link-state acknoledge and database description respectively.
26
 * In |lsupd.c| there are function for sending and receiving
27
 * link-state updates and also flooding algoritmus. |Topology.c| is
28
 * a place where routins for searching LSAs in link-state database,
29
 * adding and deleting them, there are also functions for originating
30
 * various types of LSA. (router lsa, net lsa, external lsa) |Rt.c|
31
 * contains routins for calculating of routing table. |Lsalib.c| is a set
32
 * of various functions for work with LSAs. (Endianity transformations,
33
 * checksum calculation etc.)
12
 * The OSPF protocol is quite complicated and its complex implemenation is
13
 * split to many files. In |ospf.c|, you can find mostly interface
14
 * for communication with the core (e.g., reconfiguration hooks, shutdown
15
 * and initialisation and so on). In |packet.c|, you can find various
16
 * functions for sending and receiving of generic OSPF packets. There are
17
 * also routines for autentication and checksumming. File |iface.c| contains
18
 * the interface state machine, allocation and deallocation of OSPF's
19
 * interface data structures. Source |neighbor.c| includes the neighbor state
20
 * machine and functions for election of Designed Router and Backup
21
 * Designed router. In |hello.c|, there are routines for sending
22
 * and receiving of hello packets as well as functions for maintaining
23
 * wait times and the inactivity timer. Files |lsreq.c|, |lsack.c|, |dbdes.c|
24
 * contain functions for sending and receiving of link-state requests,
25
 * link-state acknoledges and database descriptions respectively.
26
 * In |lsupd.c|, there are functions for sending and receiving
27
 * of link-state updates and also the flooding algorithm. Source |topology.c| is
28
 * a place where routines for searching LSA's in the link-state database,
29
 * adding and deleting them reside, there also are functions for originating
30
 * of various types of LSA's (router LSA, net LSA, external LSA). File |rt.c|
31
 * contains routines for calculating the routing table. |lsalib.c| is a set
32
 * of various functions for working with the LSA's (endianity conversions,
33
 * calculation of checksum etc.).
34 34
 *
35
 * Just one instance of protocol is able to hold LSA databases for
36
 * multiple OSPF areas and exhange routing information between
37
 * multiple neighbors and calculate routing tables. The core
38
 * structure is &proto_ospf, to which multiple &ospf_area and
39
 * &ospf_iface are connected. To &ospf_area is connected
40
 * &top_hash_graph, which is a dynamic hashing structure that
41
 * describes link-state database. It allows fast search, adding
42
 * and deleting. LSA is kept in two pieces: header and body. Both of them are
43
 * kept in endianity of CPU.
35
 * One instance of the protocol is able to hold LSA databases for
36
 * multiple OSPF areas, to exchange routing information between
37
 * multiple neighbors and to calculate the routing tables. The core
38
 * structure is &proto_ospf to which multiple &ospf_area and
39
 * &ospf_iface structures are connected. To &ospf_area is also connected
40
 * &top_hash_graph which is a dynamic hashing structure that
41
 * describes the link-state database. It allows fast search, addition
42
 * and deletion. Each LSA is kept in two pieces: header and body. Both of them are
43
 * kept in endianity of the CPU.
44 44
 * 
45
 * Every area has it's own area_disp() that is
46
 * responsible for late originating of router LSA, calcutating
47
 * of routing table and it also ages and flushes LSA database. This
45
 * Every area has its own area_disp() which is
46
 * responsible for late originating of router LSA, calculating
47
 * of the routing table and it also ages and flushes the LSA's. This
48 48
 * function is called in regular intervals.
49
 * To every &ospf_iface is connected one or more
50
 * &ospf_neighbors. This structure contains many timers and queues
51
 * for building adjacency and exchange routing messages.
49
 * To every &ospf_iface, we connect one or more
50
 * &ospf_neighbor's -- a structure containing many timers and queues
51
 * for building adjacency and for exchange of routing messages.
52 52
 *
53
 * BIRD's OSPF implementation respects RFC2328 in every detail but
54
 * some of inner function differs. RFC recommends to make a snapshot
55
 * of link-state database when new adjacency is building and send
56
 * database description packets based on information of this 
57
 * snapshot. The database can be quite large in some networks so
58
 * I rather walk through &slist structure which allows me to
59
 * continue even if actual LSA I worked on is deleted. New
60
 * LSA are added to the tail of this slist.
53
 * BIRD's OSPF implementation respects RFC2328 in every detail, but
54
 * some of internal algorithms do differ. The RFC recommends to make a snapshot
55
 * of the link-state database when a new adjacency is forming and send
56
 * the database description packets based on information of this 
57
 * snapshot. The database can be quite large in some networks, so
58
 * we rather walk through a &slist structure which allows us to
59
 * continue even if the actual LSA we were worked with is deleted. New
60
 * LSA's are added at the tail of this &slist.
61 61
 *
62
 * I also don't build another, new routing table besides the old
63
 * one because nest helps me. I simply flush all calculated and
64
 * deleted routes into nest's routing table. It's simplyfies
65
 * this process and spares memory.
62
 * We also don't keep a separate OSPF routing table, because the core
63
 * helps us by being able to recognize when a route is updated
64
 * to an identical one and it suppresses the update automatically.
65
 * Due to this, we can flush all the routes we've recalculated and
66
 * also those we're deleted to the core's routing table and the
67
 * core will take care of the rest. This simplifies the process
68
 * and conserves memory.
66 69
 */
67 70

  
68 71
#include "ospf.h"

Also available in: Unified diff