AsterNOS-VPP Broadband Network Gateway Technology

AsterNOS-VPP Broadband Network Gateway (BNG) is built on the SONiC control and management framework and the VPP software data plane. It integrates subscriber access control, subscriber session management, routing and forwarding, and IPv4 address sharing into a unified software architecture. Designed for carriers, regional ISPs, campuses, and multi-tenant broadband networks, this architecture forms a unified broadband edge between the access/aggregation network and the upstream IP network.

AsterNOS-VPP supports two subscriber access modes, PPPoE and IPv4 IPoE, and can perform centralized authentication through external RADIUS/AAA servers. IPoE subscriber onboarding is triggered by DHCPv4; AsterNOS-VPP acts as the DHCPv4 relay, and IPv4 addresses are provided by an external DHCP server. After a subscriber session is established, the VPP data plane handles routing and forwarding. For subscribers that use private IPv4 addresses or shared address space, CGNAT provides public IPv4 address sharing, port resource management, and traceability.

AsterNOS-VPP supports up to 50,000 concurrent PPPoE subscriber sessions and up to 100,000 concurrent IPoE subscriber sessions. CGNAT concurrent session capacity is 2.09 million and 10 million with 16 GB and 32 GB of memory, respectively.

This white paper is intended for network architects, network engineers, solution engineers, technical decision-makers, and product technical staff involved in carrier, regional ISP, campus network, and broadband access solutions. Readers should have a basic understanding of IP networking, routing, broadband access, and network address translation, as well as some familiarity with common network protocols and mechanisms such as PPPoE, DHCP, RADIUS, and NAT.

This document focuses on the software architecture of AsterNOS-VPP BNG, PPPoE and IPoE subscriber access mechanisms, CGNAT, public IPv4 address and port resource management, session capacity, deployment modes, and operations and maintenance capabilities. It can be used for product evaluation, solution design, technology selection, and broadband edge network architecture planning.

An ordinary IP router forwards packets mainly based on the destination address, the routing table, and the next hop, whereas a broadband access network serves a large number of subscribers, each with a well-defined service state. Besides deciding where a packet should be sent, the network also needs to know where a subscriber entered the network, whether the subscriber has been authenticated, what IPv4 address the subscriber has obtained, whether the current session is still valid, and whether the subscriber’s traffic has been authorized to enter the data plane.

This means the broadband edge must maintain a layer of subscriber state in addition to conventional routing state. Subscriber onboarding typically goes through identification, authentication, address assignment, and session establishment; only after these conditions are met does service traffic enter the normal forwarding path. When a subscriber goes offline, a lease expires, or a session is deleted, the corresponding forwarding state must be cleaned up accordingly. The core value of a BNG thus extends from “forwarding subscriber packets” to “managing subscribers and their network lifecycle.”

For carriers, this difference is critical. A large number of subscribers may coexist within the same IPv4 address space, each with a different identity, address, and connection state, so service state cannot be expressed by the routing table alone. A modern BNG must understand both the network topology and the subscriber context, and continuously map the latter to actual data forwarding behavior.

Both PPPoE and IPoE can be used for broadband subscriber access, but they establish the subscriber context in different ways. PPPoE establishes a PPP session over Ethernet: the subscriber first completes the PPPoE Discovery stage and then proceeds to PPP negotiation, authentication, and address configuration. The PPP session thereby forms a clear subscriber session boundary.

IPoE does not rely on PPP encapsulation; it carries IP services directly over Ethernet. Subscribers typically come online by triggering DHCPv4, after which the BNG identifies the subscriber and its access location using information such as the MAC address, access interface, VLAN, and Option 82. IPoE therefore reduces dependence on PPP sessions, while requiring the access network and the subscriber control system to provide sufficient context to form an authenticatable and maintainable subscriber session.

PPPoE and IPoE serve the same BNG service goal: turning access terminals into authenticatable, maintainable, and forwardable subscriber sessions. The two modes use different protocol mechanisms to establish the subscriber context and can be deployed separately depending on the access network form and operational framework.

