Added 4.4.3.2 Physical network deployment with RDPS

#### 4.4.3 Alternative deployments

As the rise in popularity to utilise hyperscalers and software defined everything in networking services, how we understand network structures depends on how we model those.

As the rise in popularity to utilise hyperscalers and software defined everything in networking services, how we understand network structures depends on how we model the connectivity.

The used protocols largely remains the same.

TCP and UDP dominates the network and trasport layers in the OSI-model.

DNS root servers are still trusted to point to the desired IP address and browser maintained TLS CA pool builds the trust on top of DNS being correct.

Encryption can be applied to transport layer, but is rarely seen due to computational requirements and higher cost and more complex management reasons.

Even with the emerging private networks popularised by the 5G slicing features, the transport layer rarely is fully encrypted throughout the private intranet sold for the service requesting users.

If the application needs assunrance on integrity, it needs to be responsible on encrypting its own traffic.

If somebody elses provided locks and keys are used to protect the house, there can be no certainty who can open up the door.

If the application needs assurance on integrity, it needs to be responsible on encrypting its own traffic.

If somebody else's provided locks and keys are used to protect the house, there can be no certainty who can open up the door.

Complex networks can be implemented and modeled through [how much RDPS](#4431-physical-network-deployment) is involved in the whole design or how everything can be [implemented in software](#4432-logical-network-deployment). These approaches are explained in the following use-cases.

Complex networks can be implemented and modeled through [how much RDPS](#4432-physical-network-deployment-with-rdps) is involved in the whole design or how everything can be [implemented in software](#4431-logical-network-deployment). These approaches are explained in the following use-cases.

#### 4.4.3.1 Physical network deployment

In fucntion of RDPS.

#### 4.4.3.2 Logical network deployment

#### 4.4.3.1 Logical network deployment

Early versions of Software Defined Networking (SDN) imitated the physical network structure by replacing the real-world devices with digital counterparts.

A SDN needed a IP subnetwork definition in order to hand out IP addresses with a DHCP from a switch.

This highly abstract and fluid control scheme can host emergency services critical information, nations polling results or a non-profit organisations read-only website.

Only the implementing entitys risk apetite sets the upper limit on what this structure can be used for.

#### 4.4.3.2 Physical network deployment with RDPS

When almost everything can be software, the minimum sill remains: the user needs to have some form of User Equipment to be able to connect.

This Network Interface can be a radio in the cellphone, a WiFi Access Point in the living room, or router with SFP+ ports serving the local datacenter.

How much the network strcutrue has autonomy on control and local network routing the device has can be modeled in function of how much RDPS is involved in the design.

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

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

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

The connection is handed over for RDPS as soon as possible.

The local network is used as little as possible, and even the home office routing can take a detour through RDPS in order to provide auditable trail of how the remote working employee is using the network.

With technologies like 5G slicing, the closest point of return in respect to re-routing back to your network could be the nearest basestation or it could be the squid proxy in other side of the world.

These two scenarios results to 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.4.3.2-2: Medium RDPS involvement](./media/2026-04-14_rdps_mid.drawio.png)

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

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

Part of the network design is created with virtual assets, that could be the new IT infrastructure for the latest accuired comapany, while the still significant portion of networking assets are tied to the headquarters datacenter.

Control strucures are different, device management strategies are varying, and even the physicality can extend to multiple nations.

The balance of owned assets and bought services is often selected due to ease of deployment, while the partial reliance on headquarters datacenter offers resilience towards major outages in the connectivity.

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

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

**Figure 4.4.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 spannign multiple locations for example.

Interconnection between the sites is either owned, or leased from a provider.

Some links can be through dedicated IP/MPLS tunnels, while some could be implemented through public connectivity with VPN tunnels. The RDPS mainly serves only update packages to the NMS, validates licensing if needed and can collect usage statistics for product development purposes.

While system updates are critical for the product, the installation is fully idenpendent and no functionality is relying on the RDPS connectivity. The system updates can be delivered with a removable medium, if no connectivity to software repositories is available.

## 4.5 Risk Factors

To address the risks of an NMS product prior a manufacturer's placing it on the market this standard encourages the manufacturer to threat model and risk profile of the use of the product, including its foreseeable uses, and considering the interplay between: