General session functionality

The PFCP association and path define the connectivity between the cMAG-c and MAG-u.

To send a session to a MAG-u, a PFCP association needs to be established. While establishing this association, the MAG-u and the cMAG-c exchange capabilities, functional features, and parameters; for example, a MAG-u sends functional features such as PPPoE support, IPoE support, and LCP keep-alive offload support. Capability exchange can influence the IE applicability in PFCP session messages.

• PFCP association

  A PFCP association must be set up before sessions can be established between the MAG-u and the cMAG-c. Only one association per cMAG-c and MAG-u pair is allowed. The identifiers of the association are the cMAG-c and the MAG-u node IDs, which can be IP addresses or domain names.

• PFCP path

  Multiple paths are possible per PFCP association. The identifier of a PFCP path is the pair of IP addresses to communicate between the cMAG-c and the MAG-u. Paths are not negotiated but are learned while using PFCP signaling. Each IP address is called a PFCP entity. Each pair of cMAG-c and MAG-u IP addresses is called a PFCP path.

The cMAG-c selects a MAG-u for each session depending on the session type.

The MAG-u selection varies from very static to very dynamic.

See In-band control plane and MAG-u selection for more information about the selection process for fixed access session.

PFCP sessions require the creation of a forwarding state on the MAG-u device. Session operations allow to manage the forwarding state on the MAG-u.

The forwarding state includes rules (for example, encapsulation and decapsulation), information about routing context forwarding, QoS rules, and requested charging functionality.

The PFCP session establishment procedure creates the initial forwarding state. The path used for the PFCP session establishment procedure is tied to the session.

The following operations are supported for an established session:

• PFCP session modification

  The cMAG-c modifies the state or performs a state query (for example, to fetch statistics).

• PFCP session deletion

  The cMAG-c removes all state information.

• PFCP session report

  The MAG-u sends information unsolicited (for example, to report statistics or a connectivity failure).

In stable conditions, the MAG-u only modifies or deletes the state if instructed by the cMAG-c. If the MAG-u detects a failure, for example, a link failure, it does not delete the state but sends a report and keeps the local state. The MAG-u deletes the state only when the cMAG-c sends a delete request.

The PFCP protocol uses components that must be provisioned and verified using the CLI.

# info from running /subscriber-management ref-points up
    subscriber-management {
        ref-points {
            up {
                fixed-access {
                    entry-point fixed-access
                    ibcp-triggers {
                        pppoe-discover true
                        ipoe-dhcp true
                        ipoe-dhcpv6 true
                        ipoe-router-solicit true
                    }
                }
                peer up-east {
                    admin-state enable
                    address-resolution {
                        static-ip [
                            192.0.2.11
                        ]
                    }
                }
            }
        }
    } 

info from state /subscriber-management ref-points up

# info detail depth 1 from state /subscriber-management ref-points up peer up-east
    subscriber-management {
        ref-points {
            up {
                peer up-east {
                    association-state up
                    setup-time 2025-04-03T15:35:30Z
                    last-change 2025-04-03T15:35:30Z
                    up-state active
                    admin-state enable
                    node-id-type fqdn
                    drain false
                    oper-mag-c-node-id cmag-c
                    apply-state applied
                    up-function-features-3gpp [
                        ip6pl
                        adpdp
                        mnop
                        empu
                        pdiu
                        frrt
                        ftup
                        treu
                    ]
                    up-function-features-bbf [
                        agf-direct
                        b-upf
                        pppoe
                        ipoe
                        lcp-keepalive-offload
                    ]
                    up-function-features-nokia [
                        bulk-audit
                        lac
                        session-subnet-signaling
                        fsg
                        per-l2-access-id-tunnels
                        partial-audit
                    ]
                    fsg {
                    }
                    path 192.0.2.11 {
                        path-state up
                        last-successful-heartbeat 2025-04-03T16:25:30Z
                        ongoing-heartbeat 2025-04-03T16:25:30Z
                        recovery-timestamp 2025-04-03T15:27:21Z
                        last-changed 2025-04-03T15:35:30Z
                    }
                    statistics {
                    }
                    address-resolution {
                        static-ip [
                            192.0.2.11
                        ]
                    }
                }
            }
        }
    }

