mirror of
https://github.com/markqvist/Reticulum.git
synced 2024-12-23 04:10:18 +00:00
284 lines
15 KiB
HTML
284 lines
15 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
<html>
|
||
<head>
|
||
<meta charset="utf-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||
<title>Building Networks — Reticulum Network Stack 0.3.8 beta documentation</title>
|
||
<link rel="stylesheet" type="text/css" href="_static/pygments.css" />
|
||
<link rel="stylesheet" type="text/css" href="_static/classic.css" />
|
||
|
||
<script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script>
|
||
<script src="_static/jquery.js"></script>
|
||
<script src="_static/underscore.js"></script>
|
||
<script src="_static/doctools.js"></script>
|
||
|
||
<link rel="index" title="Index" href="genindex.html" />
|
||
<link rel="search" title="Search" href="search.html" />
|
||
<link rel="next" title="Supported Interfaces" href="interfaces.html" />
|
||
<link rel="prev" title="Using Reticulum on Your System" href="using.html" />
|
||
</head><body>
|
||
<div class="related" role="navigation" aria-label="related navigation">
|
||
<h3>Navigation</h3>
|
||
<ul>
|
||
<li class="right" style="margin-right: 10px">
|
||
<a href="genindex.html" title="General Index"
|
||
accesskey="I">index</a></li>
|
||
<li class="right" >
|
||
<a href="interfaces.html" title="Supported Interfaces"
|
||
accesskey="N">next</a> |</li>
|
||
<li class="right" >
|
||
<a href="using.html" title="Using Reticulum on Your System"
|
||
accesskey="P">previous</a> |</li>
|
||
<li class="nav-item nav-item-0"><a href="index.html">Reticulum Network Stack 0.3.8 beta documentation</a> »</li>
|
||
<li class="nav-item nav-item-this"><a href="">Building Networks</a></li>
|
||
</ul>
|
||
</div>
|
||
|
||
<div class="document">
|
||
<div class="documentwrapper">
|
||
<div class="bodywrapper">
|
||
<div class="body" role="main">
|
||
|
||
<div class="section" id="building-networks">
|
||
<span id="networks-main"></span><h1>Building Networks<a class="headerlink" href="#building-networks" title="Permalink to this headline">¶</a></h1>
|
||
<p>This chapter will provide you with the knowledge needed to build networks with
|
||
Reticulum, which can often be easier than using traditional stacks, since you
|
||
don’t have to worry about coordinating addresses, subnets and routing for an
|
||
entire network that you might not know how will evolve in the future. With
|
||
Reticulum, you can simply add more segments to your network when it becomes
|
||
necesarry, and Reticulum will handle the convergence of the entire network
|
||
automatically.</p>
|
||
<div class="section" id="concepts-overview">
|
||
<h2>Concepts & Overview<a class="headerlink" href="#concepts-overview" title="Permalink to this headline">¶</a></h2>
|
||
<p>There are important points that need to be kept in mind when building networks
|
||
with Reticulum:</p>
|
||
<blockquote>
|
||
<div><ul>
|
||
<li><div class="line-block">
|
||
<div class="line">In a Reticulum network, any node can autonomously generate as many adresses
|
||
(called <em>destinations</em> in Reticulum terminology) as it needs, which become
|
||
globally reachable to the rest of the network. There is no central point of
|
||
control over the adress space.</div>
|
||
</div>
|
||
</li>
|
||
<li><div class="line-block">
|
||
<div class="line">Reticulum was designed to handle both very small, and very large networks.
|
||
While the adress space can support billions of endpoints, Reticulum is
|
||
also very useful when just a few devices needs to communicate.</div>
|
||
</div>
|
||
</li>
|
||
<li><div class="line-block">
|
||
<div class="line">Low-bandwidth networks, like LoRa and packet radio, can interoperate and
|
||
interconnect with much larger and higher bandwidth networks without issue.
|
||
Reticulum automatically manages the flow of information to and from various
|
||
network segments, and when bandwidth is limited, local traffic is prioritised.</div>
|
||
</div>
|
||
</li>
|
||
<li><div class="line-block">
|
||
<div class="line">Reticulum provides sender/initiator anonymity by default. There is no way
|
||
to filter traffic or discriminate it based on the source of the traffic.</div>
|
||
</div>
|
||
</li>
|
||
<li><div class="line-block">
|
||
<div class="line">All traffic is encrypted using ephemeral keys generated by an Elliptic Curve
|
||
Diffie-Hellman key exchange on Curve25519. There is no way to inspect traffic
|
||
contents, and no way to prioritise or throttle certain kinds of traffic.
|
||
All transport and routing layers are thus completely agnostic to traffic type,
|
||
and will pass all traffic equally.</div>
|
||
</div>
|
||
</li>
|
||
<li><div class="line-block">
|
||
<div class="line">Reticulum can function both with and without infrastructure. When <em>transport
|
||
nodes</em> are available, they can route traffic over multiple hops for other
|
||
nodes, and will function as a distributed cryptographic keystore. When there
|
||
is no transport nodes available, all nodes that are within communication range
|
||
can still communicate.</div>
|
||
</div>
|
||
</li>
|
||
<li><div class="line-block">
|
||
<div class="line">Every node can become a transport node, simply by enabling it in it’s
|
||
configuration, but there is no need for every node on the network to be a
|
||
transport node. Letting every node be a transport node will in most cases
|
||
degrade the performance and reliability of the network.</div>
|
||
</div>
|
||
<blockquote>
|
||
<div><p><em>In general terms, if a node is stationary, well-connected and kept running
|
||
most of the time, it is a good candidate to be a transport node. For optimal
|
||
performance, a network should contain the amount of transport nodes that
|
||
provides connectivity to the intended area / topography, and not many more
|
||
than that.</em></p>
|
||
</div></blockquote>
|
||
</li>
|
||
<li><div class="line-block">
|
||
<div class="line">Reticulum is designed to work reliably in open, trustless environments. This
|
||
means you can use it to create open-access networks, where participants can
|
||
join and leave in an free and unorganised manner. This property allows an
|
||
entirely new, and so far, mostly unexplored class of networked applications,
|
||
where networks, and the information flow within them can form and dissolve
|
||
organically.</div>
|
||
</div>
|
||
</li>
|
||
<li><div class="line-block">
|
||
<div class="line">You can just as easily create closed networks, since Reticulum allows you to
|
||
add authentication to any interface. This means you can restrict access on
|
||
any interface type, even when using legacy devices, such as modems. You can
|
||
also mix authenticated and open interfaces on the same system. See the
|
||
<a class="reference internal" href="interfaces.html#interfaces-options"><span class="std std-ref">Common Interface Options</span></a> section of the <a class="reference internal" href="interfaces.html#interfaces-main"><span class="std std-ref">Interfaces</span></a>
|
||
chapter of this manual for information on how to set up interface authentication.</div>
|
||
</div>
|
||
</li>
|
||
</ul>
|
||
</div></blockquote>
|
||
<p>Reticulum allows you to mix very different kinds of networking mediums into a
|
||
unified mesh, or to keep everything within one medium. You could build a “virtual
|
||
network” running entirely over the Internet, where all nodes communicate over TCP
|
||
and UDP “channels”. You could also build such a network using other already-established
|
||
communications channels as the underlying carrier for Reticulum.</p>
|
||
<p>However, most real-world networks will probably involve either some form of
|
||
wireless or direct hardline communications. To allow Reticulum to communicate
|
||
over any type of medium, you must specify it in the configuration file, by default
|
||
located at <code class="docutils literal notranslate"><span class="pre">~/.reticulum/config</span></code>. See the <a class="reference internal" href="interfaces.html#interfaces-main"><span class="std std-ref">Supported Interfaces</span></a>
|
||
chapter of this manual for interface configuration examples.</p>
|
||
<p>Any number of interfaces can be configured, and Reticulum will automatically
|
||
decide which are suitable to use in any given situation, depending on where
|
||
traffic needs to flow.</p>
|
||
</div>
|
||
<div class="section" id="example-scenarios">
|
||
<h2>Example Scenarios<a class="headerlink" href="#example-scenarios" title="Permalink to this headline">¶</a></h2>
|
||
<p>This section illustrates a few example scenarios, and how they would, in general
|
||
terms, be planned, implemented and configured.</p>
|
||
<div class="section" id="interconnected-lora-sites">
|
||
<h3>Interconnected LoRa Sites<a class="headerlink" href="#interconnected-lora-sites" title="Permalink to this headline">¶</a></h3>
|
||
<p>An organisation wants to provide communication and information services to it’s
|
||
members, which are located mainly in three separate areas. Three suitable hill-top
|
||
locations are found, where the organisation can install equipment: Site A, B and C.</p>
|
||
<p>Since the amount of data that needs to be exchanged between users is mainly text-
|
||
based, the bandwidth requirements are low, and LoRa radios are chosen to connect
|
||
users to the network.</p>
|
||
<p>Due to the hill-top locations found, there is radio line-of-sight between site A
|
||
and B, and also between site B and C. Because of this, the organisation does not
|
||
need to use the Internet to interconnect the sites, but purchases four Point-to-Point
|
||
WiFi based radios for interconnecting the sites.</p>
|
||
<p>At each site, a Raspberry Pi is installed to function as a gateway. A LoRa radio
|
||
is connected to the Pi with a USB cable, and the WiFi radio is connected to the
|
||
ethernet port of the Pi. At site B, two WiFi radios are needed to be able to reach
|
||
both site A and site C, so an extra ethernet adapter is connected to the Pi in
|
||
this location.</p>
|
||
<p>Once the hardware has been installed, Reticulum is installed on all the Pis, and at
|
||
site A and C, one interface is added for the LoRa radio, as well as one for the WiFi
|
||
radio. At site B, an interface for the LoRa radio, and one interface for each WiFi
|
||
radio is added to the Reticulum configuration file. The transport node option is
|
||
enabled in the configuration of all three gateways.</p>
|
||
<p>The network is now operational, and ready to serve users across all three areas.
|
||
The organisation prepares a LoRa radio that is supplied to the end users, along
|
||
with a Reticulum configuration file, that contains the right parameters for
|
||
communicating with the LoRa radios installed at the gateway sites.</p>
|
||
<p>Once users connect to the network, anyone will be able to communicate with anyone
|
||
else across all three sites.</p>
|
||
</div>
|
||
<div class="section" id="bridging-over-the-internet">
|
||
<h3>Bridging Over the Internet<a class="headerlink" href="#bridging-over-the-internet" title="Permalink to this headline">¶</a></h3>
|
||
<p>As the organisation grows, several new communities form in places too far away
|
||
from the core network to be reachable over WiFi links. New gateways similar to those
|
||
previously installed are set up for the new communities at the new sites D and E, but
|
||
they are islanded from the core network, and only serve the local users.</p>
|
||
<p>After investigating the options, it is found that it is possible to install an
|
||
Internet connection at site A, and an interface on the Internet connection is
|
||
configured for Reticulum on the Raspberry Pi at site A.</p>
|
||
<p>A member of the organisation at site D, named Dori, is willing to help by sharing
|
||
the Internet connection she already has in her home, and is able to leave a Raspberry
|
||
Pi running. A new Reticulum interface is configured on her Pi, connecting to the newly
|
||
enabled Internet interface on the gateway at site A. Dori is now connected to both
|
||
all the nodes at her own local site (through the hill-top LoRa gateway), and all the
|
||
combined users of sites A, B and C. She then enables transport on her node, and
|
||
traffic from site D can now reach everyone at site A, B and C, and vice versa.</p>
|
||
</div>
|
||
<div class="section" id="growth-and-convergence">
|
||
<h3>Growth and Convergence<a class="headerlink" href="#growth-and-convergence" title="Permalink to this headline">¶</a></h3>
|
||
<p>As the organisation grows, more gateways are added to keep up with the growing user
|
||
base. Some local gateways even add VHF radios and packet modems to reach outlying users
|
||
and communities that are out of reach for the LoRa radios and WiFi backhauls.</p>
|
||
<p>As more sites, gateways and users are connected, the amount of coordination required
|
||
is kept to a minimum. If one community wants to add connectivity to the next one
|
||
over, it can simply be done without having to involve everyone or coordinate address
|
||
space or routing tables.</p>
|
||
<p>With the added geographical coverage, the operators at site A one day find that
|
||
the original internet bridged interfaces are no longer utilised. The network has
|
||
converged to be completely self-connected, and the sites that were once poorly
|
||
connected outliers are now an integral part of the network.</p>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
<div class="clearer"></div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
|
||
<div class="sphinxsidebarwrapper">
|
||
<h3><a href="index.html">Table of Contents</a></h3>
|
||
<ul>
|
||
<li><a class="reference internal" href="#">Building Networks</a><ul>
|
||
<li><a class="reference internal" href="#concepts-overview">Concepts & Overview</a></li>
|
||
<li><a class="reference internal" href="#example-scenarios">Example Scenarios</a><ul>
|
||
<li><a class="reference internal" href="#interconnected-lora-sites">Interconnected LoRa Sites</a></li>
|
||
<li><a class="reference internal" href="#bridging-over-the-internet">Bridging Over the Internet</a></li>
|
||
<li><a class="reference internal" href="#growth-and-convergence">Growth and Convergence</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
<h4>Previous topic</h4>
|
||
<p class="topless"><a href="using.html"
|
||
title="previous chapter">Using Reticulum on Your System</a></p>
|
||
<h4>Next topic</h4>
|
||
<p class="topless"><a href="interfaces.html"
|
||
title="next chapter">Supported Interfaces</a></p>
|
||
<div role="note" aria-label="source link">
|
||
<h3>This Page</h3>
|
||
<ul class="this-page-menu">
|
||
<li><a href="_sources/networks.rst.txt"
|
||
rel="nofollow">Show Source</a></li>
|
||
</ul>
|
||
</div>
|
||
<div id="searchbox" style="display: none" role="search">
|
||
<h3 id="searchlabel">Quick search</h3>
|
||
<div class="searchformwrapper">
|
||
<form class="search" action="search.html" method="get">
|
||
<input type="text" name="q" aria-labelledby="searchlabel" />
|
||
<input type="submit" value="Go" />
|
||
</form>
|
||
</div>
|
||
</div>
|
||
<script>$('#searchbox').show(0);</script>
|
||
</div>
|
||
</div>
|
||
<div class="clearer"></div>
|
||
</div>
|
||
<div class="related" role="navigation" aria-label="related navigation">
|
||
<h3>Navigation</h3>
|
||
<ul>
|
||
<li class="right" style="margin-right: 10px">
|
||
<a href="genindex.html" title="General Index"
|
||
>index</a></li>
|
||
<li class="right" >
|
||
<a href="interfaces.html" title="Supported Interfaces"
|
||
>next</a> |</li>
|
||
<li class="right" >
|
||
<a href="using.html" title="Using Reticulum on Your System"
|
||
>previous</a> |</li>
|
||
<li class="nav-item nav-item-0"><a href="index.html">Reticulum Network Stack 0.3.8 beta documentation</a> »</li>
|
||
<li class="nav-item nav-item-this"><a href="">Building Networks</a></li>
|
||
</ul>
|
||
</div>
|
||
<div class="footer" role="contentinfo">
|
||
© Copyright 2022, Mark Qvist.
|
||
Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 4.0.1.
|
||
</div>
|
||
</body>
|
||
</html> |