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-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, or the name "default" if no profiles are configured

    Note: You must always configure the SLA and subscriber profiles for use with BNG CUPS. This disables any feature that is not supported within BNG CUPS. Use the commands in the following contexts to configure a SLA and subscriber profile. 
    configure subscriber-mgmt sla-profile control cups
configure subscriber-mgmt sub-profile control 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, use the following command to map the MBR and GBR to a direct QoS object PIR or CIR override. 
configure subscriber-mgmt sla-profile name pfcp-mappings session-qer

The MAG-c 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 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.

IP gateway, services, and routing

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, use the following command option to distinguish all CUPS routes.
configure policy-options policy-statement entry from origin pfcp

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

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 use the following command to manually clear statistics on the BNG-UP.

clear service statistics subscriber
Other operational commands such as the following only show the accumulated statistics on the BNG-UP.
show service active-subscribers detail

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.

Selective aggregate statistics

Default and custom aggregate statistics calculation

The BNG-UP calculates aggregate statistics based on the statistics of policers and queues. By default, the BNG-UP accumulates all the following policers and queues for statistics calculation:

  • All egress queues

    All egress queues includes both dynamically created and statically configured queues.

  • All statically configured egress policers

    Dynamic egress policers are by default not included. The traffic that is subject to a dynamic egress policer is usually also subject to a static or dynamic egress queue, and therefore is already counted.

  • All ingress queues

    All ingress queues include both dynamically created and statically configured queues.

  • All ingress policers

    All ingress policers includes both dynamically created and statically configured policers.

You can change the default calculation by configuring a custom selection of policers and queues. Use the commands in the following context to change the default queues and policers that the BNG-UP accumulates for aggregate statistics calculations. 

configure subscriber-mgmt sla-profile aggregate-qos-statistics

custom selective aggregate statistics to only count policers

The following example shows a configuration that counts all dynamic policers and no queues.

[ex:/configure subscriber-mgmt sla-profile "example" aggregate-qos-statistics]
A:admin@UP-East# info
egress {
    queues {
        none
    }
    policers {
        all-dynamic
    }
}

Use case examples

The following are examples of use cases for which you may want to configure granular control of aggregate statistics calculation:
  • to zero rate specific traffic
  • to avoid double counting packets in QoS hierarchies that combine policers and queues

You can use this functionality to zero rate traffic so it is not counted in aggregate statistics, while maintaining full QoS enforcement. The following example shows a zero-rating QoS configuration for FWA with dynamic flows, where the following applies:

  • The zero-rated traffic is identified by a specific DSCP value AF42, and is excluded from aggregated statistics but is still subject to the session AMBR.
  • All traffic other than the zero-rated traffic is subject to a dynamic policer (SDF MBR), and either the session AMBR queue, or a GFBR or MFBR dynamic queue.
  • The QoS profile is configured with the following:
    • A single static queue enforces the session AMBR. This is not visible in the configuration example because the default queue is used.
    • A single static policer for zero rating is configured with an infinite PIR or CIR because this policer is only used for counting, and not for rate enforcement.
    • All necessary configurations to enable dynamic flows are used. See Dynamic QoS based on PCC rules for more information about the configuration of dynamic objects.
    • A single static IP criteria entry is used, with a higher precedence value (lower entry ID) than any dynamic criteria. This entry matches the DSC accepts the traffic, and subjects the traffic to the static policer and static queue.
  • The SLA profile is configured to use queue 1 as the session AMBR and only count traffic from any dynamic policers for aggregate statistics.

Zero rating configuration with dynamic QoS

Note: Only the egress IPv4 configuration is shown in the example, to reduce the example output.
[ex:/configure qos sap-egress "zero_rating"]
A:admin@UP-East# info
    subscriber-mgmt {
        pcc-rule-entry {
            range {
                start 10000
                end 65535
            }
        }
        dynamic-policer {
            policer-id-range {
                start 10
                end 63
            }
        }
        dynamic-queue {
            queue-id-range {
                start 2
                end 8
            }
        }
    }
    policer 1 {
        description "Policer used for zero-rated traffic"
        rate {
            pir max
            cir max
        }
    }
    ip-criteria {
        entry 10 {
            match {
                dscp af42
            }
            action {
                type accept
                policer 1
                queue 1
            }
        }
    }
