Added Logical network deployment use-case

#### 4.6.3 Alternative deployments

As the use of extremely large scale network services, or hyperscalers, becomes increasingly popular and the networked services perform an ever greater number of software functions, how we understand network structures depends on how we model their connectivity. The following two use cases in sub chapters consider such deployment and other complex deployments primarily by focusing two approaches. These complex networks can be modeled by how the functions are virtualised in the network [4.4.3.1 Logical network deployment](#4431-logical-network-deployment) or examining how much RDPS is involved in the design [4.4.3.2 Physical network deployment with RDPS](#4432-physical-network-deployment-with-rdps).

As the use of extremely large scale network services, or hyperscalers, becomes increasingly popular and the networked services perform an ever greater number of software functions, how we understand network structures depends on how we model their connectivity.

The following two use cases in sub-chapters consider such deployment and other complex deployments primarily by focusing two approaches.

These complex networks can be modeled by how the functions are virtualised in the network [4.4.3.1 Logical network deployment](#4431-logical-network-deployment) or examining how much RDPS is involved in the design [4.4.3.2 Physical network deployment with RDPS](#4432-physical-network-deployment-with-rdps).

Yet, the protocols used for all network deployments remain consistent. TCP and UDP dominate the network and transport layers in the OSI-model. DNS root servers are still trusted to point to the desired IP address and browser maintained TLS CA pools build trust beyond that provided by the DNS.

Yet, the protocols used for all network deployments remain consistent.

TCP and UDP dominate the network and transport layers in the OSI-model.

DNS root servers are still trusted to point to the desired IP address and browser maintained TLS CA pools build trust beyond that provided by the DNS.

Encryption can be applied to the transport layer, but is rarely seen as it imposes increased computational requirements, higher cost, and more complex management. Even with the emerging private networks popularised by the 5G slicing features, the transport layer rarely is fully encrypted throughout a private intranet. Only in networks that need greater integrity assurance, does the network need to be responsible for encrypting its own traffic.

Encryption can be applied to the transport layer, but is rarely used in high traffic and low latency nodes as it imposes increased computational requirements, higher cost, and more complex management.

Even with the emerging private networks popularised by the 5G slicing features, the transport layer rarely is fully encrypted throughout a private intranet.

Only in networks that need greater integrity assurance, does the network need to be responsible for encrypting its own traffic.

#### 4.6.3.1 Logical network deployment

<mark>This could be about how wireguard nodes are configured manually and how they form the routing infrastructure that is built extending to tailscale. Similar setup to VPN. The content would be a prelude to RDPS stuff down below.</mark>

A traditional simple network design has a single device listening on incoming connections from public network facing port and allows selected traffic to pass through to subnets behind the device.

A mesh network can be a set of these devices, physical or virtual, where multiple subnetworks are interconnected together, and the routing design is many-to-many instead of point-to-point.

While it is often possible to manage the individual node configuration, and the authentication keys between the links, by hand, the configuration management becomes complex and error prone quite fast.

![From classic gateway to mesh networking](./media/4_logical_network_deployment.drawio.png)

**Figure 4.6.3.1-1: From classic gateway to mesh networking**

Mesh network routing can be made more accurate, if the services are listed as routing targets, and the subjects who would like to have connectivity to those targets are identified.

Combining the known locations of services and subjects connectivity grants, a custom routing table can be calculated for each subject.

This custom routing table can be enforced on network side by added layer of control, that either provisions configuration changes to connected nodes firewalls, or provides other mechanisms to assert the authority of the connection.

#### 4.6.3.2 Physical network deployment with RDPS

Inter-networking architecture with RDPS participating in the routing transforms a physical deployment into a logical deployment in the convergence point, which is the device installed into the site.

![Figure 4.6.3.2-1: Maximum RDPS involvement](./media/2026-04-14_rdps_max.drawio.png)

**Figure 4.6.3.2-1: Maximum RDPS involvement**

In figure the maximum RDPS involvement, the network design follows the hot potato design rule.

These two scenarios result in a different user experience where the latter would most likely show as slow and unresponsive service, but both are valid designs that can be deployed.

![Figure 4.6.3.2-2: Medium RDPS involvement](./media/2026-04-14_rdps_mid.drawio.png)

**Figure 4.6.3.2-2: Medium RDPS involvement**

Medium RDPS involvement is a common hybrid setup, where the company already has older assets that are grown into the enterprise, and are kept around as there is little or no need to change the infrastructure.

The end result might not be optimal, but often acceptable in the eyes of company risk management.

![Figure 4.6.3.2-3: Minimal RDPS involvement](./media/2026-04-14_rdps_min.drawio.png)

**Figure 4.6.3.2-3: Minimal RDPS involvement**

In a minimal RDPS involvement, all of the relevant infrastructure is not fulfilling the RDPS definition, and can be deployed to an underground infrastructure spanning multiple locations for example.