One document matched: draft-chroboczek-babel-diversity-routing-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="no" ?>
<rfc category="exp" docName="draft-chroboczek-babel-diversity-routing-00"
     ipr="trust200902">
<front>
<title abbrev="Babel Diversity Routing">Diversity Routing for the Babel
Routing Protocol</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
<organization>PPS, University of Paris-Diderot</organization>
<address>
<postal>
<street>Case 7014</street>
<city>75205 Paris Cedex 13</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<email>jch@pps.univ-paris-diderot.fr</email>
</address>
</author>

<date day="4" month="July" year="2014"/>

<abstract>
<t>This document defines an extension to the Babel routing protocol that
allows routing updates to carry radio frequency information, and therefore
makes it possible to use radio diversity information for route
selection.</t>
</abstract>

</front>

<middle>

<section title="Introduction and background">

<t>The Babel routing protocol <xref target="BABEL"/> does not mandate
a specific algorithm for computing metrics; Appendix A of that document
suggests using an additive integer metric.  While this works well in many
topologies, it fails to take into account the possibility of interference
between radio links, which is important in multi-frequency wireless mesh
networks.</t>

<figure><preamble>Consider for example the following topology, where the
solid lines use one radio frequency and the dashed lines another, and
suppose that the solid frequency has very slightly lower packet loss than
the dashed one:</preamble>
<artwork><![CDATA[
   B
  / \
 /   \
A     D
 \   .
  \ .
   C
]]></artwork></figure>

<t>When sending data from A to D, Babel will reliably choose the solid
route through B.  Howerver, this route self-interferes: when B is sending
a packet to D, it cannot simultaneously be receiving a packet from A,
which halves the effective throughput.  No such issue arises with the
route through C, which should therefore be preferred.</t>

<figure><preamble>Interference needs to be taken into account even when it
happens between non-adjacent links.  Consider the following topology:
</preamble>
<artwork><![CDATA[
   B +++ C
  /       \
 /         \
A           F
 \         .
  \       .
   D +++ E
]]></artwork></figure>

<t>When routing data from A to F, the route through B and C has two
interfering links: if two packets are sent by A and C at roughly the same
time, a collision will occur, and both packets will need to be resent.
Again, no such issue arises with the route through D and E.</t>

</section>

<section title="Operation of the protocol">

<t>The diversity protocol extension allows a Babel router to attach
information about radio frequency to the routes that it maintains —
we call this the route's "diversity information".</t>

<t>We assume that all links can be categorised into one of the following
categories:
<list style="symbols">
<t>non-interfering links, e.g. wired links;</t>
<t>links that have a well defined frequency, and only interfere with other
links at the same frequency; these are described by a single channel
number, an integer between 1 and 254;</t>
<t>interfering links, links that interfere with all other links except
non-interfering links.</t>
</list></t>

<t>This model does not describe reality accurately, since distinct but
close radio frequencies do in fact interfere, but it works well enough in
practical networks, where a small number of discrete radio frequencies are
used.</t>

<section title="Changes to data structures">

<t>A Babel router maintains a route table (<xref target="BABEL"/> Section
3.2.5).  A router implementing diversity routing has one additional field
in every route table entry:
<list style="symbols">
<t> the diversity data, a (possibly zero-length) sequence of channel
numbers, each of which is an integer between 1 and 255.</t>
</list></t>
<t>The diversity data is interpreted as the set of channels of the links
that would be followed by a packet sent along this route, omitting
non-interfering links.  The value 255 is special — it indicates an
interfering link.</t>

</section>

<section title="Receiving updates">

<t>When a node receives an Update TLV, it creates or updates a routing
table entry according to <xref target="BABEL"/>, Section 3.5.4.  A node
that performs diversity routing extends the procedure given in that
section with the following procedure.</t>

<t>Let D be the diversity information attached to the received Update TLV,
or the one-element sequence 255 if there is no such information.  Then the
routing table entry diversity information is set to D', where:
<list style="symbols">
<t>if the interface over which the update was received is non-interfering,
then D'=D;</t>
<t>if the interface over which the update was received is tuned to channel
C, then D'=C.D;</t>
<t>if the interface over which the update was received is interfering,
then D'=255.D.</t>
</list></t>

<t>Note that zero-length diversity information is different from lack of
diversity information: the latter is treated as 255 (interfering, since no
information is available) in order to ensure interoperability with the
original Babel protocol.</t>

</section>

<section title="Sending updates">

