The Automatic Session Reconciliation feature enables reconciliation of sessions that are out of synchronization between the Control Plane (CP) and User Plane (UP).

Desynchronization of a session occurs when the transaction is successful in the UP but times out before receiving a response from the UP.

The existing transaction-id increments by 1 in every request initiated from the CP to the UP. The CDL record stores the transaction-id per session when the UP conveys a successful response to the CP. The UP also stores this transaction-id when the transaction is successful in the UP.

The Charging functionality is now part of the Subscriber Manager (SM - also referred to as the "Session Manager"). This functionality is merged into the SM to reduce the number of transactions and number of CDL records. Therefore, the Subscriber pod now includes the Charging pod functionality, that is, subscriber access and subscriber management.

For more information, see the Cloud Native BNG Control Plane Configuration Guide > Pods and Services Reference chapter and Subscriber Manager chapter.

The NAS-Port value can now be explicitly specified using the nas_port variable.

Also, to enable individual bits or group of bits in 32 bits of the NAS-Port (which represents or encodes various pieces that constitute port information), a new keyword, format-e is introduced.

The nas_port variable and format-e keyword are supported in the profile radius accounting and profile radius attribute commands

For more information, see the Cloud Native BNG Control Plane Configuration Guide > Authentication, Authorization, and Accounting Functions chapter.

The Framed Route Support on subscriber sessions enables framed (dynamic) routes to be added for individual subscribers. Framed route per subscriber support is provided through RADIUS or Change of Authorization (CoA).

A framed route is pushed from the Control Plane (CP) to the User Plane (UP) only when the IP address is allocated for the respective address family indicator (AFI). The UP withdraws the framed route when the respective AFI goes down (for example, when an IP address is deallocated).

The configuration format of the framed route is as follows:

• IPv4

  
  Framed-Route = “[vrf <prefix VRF>] {<prefix>/<prefix_length>} [vrf <next hop vrf>] 
                  [<next hop prefix>] [<metric>] [tag <tag-value>] “ 
  Framed-Route = “[vrf <vrf-name>] {<prefix> <netmask>} [vrf <next hop vrf>]  
                  [<next hop prefix>] 
                  [<metric>] [tag <tag-value>] “ 
  
  
  
  cisco-avpair = “[vrf <prefix VRF>] {<prefix>/<prefix_length>} [vrf <next hop vrf>] 
                  [<next hop prefix>] [<metric>] [tag <tag-value>]  
  cisco-avpair = “[vrf <vrf-name>] {<prefix> <netmask>} [vrf <next hop vrf>] 
                  [<next hop prefix>] 
                  [<metric>] [tag <tag-value>] “ 

• IPv6

  
  Framed-IPv6-Route = “[vrf <prefix VRF>] {<prefix>/<prefix_length>}  
                       [vrf <next hop vrf>] 
                       [<next-hop prefix>] [<metric>] [tag <tag-value>] “ 
  cisco-avpair = “[vrf <prefix VRF>] {<prefix>/<prefix_length>} [vrf <next hop vrf>]  
                  [<next hop prefix>][<metric>] [tag <tag-value>] “ 
                              

The description of the format of the framed route is as follows:

• [vrf <prefix VRF>]: This is an optional parameter. Specfies the virtual routing and forwarding (VRF ) prefix.

• {<prefix>/<prefix_length>} or {<prefix> <netmask>}: This is a mandatory parameter. Specifies the prefix and prefix mask or prefix length for the destination.

• [vrf <next hop vrf>]: This is an optional parameter. Specifies the next hop VRF name.

• [<next hop prefix>]: This is an optional parameter. Specifies that when the next hop is specified as "0.0.0.0" for IPv4 or “::” for IPv6, the IP address of the session must be used as the next hop prefix.

• [<metric>]: This is an optional parameter. Specifies the route metric.

• [tag <tag-value>]: This is an optional parameter. Specifies a tag value that can be used as a match for controlling redistribution using route policies.

For information about the framed-route attributes, see Table 1 and Table 2 in the Cloud Native BNG Control Plane Configuration Guide > RADIUS Attributes chapter.

Implementing the framed (dynamic) route support depends on the UP. Therfore, check the UP Cloud Native BNG User Plane Configuration Guide for Cisco ASR 9000 Series Router for the following before enabling the framed route.

• IPv4 and IPv6 framed route support for PPP Termination and Aggregation (PTA) and IPoE

• VRF and next hop VRF support for PTA and IPoE

