commits

commits@lists.open-mesh.org

1 participants
12425 discussions

[doc] batman-adv-doc, master: hop penalty and packet format added (3d3bd8aa)
by postmaster＠open-mesh.org 14 Dec '17

14 Dec '17

Repository : ssh://git@open-mesh.org/doc On branches: batman-adv-doc,master >--------------------------------------------------------------- commit 3d3bd8aa71697ff094b86402e1d2341c013c528c Author: Marek Lindner <lindner_marek(a)yahoo.de> Date: Thu Jan 1 16:24:13 2009 +0100 hop penalty and packet format added >--------------------------------------------------------------- 3d3bd8aa71697ff094b86402e1d2341c013c528c batman_iv.docbook | 100 ++++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 90 insertions(+), 10 deletions(-) diff --git a/batman_iv.docbook b/batman_iv.docbook index dbcb4a4c..e7d651e2 100644 --- a/batman_iv.docbook +++ b/batman_iv.docbook @@ -1,8 +1,8 @@ <?xml version="1.0" encoding="UTF-8" ?> <chapter id="batman_iv_tq"> -<title>B.A.T.M.A.N. IV/TQ Meshing</title> +<title>B.A.T.M.A.N. IV (TQ) Meshing</title> <sect1 id="batman3"> -<title>BATMAN III (introduction)</title> +<title>B.A.T.M.A.N. III (introduction)</title> <para> [RFC Introduction reused. I think we should do that - it is well @@ -25,7 +25,7 @@ </para> <sect2 id="how_works"> -<title>BATMAN III (brief overview)</title> +<title>B.A.T.M.A.N. III (brief overview)</title> <para> [RFC reused - 1.2. Protocol Overview (second paragraph)] @@ -68,7 +68,7 @@ [more text needed here ? we can add it later when we work on the IV advantages] - </para> +</para> </sect2> <sect2 id="multiple_interfaces"> <title>multiple interfaces</title> @@ -82,21 +82,73 @@ TODO Explain multiple interfaces, which interface sends which OGM by which TTL, </sect1> <sect1 id="batman4"> -<title>BATMAN IV/TQ</title> +<title>B.A.T.M.A.N. IV (TQ)</title> <para> The B.A.T.M.A.N. III algorithm has serious problems when it comes to asymetric links. The bidirectional link check tries to limit its impact but the result is far from being perfect. The timeframe in which B.A.T.M.A.N. accepts his own OGMs being rebroadcasted by its neighbor allows to tweak the behaviour. If this timeframe is rather short B.A.T.M.A.N. is very strict on choosing links. This may lead to many ignored links which might be usable in one direction. Only symetric connections will be considered. If the timeframe value is less strict B.A.T.M.A.N. will accept more links but tends to route in the wrong direction. </para> <para> - Example: OGMs from Node A propagate to B. The link is asymetric, therefore B receives all packets from A in contrast to A which receives almost nothing from B. As all the packets from A get to B the packet count at B's side goes up. B will assume that it has a perfect link towards A which is not the case. + Example: OGMs from Node A propagate to B. The link is asymetric, therefore B receives all packets from A in contrast to A which receives almost nothing from B. As all the packets from A get to B the packet count at B's side goes up. B will assume that it has a perfect link towards A which is not the case. <inlinemediaobject> - <imageobject> <imagedata fileref="images/asymetry.pdf" format="EPS" scale="50"/> </imageobject> - <imageobject> <imagedata fileref="images/asymetry.png" format="PNG" /> </imageobject> - <textobject> <phrase>asymetry illustration</phrase> </textobject> + <imageobject> <imagedata fileref="images/asymetry.pdf" format="EPS" scale="50"/> </imageobject> + <imageobject> <imagedata fileref="images/asymetry.png" format="PNG" /> </imageobject> + <textobject> <phrase>asymetry illustration</phrase> </textobject> </inlinemediaobject> </para> <para> - To overcome this flaw B.A.T.M.A.N. IV has been enhanced with the Transmit Quality (TQ) algorithm. The following section is going to outline its design and how it strengthens B.A.T.M.A.N.'s routing capabilities in asymetric environments. + To overcome this flaw B.A.T.M.A.N. IV has been enhanced with the Transmit Quality (TQ) algorithm. The following sections are going to outline its design and how it strengthens B.A.T.M.A.N.'s routing capabilities in asymetric environments. +</para> +<sect2 id="batman4_packet_layout"> +<title>The B.A.T.M.A.N. IV Orginator Message format</title> +<para> +<table> + <title>B.A.T.M.A.N. IV layer 3 packet format</title> + <tgroup cols="5"> + <colspec colnum="1" colname="colB" colwidth="1*"/> + <colspec colnum="2" colname="col0" colwidth="1*"/> + <colspec colnum="3" colname="col1" colwidth="1*"/> + <colspec colnum="4" colname="col2" colwidth="1*"/> + <colspec colnum="5" colname="col3" colwidth="1*"/> + <thead><row> + <entry>+</entry> + <entry>00</entry> + <entry>01</entry> + <entry>02</entry> + <entry>03</entry> + </row> + </thead> + <tbody> + <row> + <entry colname="colB">00-03</entry> + <entry namest="col0" nameend="col0">Version</entry> + <entry namest="col1" nameend="col1">Flags</entry> + <entry namest="col2" nameend="col2">TTL</entry> + <entry namest="col3" nameend="col3">GW Flags</entry> + </row> + <row> + <entry colname="colB">04-07</entry> + <entry namest="col0" nameend="col1">Seqence Number</entry> + <entry namest="col2" nameend="col3">GW Port</entry> + </row> + <row> + <entry colname="colB">08-11</entry> + <entry namest="col0" nameend="col3">Originator Address</entry> + </row> + <row> + <entry colname="colB">11-15</entry> + <entry namest="col0" nameend="col0">TQ</entry> + <entry namest="col1" nameend="col3">Old Originator Address</entry> + </row> + <row> + <entry colname="colB">16-19</entry> + <entry namest="col0" nameend="col0">Old Originator Address</entry> + <entry namest="col1" nameend="col3"> (...)</entry> + </row> + + </tbody> + </tgroup> + </table> </para> +</sect2> <sect2 id="batman4_tq"> <title>The Transmit Quality</title> <para> @@ -229,6 +281,27 @@ TODO Explain multiple interfaces, which interface sends which OGM by which TTL, <sect2 id="batman4_tq_hop_penalty"> <title>Hop penalty</title> <para> + B.A.T.M.A.N. IV loosens the strict packet drop policy used by B.A.T.M.A.N. III to make the TQ algorithm work. This introduces a new problem: In certain cases B.A.T.M.A.N. IV is unable to detect the 'real' source of an OGM which may lead to temporary routing loops. The following section is going to illustrate the issue and how it is going to be addressed using an Ethernet network as example for the sake of simplicity. WiFi and other mediums are less susceptible as Ethernet but still affected. +</para> +<para> + Example topology: The node SOURCE has a WiFi connection towards node A but no link to node B at all. Node A and node B are connected via Ethernet. We assume the Ethernet connection to be perfect (no packet loss) whereas the WiFi connection suffers from occasional collisions and interferences. [bild1 hier] +</para> +<para> + Whenever node A receives a packet via the WiFi connection it will rebroadcast the information on the Ethernet to inform neighbors nodes about the existance of the source node. Node B receive the broadcast and parses the packet before rebroadcasting it. At that point node A will receive that very packet again. [bild2] + + B.A.T.M.A.N. III would have dropped the packet at this point. It has a duplicate packet detection based on sequence numbers. The sequence number is known, hence the packet dropped (the fastest packet wins). In asymetric environments this may lead to suboptimal routing decisions. Therefore B.A.T.M.A.N. IV interprets the arrival of this packet as second path towards the originator. This path transmits the packet slower (due to more hops for example) but but may offer a better transmit quality. +</para> +<para> + On a lossy medium the TQ value is decreased while travelling from hop to hop (see asymetric link handling). The Ethernet connection does not suffer from packet loss which results in not decreasing the TQ value at all. Node A has 2 possible routes towards the originator: The SOURCE itself and node B (both will advertise the same TQ value). [bild3] + + As B.A.T.M.A.N. IV values TQ and fastest packet the node A's route will point towards the SOURCE node. Once the WiFi link quality drops (for a few moments due to some collisions) the TQ value from the SOURCE node will drop. At that point the B.A.T.M.A.N. IV node A will change its route towards node B which offers a better TQ value. Node A and node B will send packets forth and back in a loop. +</para> +<para> + To overcome this issue B.A.T.M.A.N. IV introduces a hop penalty: Every time an OGM passes a node the TQ value will be decreased by a fixed value regardless of the asymetric link penalty before rebroadcasting the packet. In the given example it decrease the value of the second route via node B. [bild???] +</para> +<para> + + The duplicate packet detection wont drop this packet because it was never received via this neighbor. It TODO There would be loops in "perfect" networks without loss, e.g. ethernet. <inlinemediaobject> <imageobject> <imagedata fileref="images/hop_penalty1.pdf" format="EPS" scale="50" /> </imageobject> @@ -253,5 +326,12 @@ TODO Explain multiple interfaces, which interface sends which OGM by which TTL, </para> </sect2> +<sect2 id="batman4_packet_aggregation"> +<title>Packet Aggregation</title> +<para> + TODO aggregate packets to reduce overhead and CPU cycles +</para> +</sect2> + </sect1> </chapter>

