Migrate to Juniper BNG CUPS

Rising operational costs with declining or flattening revenues have driven telco service providers to rethink the way they plan, design, and operate their networks. Telcos are following the lead of cloud operators looking to apply cloud and data center design principles to their next-generation network architectures as a way to save costs.

Additionally, many next-generation designs control software and leverage disaggregation of network devices. Decoupling the operating system software from the hardware allows you to manage hardware and software life cycles separately. Decoupling also offers you the flexibility to purchase software from different vendors.

Juniper BNG CUPS (separation of the control plane and the user planes) offers the following benefits over traditional BNG network designs to the customers of service providers:

• Scaling. Scaleout of the broadband edge control plane enables maximum capacity utilization of the user plane hardware resources.

• CAPX savings through simplified user planes as a result of running most control plane functions off box. Also, back-office scale efficiencies with a single disaggregated control plane minimizes sessions to policy layer servers, provisioning tools, and telemetry collectors.

• OPEX savings through simplified management. Provisioning a disaggregated control plane does not require you to provision a control plane on downstream user planes.

• Streamlined software upgrades when control plane centric enhancements are needed to enable new use cases. For example, you can upgrade a disaggregated control plane's software independently of a user plane's software.

• Improved return on investment and total cost of ownership. These financial benefits result from using your existing integrated BNG hardware devices by re-purposing them as BNG User Planes.

Juniper BNG CUPS is used for the following purposes:

• Intelligent subscriber placement

  This placement assumes a multi-service network architecture where broadband edge services are served from multiple locations. Some services come from distributed broadband edge routers close to the subscribers. Other services are more centralized, served from the service provider point of presence (POP) location. An external control plane running on an x86 computer interacts with the policy layer and back-office systems to drive optimized subscriber service placement on a per-subscriber and per-service basis.

• Load balancing subscribers across a pool of broadband edge routers

  Telcos are driving broadband network designs. In these designs, groups of broadband edge network elements are pooled together. Also, external broadband control planes are used to load balance subscriber traffic across the pool of broadband edge routers. This use case, you can use the broadband control plane to trigger a provisioning change within the access network. This provisioning change results in the subscriber being steered to the most underutilized broadband edge router.

• IP address pool management

  As broadband edge routers are increasingly deployed closer to the subscriber, telcos find it challenging to manage IP address pools for their subscriber base. Distributed broadband edge routers require telcos to allocate address pools in smaller, more granular address pool blocks. A telco can use a disaggregated broadband control plane to monitor IP address pool utilization and trigger optimized IP address pool distribution across broadband edge routers.

To take advantage of the benefits listed in Benefits of Juniper BNG CUPS, you need to change the BNG architecture from an aggregated BNG to a disaggregated BNG (Juniper BNG CUPS). In a disaggregated BNG the control plane (Juniper BNG CUPS Controller) is separate from the user plane (Juniper BNG User Plane). Aggregated BNG functions are split into the control plane functions and the user plane functions. Disaggregated BNG defines management, state, and control packet interfaces between the control plane and the user plane.

The Broadband Forum's TR-459 Control and User Plane Separation for a Disaggregated BNG specification standardizes the control plane and user plane functions and interfaces (for more information, see TR-459 Control Plane and User Plane Separation for a Disaggregated BNG.

The Juniper BNG CUPS solution is a cloud application that runs in a Kubernetes environment and consists of the following:

• A cloud control plane. In Juniper BNG CUPS, the control plane is called Juniper BNG CUPS Controller (BNG CUPS Controller). It supports the following features:

  • DHCP

  • PPP/PPPoE

  • L2TP (LAC/LNS)

  • AAA

• User planes on MX Series routers. In Juniper BNG CUPS, the user planes are called Juniper BNG User Planes (BNG User Planes).

• Centralized address pool management.

  Note:

  Juniper Address Pool Manager is a separate application from Juniper BNG CUPS. You must purchase it separately and then configure it to operate with Juniper BNG CUPS.

The TR-459 Control Plane and User Plane Separation for a Disaggregated BNG (TR-459) specification was created by the Broadband Forum to define disaggregated BNG architecture. Figure 2 from the TR-459 specification shows the placement of functional blocks on the control plane and the user plane.

A combination of the control plane functions is referred to as a control plane of the disaggregated BNG (DBNG-CP). Similarly, a combination of the user plane specific functions is referred to as a user plane of the disaggregated BNG (DBNG-UP).

Three types of interfaces exist between the control plane and the user plane:

• Management Interface (Mi):

  • Used to configure a user plane

  • Used to retrieve user plane state information

• Control Packet Redirect Interface (CPRi): Used for disaggregated BNG control traffic