• CoA support for framed route for PTA and IPoE

• Maximum routes supported per subscriber per AFI for PTA and IPoE

This section provides the following configuration recommendations.

Pool-Size Configuration

While configuring the pool-size, the recommendation is to keep additional buffer of IPs for undisturbed subscriber churn. Consider the following recommendations:

• Released IPs become part of the quarantine queue depending on the quarantine configuration. These IPs cannot be reused until they are free.

• Due to the threshold logic, the CP automatically reserves additional chunks to the User Plane function (UPF) when requried. It based on a first-come-first-server basis.

  In a multiple UPF sharing a pool use case, whichever UPF hits the threshold first is given a chunk. Therefore, free chunks may not be available for other UPFs. That is, 100% pool utilization may not occur for a given pool in certain conditions. In this scenario, configure additional IPs accordingly or split into multiple pools per UPF.

Split-Size Configuration

While configuring the split-size of a dynamic pool, consider the following recommendations:

• Number of IPs in the pool.

• Total number of subscribers—The number of IPs versus the percentage of the number of sessions.

• Number of UPFs sharing the pool.

• Number of sessions per UPF—The number of sessions versus the percentage of the number of UPFs.

• Quarantine time of the pool.

• Churn rate—The CPS of IP allocation, CPS of IP release.

• Maximum routes a UPF can support (example: ASR9k supports 32 routes per loopback in Release 7.4.x/7.5.x).

Each Node Manager (nodemgr) uses per-cache as the split-size of the chunk.

Each UPF is assigned per-dp as the split-size of chunk.

Each Node Manager reserves chunks of per-cache size and further splits (if-applicable) and assigns them to a UPF.

A chunk can be in one of the following states:

• <upf-name>—The chunk assigned to an UPF.

• Free:CP—It is free in the cache-pod, any Node Manager can use it.

• Free:NM0— It is free in the Node Manager instance-0. Only this Node Manager can use it.

• Free:NM1— It is free in the Node Manager instance-1. Only this Node Manager can use it.

• QT:NM0— It is in quarantine in the Node Manage instance-0. This is moved to free after quarantine timer expiry.

• QT:NM1—It is in quarantine the Node Manage instance-1. This is moved to free after quarantine timer expiry.

Threshold Configuration

Changing threshold configuration on-the-fly takes effect only after the next event, such as address-allocation or address-delete. On an idle-system, there may not be any immediate action.

This release supports IPAM enhancements that include updates to the IPAM quaratine timer, address-range level quarantine, pool and User Plane function (UPF) threhsold monitoring, and multiple replica handling

For more information, see the Cloud Native BNG Control Plane Configuration Guide > IP Address Management chapter.

The Monitor Subscriber and Protocol feature supports the debugging functionality.

Monitor Subscriber

The Monitor Subscriber feature captures all the transactional logs for a given subscriber over a specified period of time across all the Kubernetes pods. It also supports the simultaneous monitoring of multiple subscribers on a given cluster. This information allows to track all the events that had occurred for a given subscriber when the subscriber was coming up or going down.

Monitor Protocol

The Monitor Protocol feature replicates the packets from different protocol endpoints of cnBNG and sends it to the OAM pod. There two levels of packet replication that occur:

• First replication dumps only the basic packet information

• Second replication dumps the full packet with details like headers, keys of subscriber, and so on.

This feature captures all ingress and egress packets on the cnBNG protocol pods.

For configuring the Monitor Subscriber and Protocol feature, see the Cloud Native BNG Control Plane Configuration Guide >Monitor Protocol and Subscriber chapter.

The Cloud Native BNG (cnBNG) supports multi-action Change of Authorization (CoA) wherein service providers can activate and deactivate multiple services using a single CoA request. Multi-action CoA is supported for Service-Activate and Service-Deactivate commands.

During the multi-action CoA request, if any of the COA requests fail to activate or deactivate, then any of the services which have been activated or deactivated as part of that CoA request is rolled back to its previous state. The session restores back to the its pre-MA-CoA state upon failure to activation or deactivation.

For more information, see the Cloud Native BNG Control Plane Configuration Guide > Authentication, Authorization, and Accounting Functions chapter.

The Multiple Replica Support for cnBNG Services is designed to support multiple instances of the cnBNG services and load balance the session transactions to address the following requirements:

• Higher scalability

• Calls per Second (CPS) [CEPS - Call Events per Second (CEPS), TPS - Transactions per Second (TPS)]

