Different Approaches to Building a BNG

There are a number of different ways to create a BNG, from legacy monolithic systems to modern software-based systems. So, what are the main alternatives that you can consider?

Monolithic

This is a deployment using a monolithic chassis-based router which slots in line cards for terminating subscriber sessions and routing them towards the core network. Sometimes, services such as CGNAT, etc. can also be supported on such routers by using service line cards. Since such routers are large and incur significant capital expense, they are placed in centralized locations such as central offices and often traffic from multiple access networks is aggregated before being delivered to these routers. This increases their blast radius requires specialized SLAs to ensure uptime thereby also incurring significant running costs. These solutions also cause what are called 'forklift' upgrades where a single component upgrade, such as need to support a linecard with a faster port causes a spiralling out of upgrades across other dependent components such as backplane and control plane cards in the router

Virtualized solution

Some solutions are based on a using a general-purpose CPU such as x86 for forwarding traffic instead of a dedicated NPU. While this can be a cost-effective approach and allows significant number of subscribers to be onboarded on one device, there are inherent drawbacks to this approach. Since the same CPU is used for control plane and forwarding plane, forwarding plane issues can cause control plane disruptions. Also provisioning QoS policies, etc. is very resource intensive and cause aforementioned disruptions or impact subscriber scaling negatively

CUPS

This is a novel approach to separate the control plane and the forwarding plane. This allows the control plane to be virtualized in the cloud to provide high availability and allows independent scaling of the control plane and forwarding plane resources. This also allows control plane and forwarding plane to be procured from separate vendors provided that they adhere to the proposed standardized interfaces specified in Broadband Forum Technical Reports. Since the forwarding plane is separate from the control plane, this approach allows for a more distributed way of deploying BNG across the network which enables a reduction in form factor and hence blast radius as well as reduction in latency by bringing the forwarding plane of the BNG closer to the subscriber

Disaggregated BNG

This approach enables software provided by a disaggregated solutions provider to be overlaid on a whitebox router which uses merchant silicon as the NPU. This helps the customer to tide over the vendor lock-in and the aforementioned forklift upgrades which can help optimize the capex as well as opex costs for the customer. Since current merchant silicon is highly capable and performant, such devices, despite being small 1-RU/2-RU switches, can host 10s of 1000s of subscribers. Therefore this approach also brings the benefits of the CUPS approach of enabling a more distributed deployment. Further, these devices do not place the stringent latency and congestion related requirements that CUPS has on the Control plane and forwarding plane communication

RtBrick's Solution

RtBrick's solution is based on the disaggregated approach. It uses open 1RU/2RU OCP compliant switches built by ODMs using merchant silicon from Broadcom. The solution unlocks multiple network functions in this role when overlaid with RtBrick NoS, called RtBrick Full Stack (RBFS). In spite of following a disaggregated approach, RtBrick takes full maintenance and support responsibility for the combined network nodes thereby enabling customers to deal with a single entity for support services

The approach of combining hardware and software from different vendors enables the customer to break out of vendor lock-in situations. Moreover, merchant silicon-based solutions offer significant cost optimization, both in terms of capex and also opex through low power consumption (0.5W/Gbps). Further, each device can unlock upto 3 network function (BNG, CGNAT, full table IP/MPLS router) and enable collapsing multiple hardware devices into one

The devices themselves are pizza box switches that can be combined with other devices using standards-based protocols thereby avoiding forklift upgrades and upgrade of one device does not cascade into more upgrades in the network

This solution brings the benefits of the CUPS approach without the attendant disadvantages. The fact that these devices are of a small form factor and in many cases, temperature hardened, means that they encourage a distributed deployment. This also enables a reduction in the blast radius which further reduces the SLAs needed to maintain these devices. Since the devices retain the control plane, they do not place the stringent communication requirements on network as in a CUPS deployment

Lastly, it needs to be pointed out that integration of Prometheus enables efficient storage and access to 1000s of metrics at granularity not provided by legacy approaches such as SNMP. These can be integrated with well-known open-source tools to build customer dashboard which provide unrestricted visibility into the system as well as the ability to federate this data for a centralized analysis across multiple systems

Thus, we see that RtBrick bring compelling value to customers for their BNG and CGNAT deployments

Alternative BNG Approaches