[ex:/configure subscriber-mgmt sla-profile "default"]
A:admin@UP-East# info
    control {
        cups true
    }
    egress {
        qos {
            sap-egress {
                policy-name "zero_rating"
            }
        }
    }
    aggregate-qos-statistics {
        egress {
            queues {
                none
            }
            policers {
                all-dynamic
            }
        }
    }
    pfcp-mappings {
        session-qer {
            downlink {
                queue 1
            }
        }
    }

You can also use the selective aggregate statistics functionality to avoid double counting packets in more complex QoS hierarchies. The following example shows a configuration where all the traffic is subject to a common queue, but DNS (TCP/UDP port 53) traffic is additionally subject to a lower rate using IP criteria and policers. The aggregate statistics configuration shown in the example avoids counting the DNS traffic twice, as part of the static policer and the static queue.

Configuration to avoid double-counting aggregate statistics as part of the static policer and static queue

Note: Only the egress IPv4 configuration is shown in the example, to reduce the example output.
[ex:/configure qos sap-egress "rate_limit_dns"]
A:admin@UP-East# info
    queue 1 {
        rate {
            pir 100000
            cir 10000
        }
    }
    policer 1 {
        description "Policer to restrict DNS traffic to 1Mbps"
        rate {
            pir 1000
            cir 1000
        }
    }
    ip-criteria {
        entry 10 {
            match {
                protocol tcp
                src-port {
                    eq 53
                }
            }
            action {
                type accept
                policer 1
                queue 1
            }
        }
        entry 20 {
            match {
                protocol udp
                src-port {
                    eq 53
                }
            }
            action {
                type accept
                policer 1
                queue 1
            }
        }
    }
[ex:/configure subscriber-mgmt sla-profile "rate_limit_dns"]
A:admin@UP-East# info
    control {
        cups true
    }
    egress {
        qos {
            sap-egress {
                policy-name "rate_limit_dns"
            }
        }
    }
    aggregate-qos-statistics {
        egress {
            policers {
                all-dynamic
            }
        }
    }

Threshold and quota monitoring

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.

Relationship between the UP and MAG-c threshold and quota

The MAG-c typically maps multiple applications to a URR threshold or quota. It is therefore normal that a threshold or quota installed on the UP does not correspond to a threshold or quota applied by a charging function such as the CHF.

The following are example scenarios of multiple applications mapped to a URR threshold or quota:

  • A charging quota can map to both a UP quota, to immediately stop forwarding upon exhaustion, and to a UP threshold, to apply more complex actions (such as HTTP redirection) instead of stopping forwarding.

  • An online charging threshold and offline charging volume limit can both use the threshold, based on whichever expires first. For example, if a volume limit of 300 MB and a threshold of 1 GB are configured, the initial URR threshold is 300 MB, but after 3 reports it changes to 100 MB to reflect the remaining online threshold of 1 GB − 3 * 300 MB.

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

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.

Use the commands in the following context to manage SAP creation using a SAP template.
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.
Note: Configure the SAP and group interface templates on the BNG-UP (as well as the name "default") to ensure the session setup does not fail.

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

Mixing different encapsulation sessions on the same port

The BNG-UP supports the following mix of encapsulation sessions:
  • *.* capture SAP – dot1q and null encapsulation sessions
    Note: To support this, enable the following command on the systems where this is not the default.
    configure service system extended-default-qinq-sap-lookup
  • * 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@node-2# info 
    pfcp {
        association "BNG-CPF"
    }
    trigger-packet {
        pppoe true
    }

To identify sessions in the data plane, the MAG-c 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 MAG-c knows the correct logical port because the BNG-UP 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 MAG-c must signal all the VLAN tags to match the encapsulation type provisioned for the port; for example, only signaling an S-tag for a QinQ port is not allowed. As an exception, the MAG-c 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-UP 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-UP can perform LCP keep-alive offload, if supported and signaled by the MAG-c. The BNG-UP automatically signals support for this feature when the PFCP association is created.

Fixed wireless access sessions

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

