PFCP association

This chapter provides an overview of the BNG-UP Packet Forwarding Control Protocol (PFCP) association configuration, heartbeat and headless mode operation, and operational management and debugging options.

BNG-UP PFCP association

A BNG-UP requires an active PFCP association with the MAG-c. Through the PFCP association, the MAG-c installs the rules that determine how the BNG-UP forwards subscriber traffic.

The BNG-UP requires the PFCP association to be preconfigured using the configure subscriber-mgmt pfcp association command.

Each PFCP association is linked to a specific peer, interface, and router instance. The loopback interface is the recommended interface because it allows resiliency over multiple physical interfaces.

As soon as the PFCP association is configured and administratively enabled, the BNG-UP will probe the MAG-c by sending PFCP Heartbeat Request message. As soon as the BNG-UP receives a corresponding PFCP Heartbeat Response message, it will establish a permanent PFCP Association by sending a PFCP Association Setup Request message. If either the Heartbeat or the Association Setup messages fail (for example, timed out) the BNG-UP periodically retransmits the Heartbeat until this procedure succeeds or the PFCP association is administratively disabled.

The BNG-UP can also set up the PFCP association when it receives a PFCP Association Setup Request from the configured peer. However, the BNG-UP does not accept an association setup from a non-configured peer.

BNG-UP PFCP association setup flow shows the PFCP association setup flow for the BNG-UP.

Figure 1. BNG-UP PFCP association setup flow

The PFCP protocol supports node identification using node IDs. The node ID can be either an IP address or a FQDN. By default, the IP address of the linked interface is chosen; however, this can be overridden using the node-id command. All the BNG-UPs in a deployment require different node IDs.

PFCP messages sent for an active association use the following configuration under the PFCP association tx command:

  • The ttl command defines the outgoing TTL.

  • The timeout command defines the request message timeout (T1).

  • The retries command defines the number of times a request message is retried (N1).

Note: For heartbeat messages, N1 and T1 are configured separately. For correct operation, N1 and T1 must be configured identically on both the MAG-c and BNG-UP. See the MAG-c Control Plane Function Guide and the MAG-c CLI Reference Guide for more information about the MAG-c configuration.

The QoS of the outgoing PFCP messages is managed through sgt-qos command configuration in the routing instance used by the PFCP. In the application list command, a pfcp keyword can be mapped to its own DSCP value (default NC2), after which that DSCP value can be mapped to a specific Forwarding Class (FC).

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 about QoS configuration.

When a PFCP association is administratively disabled, it is not immediately brought down. The BNG-UP requests a graceful MAG-c release and keeps the PFCP association up until the MAG-c removes it, or the association release timeout expires.

To configure the PFCP association release timeout, use the association-release-timeout command.

To force an immediate PFCP association removal, configure the association-release-timeout to none.

The following example shows a BNG-UP PFCP association configuration.

[gl:configure subscriber-mgmt pfcp association "MAG-c"]
A:admin@DUT-B# info detail 
    admin-state enable
 ## description
    association-setup-retry 1
    association-release-timeout 3600
    path-restoration-time 180
    node-id {
     ## fqdn
     ## use-ip-address
    }
    interface {
        router-instance "to_magc"
        name "endpoint"
    }
    peer {
        ip-address 17.17.17.10
    }
    heartbeat {
        interval 60
        timeout 5
        retries 4
    }
    tx {
        timeout 5
        retries 3
        ttl 255
    }

PFCP heartbeats and headless mode

The following concepts define the connectivity between the BNG-UP and the MAG-c:

  • PFCP association

    One PFCP association is allowed per BNG-UP and MAG-c. The identifiers of the association are the BNG-UP and MAG-c node IDs.

  • PFCP path

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

    See BNG-UP PFCP association for information about how PFCP associations are negotiated.

Note: The terms PFCP path and PFCP association are often used interchangeably because there is typically only one PFCP path per PFCP association.

The BNG-UP only uses one IP address, but starts heartbeats for each PFCP path it learns. The frequency, timeout, and retry values of the heartbeats are configured for the PFCP association using the interval, retries, and timeout commands in the configure subscriber-mgmt pfcp association heartbeat context.