1 0

[doc] batman-adv-doc, master: fix typos, add illustrations for hop penalty (9dced641)
by postmaster＠open-mesh.org 14 Dec '17

14 Dec '17

Repository : ssh://git@open-mesh.org/doc On branches: batman-adv-doc,master >--------------------------------------------------------------- commit 9dced6419bb15f61a56079f7901b5fdcf0bb115b Author: Simon Wunderlich <siwu(a)hrz.tu-chemnitz.de> Date: Fri Jan 2 11:10:51 2009 +0100 fix typos, add illustrations for hop penalty >--------------------------------------------------------------- 9dced6419bb15f61a56079f7901b5fdcf0bb115b batman_iv.docbook | 43 ++++++++++++++++++++++++------------------- images/hop_penalty3.dia | Bin 0 -> 1297 bytes images/hop_penalty4.dia | Bin 0 -> 1448 bytes images/hop_penalty5.dia | Bin 0 -> 1328 bytes images/hop_penalty6.dia | Bin 0 -> 1453 bytes 5 files changed, 24 insertions(+), 19 deletions(-) diff --git a/batman_iv.docbook b/batman_iv.docbook index e7d651e2..cf05948c 100644 --- a/batman_iv.docbook +++ b/batman_iv.docbook @@ -252,7 +252,7 @@ TODO Explain multiple interfaces, which interface sends which OGM by which TTL, <para> <inlinemediaobject> <imageobject> <imagedata fileref="images/asym_link1.pdf" format="EPS" scale="50" /> </imageobject> - <imageobject> <imagedata fileref="images/asym_link1.png" format="PNG" /> </imageobject> + <imageobject> <imagedata fileref="images/asym_link1.png" format="PNG" scale="50" /> </imageobject> <textobject> <phrase>Asymetry situation without asymetry penalty</phrase> </textobject> </inlinemediaobject> </para> @@ -284,36 +284,41 @@ TODO Explain multiple interfaces, which interface sends which OGM by which TTL, B.A.T.M.A.N. IV loosens the strict packet drop policy used by B.A.T.M.A.N. III to make the TQ algorithm work. This introduces a new problem: In certain cases B.A.T.M.A.N. IV is unable to detect the 'real' source of an OGM which may lead to temporary routing loops. The following section is going to illustrate the issue and how it is going to be addressed using an Ethernet network as example for the sake of simplicity. WiFi and other mediums are less susceptible as Ethernet but still affected. </para> <para> - Example topology: The node SOURCE has a WiFi connection towards node A but no link to node B at all. Node A and node B are connected via Ethernet. We assume the Ethernet connection to be perfect (no packet loss) whereas the WiFi connection suffers from occasional collisions and interferences. [bild1 hier] + Example topology: The node SOURCE has a WiFi connection towards node A but no link to node B at all. Node A and node B are connected via Ethernet. We assume the Ethernet connection to be perfect (no packet loss) whereas the WiFi connection suffers from occasional collisions and interferences. + <inlinemediaobject> + <imageobject> <imagedata fileref="images/hop_penalty3.pdf" format="EPS" scale="50" /> </imageobject> + <imageobject> <imagedata fileref="images/hop_penalty3.png" format="PNG" /> </imageobject> + <textobject> <phrase>example topology</phrase> </textobject> + </inlinemediaobject> + </para> <para> - Whenever node A receives a packet via the WiFi connection it will rebroadcast the information on the Ethernet to inform neighbors nodes about the existance of the source node. Node B receive the broadcast and parses the packet before rebroadcasting it. At that point node A will receive that very packet again. [bild2] + Whenever node A receives a packet via the WiFi connection it will rebroadcast the information on the Ethernet to inform neighbor nodes about the existance of the source node. Node B receives the broadcast and parses the packet before rebroadcasting it. At that point node A will receive that very packet again. + <inlinemediaobject> + <imageobject> <imagedata fileref="images/hop_penalty4.pdf" format="EPS" scale="50" /> </imageobject> + <imageobject> <imagedata fileref="images/hop_penalty4.png" format="PNG" /> </imageobject> + <textobject> <phrase>packet hops</phrase> </textobject> + </inlinemediaobject> B.A.T.M.A.N. III would have dropped the packet at this point. It has a duplicate packet detection based on sequence numbers. The sequence number is known, hence the packet dropped (the fastest packet wins). In asymetric environments this may lead to suboptimal routing decisions. Therefore B.A.T.M.A.N. IV interprets the arrival of this packet as second path towards the originator. This path transmits the packet slower (due to more hops for example) but but may offer a better transmit quality. </para> <para> On a lossy medium the TQ value is decreased while travelling from hop to hop (see asymetric link handling). The Ethernet connection does not suffer from packet loss which results in not decreasing the TQ value at all. Node A has 2 possible routes towards the originator: The SOURCE itself and node B (both will advertise the same TQ value). [bild3] + <inlinemediaobject> + <imageobject> <imagedata fileref="images/hop_penalty5.pdf" format="EPS" scale="50" /> </imageobject> + <imageobject> <imagedata fileref="images/hop_penalty5.png" format="PNG" /> </imageobject> + <textobject> <phrase>route candidates</phrase> </textobject> + </inlinemediaobject> + As B.A.T.M.A.N. IV values TQ and fastest packet the node A's route will point towards the SOURCE node. Once the WiFi link quality drops (for a few moments due to some collisions) the TQ value from the SOURCE node will drop. At that point the B.A.T.M.A.N. IV node A will change its route towards node B which offers a better TQ value. Node A and node B will send packets forth and back in a loop. </para> <para> - To overcome this issue B.A.T.M.A.N. IV introduces a hop penalty: Every time an OGM passes a node the TQ value will be decreased by a fixed value regardless of the asymetric link penalty before rebroadcasting the packet. In the given example it decrease the value of the second route via node B. [bild???] -</para> -<para> - - The duplicate packet detection wont drop this packet because it was never received via this neighbor. It - TODO There would be loops in "perfect" networks without loss, e.g. ethernet. - <inlinemediaobject> - <imageobject> <imagedata fileref="images/hop_penalty1.pdf" format="EPS" scale="50" /> </imageobject> - <imageobject> <imagedata fileref="images/hop_penalty1.png" format="PNG" /> </imageobject> - <textobject> <phrase>no hop penalty</phrase> </textobject> - </inlinemediaobject> - - Explain hop penalty. + To overcome this issue B.A.T.M.A.N. IV introduces a hop penalty: Every time an OGM passes a node the TQ value will be decreased by a fixed value regardless of the asymetric link penalty before rebroadcasting the packet. In the given example it decrease the value of the second route via node B. <inlinemediaobject> - <imageobject> <imagedata fileref="images/hop_penalty2.pdf" format="EPS" scale="50" /> </imageobject> - <imageobject> <imagedata fileref="images/hop_penalty2.png" format="PNG" /> </imageobject> - <textobject> <phrase>hop penalty applied</phrase> </textobject> + <imageobject> <imagedata fileref="images/hop_penalty6.pdf" format="EPS" scale="50" /> </imageobject> + <imageobject> <imagedata fileref="images/hop_penalty6.png" format="PNG" /> </imageobject> + <textobject> <phrase>applied hop penalty</phrase> </textobject> </inlinemediaobject> </para> diff --git a/images/hop_penalty3.dia b/images/hop_penalty3.dia new file mode 100644 index 00000000..26672e09 Binary files /dev/null and b/images/hop_penalty3.dia differ diff --git a/images/hop_penalty4.dia b/images/hop_penalty4.dia new file mode 100644 index 00000000..5f093c01 Binary files /dev/null and b/images/hop_penalty4.dia differ diff --git a/images/hop_penalty5.dia b/images/hop_penalty5.dia new file mode 100644 index 00000000..0e8d83a8 Binary files /dev/null and b/images/hop_penalty5.dia differ diff --git a/images/hop_penalty6.dia b/images/hop_penalty6.dia new file mode 100644 index 00000000..e002f695 Binary files /dev/null and b/images/hop_penalty6.dia differ

