1  .. _networks-main:
  2  
  3  *****************
  4  Building Networks
  5  *****************
  6  
  7  This chapter will provide you with the knowledge needed to build networks with
  8  Reticulum, which can often be easier than using traditional stacks, since you
  9  don't have to worry about coordinating addresses, subnets and routing for an
 10  entire network that you might not know how will evolve in the future. With
 11  Reticulum, you can simply add more segments to your network when it becomes
 12  necessary, and Reticulum will handle the convergence of the entire network
 13  automatically.
 14  
 15  Concepts & Overview
 16  --------------------
 17  
 18  There are important points that need to be kept in mind when building networks
 19  with Reticulum:
 20  
 21   * | In a Reticulum network, any node can autonomously generate as many addresses
 22       (called *destinations* in Reticulum terminology) as it needs, which become
 23       globally reachable to the rest of the network. There is no central point of
 24       control over the address space.
 25  
 26   * | Reticulum was designed to handle both very small, and very large networks.
 27       While the address space can support billions of endpoints, Reticulum is
 28       also very useful when just a few devices needs to communicate.
 29  
 30   * | Low-bandwidth networks, like LoRa and packet radio, can interoperate and
 31       interconnect with much larger and higher bandwidth networks without issue.
 32       Reticulum automatically manages the flow of information to and from various
 33       network segments, and when bandwidth is limited, local traffic is prioritised.
 34  
 35   * | Reticulum provides sender/initiator anonymity by default. There is no way
 36       to filter traffic or discriminate it based on the source of the traffic.
 37  
 38   * | All traffic is encrypted using ephemeral keys generated by an Elliptic Curve
 39       Diffie-Hellman key exchange on Curve25519. There is no way to inspect traffic
 40       contents, and no way to prioritise or throttle certain kinds of traffic.
 41       All transport and routing layers are thus completely agnostic to traffic type,
 42       and will pass all traffic equally.
 43  
 44   * | Reticulum can function both with and without infrastructure. When *transport
 45       nodes* are available, they can route traffic over multiple hops for other
 46       nodes, and will function as a distributed cryptographic keystore. When there
 47       is no transport nodes available, all nodes that are within communication range
 48       can still communicate.
 49  
 50   * | Every node can become a transport node, simply by enabling it in it's
 51       configuration, but there is no need for every node on the network to be a
 52       transport node. Letting every node be a transport node will in most cases
 53       degrade the performance and reliability of the network.
 54  
 55       *In general terms, if a node is stationary, well-connected and kept running
 56       most of the time, it is a good candidate to be a transport node. For optimal
 57       performance, a network should contain the amount of transport nodes that
 58       provides connectivity to the intended area / topography, and not many more
 59       than that.*
 60  
 61   * | Reticulum is designed to work reliably in open, trustless environments. This
 62       means you can use it to create open-access networks, where participants can
 63       join and leave in a free and unorganised manner. This property allows an
 64       entirely new, and so far, mostly unexplored class of networked applications,
 65       where networks, and the information flow within them can form and dissolve
 66       organically.
 67  
 68   * | You can just as easily create closed networks, since Reticulum allows you to
 69       add authentication to any interface. This means you can restrict access on
 70       any interface type, even when using legacy devices, such as modems. You can
 71       also mix authenticated and open interfaces on the same system. See the
 72       :ref:`Common Interface Options<interfaces-options>` section of the :ref:`Interfaces<interfaces-main>`
 73       chapter of this manual for information on how to set up interface authentication.
 74  
 75  
 76  Reticulum allows you to mix very different kinds of networking mediums into a
 77  unified mesh, or to keep everything within one medium. You could build a "virtual
 78  network" running entirely over the Internet, where all nodes communicate over TCP
 79  and UDP "channels". You could also build such a network using other already-established
 80  communications channels as the underlying carrier for Reticulum.
 81  
 82  However, most real-world networks will probably involve either some form of
 83  wireless or direct hardline communications. To allow Reticulum to communicate
 84  over any type of medium, you must specify it in the configuration file, by default
 85  located at ``~/.reticulum/config``. See the :ref:`Supported Interfaces<interfaces-main>`
 86  chapter of this manual for interface configuration examples.
 87  
 88  Any number of interfaces can be configured, and Reticulum will automatically
 89  decide which are suitable to use in any given situation, depending on where
 90  traffic needs to flow.
 91  
 92  Example Scenarios
 93  -----------------
 94  
 95  This section illustrates a few example scenarios, and how they would, in general
 96  terms, be planned, implemented and configured.
 97  
 98  Interconnected LoRa Sites
 99  =========================
