Annotation of embedaddon/bird/doc/prog-1.html, revision 1.1.1.1
1.1 misho 1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
2: <HTML>
3: <HEAD>
4: <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 1.0.9">
5: <TITLE>BIRD Programmer's Documentation: BIRD Design</TITLE>
6: <LINK HREF="prog-2.html" REL=next>
7:
8: <LINK HREF="prog.html#toc1" REL=contents>
9: </HEAD>
10: <BODY>
11: <A HREF="prog-2.html">Next</A>
12: Previous
13: <A HREF="prog.html#toc1">Contents</A>
14: <HR>
15: <H2><A NAME="s1">1.</A> <A HREF="prog.html#toc1">BIRD Design</A></H2>
16:
17: <H2><A NAME="ss1.1">1.1</A> <A HREF="prog.html#toc1.1">Introduction</A>
18: </H2>
19:
20: <P>This document describes the internal workings of BIRD, its architecture,
21: design decisions and rationale behind them. It also contains documentation on
22: all the essential components of the system and their interfaces.
23: <P>
24: <P>Routing daemons are complicated things which need to act in real time
25: to complex sequences of external events, respond correctly even to the most erroneous behavior
26: of their environment and still handle enormous amount of data with reasonable
27: speed. Due to all of this, their design is very tricky as one needs to carefully
28: balance between efficiency, stability and (last, but not least) simplicity of
29: the program and it would be possible to write literally hundreds of pages about
30: all of these issues. In accordance to the famous quote of Anton Chekhov "Shortness
31: is a sister of talent", we've tried to write a much shorter document highlighting
32: the most important stuff and leaving the boring technical details better explained
33: by the program source itself together with comments contained therein.
34: <P>
35: <H2><A NAME="ss1.2">1.2</A> <A HREF="prog.html#toc1.2">Design goals</A>
36: </H2>
37:
38: <P>When planning the architecture of BIRD, we've taken a close look at the other existing routing
39: daemons and also at some of the operating systems used on dedicated routers, gathered all important
40: features and added lots of new ones to overcome their shortcomings and to better match the requirements
41: of routing in today's Internet: IPv6, policy routing, route filtering and so on. From this
42: planning, the following set of design goals has arisen:
43: <P>
44: <UL>
45: <LI><I>Support all the standard routing protocols and make it easy to add new ones.</I>
46: This leads to modularity and clean separation between the core and the protocols.
47: </LI>
48: <LI><I>Support both IPv4 and IPv6 in the same source tree, re-using most of the code.</I>
49: This leads to abstraction of IP addresses and operations on them.
50: </LI>
51: <LI><I>Minimize OS dependent code to make porting as easy as possible.</I>
52: Unfortunately, such code cannot be avoided at all as the details of communication with
53: the IP stack differ from OS to OS and they often vary even between different
54: versions of the same OS. But we can isolate such code in special modules and
55: do the porting by changing or replacing just these modules.
56: Also, don't rely on specific features of various operating systems, but be able
57: to make use of them if they are available.
58: </LI>
59: <LI><I>Allow multiple routing tables.</I>
60: Easily solvable by abstracting out routing tables and the corresponding operations.
61: </LI>
62: <LI><I>Offer powerful route filtering.</I>
63: There already were several attempts to incorporate route filters to a dynamic router,
64: but most of them have used simple sequences of filtering rules which were very inflexible
65: and hard to use for non-trivial filters. We've decided to employ a simple loop-free
66: programming language having access to all the route attributes and being able to
67: modify the most of them.
68: </LI>
69: <LI><I>Support easy configuration and re-configuration.</I>
70: Most routers use a simple configuration language designed ad hoc with no structure at all
71: and allow online changes of configuration by using their command-line interface, thus
72: any complex re-configurations are hard to achieve without replacing the configuration
73: file and restarting the whole router. We've decided to use a more general approach: to
74: have a configuration defined in a context-free language with blocks and nesting, to
75: perform all configuration changes by editing the configuration file, but to be able
76: to read the new configuration and smoothly adapt to it without disturbing parts of
77: the routing process which are not affected by the change.
78: </LI>
79: <LI><I>Be able to be controlled online.</I>
80: In addition to the online reconfiguration, a routing daemon should be able to communicate
81: with the user and with many other programs (primarily scripts used for network maintenance)
82: in order to make it possible to inspect contents of routing tables, status of all
83: routing protocols and also to control their behavior (disable, enable or reset a protocol without restarting all the others). To achieve
84: this, we implement a simple command-line protocol based on those used by FTP and SMTP
85: (that is textual commands and textual replies accompanied by a numeric code which makes
86: them both readable to a human and easy to recognize in software).
87: </LI>
88: <LI><I>Respond to all events in real time.</I>
89: A typical solution to this problem is to use lots of threads to separate the workings
90: of all the routing protocols and also of the user interface parts and to hope that
91: the scheduler will assign time to them in a fair enough manner. This is surely a good
92: solution, but we have resisted the temptation and preferred to avoid the overhead of threading
93: and the large number of locks involved and preferred a event driven architecture with
94: our own scheduling of events. An unpleasant consequence of such an approach
95: is that long lasting tasks must be split to more parts linked by special
96: events or timers to make the CPU available for other tasks as well.
97: </LI>
98: </UL>
99: <P>
100: <H2><A NAME="ss1.3">1.3</A> <A HREF="prog.html#toc1.3">Architecture</A>
101: </H2>
102:
103: <P>The requirements set above have lead to a simple modular architecture containing
104: the following types of modules:
105: <P>
106: <DL>
107: <P>
108: <DT>Core modules<DD><P>implement the core functions of BIRD: taking care
109: of routing tables, keeping protocol status, interacting with the user using
110: the Command-Line Interface (to be called CLI in the rest of this document)
111: etc.
112: <P>
113: <DT>Library modules<DD><P>form a large set of various library functions
114: implementing several data abstractions, utility functions and also functions
115: which are a part of the standard libraries on some systems, but missing on other
116: ones.
117: <P>
118: <DT>Resource management modules<DD><P>take care of resources, their allocation
119: and automatic freeing when the module having requested shuts itself down.
120: <P>
121: <DT>Configuration modules<DD><P>are fragments of lexical analyzer,
122: grammar rules and the corresponding snippets of C code. For each group
123: of code modules (core, each protocol, filters) there exist a configuration
124: module taking care of all the related configuration stuff.
125: <P>
126: <DT>The filter<DD><P>implements the route filtering language.
127: <P>
128: <DT>Protocol modules<DD><P>implement the individual routing protocols.
129: <P>
130: <DT>System-dependent modules<DD><P>implement the interface between BIRD
131: and specific operating systems.
132: <P>
133: <DT>The client<DD><P>is a simple program providing an easy, though friendly
134: interface to the CLI.
135: <P>
136: </DL>
137: <P>
138: <H2><A NAME="ss1.4">1.4</A> <A HREF="prog.html#toc1.4">Implementation</A>
139: </H2>
140:
141: <P>BIRD has been written in GNU C. We've considered using C++, but we've
142: preferred the simplicity and straightforward nature of C which gives us fine
143: control over all implementation details and on the other hand enough
144: instruments to build the abstractions we need.
145: <P>
146: <P>The modules are statically linked to produce a single executable file
147: (except for the client which stands on its own).
148: <P>
149: <P>The building process is controlled by a set of Makefiles for GNU Make,
150: intermixed with several Perl and shell scripts.
151: <P>
152: <P>The initial configuration of the daemon, detection of system features
153: and selection of the right modules to include for the particular OS
154: and the set of protocols the user has chosen is performed by a configure
155: script generated by GNU Autoconf.
156: <P>
157: <P>The parser of the configuration is generated by the GNU Bison.
158: <P>
159: <P>The documentation is generated using <CODE>SGMLtools</CODE> with our own DTD
160: and mapping rules which produce both an online version in HTML and
161: a neatly formatted one for printing (first converted
162: from SGML to LaTeX and then processed by TeX and <CODE>dvips</CODE> to
163: get a PostScript file).
164: <P>
165: <P>The comments from C sources which form a part of the programmer's
166: documentation are extracted using a modified version of the <CODE>kernel-doc</CODE>
167: tool.
168: <P>
169: <P>If you want to work on BIRD, it's highly recommended to configure it
170: with a <CODE>--enable-debug</CODE> switch which enables some internal consistency
171: checks and it also links BIRD with a memory allocation checking library
172: if you have one (either <CODE>efence</CODE> or <CODE>dmalloc</CODE>).
173: <P>
174: <HR>
175: <A HREF="prog-2.html">Next</A>
176: Previous
177: <A HREF="prog.html#toc1">Contents</A>
178: </BODY>
179: </HTML>
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to prog-1.html CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / bird / doc