Table 1 Comparison of PPPoE and IPoE Access Models

After a subscriber connects to the Layer 2 network, service traffic must still undergo identity and service-eligibility verification before it is granted forwarding permission. The BNG performs authentication through the AAA system and, upon successful authentication, establishes the address and session state corresponding to the subscriber. RADIUS is a common centralized AAA protocol in broadband networks; it decouples subscriber authentication and some service policies from the access device itself.

In PPPoE scenarios, PPP authentication information such as the username can directly serve as part of the subscriber identity. In IPoE scenarios, because there is no PPP session to provide a subscriber identifier, the system relies more on access context such as the MAC address, interface, VLAN, Circuit-ID, and Remote-ID. Either way, the system must form a stable subscriber session and translate the authentication result into enforceable data plane state.

A modern BNG therefore handles a continuous chain of state rather than several independent network functions: a subscriber is first discovered and identified, then authenticated and assigned an address; the system then establishes the subscriber session and pushes down the forwarding state; accounting statistics and O&M systems continue to track the subscriber lifecycle on this basis.

After a subscriber comes online and obtains an IPv4 address, public network access still needs to be addressed. Traditional NAT can translate private addresses into public addresses, but in broadband networks a single public IPv4 address often needs to serve a large number of subscribers at the same time, which turns NAT from a simple address translation problem into one of operational management of public address and port resources.

When many subscribers share public IPv4 addresses, the network needs to control how many port resources each subscriber can consume to prevent a single subscriber from over-occupying shared resources. The device must also handle the creation, aging, and reclamation of large-scale NAT sessions and, when operational or compliance traceability is required, be able to map a public IP address, port, and time back to the corresponding subscriber. CGNAT is the subscriber-oriented IPv4 sharing mechanism that emerged from these requirements.

Subscriber management establishes subscriber identity and online state, while CGNAT manages public IPv4 address sharing and port resources. In networks that use CGNAT, subscriber-side addresses and the associated policies participate in public resource allocation.

Taking the above requirements together, a modern BNG can be decomposed into several interrelated functional domains. PPPoE or IPoE establishes the subscriber access context; AAA and subscriber session management verify identity and maintain online state; address management provides network parameters to subscribers; and the data plane performs routing and forwarding based on this state. In networks that need to share public IPv4 addresses, CGNAT further provides public address and port resource management. Management, monitoring, and logging capabilities run throughout service operation, providing visibility for operations, troubleshooting, and subscriber traceability.

Traditional BNGs are usually delivered as integrated network devices, with subscriber access, control plane, data plane, and platform management capabilities built around a specific device system. This model concentrates broadband access functions in a single system, but software capabilities, forwarding platforms, and device form factors are typically tightly coupled to the platform.

AsterNOS-VPP adopts an architecture that combines the SONiC control and management framework with the VPP software data plane. It separates subscriber access control, network service orchestration, and packet processing into different software layers, and establishes an adaptation path between service control and the VPP data plane through SAI and libsaivpp. On this basis, the same software architecture can be deployed on supported ARM / ET series hardware devices as well as on x86 virtual machines.

Table 2 Comparison of Architecture Models: Integrated BNG vs. AsterNOS-VPP BNG

Both architecture models fulfill the same basic BNG service responsibilities; the difference lies mainly in how software functions and hosting platforms are organized. AsterNOS-VPP separates broadband subscriber control from high-frequency packet processing and reuses a unified software architecture across physical devices and virtualized deployments, providing a common technical foundation for subscriber access, address translation, and automated management.

AsterNOS-VPP is built on the SONiC + VPP software architecture. SONiC provides the framework for control, configuration, state management, and network function orchestration; SAI (Switch Abstraction Interface) provides an abstract interface between service logic and the data plane; and libsaivpp converts the corresponding SAI operations into data plane operations executable by VPP, which ultimately performs the main packet processing and forwarding.

