3. Session management

This chapter provides an overview of the common and fixed access session functionality.

3.1. Common functions

While PFCP sessions can support many access types, the basic session management is identical. This section provides an overview of the common session functionality.

3.1.1. Subscribers, QoS, and filters

BNG CUPS sessions are automatically linked together into subscribers, based on a QoS Enforcement Rule (QER) Correlation ID that is received in the PFCP session. 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 following parameters may be passed via PFCP:

  1. subscriber and SLA profile names
    The subscriber profiles must be configured for use with BNG CUPS by enabling the configure subscriber-mgmt sla-profile control cups command for the profile.This flag disables any feature that is not supported within CUPS.
  2. any QoS overrides
  3. SLA filter overrides
    Overrides are either by name or by ID.
  4. Inter-Dest-ID

3.1.2. In-band control plane

Most BNG session types have one or more control plane messages that are sent in­-band and therefore arrive directly on the UPF. Since 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 more 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 configuration, using the application list ibcp keyword. A specific DSCP value (default NC2) can be provisioned and mapped to a specific FC, as usual.

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

The downstream IBCP QoS handling depends on the session type.

3.1.3. IP gateway, services, and routing

In many deployments, a BNG UPF acts as a direct IP gateway for sessions. All IP addresses are allocated by the CPF and installed using the PFCP protocol. Optionally, framed routes can be provided by the CPF.

To assist with forwarding, the CPF signals the following information using the PFCP protocol:

  1. service for forwarding
    The service in which forwarding must occur is a name that maps to a preprovisioned IES or VPRN service.
  2. aggregate routes
    These are the aggregate routes that the BNG UPF can announce in routing protocols to attract traffic. They can be distinguished in policies using the protocol name direct option, for example, configure policy-options policy-statement entry from protocol name direct
    The CPF guarantees that no addresses from this aggregate are assigned to sessions on another BNG UPF.
    For more information about route policies, refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide.
  3. gateway addresses
    For IPv4, the gateway address is typically a dedicated address within the aggregate route. For IPv6, the gateway address is a link-local address, and only one link-local address per VPRN or per IES is supported for IPv6.

The BNG UPF still runs the appropriate routing protocols and responds to ARP/ND for the gateway addresses.

3.1.4. 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:

  1. aggregate octet counters
    This counter is always signaled.
  2. aggregate packet counters
    If enabled by the CPF, this counter is signaled.

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:

  1. the UPF is explicitly queried by the BNG CPF via a PFCP Session Modification Request
  2. the SPI counters are modified while the SPI statistics are enabled; the BNG UPF includes the counters for the old SPI in a PFCP Session Modification Response
  3. the BNG CPF periodic URR reporting is enabled and the BNG UPF sends unsolicited PFCP Session Report Request messages

Statistics reporting in PFCP is always done in an incremental manner. This means that only new statistics, since 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.

Since statistics are based on QoS counters, sessions sharing the same 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 is changed, the BNG UPF reports the final SPI statistics in PFCP if instructed to do so by the BNG CPF.

The reporting automatically takes hardware failures into account. Statistics since the last report are irretrievably lost. However, due to 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.

3.1.5. 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 the following.

  1. The show service active-subscribers 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).
  2. The show subscriber-mgmt statistics 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 listed in Operational commands and debugging.

3.2. Fixed access sessions

To enable fixed access sessions, a capture-sap must be provisioned under service vpls 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.

The following example shows the 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:

  1. l2-access-id (logical port)
    This parameter identifies the port, LAG, or pw-port where the session is terminated.
  2. all applicable VLAN tags
    Together with the l2-access-id, this identifies a SAP where the session is terminated, also known as an l2-circuit. The BNG CPF must signal all the tags to match provisioning. For example, it is not allowed to only signal an s-tag for a q-in-q port.
  3. source MAC address
  4. PPPoE session ID
    This is used for PPPoE only.
  5. IP anti-spoofing IP address (optional)
    The IP address to enable IP anti-spoofing is optional. 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.

3.2.1. Downstream IBCP

For fixed access, downstream IBCP packets are handled directly in the data path. These packets bypass per-session processing, including QoS and filters. Ingress QoS is applied, as usual, based on the provisioning. Egress QoS is based on the QoS configuration of the capture SAP that is linked to the session.

3.2.2. 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.

Creation of SAPs can be manipulated by configuring a SAP template under the following command:

configure subscriber-mgmt sap-template

Similarly, group-interface creation can be manipulated by configuring a group interface template under the following command:

configure subscriber-mgmt group-interface-template

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

Note:

The SAP and group interface templates must be configured on the BNG UPF (as well as the name "default") or the session setup fails.

A SAP template allows the configuration of the following parameters:

  1. hold-time
    This parameter delays the deletion of the SAP after the last PFCP session is removed. An infinite hold-time can be configured but is not recommended. Idle SAPs can be cleared using the idle-saps option under clear subscriber-mgmt sap-template.
  2. cpu-protection and dist-cpu-protection
    For more information about CPU protection, refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide, section “Centralized CPU protection and distributed CPU protection”.
    Note:

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

A group interface template allows configuration of the following parameters:

  1. ip-mtu
    This MTU is applied to outgoing packets.
  2. urpf-check
    For information, refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide, section “Unicast reverse path forwarding check”.
  3. icmp
  4. remote-proxy-arp
    For information, refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide, section “Proxy ARP”.
Note:

Changing the configuration of a template does not automatically change all created SAPs or group interfaces.