diff --git a/arednNetworkDesign/_images/01-mesh-topology.png b/arednNetworkDesign/_images/01-mesh-topology.png index 1802e0c..c69a074 100644 Binary files a/arednNetworkDesign/_images/01-mesh-topology.png and b/arednNetworkDesign/_images/01-mesh-topology.png differ diff --git a/arednNetworkDesign/_images/02-link-types.png b/arednNetworkDesign/_images/02-link-types.png index a11b26c..072c99c 100644 Binary files a/arednNetworkDesign/_images/02-link-types.png and b/arednNetworkDesign/_images/02-link-types.png differ diff --git a/arednNetworkDesign/_images/collocated-nodes.png b/arednNetworkDesign/_images/collocated-nodes.png index ad3a0f4..9e427ec 100644 Binary files a/arednNetworkDesign/_images/collocated-nodes.png and b/arednNetworkDesign/_images/collocated-nodes.png differ diff --git a/arednNetworkDesign/_images/dtd-linking.png b/arednNetworkDesign/_images/dtd-linking.png index f04ff8f..8c2b47d 100644 Binary files a/arednNetworkDesign/_images/dtd-linking.png and b/arednNetworkDesign/_images/dtd-linking.png differ diff --git a/arednNetworkDesign/_images/hidden-node.png b/arednNetworkDesign/_images/hidden-node.png index 32a5418..3eb6270 100644 Binary files a/arednNetworkDesign/_images/hidden-node.png and b/arednNetworkDesign/_images/hidden-node.png differ diff --git a/arednNetworkDesign/channel_planning.rst b/arednNetworkDesign/channel_planning.rst index 4e9f993..1256b37 100644 --- a/arednNetworkDesign/channel_planning.rst +++ b/arednNetworkDesign/channel_planning.rst @@ -70,26 +70,28 @@ The example coverage map shows that four different channels have been assigned t Collocated Nodes ---------------- +At some sites there may be several devices mounted on the same building or structure. This photo shows many nodes collocated on a mountaintop. + .. image:: _images/collocated-nodes.png :alt: Collocated Nodes - :align: right + :align: center -At some sites there may be several devices mounted on the same building or structure. The photo on the right shows many nodes collocated on a single tower. Network performance degradation can occur if these nodes share an RF band and channel. For example, when two sector antennas are collocated and share the same channel, the network throughput for that site will be reduced by half or more. If you have collocated nodes then it makes sense to allow the devices to pass traffic over their Ethernet interface (as described below) rather than forcing them to use their radio channel. +Network performance degradation can occur if these nodes share an RF band and channel. For example, when two sector antennas are collocated and share the same channel, the network throughput for that site will be reduced by half or more. If you have collocated nodes then it makes sense to allow the devices to pass traffic over their Ethernet interface (as described below) rather than forcing them to use their radio channel. Device to Device (DtD) Linking ++++++++++++++++++++++++++++++ In its most basic configuration for two collocated nodes, an Ethernet cable is connected between the PoE *LAN* port of each device. :abbr:`OLSR (Optimized Link State Routing protocol)` will assign a very low "link cost" (0.1) to the DtD connection and automatically route traffic between the nodes over Ethernet rather than causing the RF channel to become busy. -One added benefit of DtD linking is that you can link nodes which are operating on different bands and channels. Nodes that are using *Channel Separation* to segment traffic can still pass data at high speeds through their DtD link and be members of a single network. At a tower site like the one shown here, you could link 2.4 GHz and 5.8 GHz nodes to the same network. In fact, at a busy site like this it is best practice to use DtD linking, because otherwise RF channel contention could make the network unusable. - -Ideally you should configure your collocated nodes to use different bands and channels, then set up DtD links between the nodes to ensure that traffic is routed efficiently without generating RF contention or delays. :abbr:`OLSR (Optimized Link State Routing protocol)` will always choose the DtD path first when passing traffic between linked nodes. Each AREDN |trade| node recognizes incoming packets tagged with :abbr:`VLAN (Virtual Local Area Network)` 2 as DtD traffic. - .. image:: _images/dtd-linking.png :alt: DtD Linking - :align: center + :align: right -In the simple example above, the switch will share all traffic across all ports and every node will receive it on its DtD link. If you want to partition traffic even further, you can configure additional VLANs on the switch to isolate port traffic so that only the nodes which should receive specific traffic will see it. For example, you may have a video surveillance system (5) or a :abbr:`VoIP (Voice over IP)` PBX system (6), and traffic from those devices should only be passed to a specific set of links as shown in the diagram below. The port-based VLANs will ensure that traffic is controlled and routed, rather than being broadcast across every link. +One added benefit of DtD linking is that you can link nodes which are operating on different bands and channels. Nodes that are using *Channel Separation* to segment traffic can still pass data at high speeds through their DtD link and be members of a single network. At a tower site like the one shown here, you could link 2.4 GHz and 5.8 GHz nodes to the same network. In fact, at a busy site like this it is best practice to use DtD linking, because otherwise RF channel contention could make the network unusable. + +Ideally you should configure your collocated nodes to use different bands and channels, then set up DtD links between the nodes to ensure that traffic is routed efficiently without generating RF contention or delays. :abbr:`OLSR (Optimized Link State Routing protocol)` will always choose the DtD path first when passing traffic between linked nodes. Each AREDN |trade| node recognizes incoming packets tagged with :abbr:`VLAN (Virtual Local Area Network)` 2 as DtD traffic. In the simple example shown here, the switch will share all traffic across all ports and every node will receive it on its DtD link. + +If you want to partition traffic even further, you can configure VLANs on a managed switch to isolate port traffic so that only the nodes which should receive specific traffic will see it. For example, you may have a video surveillance system (5) or a :abbr:`VoIP (Voice over IP)` PBX system (6), and traffic from those devices should only be passed to a specific set of links as shown in the diagram below. The port-based VLANs will ensure that traffic is controlled and routed, rather than being broadcast across every link. .. image:: _images/vlan-isolation.png :alt: Traffic Isolation with VLANs @@ -120,7 +122,7 @@ Based on the purpose for your network, try to create reliable paths to the locat * If you need broad local coverage for a high profile area you can install sector antennas on a tower site: for example, three panels with 120 degree beam width each. DtD link the sectors at the tower site, and use different channels for each sector to avoid channel contention. -* Consider putting each local coverage area on its own channel to minimize the interaction between zones. +* Consider putting each local coverage area on its own channel to minimize the interaction between zones. Be sure to allow adequate RF separation between zones where channels are being reused. * If you are installing long distance point-to-point links to connect mesh islands, be sure to use a separate band or channel for the backbone link. This type of link has a single purpose: to carry as much data as quickly as possible from one end to the other. Eliminate any type of channel contention so that these links can achieve high throughput. diff --git a/arednNetworkDesign/network_topology.rst b/arednNetworkDesign/network_topology.rst index 6de6000..8eff334 100644 --- a/arednNetworkDesign/network_topology.rst +++ b/arednNetworkDesign/network_topology.rst @@ -2,11 +2,13 @@ Network Topologies ================== -Every AREDN |trade| node is capable of automatically joining an AREDN |trade| mesh network which is operating with the same SSID, channel, and bandwidth. A *Mesh* topology consists of independent nodes which each explore their surroundings by broadcasting their identity and listening for their neighbors' responses. Once nodes identify others within radio range, they share this information so that each node has a picture of the network topology. Periodic updates adjust the routes based on changes in signal quality or loss of a link, allowing the network to adapt to changing conditions. Since there are usually several possible routes between nodes, and since network disruptions typically effect only part of the network, a *Mesh* topology can be self-healing. +Every AREDN |trade| node is capable of automatically joining an AREDN |trade| mesh network which is operating with the same SSID, channel, and bandwidth. A *Mesh* topology consists of independent nodes which each explore their surroundings by broadcasting their identity and listening for their neighbors' responses. .. image:: _images/01-mesh-topology.png :alt: Mesh Topology - :align: center + :align: right + +Once nodes identify others within radio range, they share this information so that each node has a picture of the network topology. Periodic updates adjust the routes based on changes in signal quality or loss of a link, allowing the network to adapt to changing conditions. Since there are usually several possible routes between nodes, and since network disruptions typically effect only part of the network, a *Mesh* topology can be self-healing. This automatic ability to form a mesh network is built into the AREDN |trade| firmware on each node. Every node within radio range of other nodes will be able to participate in the network to extend its reach, provide route redundancy, or host services needed on the network at large. This basic network may serve its purpose perfectly for a short-term network deployment in support of a local event, or even for more permanent communication between nodes which are always within radio range. diff --git a/arednServicesGuide/chat_programs.rst b/arednServicesGuide/chat_programs.rst index 159a3fb..f482fee 100644 --- a/arednServicesGuide/chat_programs.rst +++ b/arednServicesGuide/chat_programs.rst @@ -27,7 +27,7 @@ Internet Relay Chat Several implementations of `Internet Relay Chat `_ are available, either as open source software or in proprietary versions. The Internet Relay Chat Daemon (IRCd) is a server program that listens for connections from IRC client programs and brokers the communication between the connected clients. With this client-server architecture, the IRC server must be available on a network link with sufficient bandwidth in order for the clients to function. -A wide variety of features and functions are available with these and similar chat programs, including various zones, channel types, and user roles. For additional information about IRC services, visit these links: `IRC Servers `_ and `IRC Clients `_ +A wide variety of features and functions are available with these and similar chat programs, including various zones, channel types, and user roles. For additional information about IRC services, visit `IRC Clients `_ .. image:: _images/irc.png :alt: IRC in KiwiChat Web Interface