1 0

[doc] batman-adv-doc,master: initial commit (311f820a)
by postmaster＠open-mesh.org 14 Dec '17

14 Dec '17

Repository : ssh://git@open-mesh.org/doc On branches: batman-adv-doc,master >--------------------------------------------------------------- commit 311f820a30aea098d9a2839ff3474bd8e1f64fc0 Author: Simon Wunderlich <dotslash(a)prime.dot.net> Date: Sat Jul 5 16:52:55 2008 +0200 initial commit >---------------------------------------------------------------

1 0

[doc] batman-adv-doc, master: add batman IV content (5b3867ec)
by postmaster＠open-mesh.org 14 Dec '17

14 Dec '17

Repository : ssh://git@open-mesh.org/doc On branches: batman-adv-doc,master >--------------------------------------------------------------- commit 5b3867ec25c6033869a72144531960124f1c7f68 Author: Marek <marek(a)openmoko.com> Date: Wed Aug 20 16:04:44 2008 +0800 add batman IV content >--------------------------------------------------------------- 5b3867ec25c6033869a72144531960124f1c7f68 batman_iv.docbook | 94 ++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 86 insertions(+), 8 deletions(-) diff --git a/batman_iv.docbook b/batman_iv.docbook index 21d48170..85688d9c 100644 --- a/batman_iv.docbook +++ b/batman_iv.docbook @@ -2,16 +2,72 @@ <chapter id="batman_iv_tq"> <title>B.A.T.M.A.N. IV/TQ Meshing</title> <sect1 id="batman3"> -<title>BATMAN III</title> +<title>BATMAN III (introduction)</title> <para> -TODO What is BATMAN III, where was it implemented first? + + [RFC Introduction reused. I think we should do that - it is well + written. I would even mention that the RFC introduction has been reused.] + + B.A.T.M.A.N. is a proactive routing protocol for Wireless Ad-hoc Mesh + Networks, including (but not limited to) Mobile Ad-hoc Networks + (MANETs). The protocol proactively maintains information about the + existence of all nodes in the mesh that are accessible via single-hop + or multi-hop communication links. The strategy of B.A.T.M.A.N. is to + determine for each destination in the mesh one single-hop neighbor, + which can be utilized as best gateway to communicate with the + destination node. In order to perform multi-hop IP-based routing, + the routing table of a node must contain a link-local gateway for + each host or network route. To learn about the best next-hop for + each destination is all that the B.A.T.M.A.N. algorithm cares about. + There is no need to find out or calculate the complete route, which + makes a very fast and efficient implementation possible. + </para> <sect2 id="how_works"> -<title>BATMAN III</title> +<title>BATMAN III (brief overview)</title> +<para> + + [RFC reused - 1.2. Protocol Overview (second paragraph)] + + On a regular basis every B.A.T.M.A.N. node broadcasts an originator + message (or OGM), thereby informing its link-local neighbors about + its existence (first step). Link-local neighbors which are receiving the + Originator messages are relaying them by rebroadcasting it, according + to specific B.A.T.M.A.N. forwarding rules. The B.A.T.M.A.N. mesh + network is therefore flooded with Originator messages. This flooding + process will be performed by single-hop neighbors in the second step, + by two-hop neighbors in the third step, and so forth. OGMs are send + and repeated as UDP broadcasts, therefore OGMs are flooded until + every node has received it at least once, or until they got lost due + to packet loss of communication links, or until their TTL (time to + live) value has expired. In practise OGM packet loss caused by + interference, collision or congestion is significant. The number of + OGMs received from a given Originator via each link-local neighbor is + used to estimate the quality of a (single-hop or multi-hop) route. + In order to be able to find the best route to a certain Originator, + B.A.T.M.A.N counts the originator-messages received and logs which + link-local neighbor relayed the message. Using this information + B.A.T.M.A.N. maintains a table with the best link-local router + towards every Originator on the network. By using a sequence number, + embedded in each OGM, B.A.T.M.A.N. can distinguish between new + Originator message packets and duplicates ensuring that every OGM + gets only counted once. + +</para> <para> -TODO How does batman III work (briefly, explain bidirectional link checks etc) -Explain how asymetric links are handled (or rather not handled). + [new text! - may be put this into a different subsection (asymetric links)?] + + Unlike wired networks, WiFi setups often face the problem of asymetric + links (Node A has a better connection towards Node B than vice versa). + To ensure that the detected connections allow communication in both + directions each B.A.T.M.A.N. node awaits rebroadcasts of its own OGMs + from his neighbors within a certain timeframe (bidirectional link check). + If the OGMs are not successfully retransmitted the connection is + considered asymetric and therefore ignored. + + [more text needed here ? we can add it later when we work on the IV advantages] + </para> </sect2> <sect2 id="multiple_interfaces"> @@ -19,18 +75,40 @@ Explain how asymetric links are handled (or rather not handled). <para> TODO Explain multiple interfaces, which interface sends which OGM by which TTL, and why. (Maybe move this section somewhere else ... ) + +==> why explaining this in this document ? I would refer them to the RFC because this did not change with IV. </para> </sect2> </sect1> <sect1 id="batman4"> <title>BATMAN IV/TQ</title> +<para> + The B.A.T.M.A.N. III algorithm has serious problems when it comes to asymetric links. The bidirectional link check tries to limit its impact but the result is far from being perfect. The timeframe in which B.A.T.M.A.N. accepts his own OGMs being rebroadcasted by its neighbor allows to tweak the behaviour. If this timeframe is rather short B.A.T.M.A.N. is very strict on choosing links. This may lead to many ignored links which might be usable in one direction. Only symetric connections will be considered. If the timeframe value is less strict B.A.T.M.A.N. will accept more links but tends to route in the wrong direction. +</para> +<para> + Example: OGMs from Node A propagate to B. The link is asymetric, therefore B receives all packets from A in contrast to A which receives almost nothing from B. As all the packets from A get to B the packet count at B's side goes up. B will assume that it has a perfect link towards A which is not the case. [illustration needed] +</para> +<para> + To overcome this flaw B.A.T.M.A.N. IV has been enhanced with the Transmit Quality (TQ) algorithm. The following section is going to outline its design and how it strengthens B.A.T.M.A.N.'s routing capabilities in asymetric environments. +</para> <sect2 id="batman4_tq"> <title>The Transmit Quality</title> <para> -TODO BATMAN uses "receive quality", by counting packets, but should use/calculate - "transmit quality". Send metric (tq) with batman packets. -[ illustration: ... ] + B.A.T.M.A.N. IV divides a given link quality into 2 distinct parts: receiving link quality and transmit link quality. The receiving link quality expresses the propability of a successfull packet transmission towards the node. The transmit link quality describes the probability of a successful transmission towards a neighbor node. Obviously, B.A.T.M.A.N. is more interested in the transmit link quality as the receiving link quality can't be used to influence the routing decision. +</para> +<para> + As explained in the previous section the packet counting floods the network with receiving link quality rather than transmit link quality. On the link-local level the transmit link quality can be derived from the receiving link quality by applying some calculations on the packet count. + + <orderedlist> + <listitem><para>B.A.T.M.A.N. knows the receiving link quality (RQ) by counting the packets of its neighbors.</para></listitem> + <listitem><para>B.A.T.M.A.N. knows the echo link quality (EQ) by counting rebroadcasts of its own OGMs from his neighbors.</para></listitem> + <listitem><para>B.A.T.M.A.N. can calculate the transmit link quality (TQ) by dividing the echo link quality by the receiving link quality.</para></listitem> + </orderedlist> + + As shown above B.A.T.M.A.N. IV is able to retrieve the local transmit quality by using the same mechanisms as B.A.T.M.A.N. III without adding further overhead. + +[4 illustrations needed (for each list item and one for the tq alone)] </para> </sect2> <sect2 id="batman4_tq_prop">