Configuring FWA sessions

Consider the following before configuring FWA sessions:

  • The configuration for both 4G and 5G sessions is the same and can be shared. Both 4G and 5G use GTP-U tunnels; however, an additional GTP-U extension header is added for 5G that contains a 64-bit QoS flow indicator (QFI), and optionally a 1-bit reflective QoS indicator (RQI). The system decides whether to include this extension header based on dynamic signaling in the PFCP; no additional user configuration is required.
  • FWA sessions do not use default IBCP tunnels because the initial session setup is out-of-band and does not involve the FWA-UP. Per-session IBCP is supported to forward deferred allocation (DHCP), ICMPv6 RS/RA, and DHCPv6 packets.
  • The system automatically creates all the required constructs to correctly handle FWA sessions. Additionally, the system load balances sessions over each forwarding path extension (FPE), using the path that is the least loaded when the session is set up.
  • See the MAG-c Control Plane Function Guide, "Fixed wireless access sessions", for more information about configuring FWA sessions.

FWA sessions require configuration of an FWA-UP data endpoint for the router or VPRN, an optional secondary interface to terminate GTP-U tunnels, and an FPE construct to enable the datapath function in the router.

  1. Configure an FWA-UP data endpoint for the router or service VPRN.
    The endpoint must reference an interface in the routing instance that is configured with GTP-U tunnels to the RAN. The MAG-c CP also signals this routing instance in the S1-u or N3 Network Instance (network realm) in PFCP in the format service-name, where the service name is either the VPRN service name or "Base" to indicate the base router.
    configure router gtp upf-data-endpoint interface
configure service vprn gtp upf-data-endpoint interface
  2. Optional: Configure a secondary interface to terminate GTP-U tunnels.
    The interface created in step 1 is used for the primary, and the interface created in this step is used for the secondary. You can use this, for example, to differentiate 4G from 5G traffic, by provisioning different network instances (network realms) for S1-u (4G) and N3 (5G). 
    configure router gtp upf-data-endpoint secondary-interface
configure service vprn gtp upf-data-endpoint secondary-interface

    The MAG-c CP can choose the primary or secondary interface to use by applying the corresponding special S1-u or N3 Network Instance (network realm) configurations on the MAG-c:

    • service-name#%primary
    • service-name#%secondary
  3. Configure an FPE construct as type multi-path to enable the datapath functions in the router.
    See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Interface Configuration Guide for more information.

FWA-UP data-endpoint and multipath FPE configuration

[ex:/configure service vprn "to_ran" gtp upf-data-endpoint]
A:admin@FWA-UP# info
    interface "gtp_u_endpoint"
    fpe 1

[ex:/configure fwd-path-ext fpe 1]
A:admin@FWA-UP# info
    multi-path {
        path 1 {
            pxc 1
        }
    }
    application {
        sub-mgmt-extension true
    }

Dynamic QoS based on PCC rules

FWA sessions support dynamic QoS based on policy and charging control (PCC) rules, based on the configuration guidelines and examples provided in the topics in this section.

Overview of dynamic QoS based on PCC rules

FWA sessions support dynamic QoS based on policy and charging control (PCC) rules. An FWA session can have multiple PCC rules, each composed of a set of packet classifiers and specific QoS behavior. Acting as an SMF, the MAG-c receives these PCC rules from multiple sources, such as a policy control function (PCF). The MAG-c translates these PCC rules to common PFCP constructs, where each PCC rule is represented by a PDR rule and associated QER/FAR rules.

The FWA-UP supports up to two QER rates per PDR, which it enforces using the following automatically- derived two‑level QoS hierarchy:

  • The first rate is enforced using policing, and represents the SDF MBR as constructed by the MAG-c. This rate is optional in the 5G QoS model.
  • The second rate is enforced using shaping. This rate represents either the Session-AMBR or GFBR/MFBR, depending on whether the PCC rule is mapped to a GBR or non-GBR QoS flow.

See the MAG-c Control Plane Function Guide, "Fixed Wireless Access QoS", for more information about SDF MBR, session-AMBR, GFBR, and MFBRs.