<t>A Babel node sends updates in various circumstances, described in
<xref target="BABEL"/>, Section 3.7.  A node performing diversity routing
attaches diversity data to every update that it send.  This diversity data
is computed as follows:
<list style="symbols">
<t>if the update is for a locally redistributed route, then the value is
implementation-dependent (zero-length diversity information is a good
choice);</t>
<t>if the update is for a route in the Babel route table, then the
diversity information is taken from the route table.</t>
</list></t>

</section>

<section title="Metric computation and route selection">

<t>How the diversity data is used for metric computation and/or route
selection is left to the implementation, as long as it obeys the rules
given in Sections 3.5.2 and 3.6 of <xref target="BABEL"/>.  In particular,
the strict monotonicity requirement implies that a non-interfering hop
must be taken into account in the resulting metric — it cannot be simply
ignored.</t>

<t>An algorithm that has been found to work relatively well in practice is
given in <xref target="z3"/>.</t>

</section>

<section title="Protocol encoding">

<t>We define one new sub-TLV which is attached to Update TLVs and contains
a sequence of channel numbers.</t>

<section title="Encoding of channel numbers">

<t>A channel number is encoded as a one-octet integer.  The following
values are used by the current implementation:
<list style="hanging">
<t hangText="0">This value is reserved, MUST NOT be sent, and MUST be
silently filtered out on reception;</t>
<t hangText="1-14">IEEE 802.11b channels;</t>
<t hangText="36-165">IEEE 802.11a channels;</t>
<t hangText="255">used to represent an interfering link.</t>
</list></t>

<t>Other values are not currently used, and MAY be used by mutual
agreement to represent radio frequencies not covered by the above.</t>

</section>

<section title="The Diversity sub-TLV">

<t>Diversity data is carried in a Diversity sub-TLV <xref target="BABEL-EXT"/>
that is carried by Update TLVs.  The sub-TLV contains a sequence of octets
that directly encode the diversity data from the route table.</t>

<figure><artwork><![CDATA[
0                   1                   2                   3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 2   |    Length     |   Channel 1   |   Channel 2   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Channel 3   |  ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork></figure>

<t>Fields :
<list style="hanging" hangIndent="10">
<t hangText="Type">Set to 2 to indicate a Diversity Information sub-TLV.</t>
<t hangText="Length">The length of the body, exclusive of the Type and
Length fields.</t>
<t hangText="Channel n">A channel number, or 255 if the hop is assumed
to interfere with all other hops, as described in the previous section.</t>
</list></t>

</section>

</section>

</section>

</middle>

<back>

<references>

<reference anchor="BABEL"><front>
<title>The Babel Routing Protocol</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date month="February" year="2011"/>
</front>
<seriesInfo name="RFC" value="6126"/>
</reference>

<reference anchor="BABEL-EXT"><front>
<title>Extension Mechanism for the Babel Routing Protocol</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date day="30" month="June" year="2014"/>
</front>
<seriesInfo name="Internet Draft" value="draft-chroboczek-babel-extension-mechanism-01"/>
</reference>

</references>

<section title="The Z3 algorithm" anchor="z3">

<t>In this section, we describe the Z3 algorithm, a particular instance of
diversity routing that has seen some modest deployment and that appears to
work reasonably well in practice while being extremely easy to implement.</t>

<t>The Z3 algorithm works by announcing a slightly smaller metric than the
metric it uses for route selection when announcing over a non-interfering
link.  In effect, a Z3 router maintains two metrics for each route: the
noninterfering metric, which is announced on links that can be proven to
not interfere with the route being announced, and the interfering metric,
which is used for route selection and announced over all other links.</t>

<t>More precisely, upon receiving an update with metric M over a link with
cost C, the interfering metric is set to C+M, as suggested in Appendix
A of <xref target="BABEL"/>.  The non-interfering metric is set to
alpha*C+M, where 0<alpha<1 is called the diversity factor (with
rounding biased upwards in order to ensure strict monotonicity).</t>

<t>Let D be the diversity data of route R, and L be a link.  We say that
R interferes with L when one of the following is true:
<list style="symbols">
<t>L is a non-interfering link (e.g. an Ethernet); or</t>
<t>L is a radio interface tuned to channel C, and neither C nor 255 is an
element of D.</t>
</list></t>

<t>When we announce R over L, we announce the interfering metric if
R interferes with L, and the non-interfering metric otherwise.</t>

<t>The metric that Z3 yields is non-isotonic; hence, Z3 Babel does not
necessarily converge to a set of minimum-metric routes.  In fact, the set
of minimum-metric routes might not even be a tree in the general case.
The author believes that Z3 Babel converges to a Nash equilibrium, but
this appears to be a difficult property to prove.</t>

</section>

</back>
</rfc>