A disaggregated BNG can place subscriber forwarding near the access network while operating control functions elsewhere. That becomes valuable when the placement improves the network economics or a large fleet benefits from shared control capacity. It also creates a distributed system whose state and failures need explicit ownership.
Separate control and forwarding software is only the starting point. The investment decision is whether independently deployed planes solve a measurable problem large enough to justify their interfaces, transport dependencies and operating model.
Process separation and CUPS are different boundaries
A single appliance can run its control plane and data plane as separate processes. The control plane authenticates subscribers, applies policy and manages sessions. The data plane forwards packets using installed state. Process separation lets those workloads use different implementation and scheduling choices without requiring a network between them.
Netavo uses this model: a .NET control plane and C data plane run on one box and share memory. The data plane can keep forwarding installed state if the control-plane process restarts. That describes forwarding independence, not a guarantee that every subscriber protocol session survives restart recovery unchanged.
Netavo is a single-appliance architecture. It is not a disaggregated BNG or CUPS product and does not implement TR-459. Its process boundary should be evaluated on those terms.
CUPS, control/user-plane separation, makes the planes independently deployable. The Broadband Forum's TR-459 family addresses control and user plane separation for a disaggregated BNG. A procurement discussion needs the applicable issue and supported capabilities, rather than treating the report number as a complete interoperability guarantee.
| Decision | Separate processes on one appliance | Independently deployed CUPS planes |
|---|---|---|
| Placement | Control and forwarding share a host | Control and forwarding can occupy different sites |
| State exchange | Local mechanisms, including shared memory | A defined network interface and reconciliation model |
| Scaling | Appliance capacity and local resource allocation | Potentially separate control and forwarding capacity |
| Failure planning | Process, host and site failures | Those failures plus control transport partitions |
| Operations | Per-appliance lifecycle | Coordinated controller, user-plane and interface lifecycle |
Placement must deliver a concrete benefit
Consider a network with many access regions but only a few operational centres. Local user planes may keep subscriber traffic close to peering, content or regional services. A central control estate may avoid placing a full control stack at each small location.
Compare that with deploying complete appliances at those same locations. Both designs can put forwarding near subscribers. The CUPS case must explain what independent control placement adds: better utilisation, a different staffing model, easier fleet-wide changes or another measurable benefit.
Map traffic before choosing. If every regional user plane still sends all traffic to a central service chain, distributing it may save little transport. If local breakout removes expensive backhaul, quantify that saving separately from any benefit attributed to centralised control.
Small fleets can often meet placement requirements with complete appliances and consistent configuration. As the number of sites grows, common control becomes more attractive, but scale alone is insufficient. Subscriber behaviour, admission rates, geographic constraints and operational maturity determine the threshold.
State ownership is the first hard question
A subscriber session contains more than a forwarding entry. Authentication, addressing, policy, counters, accounting and protocol state must describe the same service. A distributed design needs an authoritative owner for each item and a method for reconciling disagreements.
Ask what happens when an install succeeds at the user plane but its acknowledgement is lost. Can the controller retry without creating duplicate state? How are stale entries distinguished from current ones after restart? Which component decides that a subscriber has disconnected, and how does accounting follow that decision?
These questions apply during normal upgrades as well as failures. A controller and user plane may run different software versions during a rolling change. The supported compatibility window and rollback behaviour belong in the acceptance criteria.
For integrated services, identify additional state explicitly. CGN mappings are distinct from subscriber session policy. Moving session control does not by itself preserve active translations when a forwarding node fails. Netavo does not provide active/standby NAT binding synchronisation or stateful NAT failover; plan service recovery around that shipped boundary.
Controller reachability changes the failure model
A user plane may continue forwarding existing sessions while its controller is unreachable. That is useful, but it leaves several operational questions: can new subscribers connect, can policy change, how are counters retained, and what happens when a subscriber leaves during the partition?
Define behaviour for a short interruption, a prolonged partition and controller recovery. Then test it under a realistic admission rate. A lab test with established sessions and no churn can conceal the outage that new customers would experience.
Also consider partial reachability. One controller may reach a user plane while another cannot. The design must prevent competing owners from issuing inconsistent updates. Transport redundancy helps availability, but it does not replace ownership and reconciliation rules.
Continued forwarding during a control outage proves only one part of resilience; admission, accounting, policy changes and recovery need their own acceptance tests.
Keep the blast radius visible. A controller service covering many regions can simplify operations while increasing the number of subscribers exposed to a bad policy deployment. Staged rollout, bounded changes and recovery procedures should scale with that population.
Multi-vendor interoperability needs a test contract
Standards provide a shared framework. Operators still need agreement on supported features, versions, optional behaviours and failure handling. Two products can support a common interface while differing in the subscriber services that can be delivered through it.
Build an interoperability matrix around your actual service: PPPoE or IPoE admission, IPv4 and IPv6 addressing, QoS policy, accounting, disconnects and operational telemetry. Include the services you intend to deploy rather than only a successful basic session.
Run the matrix across upgrades and recovery events. Check that both vendors interpret errors consistently and expose enough evidence to resolve a failed transaction. Agree who owns an incident when the controller reports success but the user plane has incomplete state.
This validation effort is an operating cost. Count lab equipment, release qualification, engineering time and support coordination in the business case. Multi-vendor choice has value when the organisation can sustain the work needed to exercise it.
Put a price on the architecture choice
Compare complete lifecycle costs over the same growth forecast. Include forwarding hardware, control compute, inter-site transport, redundancy, software, observability and staff effort. Model ordinary operation and the failure scenario the service must tolerate.
For CUPS, identify the specific purchase or transport cost that independent placement avoids. For complete appliances, count any duplicated control resources and fleet-management effort. Avoid crediting either design with automation or resilience that has not been demonstrated.
CUPS earns its cost when placement freedom and fleet scale produce benefits greater than the distributed-state burden. A single-appliance design earns its place when local ownership and a contained operating model meet the service requirements. Netavo offers that appliance model with separate control and forwarding processes, making the architectural boundary clear before deployment.
Evaluate the appliance approach with a Netavo evaluation, review the documentation, and use the performance material when comparing capacity against your own subscriber workload.