embedaddon/bird/doc/prog-1.html - view

File: [ELWIX - Embedded LightWeight unIX -] / embedaddon / bird / doc / prog-1.html
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Tue Aug 22 12:33:54 2017 UTC (6 years, 10 months ago) by misho
Branches: bird, MAIN
CVS tags: v1_6_8p3, v1_6_3p0, v1_6_3, HEAD

bird 1.6.3

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: 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:  24: 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:  35: <H2><A NAME="ss1.2">1.2</A> <A HREF="prog.html#toc1.2">Design goals</A> 36: </H2> 37: 38: 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:  44: <UL> 45: <LI>Support all the standard routing protocols and make it easy to add new ones. 46: This leads to modularity and clean separation between the core and the protocols. 47: </LI> 48: <LI>Support both IPv4 and IPv6 in the same source tree, re-using most of the code. 49: This leads to abstraction of IP addresses and operations on them. 50: </LI> 51: <LI>Minimize OS dependent code to make porting as easy as possible. 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>Allow multiple routing tables. 60: Easily solvable by abstracting out routing tables and the corresponding operations. 61: </LI> 62: <LI>Offer powerful route filtering. 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>Support easy configuration and re-configuration. 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>Be able to be controlled online. 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>Respond to all events in real time. 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:  100: <H2><A NAME="ss1.3">1.3</A> <A HREF="prog.html#toc1.3">Architecture</A> 101: </H2> 102: 103: The requirements set above have lead to a simple modular architecture containing 104: the following types of modules: 105:  106: <DL> 107:  108: <DT>Core modules<DD>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:  113: <DT>Library modules<DD>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:  118: <DT>Resource management modules<DD>take care of resources, their allocation 119: and automatic freeing when the module having requested shuts itself down. 120:  121: <DT>Configuration modules<DD>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:  126: <DT>The filter<DD>implements the route filtering language. 127:  128: <DT>Protocol modules<DD>implement the individual routing protocols. 129:  130: <DT>System-dependent modules<DD>implement the interface between BIRD 131: and specific operating systems. 132:  133: <DT>The client<DD>is a simple program providing an easy, though friendly 134: interface to the CLI. 135:  136: </DL> 137:  138: <H2><A NAME="ss1.4">1.4</A> <A HREF="prog.html#toc1.4">Implementation</A> 139: </H2> 140: 141: 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:  146: The modules are statically linked to produce a single executable file 147: (except for the client which stands on its own). 148:  149: The building process is controlled by a set of Makefiles for GNU Make, 150: intermixed with several Perl and shell scripts. 151:  152: 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:  157: The parser of the configuration is generated by the GNU Bison. 158:  159: 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:  165: 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:  169: 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:  174: <HR> 175: <A HREF="prog-2.html">Next</A> 176: Previous 177: <A HREF="prog.html#toc1">Contents</A> 178: </BODY> 179: </HTML>