For each PCC rule, the FWA-UP correctly marks packets as follows:

  • The FWA-UP marks the QoS flow identifier (QFI) and reflective QoS indicator (RQI) in the GTP-U header. The RAN and FWA RG use these values respectively to correctly handle QoS enforcement and classification.
  • The FWA-UP marks the DSCP fields on both the inner data packet and the outer GTP-U header. This is important primarily in cases where a node that is not mobile-QoS aware is a bottleneck. These nodes cannot use QFI because it is dynamic and session dependent; for example, a specific QFI 1 may mean high-priority for one session and low-priority for the next. Therefore, you can also map traffic to the less flexible static DSCP, which provides good basic prioritization in these nodes.

The FWA-UP automatically configures the required resources to manage the per-flow QoS, based on the following PFCP rules:

  • Configure a policer for each SDF MBR to be enforced.
  • Configure a queue for each GFBR/MFBR to be enforced.
    Note: The queue for the session-AMBR must be preprovisioned and identified by the session QER and SLA profile, as described in “Subscribers, QoS, and Filters”.
  • Configure IP criteria entries that include the signaled classifiers as match criteria, point to the applicable configured policer and queue, and enforce the correct QFI and RQI fields of the GTP-U headers.
  • Configure IP filter entries that enforce drop and forward functionality and optionally enforce DSCP marking.

See Configuring profiles for dynamic object creation for information about configuring profiles for dynamic object creation and Examples of profile configuration for dynamic object creation for example configurations.

Configuring profiles for dynamic object creation

Consider the following when configuring dynamic resources:

  • All FWA sessions using PCC rules can use the same SLA and SUB profiles. The system correctly creates the per-session QoS resources based on these. It is also possible to configure the SLA and SUB profile with the name default, so that the MAG-c does not need to provision a specific SLA and SUB profile for these sessions. See Subscribers, QoS, and filters for details.

  • To manage future growth, Nokia recommends configuring the largest range possible for dynamic resources, to accommodate adding or removing PCC rules. The range does not preallocate system resources and there is no reason to minimize these.
  • See Examples of profile configuration for dynamic object creation for examples of dynamic resource configuration.

To support automatic resource configuration, provision the session with the following IP filter, QoS, and subscriber-management profiles:

  1. Use the commands in the following contexts to configure an IPv4 and IPv6 filter with an entry range to use for PCC rule-based entries. 
    configure filter ip-filter subscriber-mgmt shared-entry pcc-rule range
configure filter ipv6-filter subscriber-mgmt shared-entry pcc-rule range
    Note: This is not mandatory if you do not require DSCP marking or explicit flow blocking. However, Nokia recommends enabling this to accommodate any future functionality extensions that may require dynamic IP filter entries.
  2. Use the following commands to configure a subscriber profile that points to a policer-control-policy. 
    configure subscriber-mgmt sub-profile
configure subscriber-mgmt sub-profile egress qos policer-control-policy policy-name
  3. Configure a SAP egress policy with the following:
    1. Configure at least one single static queue, which may be the default. 
      configure qos sap-egress queue
    2. Configure an IP criteria entry range for the PCC rule derived entries. 
      configure qos sap-egress subscriber-mgmt pcc-rule-entry range
    3. Configure a dynamic policer ID range to use when configuring the policers for SDF MBR policing. You can also configure other optional dynamic policer settings using commands in the following context. 
      configure qos sap-egress subscriber-mgmt dynamic-policer policer-id-range
    4. Create a dynamic queue ID range for the queues required for GFBR and MFBR shaping. You can also configure other optional dynamic queue settings using commands in the following context. 
      configure qos sap-egress subscriber-mgmt dynamic-queue queue-id-range
  4. Configure a SAP ingress policy with the following:
    1. Use the commands in the following context to configure an IP criteria entry range to create the PCC rule derived entries. 
      configure qos sap-ingress subscriber-mgmt pcc-rule-entry range
      Note: Nokia recommends that you configure a single static policer that points to an arbiter in the policer control policy referred by the subscriber profile, and map all FCs to this policer to avoid the creation of the default queue. You can use the default root arbiter for this by using the name root.
    2. Configure a dynamic policer ID range to use when configuring the policers required for SDF MBR policing. You can also configure other optional dynamic policer settings in this context. 
      configure qos sap-ingress subscriber-mgmt dynamic-policer policer-id-range
  5. Configure a SLA profile that points to the configured IP filter, IPv6 filter, SAP egress policy, and SAP ingress policy.
    1. Use the commands in the following context to configure and correctly apply session-AMBR. 
      configure subscriber-mgmt sla-profile pfcp-mappings session-qer
    2. Configure an uplink arbiter that points to an arbiter in the policer-control policy that the subscriber profile references. Use the name root to specify the default root arbiter. This must be the same arbiter to which the dynamic-policers is parented by the aforementioned configuration. 
      configure subscriber-mgmt sla-profile pfcp-mappings session-qer uplink arbiter
    3. Configure the downlink queue to the static queue that is configured in the SAP egress policy. 
      configure subscriber-mgmt sla-profile pfcp-mappings session-qer downlink queue

