Session management
This chapter provides an overview of the common and fixed access session functionality.
Subscribers, QoS, and filters
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 CUPS UPF 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 BNG CUPS CPF signals the QER rate, for example, to install a session-AMBR (5G) or APN-AMBR (4G) for FWA sessions.
IBCP
Most BNG session types have one or more control plane messages that are sent in-band and therefore arrive directly on the UPF. Because the BNG UPF cannot handle these messages, they are forwarded to the BNG CPF. To accomplish this, the BNG CPF 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 CPF. Similarly, the BNG CPF sends downstream In-Band Control Plane (IBCP) packets over GTP-U toward the BNG UPF.
For upstream traffic, the BNG UPF 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 BNG CPF installs per-session control plane rules for both upstream and downstream. Packets that match the upstream rules are forwarded to the BNG CPF using the signaled GTP-U parameters. For downstream rules, the BNG UPF allocates a TEID that the BNG CPF can use to send packets. The BNG UPF 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 data path. Ingress QoS is applied based on the provisioning. Egress QoS depends on the session type. The session types are as follows:
-
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.
IP gateway, services, and routing
In many deployments, a BNG UPF acts as a direct IP gateway for sessions. The BNG CPF provides all the IP addresses and framed routes using the PFCP protocol. To assist with forwarding, the BNG CPF 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 UPF announces in routing protocols to attract traffic
Note: The BNG CPF guarantees that no addresses from the aggregate routes are assigned to sessions on another BNG UPF. 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 UPF 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 BNG CPF, an IPv6 PD prefix uses the managed option (instead of the sub-mgmt option) because the BNG UPF 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
Statistics reporting uses the PFCP Usage Reporting Rule (URR) mechanism. The BNG UPF supports a single URR to count all statistics that are related to a session. The BNG UPF supports sending the following statistics for the URR:
-
Aggregate octet counters are always signaled.
-
Aggregate packet counters are signaled, if enabled by the CPF.
-
Per-queue and per-policer statistics are signaled, if enabled by the CPF. 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 UPF sends reports for a URR in the following cases:
-
The BNG CPF explicitly queries the UPF via a PFCP Session Modification Request.
-
The periodic URR reporting is enabled and the BNG UPF sends unsolicited PFCP Session Report Request messages.
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 UPF baselines the counters on every report. Consequently, it is not possible to manually clear statistics on the BNG UPF 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 UPF.
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 BNG CPF are not correct when sharing an SPI; however, their aggregate counts are correct. The BNG CPF must provide the appropriate aggregate level (for example, subscriber-level accounting). When an SPI changes, the BNG UPF reports the final SPI statistics in PFCP if instructed to do so by the BNG CPF.
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 BNG CPF does not lose any older counters and does not see a sudden reset. That is, aggregate counters on the BNG CPF never decrease as a result of a hardware failure. However, the BNG UPF local statistics as seen in show commands reset upon a hardware failure, and therefore a mismatch of BNG CPF counters may result.
Operational commands
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 UPF. The significant exceptions to this rule are operational commands related to specific protocols (such as DHCP, DHCPv6, RADIUS, and PPPoE), because a BNG CUPS UPF is not aware of these states.
The primary BNG CUPS UPF 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 BNG CPF is not shown on the BNG UPF (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.
SAP and group interface templates
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.
You can manage SAP creation by configuring a SAP template under the configure subscriber-mgmt sap-template command. The SAP template supports the configuration of the following:
-
The hold-time command delays the deletion of the SAP after the last PFCP session is removed. The infinite option can be configured for the hold-time but it is not recommended. Idle SAPs can be cleared using the idle-saps option under clear subscriber-mgmt sap-template.
-
The cpu-protection and dist-cpu-protection commands 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.
Similarly, group-interface creation can be manipulated by configuring a group interface template under the configure subscriber-mgmt group-interface-template command. When setting up a PFCP session, a template name is passed using PFCP. If the template name is absent, the system falls back to the name "default".
A group interface template allows the configuration of the following:
-
ip-mtu; is applied to outgoing packets
-
urpf-check; see 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide, section "Unicast reverse path forwarding check"
-
icmp
-
remote-proxy-arp; see 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide, section "Proxy ARP"
Changing the configuration of a template does not automatically change all created SAPs or group interfaces.
Mixing different encapsulation sessions on the same port
- on a :*.* capture SAP: dot1q and null encapsulation sessionsNote: To support this, the user must set the configure service system extended-default-qinq-sap-lookup command to true on the systems where this is not the default.
- on a :* capture SAP: null encapsulation sessions
The system internally creates SAPs with :N.0, :0.0, and :0 encapsulation to support the mix. The user can apply the SAP templates to these SAPs similarly to any other SAPs.
Traffic as seen on the wire typically does not include an S-tag or C-tag with a tag value explicitly set to zero because the absence of a tag is equal to a zero tag. Occasionally, an explicit zero tag is included; for example, when a dot1p or DEI bit needs to be set in the tag header. The internally created SAPs interact with such traffic as follows:
- Because generated traffic never includes an explicit zero tag, it is not possible to set a dot1p or DEI bit in the tag header.
- Traffic with a C-tag value explicitly set to zero is always dropped, even if it matches an internally created :N.0 or :0.0 SAP.
- Traffic with only the S-tag value explicitly set to zero is handled if it matches either a :0 or a :0.0 SAP. This kind of traffic matches the same session as if it was received without any S-tag.
Fixed access sessions
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
}
To identify sessions in the data plane, the BNG CPF must provide the following parameters:
-
The logical port (also known as the Layer 2 access ID) identifies the port, the LAG, or the pw-port where the session is terminated. The BNG CPF knows the correct logical port because the BNG UPF includes this logical port in the IBCP packets sent over the default IBCP tunnel. See Default IBCP session.
-
The VLAN tags, along with the logical port, identify a SAP where the session is terminated, also known as a Layer 2 circuit (l2-circuit). The BNG CPF must signal all the VLAN tags to match the encapsulation type provisioned for the port; for example, only signaling an s-tag for a q-in-q port is not allowed. As an exception, the BNG CPF can install sessions without any VLAN tags on a dot1q capture SAP, as described at the beginning of this section.
-
The source MAC address is required.
-
The PPPoE session ID is used for PPPoE only.
-
The IP anti-spoofing IP address is optionally used to enable IP anti-spoofing. While this can be signaled per session, the BNG UPF only supports a single anti-spoof type per SAP. When a second session on the same SAP has a conflicting anti-spoof indication, the setup fails. IP anti-spoofing is not supported for framed routes.
For PPPoE, the BNG UPF can perform LCP keep-alive offload, if supported and signaled by the BNG CPF. The BNG UPF automatically signals support for this feature when the PFCP association is created.
Fixed wireless access sessions
To configure Fixed Wireless Access (FWA) sessions, the operator must provision a GTP UPF data endpoint using the gtp upf-data-endpoint command in the service vprnor router context. The endpoint must reference an interface in the routing instance where GTP-U tunnels to the RAN are set up. Additionally, an FPE construct is required to enable datapath functions in the router. The FPE must be configured as type multi-path. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Interface Configuration Guide for more information.
The system automatically creates all the required constructs to correctly handle FWA sessions. Additionally, the system load-balances sessions over each FPE path, using the path that is the least loaded when the session is set up.
The following example shows provisioning of a UPF data endpoint and multipath FPE.
[gl:/configure service vprn "to_ran" gtp upf-data-endpoint]
A:admin@BNG-UPF# info
interface "gtp_u_endpoint"
fpe 1
[gl:/configure fwd-path-ext fpe 1]
A:admin@BNG-UPF# info
multi-path {
path 1 {
pxc 1
}
}
application {
sub-mgmt-extension true
}
Unlike in fixed access sessions, a default IBCP tunnel is not used for FWA sessions because the initial session setup is out-of-band and does not involve the BNG UPF. Per-session IBCP is supported to forward DHCP (Deferred Allocation), ICMPv6 RS/RA, and DHCPv6 packets.
Routed subscriber 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 CUPS UPF, use a static BGP neighbor that has as its neighbor address the fixed IPv4 or IPv6 WAN address of the subscriber session.
Example configuration
# configure service vprn 1000
--- snip ---
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
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
BNG CUPS subscriber sessions support static BGP neighbors for the following:
- BGPv4 neighbors with IPv4 and IPv6 address families
- BGPv6 neighbors with IPv4 and IPv6 address families
- IPoE and PPPoE sessions
- numbered and unnumbered interfaces
- single-hop and multi-hop BGP neighbors