This layering is especially important for a BNG. Subscriber onboarding involves protocol interaction, AAA, address assignment, and session state maintenance, which are low-frequency but state-complex control events; once a subscriber is online, its service traffic requires continuous high-speed processing, which is a high-frequency data plane task. Placing the two kinds of processing on the software paths best suited to each reduces direct coupling between complex subscriber control logic and high-frequency packet forwarding.

Logically, subscriber processing in AsterNOS-VPP BNG can be divided into two phases: “establishing state” and “using state.” When a subscriber connects, the system discovers and identifies the subscriber, completes authentication and address acquisition, and creates the corresponding session; once these control procedures are complete, the system converts the results into forwarding state that the data plane can use directly. When subsequent service packets arrive, the data plane does not need to re-execute the full AAA process; it evaluates and processes packets according to the state already established.

This approach creates a clear boundary between subscriber control and packet forwarding: the former decides who can come online and what state needs to be established, while the latter performs actual data forwarding and routing based on that state. For a BNG that must maintain a large number of online subscribers while continuously forwarding service traffic, this layering provides a clearer engineering boundary between control plane complexity and data plane performance.

AsterNOS-VPP uses a PPPoE server and an IPoE server to handle broadband subscriber access control. They are responsible for the corresponding protocol processing, authentication interaction, and subscriber session management, and incorporate the resulting subscriber state into the SONiC and VPP architecture. PPPoE and IPoE use independent protocol processing paths: PPPoE builds subscriber state around PPPoE and PPP sessions, while IPoE builds access state around DHCPv4, RADIUS, and IPoE subscriber sessions.

At a higher level, both access methods follow a unified BNG control model: the access protocol establishes the subscriber identity and session context, interacts with the external RADIUS system, and then converts the final subscriber state into forwarding state usable by the data plane.

AsterNOS-VPP converts service and network state in SONiC into data plane operations executable by VPP through SAI and libsaivpp. Platform-level state is pushed down along the path SONiC / service control → SAI → libsaivpp → VPP: upper-layer state is abstracted uniformly through SAI, and libsaivpp then adapts it to VPP.

PPPoE, IPoE, routing, and CGNAT create different types of state, but all of it enters the data plane through this software boundary. Service control forms the corresponding subscriber and network state, and VPP performs packet processing and forwarding based on that state.

PPPoE and IPoE each establish the subscriber access context. The system completes authentication through external RADIUS / AAA and associates address and subscriber session state with the corresponding access identity. The results formed by access control enter the data plane and establish the forwarding basis for the service traffic of authorized subscribers.

VPP performs routing and forwarding based on the established subscriber sessions and network state, connecting services to the core network or the Internet. Subscriber identity and session state are established and maintained by the control plane, while continuous packet processing is handled by the data plane.

Subscribers that obtain routable public IPv4 addresses can enter the upstream network directly through routing and forwarding; subscribers that use private IPv4 addresses or shared address space can use NAT or CGNAT according to the address plan. CGNAT provides IPv4 address sharing through public address pools, port blocks, and per-subscriber resource control.

PPPoE establishes PPP sessions over Ethernet and is a mature subscriber session model in broadband access networks. The CPE first locates the access concentrator through the PPPoE Discovery stage; after the PADI, PADO, PADR, and PADS exchange is complete, a PPP session is established, followed by the authentication and IPv4 address negotiation phases. The PPP session provides a unified maintenance boundary for the username, authentication state, address, and online state.

AsterNOS-VPP supports a PPPoE server and allows its instances to be bound to subscriber-facing physical interfaces, providing the access foundation for RADIUS AAA, address assignment, and subscriber data forwarding.

A complete PPPoE onboarding process can be divided into three phases: first, a PPPoE session is established through the Discovery stage; next, PPP negotiation and subscriber authentication are completed; finally, an IPv4 address is assigned to the subscriber and the subscriber enters the online state. If authentication fails or negotiation cannot be completed, the system does not establish a normal online subscriber session; service traffic enters the subsequent forwarding path only after the subscriber state has been fully established.