To prioritize PFCP session-related messages toward the MAG-u, the cMAG-c uses the message priority field of the PFCP header. The value of the message priority ranges from 0 to 15, with 0 indicating the highest priority. For more information about how the MAG-u enforces the priority, see the 7750 SR and VSR BNG CUPS User Plane Function Guide.

The MP bit, which can only be set for session-related PFCP messages, indicates whether the message priority field is set. If the MP bit is not set, the message priority field is ignored and the MAG-u determines the priority. The Nokia MAG-u usually uses priority 15 if the MP bit is not set. See the 7750 SR and VSR BNG CUPS User Plane Function Guide for more information.

The message priority field indicates the actual priority of a message. The cMAG-c uses a part of the priority fields to assign priority between different transaction types as part of its overload handling. For example, mid-session session modifications are prioritized over the creation of new sessions, making sure that existing sessions are less likely to be affected than new sessions in the event of overload.

To prevent the removal of sessions with a temporary heartbeat failure, cMAG-c supports a short-lived headless mode to restore connectivity.

PFCP heartbeat messages check the connectivity of a PFCP path. When the heartbeat procedure fails, all state information for the corresponding path is removed and all sessions using that path are terminated. The association remains in place.

subscriber-management profiles pfcp-profile heart-beat

subscriber-management profiles pfcp-profile path-restoration

When headless mode is enabled, the sessions are not removed when there is a heartbeat failure. Instead, the configured timer starts and heartbeats continue to be sent. Subsequently, one of the following events occurs:

• The timer expires and all sessions are removed. The association remains in place.

• The path is restored (a successful heartbeat is completed) but a MAG-u restart is detected and all sessions are removed.

• The path is restored (a successful heartbeat is completed), the sessions are kept, and a PFCP audit procedure is started to ensure that the MAG-u and cMAG-c states are synchronized.

To avoid hanging resources on a MAG-u, the cMAG-c only removes a session after it receives confirmation that the MAG-u has removed the session. The cMAG-c may receive confirmation in the following messages:

• PFCP Session Deletion Response message (most common case)
• PFCP message including a Cause IE that indicates an error (the MAG-u lost the session)
• an indication that the MAG-u restarted and lost all its sessions; for example, a new PFCP Association Setup Request

tools subscriber-management session clear

Nokia recommends aligning the session timers (signaled to the BNG RG) with the path restoration time. If the session timers are not aligned with the path restoration time, a session may time out autonomously before the headless mode could restore the path.

The following configurations for the session timers guarantee that the headless mode kicks in as expected.

• For DHCP, the DHCP lease time must at least equal the renew time plus the path restoration time. In the default case, where the renew time is half of the lease time, the lease time must be at least twice the path restoration time.
• For all IPv6 enabled sessions, the router lifetime included in RA messages must be at least equal to the maximum advertisement interval plus the path restoration time. In the default case, where the router lifetime is three times the maximum advertisement interval, the maximum advertisement interval must be equal to at least twice the path restoration time.
• For SLAAC, the IPv6 preferred lifetime must be at least equal to the maximum router advertisement interval plus the path restoration time.
• For DHCPv6, the IPv6 preferred lifetime must be at least equal to the renew timer (T1 timer) plus the path restoration time. In the default case, where the renew timer is half of the preferred lifetime, the preferred lifetime must be equal to at least twice the path restoration time.

The parameters can be locally configured or received from an external AAA server.

To configure or display information locally, use the following commands:

• path restoration time

  subscriber-management profiles pfcp-profile path-restoration

• DHCP lease time

  subscriber-management authentication-database entry address-assignment dhcpv4-lease-times lease-time

• renew time

  subscriber-management authentication-database entry address-assignment dhcpv4-lease-times renew-time

• router lifetime in RA messages

  subscriber-management profiles ra-profile options router-lifetime