1 0

[doc] batman-adv-doc, master: more IV stuff added (7b28efdc)
by postmaster＠open-mesh.org 14 Dec '17

14 Dec '17

Repository : ssh://git@open-mesh.org/doc On branches: batman-adv-doc,master >--------------------------------------------------------------- commit 7b28efdc973cff12853b2bff791375f8b265fb15 Author: Marek <marek(a)openmoko.com> Date: Sun Aug 24 03:34:02 2008 +0800 more IV stuff added >--------------------------------------------------------------- 7b28efdc973cff12853b2bff791375f8b265fb15 batman_iv.docbook | 40 ++++++++++++++++++++++++++++++++++------ bookinfo.docbook | 2 +- 2 files changed, 35 insertions(+), 7 deletions(-) diff --git a/batman_iv.docbook b/batman_iv.docbook index 85688d9c..0540c2ac 100644 --- a/batman_iv.docbook +++ b/batman_iv.docbook @@ -64,7 +64,7 @@ directions each B.A.T.M.A.N. node awaits rebroadcasts of its own OGMs from his neighbors within a certain timeframe (bidirectional link check). If the OGMs are not successfully retransmitted the connection is - considered asymetric and therefore ignored. + considered too asymetric (unusable) and therefore ignored. [more text needed here ? we can add it later when we work on the IV advantages] @@ -106,7 +106,7 @@ TODO Explain multiple interfaces, which interface sends which OGM by which TTL, <listitem><para>B.A.T.M.A.N. can calculate the transmit link quality (TQ) by dividing the echo link quality by the receiving link quality.</para></listitem> </orderedlist> - As shown above B.A.T.M.A.N. IV is able to retrieve the local transmit quality by using the same mechanisms as B.A.T.M.A.N. III without adding further overhead. + As shown above B.A.T.M.A.N. IV is able to retrieve the local transmit quality by using the same mechanisms as B.A.T.M.A.N. III without adding further overhead. [4 illustrations needed (for each list item and one for the tq alone)] </para> @@ -114,11 +114,33 @@ TODO Explain multiple interfaces, which interface sends which OGM by which TTL, <sect2 id="batman4_tq_prop"> <title>Transmit Quality Propagation</title> <para> -TODO Each node decreases TQ-field before rebroadcasting the packet. -Explain how it is done (multiple neihgbours, average over time). -[ illustration: simple setup with multiple hops] + The local link quality needs to be propagated throughout the network to inform other nodes about the transmit quality. Therefore B.A.TM.A.N. IV introduces a new field called "TQ" which is 1 byte long. This field is added to the known B.A.T.M.A.N. III packet. Whenever the OGM is generated this field is set to maximum length (256) before it is broadcasted. The receiving neighbor will calculate their own local link quality into the received TQ value and rebroadcast the packet. Hence, every node receiving a packet knows about the transmit quality towards the originator node. +</para> +<para> + To add the local link quality in the TQ value the following calculation is performed: TQ incoming * local TQ towards this node / TQ max. +</para> +<para> + Example: Node A broadcasts the packet with TQ max. Node B receives it, applies the TQ calculation and rebroadcasts it. When node C gets the packet it knows about the transmit quality towards node A. [illustration needed] +</para> +</sect2> + +<sect2 id="batman4_local_global_tq"> +<title>local TQ vs global TQ</title> +<para> + A B.A.T.M.A.N. IV node has to keep track of 2 different TQ values: + <orderedlist> + <listitem><para>The local TQ which represents the transmit quality towards every single hop neighbor (retrieved via the packet count plus TQ calculation).</para></listitem> + <listitem><para>The global link quality which describes the link quality towards every multi hop neighbor (received via B.A.T.M.A.N. IV packets).</para></listitem> + </orderedlist> +</para> +<para> + The calculation for the local TQ needs the OGM packet count of the neigbor and the own OGM packet count rebroadcasted by that very neighbor. Therefore a B.A.T.M.A.N. node has keep track of received packets over a certain interval. The slinding window size of these statistics is called TQ_LOCAL_WINDOW_SIZE. [what else shoud be mentioned here ?] +</para> +<para> + The global TQ is an average of all received TQ values from one originator via a distinct neighbor. Packets with a TQ value of 0 also count as non-received packets. B.A.T.M.A.N. IV uses a sliding window size (TQ_GLOBAL_WINDOW_SIZE) greater than 1 [dat muss noch schöner ...] </para> </sect2> + <sect2 id="batman4_tq_asymetry"> <title>Handling asymetric links</title> <para> @@ -132,7 +154,7 @@ TODO Also calculate the receive direction - but weight it. </sect2> <sect2 id="batman4_tq_hop_penalty"> -<title>Hop penalty - for ethernet networks</title> +<title>Hop penalty</title> <para> TODO There would be loops in "perfect" networks without loss, e.g. ethernet. [ illustration: triangle A,B,C with perfect links ] @@ -141,6 +163,12 @@ TODO Also calculate the receive direction - but weight it. </para> </sect2> +<sect2 id="batman4_tq_echo_cancellation"> +<title>Echo cancellation</title> +<para> + TODO rebroadcast cancellation by adding IP of previous node because we don't drop packets +</para> +</sect2> </sect1> </chapter> diff --git a/bookinfo.docbook b/bookinfo.docbook index ad2e8037..902ed474 100644 --- a/bookinfo.docbook +++ b/bookinfo.docbook @@ -17,7 +17,7 @@ <abstract> <para> - This Document should give detailed information about the B.A.T.M.A.N. advnced + This Document should give detailed information about the B.A.T.M.A.N. advanced algorithm, data types, packets and implementation. This is a DRAFT, do not refer or cite to this document. </para>