• State Control Interface (SCi):

  • Used to identify and form user plane associations

  • Used to program subscriber state from the control plane to the user plane

  • Used to collect subscriber statistics from the user plane

The control plane and user plane functions along with the interfaces constitute the disaggregated BNG Architecture as proposed by the TR-459 standard. You can find details in TR-459 Control and User Plane Separation for a Disaggregated BNG from Broadband Forum.

• Recommended stacking models:

  • DHCP Server single stack

  • DHCP Server single session dual stack

  • DHCP Relay single stack

  • DHCP Relay single session dual stack

    Note:

    DHCP Relay is not standardized by the Broadband Forum yet. The recommendation is to use a local server model or to allocate addresses through an external entity like Address Pool Manager. (See Address Pool Manager documentation.)

  • PPP dual stack

  • L2TP

  • Dynamic VLANs (for DHCP and PPP)

SUMMARY This topic lists the scaling values supported by the BNG CUPS Controller and the Kubernetes topology requirments.

A single BNG CUPS Controller supports the following number of subscribers and BNG User Planes:

• One BNG CUPS Controller can support up to 512K subscribers.

• One BNG CUPS Controller can support up to 16 BNG User Planes.

BNG CUPS Controller runs in a Kubernetes environment.

The Kubernetes environment requires the following devices:

• Primary node

• Worker nodes (you must have at least three)

  Note:

  For the primary node and worker node system requirements, see Install Juniper BNG CUPS.

• AAA server

• DHCP server

• BNG User Planes—Juniper MX Series routers

Because the BNG CUPS Controller and the BNG User Planes are separated, you must perform configurations on both the BNG CUPS Controller and the BNG User Planes. You will perform the majority of the configurations on the BNG CUPS Controller.

Configure the following features on the BNG CUPS Controller:

• Subscriber management

• Dynamic profiles

• Autosense VLAN

• DHCP

• PPP

• L2TP

• Device management access

  • RADIUS

  • Authentication profile

  • Address assignment

• Subscriber firewall

• Subscriber Class of Service (CoS)

Configure the following functions on the BNG User Planes:

Note:

For migration configuration instructions, see Configure Subscriber Management Using Juniper BNG CUPS.

Juniper BNG CUPS separates the operational commands into BNG CUPS Controller and BNG User Plane commands. The majority of the BNG-related commands run on the BNG CUPS Controller. To help with troubleshooting, some of the operational commands run on the BNG User Planes.

Below is a summary list of the functional components and where you run their operations.

Note:

For a complete set of commands, see the Juniper BNG CUPS User Guide.

You run operational commands for the following functional components on the BNG CUPS Controller:

• Node management

• DHCP

• PPP

• L2TP

• DVLAN

• AAA

• Subscriber management

You run operational commands for the following functional components on the BNG User Plane:

• Node management

• Subscriber management

Many of the existing mechanisms for troubleshooting an MX Series BNG are available for troubleshooting Juniper BNG CUPS. Most of the BNG functionality is on the BNG CUPS Controller; therefore, you perform the majority of the troubleshooting on the BNG CUPS Controller.

The following troubleshooting mechanisms are available on the BNG CUPS Controller:

• Tracelogs

• Shared memory logs

• Operational and troubleshooting commands for the following components:

  • Node management

  • DHCP

  • PPP

  • L2TP

  • DVLAN

  • AAA

  • Subscriber management

The following troubleshooting mechanisms are available on the BNG User Plane:

• Tracelogs

• Shared memory logs

• Operational and troubleshooting commands for the following components:

  • Node management

  • Subscriber management

The BNG CUPS Controller runs a Kubernetes cluster in two pods. One pod is for the BNG CUPS Controller, and another pod is for the State Cache. The State Cache pod backs up all sessions and the BNG CUPS Controller state in high-availability mode.

In the case of a BNG CUPS Controller container failure, Kubernetes creates a new BNG CUPS Controller container. The BNG CUPS Controller gets its information from the State Cache container and builds a new state. After creating all the states, the BNG CUPS Controller reconnects to the BNG User Planes and continues from where it left off. BNG User Planes continue to forward traffic during a BNG CUPS Controller failure. No new logins are allowed until the BNG CUPS Controller recovers.

Figure 3 shows the BNG CUPS Controller container and the State Cache container.

BNG User Plane's high availability is similar to what is supported on the MX Series today, with high- availability support between the Routing Engines. State and other information is replicated in a high-availability mode across the Routing Engines. On a graceful Routing Engine switchover (GRES), the standby Routing Engine takes over as the active Routing Engine immediately.

Figure 4 shows the BNG User Plane high availability and GRES support between RE0 and RE1.