CGNAT

We provide Carrier Grade Network Address Translation (CGNAT), or NAT444, which translates private IPv4 addresses into public IPv4 addresses. We do this in-line in the BNG forwarding plane, so there is no need for a separate CGNAT device. So now, using RtBrick’s multi-service edge routing software, you can deliver both CGNAT and a Broadband Network Gateway (BNG) on a single open switch to reduce costs and increase efficiency.

We can also provide CGNAT as a standalone product, on an open switch.

The initial Internet address scheme, IPv4, had roughly 4.3 billion unique addresses when it launched, but it didn’t anticipate the greater numbers of Internet-connected users and devices it would need to support. In 2011, the Internet Assigned Numbers Authority (IANA) allocated the final five IPv4 address blocks. Then, in  2019, the regional Internet registry for Europe, RIPE NCC, allocated the last twenty-two IPv4 addresses, signalling the exhaustion of IPv4 addresses. IPv6, a subsequent scheme, has since solved this issue. However, in 2023, only a third of IPv6-capable requests globally were made over IPv6*, and a lot of equipment today still only supports IPv4.

Due to the exhaustion of public IPv4 addresses and the number of connected devices, CGNAT is widely required by operators while IPv4 continues to dominate and will do so for the foreseeable future, as it enables the re-use of IPv4 addresses in a public address space. Our CGNAT function is delivered as a software container, running on the Open Network Linux (ONL) provided by the hardware SKU manufacturers, which handles peripherals such as LEDs, temperature sensors, and so on. 

Watch a demo of in-line CGNAT working on the same open switch as a BNG

Benefits derived from Implementation in Hardware

Chipset Capability enabling Full Throughput

RBFS solution is implemented using the Qumran2 NPUs thereby allowing it to scale to a high subscriber count and throughput while retaining the ability to handle multiple network events and significant route churn.

A unique feature of RBFS CGNAT is that it follows the above template and has been seamlessly implemented in the NPU thereby allowing a CSP to maintain all the speeds and feeds of the switch along with benefits of NAT flow-based service. The solution can NAT the complete throughput, which is 2.4Tbps on today's chipsets. Additionally, the switch houses an external TCAM called the OP2(NLA 16K) co-processor which allows the solution to support a massive 4.5+ Million NAT entries. In the market there are multiple appliances or service line cards that provide CGNAT functionality that can often scale to multi-million NAT entries, but they are often based on the x86 based forwarding plane which restricts them to supporting tens of Gbps to no more than low hundreds of Gbps of throughput.

The RtBrick solution differentiates itself by being able to support NAT at the entire throughput of the switch (an order of magnitude greater than any of the current solutions), enabled via a software defined container software completely in-line without impact to any of the switch functions.

Investment Protection

RBFS enables complete plug-n-play capability of all the software features which in turn allows us to package the software in a ‘lego block’ function to work either as an IP/MPLS router, BNG access switch and a CGNAT device or combined form-factor as a Multiservice Edge Router. Since the data plane chipset resources are finite, each additional capability brings in different scaling considerations, however the investment of a CSP in the bare-metal switch is completely protected as one or more functions are enabled using RBFS.

Miniaturization and Lower Power Consumption

The hardware to deploy CGNAT are either 1RU or more powerful 2-RU switches. These already use highly power-efficient chips and consume as little as 0.15W/Gbps. Competing CGNAT solutions are available either as standalone 1-2 RU appliances that have a low throughput and high power consumption or are available as service line cards on large chassis-based routers. All of this results in additional cost to operate CGNAT functions. There is no other competing solution, to the best of our knowledge, that houses multiple in-line  network functions on 1 to2 RU switches at such a high scale and throughput.

You can see all of our latest open switch hardware options, and performance figures, on our Hardware Compatibility List.

Example performance numbers for the 2RU switches:

*Please note that either 1-Q subscribers or 4-Q subscribers can be deployed but not both together

Rich Policy support

Rich NAT Policy Options

CSPs have separate service plans that cater to different price/value segments. RtBrick recognizes this CSP requirement to treat subscribers differently depending upon the plan they subscribe to. To enable this, the C-BNG config data model provides the ability to create different subscriber profiles each of which cater to service in accordance to its service plan. Once a subscriber is identified as subscribed to a particular plan, either through AAA authentication or local configuration, the services defined in the specific profile are instantiated for the subscriber within the BNG. This functionality has been extended to CGNAT as well, and RBFS provides a rich tapestry of options to support such service plans. Let us explore the broader Policy features provided by RBFS.

Public Address Allocation and Port Pool Assignment

Furthermore, it is possible to chain pools to one another so that once a pool gets exhausted, the next pool in the chain can be used for allocating port blocks. This enables assignment of public addresses to the BNG device on the go. In addition to this, subscribers can request for multiple port blocks to be assigned to them, subject to a maximum configured limit.

Public addresses are allocated in pools to the BNG to be used for CGNAT. A pool is a set of contiguous addresses defined by a starting and an ending address. UDP and TCP port blocks from each address are then allocated to subscribers. Each pool can be configured with a port block size starting from 64 in powers of 2 up to 2048 entries. Therefore it is possible to configure separate pools for different profiles to enable subscribers to receive NAT entries as per their plan.

These allocation policies help ensure that public addresses can be very efficiently utilized while enabling specific treatment to subscribers on that plan.

Deterministic NAT

It is possible that subscribers can get port blocks from different addresses, although the allocation algorithm minimizes the chance of this happening. However, CSPs may not want to allocate port blocks from more than one public address to a subscriber. This is called deterministic NAT and is available in RBFS. The flip-side of enabling this is that a subscriber may not receive an additional block, despite not reaching its max limit, if the blocks from the public IP address get exhausted. The implementation places this trade-off decision in the hands of the CSP.

Port Recirculation

Ports from an allocated port block used for TCP/UDP sessions are reused once the sessions are torn down. A configurable idle timeout for both TCP and UDP sessions is used so that timed-out entries can be reused for other sessions. While such timeout mechanisms provide reuse of port entries, this can be made more efficient under certain circumstances. It is often seen that most TCP/UDP sessions are short-lived and while a timeout will eventually free the corresponding port entries for reuse, it is not necessarily the most efficient way of doing this. For TCP sessions, the software tracks FIN requests sent from either end and when it detects that such a request has been issued, it frees up the port sooner than taking the timeout approach. This results in more efficient use of the port entries and hence fewer port blocks would need to be allocated to subscribers than otherwise.

High Availability with Hot Standby

To provide high customer experience (CX) to subscribers and reduce opex through reducing truck-rolls, RBFS can be deployed in a High Availability configuration where the OLT is connected to two different BNG devices. If a network event occurs, such as a primary BNG failure or the link failure to primary BNG, the subscriber sessions are automatically switched over to the standby BNG with the subscribers hardly noticing the impact. More importantly, urgent and expensive truck-rolls can be avoided thereby reducing expenditure. CGNAT works seamlessly with this feature.

You can read about CGNAT in more detail here

Compatible Hardware

RtBrick's Full Stack routing software can operate on many bare metal switches, depending on your performance and port count requirements. You can find details of compatible hardware here.

*according to Cloudflare