The AsterNOS-VPP PPPoE server supports integration with external RADIUS servers and can authenticate subscribers using methods such as CHAP. The device can be configured with RADIUS-related parameters such as NAS-IP so that the external AAA system can identify the access node and centrally authenticate subscribers; the PPPoE server also supports RADIUS accounting, bringing subscriber sessions into the centralized AAA system.

The significance of centralized RADIUS lies not only in moving usernames and passwords out of local device configuration, but also in giving authentication, address policies, and downstream operational systems a unified subscriber identity entry point. After a subscriber initiates PPP authentication, AsterNOS-VPP sends an Access-Request to RADIUS and decides, based on Access-Accept or Access-Reject, whether the subscriber may continue to come online.

After a PPPoE subscriber is authenticated, it must still obtain an IPv4 address. AsterNOS-VPP supports two main modes: in one, a local address pool on the device assigns addresses to subscribers; in the other, subscriber addresses are further managed centrally on the RADIUS side.

Table 3 PPPoE IPv4 Address Assignment Modes

In the first mode, RADIUS can handle subscriber authentication only, while address resources are still maintained locally on the BNG; in the second mode, authentication and address assignment are further centralized in the RADIUS system. The two modes offer different address management choices for networks of different scales and operating models.

After successful authentication and address assignment, the PPPoE subscriber enters the online state. At this point, the main work of the control plane has shifted from “establishing the subscriber” to “maintaining subscriber state,” while continuous packet forwarding is handled by the VPP software data plane. AsterNOS-VPP therefore places PPPoE subscriber control and high-frequency service packet processing at different layers, so that PPPoE protocol state does not become logic that must be repeatedly processed for every packet.

The PPP session provides the device with the subscriber identity and session boundary, and VPP forwards data based on the established state. Subscriber control and data forwarding thus have a clear division of responsibilities.

After a PPPoE subscriber enters the online state, service traffic can participate directly in Layer 3 routing according to the network design; in access scenarios that use private IPv4 addresses, it can also reach the Internet through source NAT. AsterNOS-VPP supports combined deployment of PPPoE and source NAT and can serve as a standalone Internet access gateway.

Unlike PPPoE, IPoE does not rely on PPP sessions; it carries subscriber services directly over Ethernet and IP networks. The network still needs to identify and authenticate access terminals, establish address and subscriber session state for them, and push this state down to the data plane.

IPoE broadband access combines DHCPv4 triggering and relay, subscriber identity construction, RADIUS authentication, address leasing, and data plane state. AsterNOS-VPP forms the subscriber identity from the terminal information carried in DHCPv4 packets and the access network context, and uses subscriber session orchestration to convert authentication and address state into forwarding state in the VPP data plane.

In PPPoE, subscriber identity is closely tied to the PPP session, whereas IPoE must derive more context from the Ethernet and DHCPv4 environment. The subscriber MAC address can represent the terminal itself; the access interface and VLAN can describe the logical location from which the terminal enters the network; and fields in Option 82 such as Circuit-ID and Remote-ID can further carry access location information.

The IPoE subscriber context consists of the terminal identity, the access location, and the assigned address. Carriers can thereby bring both “which terminal” and “where the terminal connects from” into AAA and session management.

Option 82 can carry access location information such as Circuit-ID and Remote-ID into the DHCPv4 and AAA processes, associating terminal identity with access location in subscriber identification and authentication policies.

AsterNOS-VPP uses the DHCPv4 Discover packet to trigger IPoE subscriber onboarding. After the client sends a DHCP Discover, the system establishes the subscriber context based on the access interface, MAC address, and relevant option information, and then enters the RADIUS authentication and DHCPv4 relay procedures. AsterNOS-VPP forwards the DHCPv4 request to the external DHCP server and receives the IPv4 address assignment result returned via the relay. After authentication, address acquisition, and data plane orchestration are complete, subscriber services enter the forwarding state.

