General session functionality

The PFCP association and path define the connectivity between the MAG-c and BNG-UP.

To send a session to a BNG-UP, a PFCP association needs to be established. While establishing this association, the BNG-UP and the MAG-c exchange capabilities, functional features, and parameters; for example, a BNG-UP 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 BNG-UP and the MAG-c. Only one association per MAG-c and BNG-UP pair is allowed. The identifiers of the association are the MAG-c and the BNG-UP node IDs, which can be IP addresses or domain names. Provisioning commands specific to PFCP associations allow to enable the PFCP protocol.

• PFCP path

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

The MAG-c selects a BNG-UP for each session depending on the session type.

The BNG-UP selection varies from very static (for example, because of hard wiring) to very dynamic (for example, for FWA).

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

See FWA-UP selection for more information about the selection process for FWA sessions.

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

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

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 MAG-c modifies the state or performs a state query (for example, to fetch statistics).

• PFCP session deletion

  The MAG-c removes all state information.

• PFCP session report

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

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

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

A:MAG-c>config>mobile>profile>pfcp# info  
---------------------------------------------- 
                pfcp-association-peer-list "peers" 
                exit 
                up-peer-list "ups" 
                exit 
---------------------------------------------- 
A:MAG-c>config>mobile>pdn# info  
---------------------------------------------- 
                instance-type control 
                sx-n4 "default"
                    pfcp-association-list "peers" 
                    interface 
                        pfcp "system" 
                        ibcp "system" 
                    exit 
                    signaling 
                        pfcp  
                            profile "default" 
                        exit 
                        ibcp  
                            bng-entry-point "start" 
                            triggers pppoe-discover ipoe-dhcp ipoe-dhcpv6 ipoe-router-solicit ipoe-data 
                        exit 
                    exit 
                exit
                up-peer-list "ups" 
---------------------------------------------- 

show mobile-gateway pdn ref-point-peers sx-n4

A:MAG-c>show mobile-gateway pdn ref-point-peers sx-n4
===============================================================================
PFCP reference point peers
===============================================================================
Peer address : 192.168.50.84
Node Id : 192.168.50.84
Router : Base
Path Mgmt State : up
Create Time : 06/21/2023 13:53:16 Gateway Id : 1
UP Features : FTUP TREU EMPU PDIU FRRT ADPDP MNOP IP6PL
UP BBF Features : PPPOE IPOE LCPKO
UP Nokia Features: BULK-AUDIT LAC SSSG FSG
UP Association : up Last Change Time : 06/21/2023 13:53:16
UP Selection : False
Enforced PFCP association list : No
-------------------------------------------------------------------------------
Number of peers : 1
===============================================================================

To handle overload scenarios, the MAG-c limits the in-flight PFCP session messages that are sent toward each BNG-UP. This automatically limits the rate with which messages are sent to the BNG-UP. When this message limit is reached, a new PFCP transaction automatically fails. The MAG-c handles failed PFCP transactions for the most part as follows:

• When the failure is triggered by an external message (for example, a DHCP Discover, GTP Create Session Request, or RADIUS CoA), the external message is discarded. A retry of the external message restarts the procedure and the PFCP signaling.
• When the failure is triggered by an internal event (for example during a UP resiliency FSG switchover), the MAG-c automatically retries the PFCP transaction itself.

The MAG-c starts with an initial in-flight limit value (not configurable) and dynamically increases or decreases the limit to address the following cases:

• The processing time on the BNG-UP differs per PFCP procedure. The MAG-c can send messages with a high rate for some PFCP procedures, but needs to lower the rate for other PFCP procedures.
• The processing time differs per BNG-UP because of the difference in hardware and software.

To prevent the removal of sessions with a temporary heartbeat failure, MAG-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.

configure mobile-gateway profile pfcp pfcp-profile heart-beat

configure mobile-gateway profile pfcp pfcp-profile path-restoration-time

To enable BFD, use the optional bfd-enable keyword in the preceding command.

When BFD is enabled, the system starts a BFD session for each known PFCP path on the BNG-UP. If a BFD failure is detected, the system immediately brings down the associated path. BFD does not affect the path recovery detection, which requires the configuration of PFCP heartbeats.

configure mobile-gateway profile pfcp pfcp-profile heart-beat

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 BNG-UP 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 BNG-UP and MAG-c states are synchronized.

To avoid hanging resources on a BNG-UP, the MAG-c only removes a session after it receives confirmation that the BNG-UP has removed the session. The MAG-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 BNG-UP lost the session)
• an indication that the BNG-UP restarted and lost all its sessions; for example, a new PFCP Association Setup Request

clear mobile-gateway bng session

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 get info about the following locally configured parameters, use the indicated CLI commands:

• path restoration time: path-restoration-time in the following context.

  configure mobile-gateway profile pfcp pfcp-profile

• DHCP lease time: option with option-number 51 in the following context.

  configure mobile-gateway profile bng dhcp-profile options

• Renew time: option with option-number 58 in the following context.

  configure mobile-gateway profile bng dhcp-profile options

• Router lifetime in RA messages: options router-lifetime in the following context.

  configure mobile-gateway profile bng ra-profile

• Maximum advertisement interval: advertisement-interval max in the following context.

  configure mobile-gateway profile bng ra-profile

• IPv6 preferred lifetime: preferred in the following context.

  configure mobile-gateway profile authentication-database entry address-assignment lifetimes