1 0

[doc] batman-adv-doc, master: add first illustration and infrastructure for png/eps (cf94e907)
by postmaster＠open-mesh.org 14 Dec '17

14 Dec '17

Repository : ssh://git@open-mesh.org/doc On branches: batman-adv-doc,master >--------------------------------------------------------------- commit cf94e907a4a30b6c3a6d91209c2bc4c126c538a5 Author: Simon Wunderlich <siwu(a)hrz.tu-chemnitz.de> Date: Mon Aug 25 16:57:27 2008 +0200 add first illustration and infrastructure for png/eps Illustrations are done in dia (vector editing program) and then converted to png (for html) and eps (for pdf). The eps output looks bad on my system, that's hopefully just a bug over here... :( >--------------------------------------------------------------- cf94e907a4a30b6c3a6d91209c2bc4c126c538a5 Makefile | 6 +++++- batman_iv.docbook | 7 ++++++- images/Makefile | 17 +++++++++++++++++ images/asymetry.dia | Bin 0 -> 1396 bytes 4 files changed, 28 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 3f2f1c9f..b25f1e3d 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,11 @@ default: all all: batman_doc -batman_doc: Makefile *.docbook +.PHONY: clean images +batman_doc: Makefile *.docbook images docbook2html batman.docbook docbook2pdf batman.docbook +images: + make -C images/ clean: rm -rf *.html *.pdf + make -C images clean diff --git a/batman_iv.docbook b/batman_iv.docbook index 0540c2ac..e9e0472c 100644 --- a/batman_iv.docbook +++ b/batman_iv.docbook @@ -87,7 +87,12 @@ TODO Explain multiple interfaces, which interface sends which OGM by which TTL, The B.A.T.M.A.N. III algorithm has serious problems when it comes to asymetric links. The bidirectional link check tries to limit its impact but the result is far from being perfect. The timeframe in which B.A.T.M.A.N. accepts his own OGMs being rebroadcasted by its neighbor allows to tweak the behaviour. If this timeframe is rather short B.A.T.M.A.N. is very strict on choosing links. This may lead to many ignored links which might be usable in one direction. Only symetric connections will be considered. If the timeframe value is less strict B.A.T.M.A.N. will accept more links but tends to route in the wrong direction. </para> <para> - Example: OGMs from Node A propagate to B. The link is asymetric, therefore B receives all packets from A in contrast to A which receives almost nothing from B. As all the packets from A get to B the packet count at B's side goes up. B will assume that it has a perfect link towards A which is not the case. [illustration needed] + Example: OGMs from Node A propagate to B. The link is asymetric, therefore B receives all packets from A in contrast to A which receives almost nothing from B. As all the packets from A get to B the packet count at B's side goes up. B will assume that it has a perfect link towards A which is not the case. +<inlinemediaobject> + <imageobject> <imagedata fileref="images/asymetry" format="EPS" /> </imageobject> + <imageobject> <imagedata fileref="images/asymetry.png" format="PNG" /> </imageobject> + <textobject> <phrase>asymetry illustration</phrase> </textobject> +</inlinemediaobject> </para> <para> To overcome this flaw B.A.T.M.A.N. IV has been enhanced with the Transmit Quality (TQ) algorithm. The following section is going to outline its design and how it strengthens B.A.T.M.A.N.'s routing capabilities in asymetric environments. diff --git a/images/Makefile b/images/Makefile new file mode 100644 index 00000000..627d1354 --- /dev/null +++ b/images/Makefile @@ -0,0 +1,17 @@ +DIA_IMAGES=asymetry.dia +PNG_IMAGES=$(DIA_IMAGES:.dia=.png) +EPS_IMAGES=$(DIA_IMAGES:.dia=.eps) + +.PHONY: clean +.SUFFIXES: .dia .png .eps + +default: all +all: $(EPS_IMAGES) $(PNG_IMAGES) + +.dia.png: + /usr/bin/dia -e $@ $< +.dia.eps: + /usr/bin/dia -e $@ $< + +clean: + rm *.png *.eps diff --git a/images/asymetry.dia b/images/asymetry.dia new file mode 100644 index 00000000..9cc362bc Binary files /dev/null and b/images/asymetry.dia differ