A DHCPv4 packet triggers subscriber identification, a RADIUS Access-Accept confirms the authentication result, and the external DHCP server returns an IPv4 lease; after the subscriber session and data plane state have been orchestrated, service traffic enters the forwarding state.

When the system obtains sufficient subscriber context from DHCPv4 and the access network, it can convert the relevant information into a RADIUS Access-Request, and the external AAA system determines whether the subscriber is allowed to continue coming online. Compared with PPPoE, which directly uses PPP user credentials, identity fields such as User-Name in IPoE can by design rely more on the MAC address and access location information; RADIUS therefore plays the role of mapping access network context to subscriber authentication policy in an IPoE architecture.

A RADIUS Access-Accept confirms successful subscriber authentication; DHCPv4 address acquisition and SAI/VPP session orchestration then establish the data plane state. The subscriber enters the forwarding state once this state has been fully established, keeping forwarding authorization consistent with the actual data plane objects.

In IPoE scenarios, AsterNOS-VPP acts as the DHCPv4 relay, and subscriber IPv4 addresses are provided by an external DHCP server. AsterNOS-VPP receives the subscriber’s DHCPv4 request, relays it to the external DHCP server, and associates the IPv4 lease returned by the server with the current subscriber context. DHCPv4 address establishment is an important part of the subscriber session lifecycle: the system associates the assigned address with the subscriber session and the subsequent data plane objects.

The IPoE data plane uses an L2 IPv4 subscriber gating mechanism. VPP looks up the corresponding subscriber session based on the access interface and the subscriber IPv4 address, and in L2 mode additionally verifies the source MAC address. For terminals that do not yet have a subscriber session, DHCPv4 control packets can continue into the onboarding process as allowlisted traffic, while other ordinary IPv4 service traffic that does not match a valid subscriber session is not granted forwarding permission by default.

This design makes IPoE subscriber state part of data plane forwarding decisions. Forwarding permission for ordinary IPv4 traffic depends both on network routing and on whether the current access location, IPv4 address, and MAC address match an existing data plane subscriber session. VPP also retains a Timer Wheel-based session expiration protection mechanism to clean up data plane authorization state that has lingered for a long time.

The basic task of traditional NAT is to translate internal addresses and ports into external addresses and ports. In enterprise or small gateway scenarios, where public IPv4 addresses and session scale are relatively limited, flow-based address translation is usually sufficient.

Broadband carriers face a completely different resource model. A large number of subscribers must share a limited pool of public IPv4 addresses over the long term, and each public address has only a limited port space. Without per-subscriber management of port resources, a single subscriber with a high connection count could quickly consume a large share of the shared resources; carrier networks also need to be able to identify the actual subscriber after the fact from the public IP address, port, and time. CGNAT therefore needs to provide per-subscriber resource control, port allocation policies, and traceability at the same time.

Table 4 Comparison of Focus Areas: Ordinary NAT vs. CGNAT

AsterNOS-VPP CGNAT organizes traffic selection and policy association, public address and port resources, and interface roles as interrelated objects. These objects respectively describe which subscriber traffic enters CGNAT, which instance processes it, which public resources and port policies are used, and from which side of the network traffic enters and leaves the address translation domain. Figure 5 shows these objects and their relationships.

AsterNOS-VPP uses an ACL to identify subscriber traffic that needs to enter CGNAT. The ACL is applied to the CGNAT Inside Interface and referenced by a CGNAT Binding; the Binding associates the traffic selection policy with a designated CGNAT Instance. Traffic matching the ACL enters that instance for address translation, and traffic selection and public resource configuration can be managed separately. An ACL no-nat policy can exclude specific destination addresses or ports from NAT translation.

A CGNAT Instance organizes the operating mode of dynamic or deterministic CGNAT and references a Public Address Pool. The address pool provides public IPv4 address resources, and a Port Allocation Profile defines port resource behaviors such as port block size, allocation mode, port selection, reserved ports, and cooling time. The public address pool and the port allocation profile together make up the public resource model; Sections 5.3 and 5.4 further describe port block allocation, public address sharing, and per-subscriber resource control mechanisms.

