mirror of
https://github.com/markqvist/Reticulum.git
synced 2024-12-11 17:04:27 -05:00
170 lines
8.9 KiB
ReStructuredText
170 lines
8.9 KiB
ReStructuredText
.. _networks-main:
|
|
|
|
*****************
|
|
Building Networks
|
|
*****************
|
|
|
|
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.
|
|
|
|
Concepts & Overview
|
|
--------------------
|
|
|
|
There are important points that need to be kept in mind when building networks
|
|
with Reticulum:
|
|
|
|
* | In a Reticulum network, any node can autonomously generate as many adresses
|
|
(called *destinations* 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.
|
|
|
|
* | 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.
|
|
|
|
* | 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.
|
|
|
|
* | Reticulum provides sender/initiator anonymity by default. There is no way
|
|
to filter traffic or discriminate it based on the source of the traffic.
|
|
|
|
* | 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.
|
|
|
|
* | Reticulum can function both with and without infrastructure. When *transport
|
|
nodes* 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.
|
|
|
|
* | 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.
|
|
|
|
*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.*
|
|
|
|
* | 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.
|
|
|
|
* | 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
|
|
:ref:`Common Interface Options<interfaces-options>` section of the :ref:`Interfaces<interfaces-main>`
|
|
chapter of this manual for information on how to set up interface authentication.
|
|
|
|
|
|
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.
|
|
|
|
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 ``~/.reticulum/config``. See the :ref:`Supported Interfaces<interfaces-main>`
|
|
chapter of this manual for interface configuration examples.
|
|
|
|
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.
|
|
|
|
Example Scenarios
|
|
-----------------
|
|
|
|
This section illustrates a few example scenarios, and how they would, in general
|
|
terms, be planned, implemented and configured.
|
|
|
|
Interconnected LoRa Sites
|
|
=========================
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Once users connect to the network, anyone will be able to communicate with anyone
|
|
else across all three sites.
|
|
|
|
Bridging Over the Internet
|
|
==========================
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Growth and Convergence
|
|
======================
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|