1 0

[doc] batman-adv-doc, master: Include figures als scalable image in pdf (ac03def1)
by postmaster＠open-mesh.org 14 Dec '17

14 Dec '17

Repository : ssh://git@open-mesh.org/doc On branches: batman-adv-doc,master >--------------------------------------------------------------- commit ac03def174a45f6fc970a9189d8310042df5f4e5 Author: Sven Eckelmann <sven.eckelmann(a)gmx.de> Date: Mon Aug 25 21:11:49 2008 +0200 Include figures als scalable image in pdf docbook2pdf (or the latex backend) will not include eps files in pdf and will choose the png file instead. To get the image displayed, we will need to set the parameter format to EPS - even when this seems to be wrong. >--------------------------------------------------------------- ac03def174a45f6fc970a9189d8310042df5f4e5 Makefile | 2 +- batman_iv.docbook | 2 +- images/Makefile | 10 ++++++---- 3 files changed, 8 insertions(+), 6 deletions(-) diff --git a/Makefile b/Makefile index b25f1e3d..09946e1e 100644 --- a/Makefile +++ b/Makefile @@ -7,5 +7,5 @@ batman_doc: Makefile *.docbook images images: make -C images/ clean: - rm -rf *.html *.pdf + rm -f *.html *.pdf *.log *.refs make -C images clean diff --git a/batman_iv.docbook b/batman_iv.docbook index e9e0472c..68838ce3 100644 --- a/batman_iv.docbook +++ b/batman_iv.docbook @@ -89,7 +89,7 @@ TODO Explain multiple interfaces, which interface sends which OGM by which TTL, <para> Example: OGMs from Node A propagate to B. The link is asymetric, therefore B receives all packets from A in contrast to A which receives almost nothing from B. As all the packets from A get to B the packet count at B's side goes up. B will assume that it has a perfect link towards A which is not the case. <inlinemediaobject> - <imageobject> <imagedata fileref="images/asymetry" format="EPS" /> </imageobject> + <imageobject> <imagedata fileref="images/asymetry.pdf" format="EPS" /> </imageobject> <imageobject> <imagedata fileref="images/asymetry.png" format="PNG" /> </imageobject> <textobject> <phrase>asymetry illustration</phrase> </textobject> </inlinemediaobject> diff --git a/images/Makefile b/images/Makefile index 627d1354..ace4a975 100644 --- a/images/Makefile +++ b/images/Makefile @@ -1,17 +1,19 @@ DIA_IMAGES=asymetry.dia PNG_IMAGES=$(DIA_IMAGES:.dia=.png) -EPS_IMAGES=$(DIA_IMAGES:.dia=.eps) +PDF_IMAGES=$(DIA_IMAGES:.dia=.pdf) .PHONY: clean -.SUFFIXES: .dia .png .eps +.SUFFIXES: .dia .png .eps .pdf default: all -all: $(EPS_IMAGES) $(PNG_IMAGES) +all: $(PDF_IMAGES) $(PNG_IMAGES) .dia.png: /usr/bin/dia -e $@ $< .dia.eps: /usr/bin/dia -e $@ $< +.eps.pdf: + /usr/bin/epstopdf --outfile=$@ $< clean: - rm *.png *.eps + rm -f *.png *.eps *.pdf

1 0

[doc] batman-adv-doc, master: add most of the proposed illustrations (3c39bd49)
by postmaster＠open-mesh.org 14 Dec '17

14 Dec '17