AsterNOS-VPP distinguishes the network roles on the two sides of CGNAT through the Inside Interface and the Outside Interface. The Inside Interface faces the subscriber-side network that requires address translation, and the Outside Interface faces the public network or upstream network. The traffic selection ACL is applied to the Inside Interface; the interface roles determine the traffic direction of address translation and have responsibilities distinct from those of the CGNAT Instance, public address pool, and port allocation policy.

Port Block Allocation (PBA) is one of the core port resource mechanisms of AsterNOS-VPP CGNAT. The system can first divide the public port space into multiple fixed-size port blocks and then allocate port blocks to specific subscribers. When a subscriber creates subsequent sessions, available ports are preferentially selected from the port blocks already allocated to that subscriber.

This approach lets multiple subscribers share the same public IPv4 address while establishing a clear port resource boundary for each subscriber. AsterNOS-VPP supports configurable port block size, on-demand allocation and pre-allocation, and random port selection within a port block. A reserved port range excludes ports from dynamic allocation, and the cooling time controls how long a released port block must wait before it becomes allocatable again; the default is 120 seconds and it can be configured according to operational policy.

Figure 6 shows how the port space of a single public IPv4 address is divided into multiple port blocks that are allocated to different subscribers, maintaining port resource boundaries while sharing the public address.

Multiple broadband subscribers can share the same public address pool. For dynamic CGNAT, when a new subscriber starts to establish connections, the system selects a suitable public address from the public address pool and port resources, and provides the subscriber with the required port blocks according to the Port Allocation Profile. AsterNOS-VPP’s Paired Pooling keeps the subscriber associated with the same public IPv4 address for as long as the subscriber binding is valid; when the subscriber accesses different external destination addresses, the translated public IPv4 address remains unchanged, and the specific address is determined by the address pool state and allocation policy.

AsterNOS-VPP can limit the resource usage of a single CGNAT subscriber along multiple dimensions, including the maximum number of port blocks a subscriber may own, the maximum number of public translation ports it may consume, the maximum number of concurrent CGNAT sessions, and the rate of new session creation. The different limits apply to port blocks, ports, session count, and session creation rate respectively, enabling operators to constrain the occupation of shared public IPv4 and port resources by a single subscriber according to their service model.

These limits take effect independently on a per-subscriber basis. For example, max-user-sessions constrains the number of CGNAT sessions a single subscriber can maintain concurrently, while max-user-create-sessions-rate constrains the rate at which that subscriber creates new sessions per unit of time. Combining static resource caps with dynamic connection-rate control reduces the risk that a single abnormal or high-connection-count subscriber continuously consumes shared CGNAT resources and affects other subscribers.

A key question in CGNAT operations is how to find the actual subscriber when the operator knows only the public IPv4 address and port used at a certain point in time. AsterNOS-VPP provides two dynamic CGNAT logging mechanisms of different granularity, port block logs and session logs, and can send logs to a remote Syslog collector.

Session logs record the creation and deletion of individual NAT sessions, providing fine-grained connection records; port block logs record the allocation and release of subscriber port blocks, including the subscriber, public IPv4 address, port range, and time. In PBA scenarios, port block logs do not need to generate allocation records at the same granularity for every NAT session, and can therefore reduce the number of log events.

The two logging methods represent different operational trade-offs: session logs provide a finer connection history, while port block logs emphasize the association between port resources and subscribers. Operators can choose the appropriate logging mechanism according to log granularity, storage volume, and traceability approach.

Dynamic CGNAT mainly serves connections initiated by internal subscribers, but some services also require external networks to access fixed services located inside the CGNAT domain. Static mapping provides a fixed mapping between public IPv4 address and port and internal IPv4 address and port for such scenarios, so that external access can reliably reach the designated internal service.

