Annotation of embedaddon/bird/doc/prog-1.html, revision 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