Examples of profile configuration for dynamic object creation

The following examples show filter, subscriber-management, and QoS configurations that enable creation of all the dynamic objects described in Overview of dynamic QoS based on PCC rules and Configuring profiles for dynamic object creation.

Filter configuration for creation of dynamic objects
[ex:/configure filter]
A:admin@node-2# info
    ip-filter "cups_default_ipv4_filter" { 
        default-action accept
        subscriber-mgmt {
            shared-entry {
                pcc-rule {
                    range {
                        start 10000
                        end 75534
                    }
                }
            }
        }
    }
    ipv6-filter "cups_default_ipv6_filter" { 
        default-action accept
        subscriber-mgmt {
            shared-entry {
                pcc-rule {
                    range {
                        start 10000
                        end 75534
                    }
                }
            }
        }
    }
Subscriber management configuration for creation of dynamic objects
[ex:/configure subscriber-mgmt ]
A:admin@node-2# info
    sub-profile "default" { 
        control {
            cups true
        }
        ingress {
            qos {
                policer-control-policy {
                    policy-name "cups_default_pcp"
                }
            }
        }
    }
    sla-profile "default" { 
        control {
            cups true
        }
        egress {
            ip-filter "cups_default_ipv4_filter"
            ipv6-filter "cups_default_ipv6_filter"
            qos {
                sap-egress {
                    policy-name "cups_default_egress_qos_policy"
                }
            }
        }
        ingress {
            ip-filter "cups_default_ipv4_filter"
            ipv6-filter "cups_default_ipv6_filter"
            qos {
                sap-ingress {
                    policy-name "cups_default_ingress_qos_policy""
                }
            }
        }
        pfcp-mappings {
            session-qer {
                uplink {
                    arbiter "root"
                }
                downlink {
                    queue 1
                }
            }
        }
    }
QoS configuration for creation of dynamic objects
[ex:/configure qos ]
A:admin@node-2# info
    sap-ingress "cups_default_ingress_qos_policy" {
        subscriber-mgmt {
            pcc-rule-entry {
                range {
                    start 1
                    end 65535
                }
            }
            dynamic-policer {
                policer-id-range {
                    start 2
                    end 63
                }
            }
        }
        policer 1 {
            arbiter-parent {
                arbiter-name "root"
            }
        }
        fc "af" {
            policer 1
        }
        fc "be" {
            policer 1
        }
        fc "ef" {
            policer 1
        }
        fc "h1" {
            policer 1
        }
        fc "h2" {
            policer 1
        }
        fc "l1" {
            policer 1
        }
        fc "l2" {
            policer 1
        }
        fc "nc" {
            policer 1
        }
    }
    policer-control-policy "cups_default_pcp" {
    }
    sap-egress "cups_default_egress_qos_policy" {
        subscriber-mgmt {
            pcc-rule-entry {
                range {
                    start 1
                    end 65535
                }
            }
            dynamic-policer {
                policer-id-range {
                    start 1
                    end 63
                }
            }
            dynamic-queue {
                queue-id-range {
                    start 2
                    end 8
                }
            }
        }
    }

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

Routed subscriber session configuration

A:node-2/config>svc#
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

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
  • single-hop and multi-hop BGP neighbors