Static mapping adds fixed inbound access capability to the dynamic address sharing architecture and is suitable for publishing internal services that need a stable public entry point.

Dynamic CGNAT allocates public address and port resources to subscribers on demand at runtime, whereas deterministic CGNAT establishes a predictable relationship between subscriber addresses and public IPv4 addresses and port ranges through pre-defined mapping rules. Based on the deterministic algorithm and address plan, the corresponding subscriber range can be derived in reverse from a public IPv4 address and port, reducing reliance on per-session dynamic logs.

The core value of this mode lies in traceability and mapping determinism. The dynamic mode emphasizes on-demand allocation and resource utilization, while the deterministic mode emphasizes advance planning and predictable mapping; the two suit different address planning and operational requirements.

CGNAT resource management spans new session creation, session aging, and port block reclamation. When a subscriber generates its first flow that requires translation, the system establishes public resources and a NAT session for it; as sessions gradually end, a port block may become idle and be released once the reclamation conditions are met. A released port block may also go through a cooling time before becoming allocatable again.

This lifecycle control ensures that public ports are reclaimed according to the rules and prevents a port block just released by one subscriber from being immediately allocated to another. In large-scale broadband scenarios, port block allocation, session aging, resource reclamation, and public address pool utilization together determine the resource efficiency of CGNAT.

RFC 6888 defines best-practice requirements for carrier-grade NAT (CGN) in areas including transport protocol handling, address pool behavior, port resource management, filtering, logging, manageability, and resource exhaustion handling. AsterNOS-VPP CGNAT implements the main requirements in address and port resource management, subscriber resource control, port reuse protection, logging, and traceability. The table below lists the key requirements relevant to the product’s current capabilities and the support status.

Table 5 Support for Key RFC 6888 Requirements

Table 6a PPPoE Subscriber Session Capacity

Table 6b IPoE Subscriber Session Capacity

CGNAT session capacity represents the number of address and port translation sessions the device can maintain simultaneously. The device maintains corresponding translation state for traffic undergoing address translation, and its scale depends on system resources such as available memory.

The number of subscribers CGNAT can serve is determined by the public address and port resource allocation policy, mainly involving the number of ports per subscriber, the port block size, and per-subscriber resource limits.

Table 6c CGNAT Session Capacity by Memory Configuration

AsterNOS-VPP BNG can be deployed between the subscriber access and aggregation network and the upstream IP network, forming a unified broadband edge. Subscriber sources and access infrastructure may differ across deployment environments, but the basic role of the BNG in the network stays the same: it terminates broadband subscriber access, maintains subscriber identity, IPv4 address, and online session state, and connects authorized services to the carrier or enterprise IP core network through routing and forwarding.

A centralized RADIUS/AAA server can provide unified subscriber authentication for different access areas; in IPoE scenarios, IPv4 addresses are provided by an external DHCP server and AsterNOS-VPP acts as the DHCPv4 relay. The BNG can establish subscriber sessions using PPPoE or IPoE depending on the access network, and, based on the public IPv4 address plan, provide subscribers with either a direct routing path or a CGNAT address sharing path.

In the broadband edge architecture shown in Figure 7, residential broadband, FTTH, and regional ISP networks can aggregate multiple residential communities, buildings, and access nodes into the AsterNOS-VPP BNG through ONT/ONU, OLT, and the access aggregation network. The BNG sits between the access aggregation network and the carrier IP core network, forming the service boundary between the regional subscriber access system and the upstream IP network.

AsterNOS-VPP BNG can establish subscriber sessions using PPPoE or IPoE depending on the access network, and completes subscriber identity control and authentication through a centralized RADIUS/AAA server. IPv4 addresses for IPoE subscribers are provided by an external DHCP server, and AsterNOS-VPP uses DHCPv4 relay to associate the address establishment result with the subscriber session and forwarding state.