100  
101  An organisation wants to provide communication and information services to it's
102  members, which are located mainly in three separate areas. Three suitable hill-top
103  locations are found, where the organisation can install equipment: Site A, B and C.
104  
105  Since the amount of data that needs to be exchanged between users is mainly text-
106  based, the bandwidth requirements are low, and LoRa radios are chosen to connect
107  users to the network.
108  
109  Due to the hill-top locations found, there is radio line-of-sight between site A
110  and B, and also between site B and C. Because of this, the organisation does not
111  need to use the Internet to interconnect the sites, but purchases four Point-to-Point
112  WiFi based radios for interconnecting the sites.
113  
114  At each site, a Raspberry Pi is installed to function as a gateway. A LoRa radio
115  is connected to the Pi with a USB cable, and the WiFi radio is connected to the
116  Ethernet port of the Pi. At site B, two WiFi radios are needed to be able to reach
117  both site A and site C, so an extra Ethernet adapter is connected to the Pi in
118  this location.
119  
120  Once the hardware has been installed, Reticulum is installed on all the Pis, and at
121  site A and C, one interface is added for the LoRa radio, as well as one for the WiFi
122  radio. At site B, an interface for the LoRa radio, and one interface for each WiFi
123  radio is added to the Reticulum configuration file. The transport node option is
124  enabled in the configuration of all three gateways.
125  
126  The network is now operational, and ready to serve users across all three areas.
127  The organisation prepares a LoRa radio that is supplied to the end users, along
128  with a Reticulum configuration file, that contains the right parameters for
129  communicating with the LoRa radios installed at the gateway sites.
130  
131  Once users connect to the network, anyone will be able to communicate with anyone
132  else across all three sites.
133  
134  Bridging Over the Internet
135  ==========================
136  
137  As the organisation grows, several new communities form in places too far away
138  from the core network to be reachable over WiFi links. New gateways similar to those
139  previously installed are set up for the new communities at the new sites D and E, but
140  they are islanded from the core network, and only serve the local users.
141  
142  After investigating the options, it is found that it is possible to install an
143  Internet connection at site A, and an interface on the Internet connection is
144  configured for Reticulum on the Raspberry Pi at site A.
145  
146  A member of the organisation at site D, named Dori, is willing to help by sharing
147  the Internet connection she already has in her home, and is able to leave a Raspberry
148  Pi running. A new Reticulum interface is configured on her Pi, connecting to the newly
149  enabled Internet interface on the gateway at site A. Dori is now connected to both
150  the nodes at her own local site (through the hill-top LoRa gateway), and all the
151  combined users of sites A, B and C. She then enables transport on her node, and
152  traffic from site D can now reach everyone at site A, B and C, and vice versa.
153  
154  Growth and Convergence
155  ======================
156  
157  As the organisation grows, more gateways are added to keep up with the growing user
158  base. Some local gateways even add VHF radios and packet modems to reach outlying users
159  and communities that are out of reach for the LoRa radios and WiFi backhauls.
160  
161  As more sites, gateways and users are connected, the amount of coordination required
162  is kept to a minimum. If one community wants to add connectivity to the next one
163  over, it can simply be done without having to involve everyone or coordinate address
164  space or routing tables.
165  
166  With the added geographical coverage, the operators at site A one day find that
167  the original internet bridged interfaces are no longer utilised. The network has
168  converged to be completely self-connected, and the sites that were once poorly
169  connected outliers are now an integral part of the network.