Repository : ssh://git@open-mesh.org/doc On branches: batman-adv-doc,master >--------------------------------------------------------------- commit 3c39bd4919c0a663694b90647fd6cfdadf399ec9 Author: Simon Wunderlich <siwu(a)hrz.tu-chemnitz.de> Date: Tue Sep 2 16:29:28 2008 +0200 add most of the proposed illustrations >--------------------------------------------------------------- 3c39bd4919c0a663694b90647fd6cfdadf399ec9 batman_iv.docbook | 69 +++++++++++++++++++++++++++++++++++++++++------- images/Makefile | 16 ++++++++--- images/asym_link1.dia | Bin 0 -> 1359 bytes images/asym_link2.dia | Bin 0 -> 1385 bytes images/asym_penalty.gp | 19 +++++++++++++ images/eq.dia | Bin 0 -> 1219 bytes images/hop_penalty1.dia | Bin 0 -> 1841 bytes images/hop_penalty2.dia | Bin 0 -> 1865 bytes images/rq.dia | Bin 0 -> 1143 bytes images/tq.dia | Bin 0 -> 1161 bytes 10 files changed, 90 insertions(+), 14 deletions(-) diff --git a/batman_iv.docbook b/batman_iv.docbook index 68838ce3..565fe797 100644 --- a/batman_iv.docbook +++ b/batman_iv.docbook @@ -89,7 +89,7 @@ TODO Explain multiple interfaces, which interface sends which OGM by which TTL, <para> Example: OGMs from Node A propagate to B. The link is asymetric, therefore B receives all packets from A in contrast to A which receives almost nothing from B. As all the packets from A get to B the packet count at B's side goes up. B will assume that it has a perfect link towards A which is not the case. <inlinemediaobject> - <imageobject> <imagedata fileref="images/asymetry.pdf" format="EPS" /> </imageobject> + <imageobject> <imagedata fileref="images/asymetry.pdf" format="EPS" scale="50"/> </imageobject> <imageobject> <imagedata fileref="images/asymetry.png" format="PNG" /> </imageobject> <textobject> <phrase>asymetry illustration</phrase> </textobject> </inlinemediaobject> @@ -106,14 +106,38 @@ TODO Explain multiple interfaces, which interface sends which OGM by which TTL, As explained in the previous section the packet counting floods the network with receiving link quality rather than transmit link quality. On the link-local level the transmit link quality can be derived from the receiving link quality by applying some calculations on the packet count. <orderedlist> - <listitem><para>B.A.T.M.A.N. knows the receiving link quality (RQ) by counting the packets of its neighbors.</para></listitem> - <listitem><para>B.A.T.M.A.N. knows the echo link quality (EQ) by counting rebroadcasts of its own OGMs from his neighbors.</para></listitem> - <listitem><para>B.A.T.M.A.N. can calculate the transmit link quality (TQ) by dividing the echo link quality by the receiving link quality.</para></listitem> + <listitem> + <para>B.A.T.M.A.N. knows the receiving link quality (RQ) by counting the packets of its neighbors.</para> + <para> + <inlinemediaobject> + <imageobject> <imagedata fileref="images/rq.pdf" format="EPS" scale="50" /> </imageobject> + <imageobject> <imagedata fileref="images/rq.png" format="PNG" /> </imageobject> + <textobject> <phrase>Receive Quality (RQ)</phrase> </textobject> + </inlinemediaobject></para> + </listitem> + <listitem> + <para>B.A.T.M.A.N. knows the echo link quality (EQ) by counting rebroadcasts of its own OGMs from his neighbors.</para> + <para> + <inlinemediaobject> + <imageobject> <imagedata fileref="images/eq.pdf" format="EPS" scale="50" /> </imageobject> + <imageobject> <imagedata fileref="images/eq.png" format="PNG" /> </imageobject> + <textobject> <phrase>Echo Link Quality (EQ)</phrase> </textobject> + </inlinemediaobject></para> + </listitem> + <listitem> + <para>B.A.T.M.A.N. can calculate the transmit link quality (TQ) by dividing the echo link quality by the receiving link quality.</para> + <para> + <inlinemediaobject> + <imageobject> <imagedata fileref="images/tq.pdf" format="EPS" scale="50" /> </imageobject> + <imageobject> <imagedata fileref="images/tq.png" format="PNG" /> </imageobject> + <textobject> <phrase>Transmit Link Quality (TQ)</phrase> </textobject> + </inlinemediaobject></para> + </listitem> </orderedlist> As shown above B.A.T.M.A.N. IV is able to retrieve the local transmit quality by using the same mechanisms as B.A.T.M.A.N. III without adding further overhead. - [4 illustrations needed (for each list item and one for the tq alone)] +[??? what kind of 4th illustration? put the formular in a picture, or in the text?] </para> </sect2> <sect2 id="batman4_tq_prop"> @@ -151,10 +175,25 @@ TODO Explain multiple interfaces, which interface sends which OGM by which TTL, <para> TODO Only transmit quality is not enough - nothing worth if the receive direction is too bad to receive WIFI acks. -[ illustration: bad situation :) ] + <inlinemediaobject> + <imageobject> <imagedata fileref="images/asym_link1.pdf" format="EPS" scale="50" /> </imageobject> + <imageobject> <imagedata fileref="images/asym_link1.png" format="PNG" /> </imageobject> + <textobject> <phrase>Asymetry situation without asymetry penalty</phrase> </textobject> + </inlinemediaobject> + + TODO Also calculate the receive direction - but weight it. -[ illustration: how to weight (graph of 1 - (1-x) **3)] -[ illustration: bad situation after using asym penalty ] + <inlinemediaobject> + <imageobject> <imagedata fileref="images/asym_penalty.pdf" format="EPS" /> </imageobject> + <imageobject> <imagedata fileref="images/asym_penalty.png" format="PNG" /> </imageobject> + <textobject> <phrase>graph for asymetry penalty</phrase> </textobject> + </inlinemediaobject> + + <inlinemediaobject> + <imageobject> <imagedata fileref="images/asym_link2.pdf" format="EPS" scale="50" /> </imageobject> + <imageobject> <imagedata fileref="images/asym_link2.png" format="PNG" /> </imageobject> + <textobject> <phrase>Asymetry situation with applied asymetry penalty</phrase> </textobject> + </inlinemediaobject> </para> </sect2> @@ -162,9 +201,19 @@ TODO Also calculate the receive direction - but weight it. <title>Hop penalty</title> <para> TODO There would be loops in "perfect" networks without loss, e.g. ethernet. - [ illustration: triangle A,B,C with perfect links ] + <inlinemediaobject> + <imageobject> <imagedata fileref="images/hop_penalty1.pdf" format="EPS" scale="50" /> </imageobject> + <imageobject> <imagedata fileref="images/hop_penalty1.png" format="PNG" /> </imageobject> + <textobject> <phrase>no hop penalty</phrase> </textobject> + </inlinemediaobject> + Explain hop penalty. - [ illustration: triangle A,B,C after hop penalty ] + <inlinemediaobject> + <imageobject> <imagedata fileref="images/hop_penalty2.pdf" format="EPS" scale="50" /> </imageobject> + <imageobject> <imagedata fileref="images/hop_penalty2.png" format="PNG" /> </imageobject> + <textobject> <phrase>hop penalty applied</phrase> </textobject> + </inlinemediaobject> + </para> </sect2> diff --git a/images/Makefile b/images/Makefile index ace4a975..ae167d56 100644 --- a/images/Makefile +++ b/images/Makefile @@ -1,13 +1,21 @@ -DIA_IMAGES=asymetry.dia -PNG_IMAGES=$(DIA_IMAGES:.dia=.png) -PDF_IMAGES=$(DIA_IMAGES:.dia=.pdf) +GP_IMAGES=asym_penalty.gp +DIA_IMAGES=asymetry.dia tq.dia eq.dia rq.dia hop_penalty1.dia hop_penalty2.dia asym_link1.dia asym_link2.dia +PNG_IMAGES= $(DIA_IMAGES:.dia=.png) +PNG_IMAGES+=$(GP_IMAGES:.gp=.png) +PDF_IMAGES= $(DIA_IMAGES:.dia=.pdf) +PDF_IMAGES+=$(GP_IMAGES:.gp=.pdf) .PHONY: clean -.SUFFIXES: .dia .png .eps .pdf +.SUFFIXES: .dia .png .eps .pdf .gp default: all all: $(PDF_IMAGES) $(PNG_IMAGES) +.gp.png: + gnuplot $< +.gp.eps: + gnuplot $< + .dia.png: /usr/bin/dia -e $@ $< .dia.eps: diff --git a/images/asym_link1.dia b/images/asym_link1.dia new file mode 100644 index 00000000..497b785d Binary files /dev/null and b/images/asym_link1.dia differ diff --git a/images/asym_link2.dia b/images/asym_link2.dia new file mode 100644 index 00000000..ce1953c1 Binary files /dev/null and b/images/asym_link2.dia differ diff --git a/images/asym_penalty.gp b/images/asym_penalty.gp new file mode 100644 index 00000000..8ed0e6b0 --- /dev/null +++ b/images/asym_penalty.gp @@ -0,0 +1,19 @@ +#!/usr/bin/gnuplot +set title "Asymetry Penalty illustration" +set xlabel "Receive Quality (RQ)" +set ylabel "applied Asymetry Penalty" +set xrange [0:1] +set yrange [0:1] +set grid + +set terminal png +set output "asym_penalty.png" + +plot (1 - (1-x) ** 3) title "asymetry penalty 1 - (1-x)^3",\ + x title "receive quality" + +set terminal postscript eps enhanced color solid +set output "asym_penalty.eps" + +plot (1 - (1-x) ** 3) title "asymetry penalty 1 - (1-x)^3",\ + x title "receive quality" diff --git a/images/eq.dia b/images/eq.dia new file mode 100644 index 00000000..2a694864 Binary files /dev/null and b/images/eq.dia differ diff --git a/images/hop_penalty1.dia b/images/hop_penalty1.dia new file mode 100644 index 00000000..ce0d584c Binary files /dev/null and b/images/hop_penalty1.dia differ diff --git a/images/hop_penalty2.dia b/images/hop_penalty2.dia new file mode 100644 index 00000000..0a926e44 Binary files /dev/null and b/images/hop_penalty2.dia differ diff --git a/images/rq.dia b/images/rq.dia new file mode 100644 index 00000000..99ba6c97 Binary files /dev/null and b/images/rq.dia differ diff --git a/images/tq.dia b/images/tq.dia new file mode 100644 index 00000000..1ee4c056 Binary files /dev/null and b/images/tq.dia differ