• maximum advertisement interval

  subscriber-management profiles ra-profile advertisement-interval max

• IPv6 preferred lifetime

  subscriber-management authentication-database entry address-assignment ipv6-lifetimes preferred-lifetime

All the pods that participate in the processing of session transactions assess each transaction to determine whether it is subject to tracing. To ensure that every transaction is automatically subject to tracing, the always-on tracing mode is enabled by default. The user can change the configuration of this mode to conserve resources, as needed.

Every pod that participates in processing a session transaction must decide whether the transaction is potentially subject to tracing. The easiest way to accomplish this is to use the default always-on enabled tracing mode. This mode automatically assumes that every transaction is potentially subject to tracing.

# info from running /subscriber-management call-trace always-on
    enabled {
        sample-rate 100
    }0

# info from running /subscriber-management call-trace always-on
    disabled

# info from running /subscriber-management call-trace always-on
    enabled {
        sample-rate 50
    }

You can use the cMAG-c CLI to manage the configuration of the default call trace packet-tracing options.

By default, the cMAG-c captures packets as part of all the traced transactions. You can use the commands in the following context to change the packet-tracing properties.

subscriber-management call-trace packet-tracing

The following are examples of reasons you may want to disable packet capturing for traced transactions, and the properties to use to do so:

• If you need to lower the resource impact of always-on tracing, use the packet-tracing default-off property. This disables the default packet-tracing functionality, while allowing session filters to explicitly enable packet tracing using the CLI or the GUI tool.

  subscriber-management call-trace packet-tracing default-off

  See Managing session tracing filters for information about how to configure call trace filters for specific sessions.

• If you need to manage privacy or regulatory requirements, use the packet-tracing disallowed property. This disables all packet tracing, and prevents individual session filters from enabling it.

  subscriber-management call-trace packet-tracing disallowed

The cMAG-c provides the ability to configure automatic tracing based on error conditions, when always-on tracing is enabled. For example, it is possible to automatically trace any session transaction that leads to a failure, and to manage the duration of tracing transactions.

subscriber-management call-trace any-error true

# info from running /subscriber-management call-trace
    any-error true
    always-on {
        enabled {
            sample-rate 100
        }
    }

# info from running /subscriber-management call-trace
    max-duration 5000
    always-on {
        enabled {
            sample-rate 100
        }
    }

The cMAG-c provides session filters with configurable options for matching the sessions to trace. You can use the CLI or the cMAG-c Call Trace GUI tool to manage filters for session tracing.

It is possible to always trace specific sessions, whether they fail or not. To do this, use the CLI or the GUI tool to enable the applicable filters. Filters provisioned using the CLI are referred to as static filters, while filters provisioned using the GUI tool are referred to as dynamic filters. Static filters cannot be modified using the GUI and dynamic filters cannot be modified using the CLI.

A filter provides the following configurable properties for matching the sessions to trace:

• options that are always available:
  • MAC address
  • UP node ID
  • Layer 2 access ID
  • C-VLAN
  • S-VLAN
• options that are only available when the always-on property is enabled:
  • subscriber name
  • username

The configuration may include multiple options that must all match (logical AND) for a transaction to match the filter. A filter is considered always available only if all its configured options are always available. If even one option requires always-on tracing, the entire filter requires always-on tracing.

To administratively disable a static filter entry without removing it, specify the disable option for the admin-state command.

subscriber-management call-trace filter admin-state disable

You can use the GUI tool to administratively disable dynamic filters.

1. Navigate to the cMAG-c Call Trace Configuration window in the GUI tool.
2. Under Dynamic filters, select the edit icon beside the filter.
3. Uncheck the Enabled check box in the Add new filter window; see the following figure.

See Managing dynamic filters using the Call Trace GUI tool for more information about using the GUI tool to manage filters.

Note: When debugging is complete, Nokia recommends fully removing the filter entry. Do not leave the entry permanently in the administratively-disabled state.

Use the Nokia Call Trace GUI tool to inspect the details of call trace captures.