The Cisco IOS XR platforms have a distributed hardware architecture that uses a switch fabric to interconnect a series of chassis slots. Each slot can hold one of several types of line cards (LCs). Each line card in these routers has integrated input-output and forwarding engines. The system can identify and handle the subscriber flow either on the route processor (RP) or on the LC. This architecture thereby provides multiple levels of redundancy and scalability for the subscriber management functionality in cnBNG.

The cnBNG UP architecture is designed to interoperate with cnBNG CP with minimal integration efforts. The main components of cnBNG user plane on the Cisco IOS XR platform are:

• Subscriber Provisioning Agent (SPA) —is the common interface to the control plane that is bundled with the existing Cisco IOS XR image. This interface helps to have a minimal configuration requirement to transform from an integrated physical BNG router to a cnBNG user plane. SPA consists of a transport layer at the top that interfaces with the CP, and an API layer at the bottom that isolates the network operating system (NOS) and the CP. This isolation from the NOS helps to make the control plane hardware-agnostic and portable across multicloud environments.

  The functionality of SPA includes:

  • The support for standard PFCP port for a single UP connection.

  • The support for nonstandard ports for both PFCP and GTPv1-U for multiple connections.

  • UP to CP keep alive (KA) to detect any communication channel faults between CP-UP.

• NOS Adaptation Layer (NAL) —translates the CP instructions or messages coming to the UP to Cisco IOS XR-defined format. It is the Cisco IOS XR implementation of cnBNG APIs that interfaces with Cisco IOS XR infra components for various functions. These functions include input-output of packets, interface creation and deletion, subscriber feature provisioning, route operations, subscriber interface statistics and notifications. NAL also manages the subscriber flow on the Cisco IOS XR platform and handles the high availability (HA) requirements of Cisco IOS XR infrastructure.

  The cnbng-nal is the internal process that provisions all the above NAL functionalities. For details on commands that are related to NAL, see the Configuring Cloud Native BNG User Plane chapter and the Verifying Cloud Native BNG User Plane Configurations chapter.

• Platform-specific Layer —is the API adaptation layer that helps to plug-in different types of hardware architectures to the common Cisco IOS XR infrastructure. This layer in turn helps to extend the user plane functionality to other Cisco IOS XR platforms without altering the basic infrastructure.

  Platform-specific layer defines the forward API calls that each underlying platform of the user plane has to implement. The system uses these APIs to provision the following BNG functions:

  • IPoE subscriber traffic classification—for L2-connected subscribers that are based on port, MAC, and VLAN.

  • PPPoE subscriber traffic classification—for L2-connected subscribers that are based on port and PPPoE session-ID.

The support for cnBNG user plane functionality on Cisco ASR 9000 Series Routers is compatible with the following line card (LC), route switch processors (RSPs), and modular port adapters (MPAs).

Note	The Cisco IOS XR Software Release 7.3.1 supports cnBNG UP only on Cisco ASR 9000 High Density 100GE Ethernet line cards. See the table for the list of supported PIDs.

This section lists the set of subscriber features that cnBNG user plane on the Cisco IOS XR platform supports.

• IPv4 or IPv6:

  • Maximum Transmission Unit (MTU)—that defines the maximum size of each packet that you can transmit during the subscriber session.

  • Unicast Reverse Path Forwarding (URPF)—that ensures that the system does not accept any traffic on the subscriber interface from malformed or forged IP source addresses.

  • Internet Control Message Protocol (ICMP)—a supporting protocol that networking devices use to send error messages and operational information to the originator of transmission.

• Access Control List (ACL)—that performs packet filtering to control the traffic flow into and out of network interfaces. It helps to define the access rights such as, filtering the content, blocking access to various resources and so on, for a subscriber .

  Supported ACL types are:

  • Input ACL (IPv4 or IPv6)

  • Output ACL (IPv4 or IPv6)

• QoS:

  • Policing (input and output)—that allows you to control the maximum rate of traffic sent or received on an interface. It also allows to partition a network into multiple priority levels or class of service (CoS).

  • Shaping (output)—that allows you to control the traffic flow that exits an interface to match its transmission to the speed of the remote target interface. It also ensures that the traffic conforms to policies contracted for it.

  • Policy Merging—that merges multiple QoS policies on a single subscriber. The UP supports a maximum of 6 policy-maps and 10 class-maps, including the default ones.