1 0

[batman-adv-doc] master: batman-adv-doc: Convert to sphinx documentation format (d80ed69)
by postmaster＠open-mesh.org 14 Dec '17

14 Dec '17

Repository : ssh://git@open-mesh.org/batman-adv-doc On branch : master >--------------------------------------------------------------- commit d80ed6979508073c2560745a9b3b250842b1ec62 Author: Sven Eckelmann <sven(a)narfation.org> Date: Thu Dec 14 15:59:17 2017 +0100 batman-adv-doc: Convert to sphinx documentation format The documentation is currently converted to Sphinx. Parts of this legacy document will also be used in the new documentation. It is therefore necessary to have both in a common format. Signed-off-by: Sven Eckelmann <sven(a)narfation.org> >--------------------------------------------------------------- .gitattributes | 4 + .gitignore | 9 +- Makefile | 244 ++++++++-- README | 29 +- batman.docbook | 24 - batman_adv.docbook | 377 --------------- batman_adv/index.rst | 250 ++++++++++ batman_iv.docbook | 509 --------------------- {images => batman_iv}/asym_link1.dia | 0 batman_iv/asym_link1.svg | 34 ++ {images => batman_iv}/asym_link2.dia | 0 batman_iv/asym_link2.svg | 34 ++ {images => batman_iv}/asym_penalty.gp | 4 +- batman_iv/asym_penalty.svg | 254 ++++++++++ {images => batman_iv}/asymetry.dia | 0 batman_iv/asymetry.svg | 39 ++ {images => batman_iv}/echo_cancel1.dia | 0 batman_iv/echo_cancel1.svg | 68 +++ {images => batman_iv}/echo_cancel2.dia | 0 batman_iv/echo_cancel2.svg | 72 +++ {images => batman_iv}/eq_alt1.dia | 0 batman_iv/eq_alt1.svg | 22 + {images => batman_iv}/hop_penalty_new1.dia | 0 batman_iv/hop_penalty_new1.svg | 51 +++ {images => batman_iv}/hop_penalty_new2.dia | 0 batman_iv/hop_penalty_new2.svg | 51 +++ batman_iv/index.rst | 429 +++++++++++++++++ {images => batman_iv}/multi_interface_1.dia | 0 batman_iv/multi_interface_1.svg | 53 +++ {images => batman_iv}/multi_interface_2.dia | 0 batman_iv/multi_interface_2.svg | 53 +++ {images => batman_iv}/rq.dia | 0 batman_iv/rq.svg | 22 + {images => batman_iv}/tq.dia | 0 batman_iv/tq.svg | 22 + {images => batman_iv}/tq_prop.dia | 0 batman_iv/tq_prop.svg | 79 ++++ {images => batman_iv}/tq_prop_best1.dia | 0 batman_iv/tq_prop_best1.svg | 43 ++ {images => batman_iv}/tq_prop_best2.dia | 0 batman_iv/tq_prop_best2.svg | 71 +++ {images => batman_iv}/tq_prop_best3.dia | 0 batman_iv/tq_prop_best3.svg | 63 +++ batman_iv_only.docbook | 17 - batmand.docbook | 428 ----------------- {images => batmand}/announce_networks.dia | 0 batmand/announce_networks.svg | 33 ++ batmand/index.rst | 468 +++++++++++++++++++ {images => batmand}/multiple_announces.dia | 0 batmand/multiple_announces.svg | 43 ++ {images => batmand}/multiple_clients.dia | 0 batmand/multiple_clients.svg | 36 ++ bookinfo.docbook | 39 -- conf.py | 338 ++++++++++++++ copyright.docbook | 10 - images/Makefile | 51 --- images/asym_penalty_formula.tex | 6 - images/compute_tq.tex | 6 - images/eq.dia | 265 ----------- images/eq_alt2.dia | 242 ---------- images/eq_alt3.dia | 242 ---------- images/hop_penalty1.dia | 686 ---------------------------- images/hop_penalty2.dia | 686 ---------------------------- images/hop_penalty3.dia | 339 -------------- images/hop_penalty4.dia | 420 ----------------- images/hop_penalty5.dia | 359 --------------- images/hop_penalty6.dia | 420 ----------------- images/tq_prop_calc.tex | 6 - index.rst | 36 ++ introduction.docbook | 0 references.docbook | 8 - 71 files changed, 2893 insertions(+), 5201 deletions(-) Diff suppressed because of size. To see it, use: git diff-tree --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc d80ed6979508073c2560745a9b3b250842b1ec62

1 0

[linux-merge]linux integration; annotated tag, v4.15-rc3, created. v4.15-rc3
by postmaster＠open-mesh.org 11 Dec '17

11 Dec '17

The annotated tag, v4.15-rc3 has been created at fa0dd402a43dd6a02af9f3b8690bc1c9d4090a26 (tag) tagging 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36 (commit) replaces v4.15-rc2 tagged by Linus Torvalds on Sun Dec 10 17:56:35 2017 -0800 - Shortlog ------------------------------------------------------------ Linux 4.15-rc3 -----BEGIN PGP SIGNATURE----- iQEcBAABAgAGBQJaLeXTAAoJEHm+PkMAQRiGA9EH/36KP3vBbsJ6gvaQP8i3d0eS VH0MWr7GajRcr82f5x1RnDE2hPeUj/T38Gealnsaz3YZMbxjMulc09UiwUHpeTFu h9Spp9dgJPAesOzwZ0AWQzqUA7eckiid6XOyoWfQielbK02uI48IeJJPO9Rf6Q3r AlxN8ufMMqs3edIRw3U64GEyH77Vn6eUrk4xX0SdYlL/XFXIrV2ud/k3QyIOh9L/ z87HgTc2oY4z104YcAJjCaOp38hAd6SLn3UPMg0A3Ao4/1nZKqXhpqnXkNTWc058 MJeYNs+wXWiglF7jzYTYXwdV1kDr6pYYmHdaSOZ7AMS2mmplklX1uOqSG3DhYCY= =v+z2 -----END PGP SIGNATURE----- ----------------------------------------------------------------------- -- linux integration

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits