Session management

The BNG CUPS automatically links sessions together into subscribers, based on the QoS Enforcement Rule (QER) Correlation ID it receives in the PFCP session. If the BNG-UP does not receive a QER Correlation ID, it assumes there is only one session per subscriber.

The usual subscriber-management processing applies, as described in the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide, sections "QoS for subscribers and hosts" through "Configuring IP and IPv6 filter policies for subscriber hosts".

The PFCP may pass the following parameters:

• subscriber and SLA profile names; if these are not provided the name "default" is used

  Note: You must always configure the SLA and subscriber profiles for use with BNG CUPS; for example, configure subscriber-mgmt sla-profile control cups or configure subscriber-mgmt sub-profile control cups. This disables any feature that is not supported within BNG CUPS.

• direct QoS overrides of QoS objects such as aggregate-rate, schedulers, arbiters, queues, and policers

• SLA filter overrides, either by name or ID

• intermediate destination ID

PFCP can also signal GBR and MBR values directly in the QER, which is not linked directly to a specific QoS object. If the QER applies to the entire session, you can map the MBR and GBR to a direct QoS object PIR or CIR override using the configure subscriber-mgmt sla-profile name pfcp-mappings session-qer command. The MAG-c signals the QER rate, for example, to install a session-AMBR (5G) or APN-AMBR (4G) for FWA sessions.

Most BNG session types have one or more control plane messages that are sent in-band and therefore arrive directly on the BNG-UP. Because the BNG-UP cannot handle these messages, they are forwarded to the MAG-c. To accomplish this, the MAG-c installs specific Ethernet or IP filter rules that match these packets; for example, by matching UDP destination port 67 to extract DHCP. These packets are encapsulated in GTP-U and sent to the MAG-c. Similarly, the MAG-c sends downstream In-Band Control Plane (IBCP) packets over GTP-U toward the BNG-UP.

For upstream traffic, the BNG-UP sends any control plane messages that do not match a session over a default tunnel. See Default IBCP session for information about how this tunnel is signaled. If the control plane messages do not match the default tunnel rules, the messages are dropped.

When a session is created, either out-of-band or via a trigger over the default tunnel, the MAG-c installs per-session control plane rules for both upstream and downstream. Packets that match the upstream rules are forwarded to the MAG-c using the signaled GTP-U parameters. For downstream rules, the BNG-UP allocates a TEID that the MAG-c can use to send packets. The BNG-UP does not support a default downstream IBCP tunnel.

The upstream IBCP (including default) follows the sgt-qos dscp application configuration, using the ibcp keyword on the router or VPRN. A specific DSCP value (default NC2) can be provisioned and mapped to a specific FC, as usual.

See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Quality of Service Guide, section "QoS for Self-Generated (CPU) Traffic on Network Interfaces" for more information.

Downstream IBCP packets are handled directly in the datapath. Ingress QoS is applied based on the provisioning. Egress QoS depends on the following session types:

• fixed access sessions

  Egress QoS packets bypass per-session processing, including egress QoS and filters. Egress QoS is instead based on the QoS configuration of the capture SAP that is linked to the session.

• FWA sessions

  Egress QoS packets go through regular per-session processing and are subject to the QoS and filters provisioned in the SLA profile.

In many deployments, a BNG-UP acts as a direct IP gateway for sessions. The MAG-c provides all the IP addresses and framed routes using the PFCP protocol. To assist with forwarding, the MAG-c also signals the following information using the PFCP protocol:

• name of the preprovisioned IES or VPRN service in which forwarding must occur

• aggregate routes that the BNG-UP announces in routing protocols to attract traffic

  Note: The MAG-c guarantees that no addresses from the aggregate routes are assigned to sessions on another BNG-UP. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide for more information about route policies.

• IPv4 gateway address, which is typically a dedicated address within the aggregate route

• IPv6 gateway link-local address, only one of which is supported per VPRN or IES

The BNG-UP runs the appropriate routing protocols and responds to ARP/ND for the gateway addresses. For the purpose of exporting routes, the operator can distinguish all CUPS routes using the pfcp option for the configure policy-options policy-statement entry from origin command. Additionally, the operator can further distinguish routes using the following options for the protocol command in the same context:

• sub-mgmt option for session IP addresses and prefixes, as signaled in the UE IP Address IE in PFCP
• managed option for framed routes, as signaled in the Framed-Route IE in PFCP
  Note: When using the pd-as-framed-route option on the MAG-c, an IPv6 PD prefix uses the managed option (instead of the sub-mgmt option) because the BNG-UP cannot distinguish the PD framed route from a regular framed route.
• direct option for all other routes, such as aggregate routes and gateway addresses

Statistics reporting uses the PFCP Usage Reporting Rule (URR) mechanism. The BNG-UP supports a single URR to count all statistics that are related to a session. The BNG-UP supports sending the following statistics for the URR:

• Aggregate octet counters are always signaled.

• Aggregate packet counters are signaled, if enabled by the MAG-c.

• Per-queue and per-policer statistics are signaled, if enabled by the MAG-c. The specific counters depend on the statistics mode (stat-mode) configured in either the QoS policy or SLA profile.

All counters, including aggregates, are based on QoS counters and are therefore affected by QoS modifiers, such as the packet-byte-offset command.

The BNG-UP sends reports for a URR in the following cases:

• The MAG-c explicitly queries the BNG-UP via a PFCP Session Modification Request.

• The periodic URR reporting is enabled and the BNG-UP sends unsolicited PFCP Session Report Request messages.

• A threshold or quota is reached; see Threshold and quota monitoring for more information.

PFCP statistics are reported in an incremental manner. This means that only new statistics after the last report are signaled. To achieve this, the BNG-UP baselines the counters on every report. Consequently, it is not possible to manually clear statistics on the BNG-UP using the clear service statistics subscriber command. Other operational commands (for example, show service active-subscribers detail) only show the accumulated statistics on the BNG-UP.

Because statistics are based on QoS counters, sessions sharing the same SLA Profile Instance (SPI) also share statistics, and a report for one session baselines the counters for the entire SPI. As a result, per-session statistics on the MAG-c are not correct when sharing an SPI; however, their aggregate counts are correct. The MAG-c must provide the appropriate aggregate level (for example, subscriber-level accounting). When an SPI changes, the BNG-UP reports the final SPI statistics in PFCP if instructed to do so by the MAG-c.

Hardware failures are automatically taken into account for statistics reporting. Statistics generated after the last report are irretrievably lost. However, as a result of the incremental reporting, the MAG-c does not lose any older counters and does not see a sudden reset. That is, aggregate counters on the MAG-c never decrease as a result of a hardware failure. However, the BNG-UP local statistics as seen in show commands reset upon a hardware failure, and therefore a mismatch of MAG-c counters may result.

MAG-c threshold and quota monitoring builds upon the URR-based usage reporting, as described in Statistics Reporting. The MAG-c signals a quota or threshold in the URR to monitor the total volume consumed. When a threshold or quota is reached, the UP generates a usage report to the MAG-c, including the consumed statistics. The UP indicates in the Usage Report Trigger field, whether the report was triggered by a quota or a threshold. This allows the MAG-c to take appropriate actions, for example:

• trigger a statistics report for offline charging
• request new quota or thresholds for online charging
• apply more complex out-of-credit actions such as custom PCC rules

When a threshold is reached, the UP reapplies the threshold immediately. This can be used to enable volume-based envelope reporting, where a report is generated based on the change in volume, for example every 1 GB, instead of periodically.

When a quota is reached, the UP immediately stops forwarding all traffic associated with the URR. For the session URR, it drops traffic until new quota are granted. Control plane traffic is still sent to the MAG-c corresponding to the IBCP rules.

Internally, the UP uses credit-control categories to perform monitoring. See the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide, "Volume and time-based accounting", for more information about credit-control categories. This has the following consequences:

• As with category maps, monitoring is done per SPI, not per session. To avoid unexpected behavior with per-session charging, it is important to use a single SPI per-session model.
• Line cards consume category resources. Specifically, each monitored unit (for example, total volume) per URR consumes one category.
• Checks for category exhaust limits are performed periodically and not on each packet. This means that a monitoring overshoot is possible. The amount of overshoot depends on the system type and system load.