• Hierarchical QoS (H-QoS)—that allows you to specify QoS behavior at multiple policy levels, which provides a high degree of granularity in traffic management. cnBNG supports the following two-level hierarchical policy for deploying QoS:

  • Parent policy:

  • Child policy

  H-QoS is applied on the router interface using nested traffic policies. The first level of traffic policy, the parent traffic policy, is used for controlling the traffic at the main interface or sub-interface level. The second level of traffic policy, the child traffic policy, is used for additional control over a specific traffic stream or class. The child traffic policy, is a previously defined traffic policy, that is referenced within the parent traffic policy. Two-level H-QoS is supported on both ingress and egress directions on all line cards and on physical or bundle main interfaces and sub-interfaces.

  To know more about H-QOS, refer the Configuring Hierarchical Modular QoS chapter in the Modular QoS Configuration Guide for Cisco ASR 9000 Series Routers

• HTTP Redirect using PBR (for input policy)—that redirects subscriber traffic to a destination other than to its original destination. Policy-based Routing (PBR) makes packet forwarding decisions based on the policy configurations, instead of routing protocols.

• Accounting: cnBNG UP supports periodic accounting for these accounting types:

  • Session Accounting—which is the statistics of a subscriber session.

  • Service Accounting:—which is the statistics for each service (collection of features) that is enabled for a subscriber.

  Note	You cannot enable service accounting without session accounting. You cannot have different periodicity for session and service accounting.

• Lawful Intercept (for mediation device in default or non-default VRF)—that allows Law Enforcement Agencies (LEA) to conduct electronics surveillance as authorized by judicial or administrative order.

• Multiple Framed Route—allows a large number of customer networks to reach through framed routes through a single broadband connection. Framed Route is supported on both IPoE and PPPoE sessions. There’s no limit enforced to the number of framed routes per session. You don't have to configure or enable Framed Route through command line interface as it is downloaded from RADIUS.

Read more about these features in the Cisco ASR 9000 Series Aggregation Services Router Broadband Network Gateway Configuration Guide.

High Availability (HA) enables network-wide protection by providing fast recovery from faults that may occur in any part of the network. The cnBNG user plane does not delete the subscriber state, summary subnet route state, subscriber route state, and so on, in a stable system except in a few scenarios. These scenarios can be either explicit execution of CLI commands to clear the session, process restart of peer process, mark and sweep procedure (an internal clean-up process which detects and reclaims the memory that is used by unused objects) of cnbng-nal process, route processor fail over (RPFO), or deletion of parent interface.

This section describes the expected behavior if a high availability event such as a router reload or RPFO occurs on the cnBNG user plane:

• NAL restores the last stable (check-pointed) session state with best effort after the HA event.

• To ensure data and session integrity between NAL and peer processes, the system triggers a mark and sweep procedure during cnbng-nal process restart. During this process, the NAL might not be able to restore the sessions due to unforeseen issues from the feature or from the IOS XR infra components. In that case, the system deletes those sessions and sends a notification to the CP.

• The cnbng-nal process restart does not initiate automatic reconciliation procedure between the CP and the UP. The CP triggers this explicitly using a CLI configuration.

• The Cisco IOS XR platform has active and standby hardware level support (active RSP and standby RSP) on logical interface subscriber. The data sync between these nodes is not real time. The cnbng-nal process periodically syncs for various internal data on a best-effort basis. There can be a few cases where session data is out of sync between route processors which leads to session recreate failure after RFPO. These cases maybe for recently created sessions or inflight sessions. The system deletes those sessions at UP and sends a notification to the CP.

• The CP acts on these notification events to make sure that the subscriber state is in sync. If not, it leads to out of sync sessions between the UP and the CP in such scenarios.

• During process restart or RPFO, mark and sweep procedure might lead to subscriber session deletion on UP.

• The UP might not push the final statistics if a process restart or RPFO happens while a subscriber or service deletion is in progress. In that case, the CP considers the last collected statistics PCRF or back-end statistics as the final statistics.

The cnBNG user plane functionality on the Cisco IOS XR platform does not support these functionalities:

• Standalone PPP use case with cnBNG enabled

• Per pool or VRF tag support for IP pool subnet routes installed with a specific tag for the entire UP

• Back-to-back RPFO or switchover without graceful shutdown

• LC-based subscribers

• Subscriber redundancy group (SRG) for Bundle-Ethernet

• Enabling service accounting without session accounting

• Different periodicity for session and service accounting