f7735ad692c80cad3752d510cd1793fd83e84428
[olsrd.git] / lib / bmf / README_BMF.txt
1 BASIC MULTICAST FORWARDING PLUGIN FOR OLSRD
2 by Erik Tromp (erik.tromp@nl.thalesgroup.com, erik_tromp@hotmail.com)
3 Version 1.5.3
4
5 1. Introduction
6 ---------------
7
8 The Basic Multicast Forwarding Plugin floods IP-multicast and
9 IP-local-broadcast traffic over an OLSRD network. It uses the
10 Multi-Point Relays (MPRs) as identified by the OLSR protocol
11 to optimize the flooding of multicast and local broadcast packets
12 to all the hosts in the network. To prevent broadcast storms, a
13 history of packets is kept; only packets that have not been seen
14 in the past 3-6 seconds are forwarded.
15
16
17 2. How to build and install
18 ---------------------------
19
20 Download the olsr-bmf-v1.5.3.tar.gz file and save it into your OLSRD
21 base install directory.
22
23 Change directory (cd) to your OLSRD base install directory.
24
25 At the command prompt, type:
26
27   tar -zxvf ./olsr-bmf-v1.5.3.tar.gz
28
29 then type:
30
31   make build_all
32
33 followed by:
34
35   make install_all
36
37 Next, turn on the possibility to create a tuntap interface (see also
38 /usr/src/linux/Documentation/networking/tuntap.txt):
39
40   mkdir /dev/net # if it doesn't exist already
41   mknod /dev/net/tun c 10 200
42   
43 Set permissions, e.g.:
44
45   chmod 0700 /dev/net/tun
46
47 To configure BMF in OLSR, you must edit the file /etc/olsrd.conf
48 to load the BMF plugin. For example, add the following lines:
49
50   LoadPlugin "olsrd_bmf.so.1.5.3"
51   {
52     # No PlParam entries required for basic operation
53   }
54
55
56 3. How to run
57 -------------
58
59 After building and installing OLSRD with the BMF plugin, run the
60 olsrd daemon by entering at the shell prompt:
61
62   olsrd
63
64 Look at the output; it should list the BMF plugin, e.g.:
65
66   ---------- LOADING LIBRARY olsrd_bmf.so.1.5.3 ----------
67   OLSRD Basic Multicast Forwarding (BMF) plugin 1.5.3 (Feb 24 2008 17:58:02)
68     (C) Thales Communications Huizen, Netherlands
69     Erik Tromp (eriktromp@users.sourceforge.net)
70   Checking plugin interface version:  5 - OK
71   Trying to fetch plugin init function: OK
72   Trying to fetch parameter table and it's size...
73   Sending parameters...
74   "NonOlsrIf"/"eth0"... NonOlsrIf: OK
75   Running plugin_init function...
76   OLSRD Basic Multicast Forwarding (BMF) plugin: opened 5 sockets
77   ---------- LIBRARY olsrd_bmf.so.1.5.3 LOADED ----------
78
79
80 4. How to check if it works
81 ---------------------------
82
83 Enter the following command on the command prompt:
84   
85   ping 224.0.0.1
86
87 All OLSR-BMF hosts in the OLSR network should respond. For example,
88 assume we have three hosts, with IP addresses 192.168.151.50,
89 192.168.151.53 and 192.168.151.55. On host 192.168.151.50 we enter
90 the following ping command:
91
92 root@IsdbServer:~# ping 224.0.0.1
93 PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data.
94 64 bytes from 192.168.151.50: icmp_seq=1 ttl=64 time=0.511 ms
95 64 bytes from 192.168.151.53: icmp_seq=1 ttl=64 time=4.67 ms (DUP!)
96 64 bytes from 192.168.151.55: icmp_seq=1 ttl=63 time=10.7 ms (DUP!)
97 64 bytes from 192.168.151.50: icmp_seq=2 ttl=64 time=0.076 ms
98 64 bytes from 192.168.151.53: icmp_seq=2 ttl=64 time=1.23 ms (DUP!)
99 64 bytes from 192.168.151.55: icmp_seq=2 ttl=63 time=1.23 ms (DUP!)
100 64 bytes from 192.168.151.50: icmp_seq=3 ttl=64 time=0.059 ms
101 64 bytes from 192.168.151.53: icmp_seq=3 ttl=64 time=2.94 ms (DUP!)
102 64 bytes from 192.168.151.55: icmp_seq=3 ttl=63 time=5.62 ms (DUP!)
103 64 bytes from 192.168.151.50: icmp_seq=4 ttl=64 time=0.158 ms
104 64 bytes from 192.168.151.53: icmp_seq=4 ttl=64 time=1.14 ms (DUP!)
105 64 bytes from 192.168.151.55: icmp_seq=4 ttl=63 time=1.16 ms (DUP!)
106
107 We can see the response from the originating host (192.168.151.50)
108 (it is normal behaviour for hosts sending multicast packets to
109 receive their own packets). We can also see the responses by the
110 other hosts (correctly seen as DUPlicates by ping).
111
112 Note: when using an older version of ping than the standard from
113 iputils-20020927, as found in most current Linux distributions, you may want
114 to test BMF by specifying the output interface to the ping command:
115
116   ping -I bmf0 224.0.0.1
117
118 Older versions of 'ping' (e.g. as found in iputils-20020124) may bind to the
119 autoselected source address, which may be incorrect. Since BMF re-uses
120 one of the existing IP addresses for the "bmf0" network interface, the
121 older-version ping command may 'autobind' to the wrong interface.
122
123 See also the note in the iputils-20020927/RELNOTES file:
124 "* Mads Martin Jørgensen <mmj@suse.de>: ping should not bind to autoselected
125   source address, it used to work when routing changes. Return classic
126   behaviour, option -B is added to enforce binding."
127
128
129 5. How does it work
130 -------------------
131
132 In the IP header there is room for only two IP-addresses:
133 * the destination IP address (in our case either a multicast
134   IP-address 224.0.0.0...239.255.255.255, or a local broadcast
135   address e.g. 192.168.1.255), and
136 * the source IP address (the originator).
137
138 For optimized flooding, however, we need more information. Let's
139 assume we are the BMF process on one host. We will need to know which
140 host forwarded the IP packet to us. Since OLSR keeps track of which
141 hosts select our host as MPR (see the olsr_lookup_mprs_set(...) function),
142 we can determine if the host that forwarded the packet, has selected us as
143 MPR. If so, we must also forward the packet, changing the 'forwarded-by'
144 IP-address to that of us. If not, we do not forward the packet.
145
146 Because we need more information than fits in a normal IP-header, the
147 original packets are encapsulated into a new IP packet. Encapsulated
148 packets are transported in UDP, port 50698. The source address of the
149 encapsulation packet is set to the address of the forwarder instead of
150 the originator. Of course, the payload of the encapsulation packet is
151 the original IP packet. For an exact specification of the encapsulation
152 format, refer to paragraph 10 below.
153
154 For local reception, each received encapsulated packets is unpacked
155 and passed into a tuntap interface which is specially created for
156 this purpose.
157
158 There are other flooding solutions available that do not use
159 encapsulation. The problem with these solutions is that they cannot
160 prevent duplicates of forwarded packets to enter the IP stack. For
161 example, if a host is receiving flooded (unencapsulated, native IP)
162 packets via two MPR hosts, there is no way to stop the reception of
163 the packets coming in via the second MPR host. To prevent this, BMF
164 uses a combination of encapsulated flooding and local reception via
165 a tuntap interface.
166
167 Here is in short how the flooding works (see also the
168 BmfEncapsulatedPacketReceived(...) function; details with respect to
169 the forwarding towards non-OLSR enabled hosts are omitted):
170   
171   On all OLSR-enabled interfaces, setup reception of packets
172     on UDP port 50698.
173   Upon reception of such a packet:
174     If the received packet was sent by myself, drop it.
175     If the packet was recently seen, drop it.
176     Unpack the encapsulated packet and send a copy to myself via the
177       TunTap interface.
178     If I am an MPR for the host that forwarded the packet to me,
179       forward the packet to all OLSR-enabled interfaces *including*
180       the interface on which it was received.
181
182
183 6. Advanced configuration
184 -------------------------
185
186 All configuration of BMF is done via the "LoadPlugin" section in
187 the /etc/olsrd.conf file.
188
189 The following gives an overview of all plugin parameters that can be
190 configured:
191
192   LoadPlugin "olsrd_bmf.so.1.5.3"
193   {
194     # Specify the name of the BMF network interface.
195     # Defaults to "bmf0".
196     PlParam "BmfInterface" "mybmf0"
197
198     # Specify the IP address and mask for the BMF network interface.
199     # By default, the IP address of the first OLSR interface is copied.
200     # The default prefix length is 32.
201     PlParam "BmfInterfaceIp" "10.10.10.234/24"
202
203     # Enable or disable the flooding of local broadcast packets
204     # (e.g. packets with IP destination 192.168.1.255). Either "yes"
205     # or "no". Defaults to "yes".
206     PlParam "DoLocalBroadcast" "no"
207
208     # Enable or disable the capturing packets on the OLSR-enabled
209     # interfaces (in promiscuous mode). Either "yes" or "no". Defaults
210     # to "no".
211     # The multicast (and, if configured, local broadcast) packets sent on
212     # the non-OLSR network interfaces and on the BMF network interface will
213     # always be flooded over the OLSR network.
214     # If this parameter is "yes", also the packets sent on the OLSR-enabled
215     # network interfaces will be flooded over the OLSR network.
216     # NOTE: This parameter should be set consistently on all hosts throughout
217     # the network. If not, hosts may receive multicast packets in duplicate.
218     PlParam "CapturePacketsOnOlsrInterfaces" "yes"
219
220     # The forwarding mechanism to use. Either "Broadcast" or
221     # "UnicastPromiscuous". Defaults to "Broadcast".
222     # In the "UnicastPromiscuous" mode, packets are forwarded (unicast) to the
223     # best candidate neighbor; other neighbors listen promiscuously. IP-local
224     # broadcast is not used. This saves air time on 802.11 WLAN networks,
225     # on which unicast packets are usually sent at a much higher bit rate
226     # than broadcast packets (which are sent at a basic bit rate).
227     PlParam "BmfMechanism" "UnicastPromiscuous"
228
229     # The number of times BMF will transmit the same packet whenever it decides
230     # to use broadcast to forward a packet. Defaults to 1. Not used if
231     # "BmfMechanism" is set to "UnicastPromiscuous".
232     PlParam "BroadcastRetransmitCount" "2"
233
234     # If the number of neighbors to forward to is less than or equal to the
235     # FanOutLimit, then packets to be relayed will be sent via unicast.
236     # If the number is greater than the FanOutLimit the packet goes out
237     # as broadcast. Legal values are 1...10. See MAX_UNICAST_NEIGHBORS
238     # as defined in NetworkInterfaces.h . Defaults to 2. Not used if
239     # "BmfMechanism" is set to "UnicastPromiscuous".
240     PlParam "FanOutLimit" "4"
241
242     # List of non-OLSR interfaces to include
243     PlParam     "NonOlsrIf"  "eth2"
244     PlParam     "NonOlsrIf"  "eth3"
245   }
246
247 BmfInterfaceIp
248 --------------
249
250 By default, the BMF network interface will get the IP address of the
251 first OLSR interface, with a prefix length of 32. Having two network
252 interfaces with the same IP address may seem strange, but it is not
253 a problem, since the BMF network interface is not used in any point-to-
254 point routing.
255
256 The advantage of assigning a known OLSR IP address to the BMF network
257 interface is that multicast packets, sent via the BMF network interface,
258 get a known IP source address, to which the receivers of the packets
259 can reply. That is useful when using, for example, the command
260 "ping 224.0.0.1".
261
262 An advantage of using a prefix length of 32 is that the Linux IP
263 stack will not automatically enter a subnet routing entry (via the BMF
264 network interface) into the kernel routing table. Such a routing entry
265 would be useless, because the BMF network interface does not forward
266 point-to-point traffic.
267
268 If you configure a specific IP address and mask via the "BmfInterfaceIp"
269 parameter, BMF will cause the specified IP host address to be advertised
270 into the OLSR network via the HNA mechanism, so that the other hosts in
271 the network know how to route back.
272
273 CapturePacketsOnOlsrInterfaces
274 ------------------------------
275
276 If "CapturePacketsOnOlsrInterfaces" is set to "yes", any multicast
277 or local broadcast IP packet, sent by an application on *any* OLSR
278 interface, will be flooded over the OLSR network. Each OLSR host
279 will receive the packet on its BMF network interface, "bmf0". The
280 OLSR-interfaces will be in promiscuous mode to capture the multicast
281 or local broadcast packets.
282
283 For example, if "eth1" is an OLSR interface, the following command
284 will result in one response from each OLSR host in the network:
285
286   ping -I eth1 224.0.0.1
287
288 A disadvantage of this configuration is that a host may, in rare
289 cases, receive a multicast packet twice. This is best explained
290 by looking at the following network diagram:
291
292         eth0   eth0
293       A ----------- B
294  eth1 |            / eth1
295       |           /
296  eth0 |          /
297       C --------+
298         eth1
299
300 Suppose host A is running a ping session that is sending ping
301 packets on "eth1". The BMF process on host A will see the outgoing
302 packets on "eth1", encapsulates these packets and sends the
303 encapsulated packets on "eth0". Let's assume we are using the link
304 quality extensions of OLSR, and the 2-hop path A - B - C is better
305 (in terms of ETX) than the 1-hop path A - C. In that case host B is
306 an MPR for host A. Host B receives the encapsulated packets of host A
307 on its "eth0" interface, and, since it is an MPR, it decides to
308 forward them on "eth1".
309
310 In most cases, host C will receive the original, unencapsulated
311 ping packet on its "eth0" interface before the encapsulated
312 ping packet from host B arrives on its "eth1" interface. When the
313 encapsulated packet from B arrives, the BMF process will then see
314 that it is a duplicate and discard it.
315
316 However, in the IP world, there are no guarantees, so it may
317 happen that host C receives the encapsulated packet from host B
318 first. That packet is then unpacked and locally delivered to the
319 BMF network interface "bmf0". When the original, unencapsulated
320 packet then comes in on "eth0", there is no way to stop it from
321 being received (for a second time) by the Linux IP stack.
322
323 As said, this may be a rare case. Besides, most applications
324 can deal with a duplicate reception of the same packet. But if
325 you're a purist and want everything to work correct, you should
326 leave "CapturePacketsOnOlsrInterfaces" to its default value "no".
327
328 A disadvantage of leaving "CapturePacketsOnOlsrInterfaces" to its
329 default value "no" is that all multicast traffic must go via the
330 BMF network interface "bmf0". However, this should not be a problem,
331 since a route to all multicast addresses via the BMF network
332 interface "bmf0" is automatically added when BMF is started.
333
334
335 7. Adding non-OLSR interfaces to the multicast flooding
336 -------------------------------------------------------
337
338 As a special feature, it is possible to also forward from and to
339 non-OLSR interfaces.
340
341 If you have network interfaces on which OLSR is *not* running, but you *do*
342 want to forward multicast and local-broadcast IP packets, specify these
343 interfaces one by one as "NonOlsrIf" parameters in the BMF plugin section
344 of /etc/olsrd.conf. For example:
345
346   LoadPlugin "olsrd_bmf.so.1.5.3"
347   {
348     # Non-OLSR interfaces to participate in the multicast flooding
349     PlParam     "NonOlsrIf"  "eth2"
350     PlParam     "NonOlsrIf"  "eth3"
351   }
352
353 If an interface is listed both as "NonOlsrIf" for BMF, and in the
354 Interfaces { ... } section of olsrd.conf, it will be seen by BMF
355 as an OLSR-enabled interface.
356
357
358 8. Interworking with other multicast routers
359 --------------------------------------------
360
361 In a typical interworking configuration there is a network of OLSR hosts
362 in which one host acts as a gateway to a fixed infrastructure network.
363 Usually that host will be advertising a default route via the HNA
364 mechanism, e.g. by adding the following lines to its /etc/olsrd.conf
365 file:
366
367   Hna4
368   {
369   #   Internet gateway:
370       0.0.0.0      0.0.0.0
371   }
372
373 Alternatively, the gateway is running OLSRDs dynamic internet gateway
374 plugin; read the file ../../lib/dyn_gw/README_DYN_GW .
375
376 The gateway host will usually have at least one OLSR-interface, and
377 at least one non-OLSR interface, running a third-party routing protocol
378 like OSPF.
379
380 It is beyond the scope of this document to deal with the interworking
381 between BMF and all possible multicast routing daemons. As an example,
382 let's assume the gateway is running the mrouted multicast daemon (which
383 implements the DVMRP protocol). Also, assume that all the IP addresses
384 in the OLSR network are within the IP subnet 10.0.0.0/8 . Then mrouted
385 on the gateway needs to be configured to accept IGMP requests from IP
386 clients within the 10.0.0.0/8 subnet on the BMF network interface
387 ("bmf0"). This is easily configured by adding a line to the
388 /etc/mrouted.conf configuration file:
389
390   phyint bmf0 altnet 10.0.0.0/8
391
392 Not strictly necessary, but clean, is to disable the DVMRP protocol
393 on the OLSR interfaces, as no DVMRP routers are expected inside the
394 OLSR network. Suppose the gateway is running OLSR on "eth1", then
395 add the following line /etc/mrouted.conf :
396
397   phyint eth1 disable
398
399 Finally, mrouted does not accept interfaces with prefix length 32.
400 Therefore, override the default IP address and prefix length of
401 the BMF network interface, by editing the /etc/olsrd.conf file.
402 For example:
403
404   LoadPlugin "olsrd_bmf.so.1.5.3"
405   {
406       PlParam "BmfInterfaceIp" "10.10.10.4/24"
407   }
408
409 Note that it is not necessary, and even incorrect, to pass the
410 non-OLSR interface to BMF as a "NonOlsrIf" parameter in the
411 "LoadPlugin" section of the gateway host. When the mrouted
412 multicast daemon is running, the forwarding of multicast traffic
413 between the OLSR interface and the non-OLSR interface is done by
414 the Linux kernel.
415
416 The remaining text in this section has nothing to do with BMF or
417 OLSR, but is added to give a number of helpful hints you might
418 need when your multicast interworking, for some reason, is not working.
419
420 When using the mrouted multicast daemon, there is a useful command,
421 mrinfo, that gives information about what mrouted thinks of its
422 neighbor hosts. For example:
423
424   root@node-4:/# mrinfo
425   127.0.0.1 (localhost.localdomain) [DVMRPv3 compliant]:
426     10.1.2.4 -> 10.1.2.2 (10.1.2.2) [1/1/querier]
427     10.0.6.4 -> 0.0.0.0 (local) [1/1/disabled]
428     10.255.255.253 -> 0.0.0.0 (local) [1/1/querier/leaf]
429
430 In this example, the line starting with "10.1.2.4" is for the
431 non-OLSR interface "eth0", on which mrouted has found an
432 mrouted-neighbor host "10.1.2.2". The next line is for the OLSR
433 interface "eth1", which is disabled for mrouted. The last line
434 is for the BMF interface "bmf0". It is clear that mrouted sees no
435 mrouted-neighbors on that interface (leaf).
436
437 To see what multicast traffic has flown through the gateway, view
438 the files /proc/net/ip_mr_vif and /proc/net/ip_mr_cache:
439
440   root@node-4:/# cat /proc/net/ip_mr_vif
441   Interface      BytesIn  PktsIn  BytesOut PktsOut Flags Local    Remote
442    0 eth0          27832      98     14200      50 00000 0402010A 00000000
443    2 bmf0          14484      51     13916      49 00000 FDFFFF0A 00000000
444   root@node-4:/# cat /proc/net/ip_mr_cache
445   Group    Origin   Iif     Pkts    Bytes    Wrong Oifs
446   4D4237EA C747010A 0         51    14484        0  2:1
447   4D4237EA C702010A 0         51    14484        0  2:1
448   4D4237EA C84C000A 2         53    15052        0  0:1
449
450 From the above we can deduce that traffic from input interface 0
451 (Iif 0, "eth0") is forwarded on output interface 2 (Oifs 2, = "bmf0"),
452 and traffic from input interface 2 (Iif 2, "bmf0") is forwarded on
453 output interface 0 (Oifs 0, "eth0"). The ":1" behind the Oifs numbers
454 indicates the TTL thresholds, in this case packets with TTL value 1
455 or less will not be forwarded.
456
457 Note that when you are connecting an OLSR-BMF network to another multicast
458 network (e.g. a DVMRP-mrouted network), you might be surprised that, when
459 you ping the all-routers multicast address 224.0.0.1 from within the OLSR
460 network, only the OLSR hosts respond. This is, however, compliant behaviour:
461 packets with their destination IP address in the range 224.0.0.0 -
462 224.0.0.255 are not routed by normal multicast protocols (i.e. their
463 TTL is implicitly assumed to be 1). It doesn't mean that multicast is
464 not working; if your application uses a multicast address outisde the
465 range 224.0.0.0 - 224.0.0.255, it should work.
466
467
468 9. Common problems, FAQ
469 ------------------------
470
471 ---------
472 Question:
473 On which platforms does BMF currently compile?
474
475 Answer:
476 Only on Linux. No compilation on Windows (yet). The oldest Linux
477 kernel on which the BMF plugin was tested was version 2.4.18.
478
479
480 ---------
481 Question:
482 When starting OLSRD with the BMF plugin, I can see the following
483 error message:
484
485 OLSRD Basic Multicast Forwarding (BMF) plugin: error opening /dev/net/tun: No such file or directory
486
487 Wat to do?
488
489 Answer:
490 Turn on the possibility to create a tuntap interface; see section 2 of this
491 file.
492
493
494 ---------
495 Question:
496 When starting OLSRD with the BMF plugin, I can see the following
497 error message:
498
499 OLSRD Basic Multicast Forwarding (BMF) plugin: error opening /dev/net/tun: No such device
500
501 Wat to do?
502
503 Answer:
504 First, turn on the possibility to create a tuntap interface; see section 2 of this
505 file. Check if the device is there:
506  
507   ~ # ls -l /dev/net/tun
508   crw-------    1 root     root      10, 200 Sep  9  2006 /dev/net/tun
509
510 If the device is there, but the error message remains to appear, the
511 tap/tun device is not compiled in your kernel. Try the command:
512
513   modprobe tun
514
515 If "modprobe tun" says something like "modprobe: Can't locate module tun", then either
516 it is not compiled at all or it is not compiled into the kernel. 
517
518 Note: if you do not want to receive multicast packets, only forward the packets
519 that other hosts send, then you do not need the tuntap interface. This could be the
520 case if your host is purely an OLSR router; normally no traffic will be directed
521 to the router itself. In that case you can ignore this error message. Beware, though,
522 that you will then not be able to do the simple 'ping 224.0.0.1' test (as described in
523 section 4. How to check if it works) to check for the presence of all OLSR-BMF routers
524 in the network. 
525
526
527 ---------
528 Question:
529 I have enabled BMF, but my multicast application is not receiving any
530 multicast packets.
531
532 Answer:
533 Many multicast applications must be configured to listen to a specific
534 network interface. Make sure that your multicast application is listening on
535 the BMF network interface, either by specifying the interface name itself
536 (e.g. "bmf0") or by specifying its IP address.
537
538
539 10. Version history
540 -------------------
541
542 24 February 2008: Version 1.5.3
543
544 * Fixed a bug so that dying or dead end edges are not taken into account.
545   As of OLSRd version 0.5.4 , stale TC entries are not cleaned up, but
546   marked with a flag OLSR_TC_EDGE_DOWN. This flag was not taken into account
547   by BMF.
548
549 7 December 2007: Version 1.5.2
550
551 * Fixed a bug that would cause BMF to always send encapsulated broadcast
552   packets twice --> thanks to Frank Renwick and Joseph Giovatto for finding
553   this bug :-)
554 * Added the plugin parameters "BroadcastRetransmitCount" and "FanOutLimit";
555   thanks to Frank and Joe for the idea.
556
557 3 September 2007: Version 1.5.1
558
559 * Fixed a bug that would cause BMF to crash (and OLSR with it) if a link
560   was timing out --> thanks to Frank Renwick
561 * Fixed bug in the checking of the packet length --> thanks to Frank Renwick
562 * Fixed a bug in shutdown, which cause a crash if the BMF thread was not
563   yet running --> thanks to Bernd Petrovitsch
564 * Updated to OLSR plugin interface version 5.
565
566 16 May 2007: Version 1.5
567
568 * Improved packet history list to take into account the full 32 bits
569   of the packet fingerprint.
570   Previous versions derived a 16-bits value from the 32-bits packet
571   fingerprint and used that 16-bits value to determine packet unicity. In
572   situations with high packet rates (e.g. multicast video), this leads to
573   packets being incorrectly seen as duplicates of other, previously received
574   packets.
575
576 * New encapsulation format. In previous versions, a complete Ethernet
577   frame was encapsulated. This is unnecessary, and not very clean; e.g.
578   from packets coming in on non-Ethernet media such as PPP, the data in
579   the Ethernet header is bogus.
580   The new encapsulation format encapsulates only the IP packet. An
581   outer IP header [1], UDP header [2] and BMF Encapsulation Header are
582   inserted before the datagram's existing IP header, as follows:
583
584                                        +---------------------------+
585                                        |                           |
586                                        |      Outer IP Header      |
587                                        +---------------------------+
588                                        |                           |
589                                        |        UDP Header         |
590                                        +---------------------------+
591                                        |      BMF Encapsulation    |
592                                        |           Header          |
593    +---------------------------+       +---------------------------+
594    |                           |       |                           |
595    |         IP Header         |       |         IP Header         |
596    +---------------------------+ ====> +---------------------------+
597    |                           |       |                           |
598    |         IP Payload        |       |         IP Payload        |
599    |                           |       |                           |
600    |                           |       |                           |
601    +---------------------------+       +---------------------------+
602
603   The BMF encapsulation header has a typical type-length-value (TLV)
604   format:
605
606     0                   1                   2                   3
607     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
608    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
609    |     Type      |    Length     |            Reserved           |
610    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
611    |                       Packet fingerprint                      |
612    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
613
614    Type                1
615
616    Length              6.  Length in bytes of this extension, not
617                        including the Type and Length bytes.
618
619    Reserved            Reserved for future use. MUST be set to 0 on
620                        sending, MUST be verified as 0 on receipt;
621                        otherwise the extension must be handled as not
622                        understood and silently skipped.
623
624    Packet fingerprint  32-bits unique fingerprint inserted by the
625                        encapsulator. MAY be used by the receiver to
626                        determine duplicate packet reception.
627
628   The new encapsulation format is incompatible with those of previous
629   BMF versions, implying that all network nodes need to be updated.
630
631
632 31 Mar 2007: Version 1.4
633 * Optimized the standard forwarding mechanism in such a way that
634   retransmissions of packets are only done on those network interfaces
635   that make a host a multi-point relay (MPR) for the sender. I.e.:
636   retransmitting a packet on a network interface is not done if that
637   does not lead to any new hosts being reached.
638 * Optimized the standard forwarding mechanism such that, if the network
639   topology indicates there is only one neighbor on an interface, packets are
640   sent to the specific IP address (unicast) of that neighbor. If the network
641   topology indicates there are multiple neighbors, then BMF will still send
642   packets to the IP local-broadcast address.
643 * Introduced a new forwarding mechanism, using only IP-unicast to
644   forward packets. Packets are forwarded to the best candidate neighbor;
645   other neighbors listen promiscuously. IP-local broadcast is not used.
646   This saves air time on 802.11 WLAN networks, on which unicast packets are
647   usually sent at a much higher bit rate than broadcast packets (which are
648   sent at a basic bit rate).
649   This mechanism can be activated by specifying the following plugin
650   parameter:
651     PlParam "BmfMechanism" "UnicastPromiscuous"
652   See also section 6 - Advanced configuration.
653
654 18 Dec 2006: Version 1.3
655 * Added the possibility to configure the BMF network interface:
656   name (e.g. "bmf0"), type (tun or tap), IP address and subnet
657   mask.
658 * Flooding of local broadcast packets (e.g. with destination
659   IP address 192.168.1.255) can now be turned off by configuration.
660 * When an application sends packets to the BMF network interface, BMF
661   also floods these packets over the OLSR network.
662 * Removed the TTL decrementing so that equipment connected to
663   a non-OLSR interface can still send their IGMP messages (TTL = 1)
664   to a fixed multicast router (running e.g. mrouted - DVMRP)
665   connected to a non-OLSR interface on another host in
666   the OLSR network. In this way, a whole OLSR network, including
667   its non-OLSR capable hosts, can be made multicast-routable
668   from a fixed multicast-enabled IP network.
669   For an example of such a configuration read section 8 above.
670 * Removed the check for 'IsNullMacAddress' when creating a network
671   interface object. The check was not necessary and prevented
672   BMF to work on non-ethernet interfaces such as ppp.
673 * Bug fix: in case there are multiple OLSR interfaces, when an
674   application sends packets to one OLSR interface, BMF did not
675   flood these packets via the other OLSR interfaces. This is
676   fixed. Also, packets sent to an OLSR interface are transmitted
677   on the non-OLSR interfaces.
678
679 23 Oct 2006: Version 1.2
680 * Packets to a local broadcast destination have their destination
681   IP address adapted to the subnet on which they are forwarded.
682   This makes it possible to use broadcast-based services (such as
683   NetBIOS) across different IP subnets.
684 * The code to relate fragments with their main IP packet did not
685   work when the fragment arrived earlier than the main packet.
686   This would cause fragments of BMF-packets to be falsely forwarded.
687   For now, removed the forwarding of IP fragments. (Who's using
688   IP-fragments anyway?)
689 * Packets are forwarded from one non-OLSR interface to the other
690   non-OLSR interfaces.
691 * Various small optimizations and style improvements.
692
693 12 Jul 2006: Version 1.1
694 * Major updates in code forwarding from and to non-OLSR enabled
695   network interfaces.
696 * Debug level 9 gives a better indication of what happens to each
697   handled multicast/broadcast packet. To run the olsr daemon with
698   debug level 9, run "olsrd -d 9"; if you're only interested in
699   BMF debug messages, run "olsrd -d 9 | grep -i bmf".
700 * Can now deal with network interface removal ("ifdown eth1") and
701   addition ("ifup eth1").
702 * CRC-calculation for duplicate detection is done over first 256
703   bytes in packet instead of over full packet length.
704 * CRC calculated only on captured packets, and is subsequently
705   passed on in a special OLSR-BMF encapsulation header.
706 * Deals correctly with fragmented packets
707
708 27 Apr 2006: Version 1.0.1
709 * First release.
710
711
712 11. Normative References
713 ------------------------
714
715    [1]  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
716
717    [2]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
718         1980.
719