Most of the traditional BNG operational commands, as described in the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide, apply to the CUPS BNG-UP. The significant exceptions to this rule are operational commands related to specific protocols (such as DHCP, DHCPv6, RADIUS, and PPPoE), because a BNG-UP is not aware of these states.

The primary BNG-UP operational commands are as follows:

• show service active-subscribers

  This command contains several sub-commands that provide details about a specific subscriber or session within a subscriber. These commands incorporate information about CUPS subscribers. Information that is only available on the MAG-c is not shown on the BNG-UP (for example, details on RADIUS and metadata such as remote-id and circuit-id).

• show subscriber-mgmt statistics

  This command contains several sub-commands that provide a wide variety of statistics on various granularity levels. These commands are extended to incorporate BNG CUPS statistics.

IBCP statistics can be displayed via the PFCP statistics using the show subscriber-mgmt pfcp statistics command.

Operational commands that are specific to PFCP associations are described in Operational commands and debugging.

The system auto-provisions any required objects, which means that subscriber interfaces, group interfaces, and SAPs do not need to be provisioned. These objects are hidden from configuration and are not modifiable. Aside from the capture SAP, the only required configuration is the VPRN or IES where IP forwarding occurs.

configure subscriber-mgmt sap-template

The SAP template supports the configuration of the following:

• Use the hold-time command to delay the deletion of the SAP after the last PFCP session is removed.

  Note: Although the infinite option can be configured for the hold-time command, it is not recommended.

  Use the following command option to clear idle SAPs.

  clear subscriber-mgmt sap-template idle-saps

• Use the cpu-protection and dist-cpu-protection commands to configure CPU protection; see the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide, section "Centralized CPU protection and distributed CPU protection" for more information about CPU protection.

  Note: On platforms where CPU protection and distributed CPU protection are not supported, these commands are ignored.

Use the commands in the following context to configure a group interface template to manage the created group-interface.

configure subscriber-mgmt group-interface-template

When setting up a PFCP session, the PFCP passes a template name. If the template name is absent, the system falls back to the name "default".

Use the following commands to configure the group interface template:

• Use ipv4 icmp to configure ICMP.

• Use ip-mtu to configure IP MTU to outgoing packets.

• Use ipv4 remote-proxy-arp to configure the remote proxy ARP; see 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide, section "Proxy ARP".

• Use ipv4 urpf-check and ipv6 urpf-check to configure URPF checks; see 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide, section "Unicast reverse path forwarding check".

• Use trigger-packet data to enable data trigger.

To enable fixed access sessions, you must provision a capture SAP under the VPLS service with appropriate values for trigger-packet and a link to the PFCP association. The triggers are mandatory and are not automatically derived from the default IBCP tunnel.

Sessions without any encapsulation are supported on a dot1q capture SAP. The system creates internal constructs to correctly handle sessions without encapsulation. These sessions can be combined with dot1q encapsulated sessions on the same capture SAP.

The following example shows trigger-packet provisioning in a PFCP association configuration.

A:admin@DUT-B# info 
    pfcp {
        association "BNG-CPF"
    }
    trigger-packet {
        pppoe true
    }

The BNG-UP supports both 4G and 5G FWA sessions.

Enterprise IP VPNs often use BGP to exchange routing information, for example, between headquarters and branch offices. Providing BGP connectivity to an enterprise router via a residential access connection requires BGP peering over a BNG CUPS subscriber session. To configure this on the BNG-UP, use a static BGP neighbor that has as its neighbor address the fixed IPv4 or IPv6 WAN address of the subscriber session.

The following example shows an auto-generated configuration based on a session setup.

# configure service vprn 1000
    subscriber-interface "_tmnx_cups_1131076" fwd-service 2148278386 
    /fwd-subscriber-interface "_tmnx_cups_1131075" wan-mode mode128 
        description "default subscriber interface template"
        private-retail-subnets
        address 10.0.240.254/20
        ipv6
        exit
    exit
--- the auto-generated configuration ends here ---
    bgp
        group "enterprise-1"
            neighbor 10.0.0.1
                family ipv4
                local-address 10.0.240.254
                type external
                local-as 65536
                peer-as 65501
            exit
        exit
        no shutdown
    exit
    no shutdown