After subscribers come online, the VPP data plane handles routing and forwarding toward the carrier IP core network. Subscribers that obtain routable public IPv4 addresses can enter the upstream IP network directly; subscribers that use private IPv4 addresses or shared address space can share public IPv4 addresses and port resources through CGNAT within the AsterNOS-VPP BNG.

University dormitories, multi-dwelling residences, industrial parks, and multi-tenant commercial buildings can adopt the same broadband edge architecture as in Figure 7. The access side of such networks is usually composed of buildings, dormitories, tenant access points, access switches, and an aggregation network, through which a large number of independent subscribers or tenants enter a unified AsterNOS-VPP BNG over shared access and aggregation infrastructure.

The centrally managed broadband access model maintains identity, IPv4 address, and online session state for each subscriber, so that different subscribers on a shared physical network still have clear access and service boundaries. AsterNOS-VPP BNG can use PPPoE or IPoE according to the network design and forwards authorized services to the carrier or enterprise IP core network through the VPP data plane.

A centralized RADIUS/AAA server can provide unified authentication for multiple buildings, dormitories, and tenants, while IPoE subscriber addresses are provided uniformly by an external DHCP server and established through the DHCPv4 relay of AsterNOS-VPP. Multiple access areas can thus share a unified broadband edge while each maintains its own subscriber identities, addresses, and session state.

After a broadband subscriber comes online, AsterNOS-VPP BNG maintains its subscriber session and the corresponding forwarding state. The path by which subscriber traffic enters the upstream network is determined by the actual IPv4 address plan and the carrier’s public IPv4 resource policy.

Subscribers that obtain routable public IPv4 addresses can enter the carrier IP core network directly through routing and forwarding. Subscribers that use private IPv4 addresses or shared address space can use shared public IPv4 addresses and port resources through CGNAT within AsterNOS-VPP BNG, and then reach the Internet via the carrier IP core network.

In this scenario, CGNAT provides public IPv4 address sharing, port resource management, and traceability: it allocates limited public address and port resources to different broadband subscribers and preserves the association between public addresses, port resources, and subscribers. The subscriber access function identifies subscribers, completes authentication, and maintains online sessions, while CGNAT handles the traffic of subscribers that need to share public IPv4 resources according to the address plan.

The broadband access and IPv4 address sharing scenarios above can run on different platforms depending on network scale, device form factor, and deployment environment. AsterNOS-VPP can be deployed on ARM hardware devices, or run on x86 virtual machines in virtualized environments such as KVM or VMware ESXi, accommodating both physical broadband edge and virtualized deployment needs. ARM hardware platforms can use related architectures including Marvell OCTEON CN102/CN103.

Different platforms have different processor, memory, NIC, and I/O capabilities; the appropriate platform and resource configuration can be selected according to the target subscriber scale and deployment requirements.

Table 7 Deployment Modes

AsterNOS-VPP builds a unified broadband edge on the SONiC control and management framework and the VPP software data plane, carrying PPPoE, IPv4 IPoE, RADIUS authentication, subscriber session control, and routing and forwarding in a single architecture. The control plane establishes and maintains subscriber identity, address, and session state, and the data plane processes continuous service traffic based on this state, keeping a clear engineering boundary between subscriber control and packet forwarding.

For public IPv4 address resource management, AsterNOS-VPP CGNAT provides public address pools, port block allocation, per-subscriber resource control, logging, and traceability mechanisms. Subscribers that obtain routable public IPv4 addresses can enter the upstream IP network directly, while subscribers that use private IPv4 addresses or shared address space can use shared public IPv4 resources through CGNAT, adapting to different carrier address plans.

AsterNOS-VPP can be deployed on ARM / ET series hardware devices, and can also run on x86 virtual machines in KVM or VMware ESXi environments. The product supports up to 50,000 concurrent PPPoE subscriber sessions and up to 100,000 concurrent IPoE subscriber sessions; CGNAT concurrent session capacity is 2.09 million and 10 million with 16 GB and 32 GB of memory respectively, making it suitable for physical or virtualized BNG deployments in regional broadband, campus, and multi-tenant networks.