• Redundancy

The following services must be configured to support multiple instances for load-balancing the session transactions.

• bng-dhcp

• bng-pppoe

• bng-sm

• bng-n4-protocol

• radius-ep

• udp-proxy

• bng-node-manager

To configure Multiple Replica Support, see the Cloud Native BNG Control Plane Configuration Guide > Multiple Replica Support for cnBNG Services chapter.

IPAM is the core component of the subscriber management system. Traditional IPAM functionalities prove insufficient in the Cloud Native network deployments. Therefore, IPAM requires additional functionalities to work with the Cloud Native subscriber management system.

The Static IP Support provides more functionalities on the cnBNG using IPAM. These functionalities are as follows:

• Supports addition of a new static-pool or static-addr-range dynamically when system is running.

  • Send routes when User Plane function (UPF) is already associated.

• Supports removal of a new static-pool or static-addr-range dynamically when system is running

  • Mark the static-pool or static-addr-range offline.

  • Clear subscribers, manually.

  • Delete the configuration. IPAM sends the route-delete command to the UPF if it is already associated.

Note	Changing the UPF name directly in the static IP pool is not supported. To change the UPF name, gracefully delete the static IP pool and readd the new UPF.

Note the following guidelines while configuring a static IP pool:

• An address pool is marked as "static" during configuration. A given address pool can be either configured as "dynamic" or "static" mode only. It cannot be modified while the system is running.

• Each static pool is associated to an Use Plane function (UPF). The IPAM configures all the address-ranges as routes on the UPF. The recommendation is to use the "no-split" configuration to avoid having too many splits and routes.

• The IPV4 address ranges must be configured with the "default-gateway" value, because unlike dynamic address-range, IPAM cannot assign "default-gateway" on its own. Also, the static address-ranges must not be split further. Therefore, use the "no-split" configuration.

For more information, see the Cloud Native BNG Control Plane Configuration Guide > IP Address Management chapter.

The Subscriber Quality of Service (QoS) Policy feature uses the following Cisco AVPs to apply the subscriber QOS policy through RADIUS.

cisco-avpair = "subscriber:sub-qos-policy-in=<ingress qos policy name>" 
cisco-avpair = "subscriber:sub-qos-policy-out=<egress qos policy name>", 

Example:

radius profile 
cisco-avpair = "subscriber:sub-qos-policy-in=qos_in_100mbps", 
cisco-avpair = "subscriber:sub-qos-policy-out=qos_out_100mbps", 

"qos_in_100mbps" and "qos_out_100mbps" are the QoS policy maps that are configured in the User Plane (UP). The merge-level and accounting features are not supported through RADIUS. If unsupported features are passed from RADIUS, behaviour is undefined.

Applying QoS from profile feature-template and through RADIUS using sub-qos-policy-in or sub-qos-policy-out is not supporetd for the same subscriber. When applied, behaviour is undefined.

For information about the sub-qos-policy-in or sub-qos-policy-out attributes, see Table 2 in the Cloud Native BNG Control Plane Configuration Guide > RADIUS Attributeschapter.

The Control Plane supports multiple User Planes (UPs). Therefore, to apply AAA attributes to a specific User Plane (UP), the profile attribute-format command now includes the user-plane keyword in the format-order value.

Also, to provide flexibility in specifiying an attribute string as a AAA attribute, the profile attribute-format command now includes the format-string keyword.

For more information, see the Cloud Native BNG Control Plane Configuration Guide > Authentication, Authorization, and Accounting Functions chapter.

The User Plane (UP) Session Disconnect Notification feature enables the UP to send a session disconnect notification to the Control Plane (CP) in the following scenario:

When the UP deletes a session locally following any local event (for example, mark and sweep).

For a list of scenarios that trigger a session disconnect notification, see the Broadband Network Gateway Configuration Guide for Cisco ASR 9000 Series Routers here: https://www.cisco.com/c/en/us/support/routers/asr-9000-series-aggregation-services-routers/products-installation-and-configuration-guides-list.html.

This notification carries the final statistics for the session and for all services, if accounting is enabled.

The CP initiates the session disconnect for this session only in the CP. The CP then deletes this session. If the session accounting is enabled for this session, the CP sends an accounting "stop record" message to RADIUS.

The UP deletes the session after initiating the session disconnect request to the CP. Therefore, the CP doesn’t send a session release Packet Forwarding Control Protocol (PFCP) message to the UP.