If a heartbeat fails, the BNG-UP starts a timer based on the path-restoration-time command configuration under the PFCP association. If the timer expires or is not configured, all sessions associated with that path are removed. If the path recovers before the timer expires, the timer is canceled, and no sessions are removed.

Note: For correct operation, the heartbeat configuration must be identical on both the BNG-UP and MAG-c. Nokia strongly recommends configuring the path-restoration-time to at least twice the sum of the heartbeat interval plus the total timeout (heartbeat retries x heartbeat timeout = N1 x T1).

To expedite the detection of path failures, enable BFD using the bfd-expedited-path-down command in the configure subscriber-mgmt pfcp association context. When enabled, the system starts a BFD session for each known PFCP path on the BNG-UP. If the system detects a BFD failure, it immediately brings down the associated path. BFD does not affect the path recovery detection, which requires the configuration of PFCP heartbeats. BFD-based path down detection requires the configuration of the path-restoration-time command under the PFCP association.

Default IBCP session

The BNG-UP always enables the IPoE and PPPoE BBF function features. A compatible MAG-c uses this as an indication to set up a default IBCP tunnel to send control plane packets, such as DHCP discover or PADI, that do not match an existing session. The default tunnel is signaled as a special PFCP session without a PDN type. The special PFCP session can apply traffic-matching rules the same as any other PFCP session for which the BNG-UP applies rules.

Packets sent over the default In-band Control Plane (IBCP) tunnel include local BNG-UP parameters that are inserted in a network service header. The network service header is inserted between the GTP-U header and the encapsulated control packet. These parameters include the following:

  • MAC address

    This is the MAC address that is associated with the capture SAP on which the IBCP packet was received. The MAG-c uses the MAC address as a source MAC address when sending control packet responses. In case of inter-BNG-UP resiliency, the MAG-c can ignore this MAC address and use the FSG MAC address instead. For more information about inter-BNG-UP resiliency, see BNG-UP resiliency.

  • Layer 2 access ID

    The Layer 2 access ID (also known as the logical port) identifies the local port, the LAG, or the pw-port that is used by the capture SAP. The MAG-c reflects this parameter as is when setting up a session so the BNG-UP installs the session in this context. To simplify provisioning on the MAG-c, you can provide an alias for the L2 access ID. The alias must be unique within the BNG-UP and cannot overlap with any identifier such as a port or a LAG name.

    To configure the L2 access ID alias, use the configure service vpls capture-sap pfcp l2-access-id-alias command.

See IBCP for more information about IBCP.

Operational commands and debugging

This section describes commands that can be used for operational and debugging purposes.

To display the number of PFCP associations and sessions, use the show subscriber-mgmt pfcp summary command.

To display PFCP message statistics, including information about packets that are received and transmitted and any transmission errors, use the show subscriber-mgmt pfcp statistics command.

To reset the PFCP association statistics to zero, use the clear subscriber-mgmt pfcp-association statistics command.

To display information including association-level parameters such as function features and node IDs, use the show subscriber-mgmt pfcp association command.

To display path state information, use the show subscriber-mgmt pfcp peer command.

See PFCP heartbeats and headless mode for information about the distinction between PFCP association and path.

To display default IBCP tunnel information, use the show subscriber-mgmt pfcp session default-tunnel command.

To display details about a specific PFCP session, use the show subscriber-mgmt pfcp session detail command. This command provides an overview for the PFCP parameters of the session. Various filters can be applied to narrow a specific session or set of sessions.

See Operational commands for more information about basic operational commands.

To forcefully remove a PFCP session, use the clear subscriber-mgmt pfcp-session command.

Caution: Although it is possible to forcefully remove a PFCP session, Nokia does not recommend invoking this command in a live network because this may cause the MAG-c to be out of sync with the BNG-UP. If the BNG-UP contains a session that is not on the MAG-c, it is preferable to first run a manual PFCP audit.

To perform basic PFCP debugging, use the debug subscriber-mgmt pfcp command. The output of this command allows inspection of PFCP packets received and transmitted. As well, any session-specific failure is reported in the PFCP response to the MAG-c, which can display the specific error as part of session debugging.