Fixed access sessions

Learn about the key identifiers for fixed access sessions, IBCP tunnels, BNG-UP selection, limits on the number of sessions, session lockout, and the PPPoE and IPoE setup flows.

Layer 2 circuit

The layer 2 circuit is the combination of the layer 2 access ID and the VLAN parameters.

Fixed access sessions have direct Ethernet connectivity from the client device to the BNG. The MAG-c assumes that the Ethernet connectivity is configured. The MAG-c makes an abstraction of the underlying technology and topology. The MAG-c only needs the opaque Layer 2 access ID (l2-access-id) that uniquely identifies the access context of a session. The access context can be a port, a LAG, a pseudowire, an EVPN service, or anything that provides Ethernet connectivity. The BNG-UP defines the content of the l2-access-id. The MAG-c does not interpret it.

The l2-access-id is called the logical port in BBF TR-459. The MAG-c is aware of all Ethernet parameters such as MAC address, S-VLAN, and C-VLAN. Nokia uses the l2-circuit for the combination of the l2-access-id and VLAN parameters.

In-band control plane and BNG-UP selection

The MAG-c creates IBCP tunnels for messages between the BNG-UP and MAG-c. Initial packets use the default IBCP tunnel. At session creation, the MAG-c sets up a per-session tunnel. The BNG-UP selection is based on the default tunnel used for the triggering packet.

Fixed access sessions send in-band MAG-c messages over the connection to the BNG-UP. As defined in BBF TR-459, the MAG-c creates GTP-U tunnels (called IBCP tunnels) between the BNG-UP and the MAG-c to forward in-band MAG-c messages.

To enable IBCP tunneling, configure an IBCP listening interface using the following command.
configure mobile-gateway pdn sx-n4 interface ibcp
The following example shows the configuration of the interfaces for an Sx-N4 reference point in the Base routing instance.
A:BNG-CP>config>mobile>pdn>sx-n4>if# info
----------------------------------------------
                  pfcp "system"
                  ibcp "system"
----------------------------------------------
The initial MAG-c packets of a fixed access session are sent over a default IBCP tunnel. The MAG-c automatically sets up the default IBCP tunnel when the BNG-UP indicates support for PPPoE or IPoE sessions. Packets sent over the default tunnel signal the Layer 2 access ID (l2-access-id) and the local BNG-UP MAC address to the MAG-c in an NSH header (as defined in BBF TR-459). The MAG-c matches packets coming in over the default tunnel against a UP group and subsequently to a BNG entry point (EP):
  • The UP group identifies interconnected UPs on which steering or resiliency is available. This step is optional and if no UP group is matched, the session is set up only in the context of the UP associated with the incoming IBCP tunnel.
  • The BNG EP acts as a gateway mechanism and provides basic setup parameters. It is mandatory for a packet to match a BNG EP.

The MAG-c can instruct the BNG-UP to forward only specified packet triggers over the default IBCP tunnel and to ignore other triggers. For example, ignore IPoE triggers if only PPPoE is deployed or the other way around.

Configure the BNG EP and triggers using the following commands.
configure mobile-gateway pdn sx-n4 signaling ibcp bng-entry-point
configure mobile-gateway pdn sx-n4 signaling ibcp triggers
The following example shows the signaling configuration.
A:BNG-CP>config>mobile>pdn>sx-n4>signaling# info
----------------------------------------------
                     pfcp
                         profile "default"
                     exit
                     ibcp
                         bng-entry-point "start"
                         triggers pppoe-discover ipoe-dhcp
                     exit
----------------------------------------------

The MAG-c sets up a per-session tunnel at session creation.

To display IBCP statistics for both the default tunnel and the per-session tunnel, use the following command with the ibcp keyword.
show mobile-gateway pdn ref-point-stats
To clear the IBCP statistics, use the following command with the ibcp keyword.
clear mobile-gateway pdn ref-point-stats
When multiple BNG-UP devices are managed by the same MAG-c, each BNG-UP has its own default tunnel. At session creation, the BNG-UP selection is based on the triggering packet:
  • If the triggering packet matches a UP group, the session is tied to an FSG of that UP group. The MAG-c creates the session on the active (and optionally standby) BNG-UPs of the FSG.
  • If the triggering packet does not match a UP group, the MAG-c installs the session on the BNG-UP that corresponds with the default tunnel on which the packet was received.

Session keys and anti-spoofing

When multiple fixed access sessions use the same key identifier, data plane and user plane discriminators can be used.

The MAG-c creates a session when receiving the initial triggering packet for a specific session type. Fixed access sessions are by default identified by the key <UP, l2-circuit, MAC address>, for IPoE as well as for PPPoE. In case a session is set up in the context of a resilient UP group, the UP and L2 circuit keys are internally mapped to a common key based on the UP group configuration. This guarantees that packets coming from different UPs within the same UP group all match the same session.

When multiple sessions share the same key, the remote ID or circuit ID can be used as a discriminator. The circuit ID and the remote ID are in the following sources:

  • DHCP: option 82, sub-option 1 (circuit ID) and sub-option 2 (remote ID) as defined in RFC 3046

  • DHCPv6: option 18 (interface ID) as defined in RFC 8415 and option 37 (remote ID) as defined in RFC 4649. The enterprise number in the remote ID option is ignored for DHCPv6.
  • PPPoE: BBF vendor-specific tags 1 (circuit ID) and 2 (remote ID) as defined in TR 101

To enable discrimination of multiple sessions with the same key, use the following command.
configure mobile-gateway profile bng entry-point entry multiple-sessions-per-mac

If multiple sessions per key are enabled, and no remote ID or circuit ID can be found, the MAG-c sets up the session anyway. No other sessions for the same <UP, l2-circuit, MAC address> key can be set up.

Note:

Nokia does not recommend enabling multiple sessions for the same key for IPoE. It is only supported for single-stack IPv4 sessions that are DHCP-triggered. IPv6 and any other triggers are not supported.

Session setup needs to finish within a hard-coded 60 second timeout. The session is set up when it is stable and the protocol-specific timers or state machines are running (for example, lease timers, or LCP state machine). If the session setup does not finish in time, the session is deleted.

Because data packets do not contain a remote ID or a circuit ID, data plane rules need an additional data plane differentiator. The session ID is an additional data plane differentiator for PPPoE. IPoE requires the enabling of IP anti-spoofing to get an additional data plane differentiator.

Data plane rules on the BNG-UP use the following keys to match data traffic to a specific session:

  • IPoE: <l2-circuit, source MAC address> or <l2-circuit, source MAC address, source IP address>

  • PPPoE: <l2-circuit, source MAC address, session ID> or <l2-circuit, source MAC address, session ID, source IP address>

To add the source IP address to the key, set the following command to true.
configure mobile-gateway profile authentication-database entry ip-anti-spoof
If not explicitly specified, the ip-anti-spoof command is enabled for all sessions, except when L2TP LAC is enabled. For more information about L2TP LAC, see L2TP Access Concentrator.

Subscriber identification

The subscriber identification is equal to the session key, but you can define alternative subscriber keys.

For fixed access sessions, the BNG subscriber key is by default equal to the session key, that is, there is a single session per subscriber. When a different subscriber scope is needed, alternative subscriber keys can be defined.

To define alternative subscriber keys, use the multi-session-key command in the following context.
configure mobile-gateway profile bng entry-point entry subscriber-identification

Session limits

The MAG-c enforces limits on the number of sessions. These limits can be configured within a specific scope; for example, per MAC address.

The MAG-c supports limits on the number of sessions within a specific scope; for example, per Layer 2 access ID. The session limits are applied when the session is created, before authentication. Changing a session limit only affects new sessions. Existing sessions are not removed to align with new session limits.

The session limits are configured in the following context.
configure mobile-gateway profile bng entry-point entry
The MAG-c enforces session limits in the following order:
  1. per MAC address
    When enabled, multiple fixed access sessions for the same MAC address are supported. By default, the support for multiple sessions per MAC is disabled. Use the multiple-sessions-per-mac limit command to limit the maximum number of sessions per MAC address. To change the limit, you must first administratively disable the BNG entry point using the following command.
    configure mobile-gateway profile bng entry-point shutdown
  2. per subscriber
    When enabled, multiple fixed access sessions for the same subscriber are supported. By default, the support for multiple sessions per subscriber is disabled. Use the subscriber-identification multi-session session-limit command to limit the maximum number of sessions per subscriber. To change the limit, you must first administratively disable the BNG entry point using the following command and then enable the subscriber-identification multi-session command.
    configure mobile-gateway profile bng entry-point shutdown
  3. per Layer 2 access ID

    Use the session-limits per-l2-access-id command to set a limit for the maximum number of sessions per Layer 2 access ID (l2-access-id). The system limits the maximum number of sessions per Layer 2 access ID (for example, port) and the associated BNG-UP. By default, two sessions with the same Layer 2 access ID on two different BNG-UPs do not count for the same session limit. However, if sessions are set up in the context of a UP group, the system maintains the limit per UP group and Layer 2 access ID combination. In this case, two sessions with the same Layer 2 access ID on different BNG-UPs in the same UP group count for the same session limit.

  4. per Layer 2 circuit

    Use the session-limits per-l2-circuit command to set a limit for the maximum number of sessions per Layer 2 circuit (l2-circuit). The system limits the maximum number of sessions per Layer 2 circuit and the associated BNG-UP. By default, two sessions with the same Layer 2 circuit on two different BNG-UPs do not count for the same session limit. However, if sessions are set up in the context of a UP group, the system maintains the limit per UP group and Layer 2 circuit ID combination. In this case, two sessions with the same Layer 2 circuit ID on different BNG-UPs in the same UP group count for the same session limit.

  5. per UP

    Use the session-limits per-up command to set a limit for the maximum number of sessions per BNG-UP. In case the sessions are set up in the context of a UP group, this limit applies to the UP group instead because sessions can dynamically move between BNG-UPs in one UP group.

It is possible to configure conflicting limits for the same context. For example, two sessions with the same Layer 2 access ID can match two different BNG EP entries. Both entries can have a different session limit. The enforced limit at session creation is the limit that is configured in the matching BNG EP entry.

Limits enforced for non-resilient contexts and resilient UP group contexts are never mixed. For example, if a BNG EP is configured with a per UP session limit of 100, the system allows up to 100 non-resilient sessions on that BNG-UP, and another 100 resilient sessions on any UP group linked to that BNG-UP.

Session lockout

Session lockout is an optional feature to prevent DoS attacks and credential brute-force attacks.

When the session lockout feature is enabled, the MAG-c blocks a client if the sum of the number of the following triggering events reaches a specified threshold within a specified time window
  • session setup failure
  • disconnection of an established session
If a client is in the locked-out state, the MAG-c drops all packets coming from the client.
The following events unblock a locked-out client:
  • expiration of the block timer
  • clearing of the locked-out state of the specified client using the session-lockout command in the following context.
    configure mobile-gateway profile bng

To enable session lockout, see Enabling session lockout.

To display information for sessions that are subject to session lockout monitoring or to display the number of sessions that are in locked-out or monitoring state, use the session-lockout command in the show mobile-gateway bng context.

Enabling session lockout

To prevent attacks, enable session lockout in the BNG EP.

  1. Define a session lockout profile.
    Use the session-lockout-profile command in the following context.
    configure mobile-gateway profile bng
    The profile includes:
    • failed-attempts (the threshold)
    • attempt-window (the time window)
    • block (the block timer)
  2. Reference the session lockout profile in the BNG EP entry.
    Use the session-lockout-profile command in the following context.
    configure mobile-gateway profile bng entry-point entry
    Session lockout is enabled for the sessions that match a BNG EP entry with a referenced session lockout profile.

IPoE

IPoE does not involve a lower-layer connectivity protocol. Address assignment protocols and upstream data packets directly trigger IPoE sessions. The MAG-c supports DHCP, DHCPv6, and ICMPv6 RS as triggering protocols.

The following figure shows an example of an IPoE session setup flow with DHCP as triggering protocol.

Figure 1. IPoE session setup with RADIUS authentication

When the MAG-c receives the initial triggering packet over the default IBCP tunnel, the following actions are executed.

  1. The MAG-c matches the triggering packet with a BNG EP, and creates an IPoE session using the configured keys. The MAG-c assigns the BNG EP and an IPoE profile. The IPoE profile defines the following behavior of the MAG-c.
    • The MAG-c sets dot1p and DSCP values in Ethernet and IP headers of CP messages to the IPoE client.
    • For packets that trigger session creation, the MAG-c verifies the DHCP client Ethernet address (chaddr field). If the DHCP client Ethernet address does not equal the Ethernet source MAC address, the packet is dropped and no session is created.
    • Use the following command to configure the MAG-c to process an upstream data packet as the trigger.
      configure mobile-gateway profile bng entry-point entry ipoe allow-data-trigger
  2. The MAG-c assigns a single authentication flow to the session and starts the authentication. Subsequent triggers for the same IPoE session do not trigger re-authentication.
  3. The MAG-c allocates addresses for the session.
  4. The MAG-c creates data plane rules and per-session IBCP tunnels on the BNG-UP.
  5. The MAG-c assigns addresses over the per-session IBCP tunnel.
  6. If accounting is provisioned, the MAG-c starts accounting for the session.

The following events cause deletion of an IPoE session.

  • The session setup is not done within the hard-coded 60 second timeout. The timer starts on reception of the initial trigger and stops when an IP stack (for example, DHCP lease) is set up.
  • The AAA triggers a failure; for example, RADIUS-initiated disconnect.
  • An operator gives an explicit clear command for the session.
  • No more DHCP or DHCPv6 lease is running, for example because of a lease timeout or an explicit release message. Because of the lack of client-generated messages, SLAAC assigned addresses are not tracked independently and require an active DHCP or DHCPv6 lease in the IPoE session.

PPPoE

PPPoE session setup is linked with the PPPoE discovery protocol as defined in RFC 2516. PPPoE session setup consists of the following phases:

  1. PPPoE discovery phase to enable PPP over Ethernet
  2. PPP LCP negotiation to negotiate the PPP link connection
  3. Authentication
  4. IP network connectivity using NCPs, such as IPCP and IPv6CP. In the case of IPv6, this is followed by IP assignment protocols, such as SLAAC or DHCPv6.

The following figure shows an example PPPoE session setup flow for IPv4 network connectivity on a CUPS BNG, using PAP as the authentication protocol.

Figure 2. PPPoE session setup flow

To initiate a PPPoE session, the RG sends a PPPoE PADI discovery packet. The packet is sent over the default IBCP tunnel because no session context is known yet.

When the MAG-c receives the initial triggering packet over the default IBCP tunnel, the following actions are executed.

  1. The MAG-c matches the triggering packet with a BNG EP. The BNG EP provides the following PPPoE-specific parameters:
    • pppoe-profile

      The PPPoE profile contains parameters for each phase in the PPPoE setup. It also specifies the dot1p value for all PPPoE control plane packets that the MAG-c sends.

    • authentication-flow

      The configuration of the authentication flow contains PADI authentication (optional) and PAP/CHAP authentication (mandatory).

    • allocation-scope

      By default, the MAG-c allocates a unique PPPoE session ID per combination of Layer 2 circuit ID and MAC address. When an aggregation device ignores MAC addresses and forwards based on PPPoE session ID only, the MAG-c allocates a unique session ID per Layer 2 circuit.

    • random

      By default, the MAG-c allocates the first free session ID within the allocation scope, starting with one. However, when randomization is configured, the MAG-c allocates a random unique session ID within the scope.

    The following example shows the PPPoE configuration for a BNG EP.
    A:MAG-c>config>mobile>profile>bng>ep>entry>pppoe# info detail
    ----------------------------------------------
    pppoe-profile "default"
    authentication-flow
        no padi-adb
        pap-chap-adb "bng_auth"
    exit
    session-id
        allocation-scope l2-circuit-mac
        no random
    exit
    ----------------------------------------------
  2. The MAG-c creates an initial session and allocates the PPPoE session ID. If a PPPoE session with the same key exists, the configuration of the PPPoE profile defines whether to delete or keep the existing PPPoE session. If the existing session is kept, the initial triggering PADI packet is ignored.

    To define the behavior in case of conflicts, use the padi-removes-existing-session command in the following context.
    configure mobile-gateway profile bng pppoe-profile
  3. If the authentication flow configuration in the BNG EP requires PADI authentication, PADI authentication is done. Before sending the PADO, the MAG-c creates a PFCP session on the BNG-UP and a per-session IBCP tunnel. The remainder of the discovery phase uses the per-session IBCP tunnel. The following parameters in the PPPoE profile apply:
    • ac-name

      By default, the AC name is the system name.

    • generate-ac-cookie

      By default, the generation of an AC cookie is enabled.

    The following example shows the discovery parameters in the configuration of the PPPoE profile.
    A:MAG-c>config>mobile>profile>pppoe>discovery# info detail
    ----------------------------------------------
    no ac-name
    generate-ac-cookie
    ----------------------------------------------

    For more information, see RFC 2516.

  4. The MAG-c performs LCP negotiation as defined in RFC 1661 and RFC 4638. The following parameters in the PPPoE profile apply:
    • max-mtu (default 1492)

      The MAG-c derives a downstream PPPoE MTU based on the maximum MTU value and based on the MRU that is signaled by the PPPoE client. If the MRU is smaller than the maximum MTU, the MRU is used; otherwise the maximum MTU is used. The MAG-c sends the derived downstream PPPoE MTU to the BNG-UP. The BNG-UP applies it on the downstream data path.

      The BNG-UP may enforce a lower MTU than the derived downstream PPPoE MTU; for example, because of port limitations. The MAG-c does not learn this lower MTU and cannot send it as the MRU to the PPPoE client; therefore Nokia recommends to align the BNG-UP and MAG-c MTU configuration.

    • mru (default 1492)

      To prevent the PPPoE client from sending packets that are dropped by the BNG-UP, Nokia recommends to align the MRU with the maximum packet size that a BNG-UP can receive.

    • require-max-payload-tag

      The require-max-payload-tag parameter defines whether an MRU above 1492 can be negotiated. When enabled, the MAG-c uses the PPP-Max-Payload tag, optionally received from the PPPoE client during PPPoE discovery, for MRU negotiations. For more information, see RFC 4638.

      When require-max-payload-tag is disabled, the MAG-c sends the MRU as configured and accepts any MRU value. When require-max-payload-tag is enabled, the MAG-c uses the value of the PPP-Max-Payload tag as a limit to MRU values.

      If the PPP-Max-Payload tag is not present, or if it is lower than 1492, the limit for MRU values is set to 1492. If the configured MRU is bigger than the limit, the limit is sent as MRU. If the received MRU is bigger than the limit, the limit is used for MTU calculations.

    • keep-alive

      The keep-alive parameters consist of an interval and a maximum number of tries. If no response is received after the configured number of tries, the session is considered disconnected. MAG-c terminates the PPPoE session in that case.

    • renegotiation

      The renegotiation parameter defines the LCP renegotiation strategy. When a new LCP Configure Request is received while the LCP stack is already in the Opened state, the new request is ignored and dropped, or the PPPoE session is terminated.

    The following example shows the LCP parameters in the configuration of the PPPoE profile.
    A:MAG-c>config>mobile>profile>bng>pppoe-profile>lcp# info detail
    ----------------------------------------------
    max-mtu 1492
    mru 1492
    renegotiation terminate-pppoe-session
    require-max-payload-tag
    keep-alive
        no ignore-magic-numbers
        interval 30
        tries 3
    exit
    ----------------------------------------------
  5. The MAG-c continues with authentication when the LCP stack is in the Opened state.
    The MAG-c supports both PAP (RFC 1334) and CHAP (RFC 1994) authentication. PAP or CHAP authentication is required. The authentication method parameter in the PPPoE profile defines the priority between PAP and CHAP as follows:
    • pap

      Only PAP authentication is performed.

    • chap

      Only CHAP authentication is performed.

    • pref-pap

      PAP authentication is performed. When PAP authentication fails, CHAP authentication is performed.

    • pref-chap

      CHAP authentication is performed. When CHAP authentication fails, PAP authentication is performed.

    In the case of CHAP, the MAG-c generates a challenge with a random length within the range defined in the chap-challenge-length parameter of the PPPoE profile.

    The following example shows the authentication parameters in the configuration of the PPPoE profile.

    A:MAG-c>config>mobile>profile>bng>pppoe>auth# info detail
    ----------------------------------------------
    chap-challenge-length min 32 max 64
    method pref-chap
    ----------------------------------------------

    Both PAP and CHAP authentication are linked to the authentication flow. On successful authentication, any applicable IP address is allocated and the PFCP session on the BNG-UP gets data plane forwarding parameters. On successful completion of the first IP address assignment protocol, accounting is started if a charging profile is provisioned during authentication.

  6. After successful authentication, the MAG-c starts the NCP stacks for the allocated addresses. PPPoE sessions support basic NCP renegotiation with the following limitations.
    • The MAG-c never triggers renegotiation.
    • Configuration Requests received while the NCP stack is in Opened state are discarded. A renegotiation consists of an NCP Termination Request, followed by an NCP Configuration Request.
    • NCP renegotiation does not trigger IP reallocation.
    • When the only remaining NCP stack changes from Opened to the Closed state, LCP termination is triggered.

When a PPPoE session must be terminated, the MAG-c fetches the final counters from the BNG-UP and tears down the session by sending an LCP Terminate Request to the PPPoE client. The following events cause termination of a PPPoE session:

  • reception of a PADT or LCP Terminate Request from the PPPoE client
  • reception of a conflicting PADI if the configuration of the PPPoE profile defines the deletion of the existing PPPoE session in case of conflicts (padi-removes-existing-session)
  • reception of a new LCP Configuration Request, if the configuration of the PPPoE profile defines the termination the PPPoE session (renegotiation is set to terminate-pppoe-session)
  • detection of an LCP keep-alive failure
  • administrative removal; for example, RADIUS-initiated disconnect or clear commands
  • charging quota exhaustion
  • all NCP stacks changed from the Opened to the Closed state
  • PFCP association loss between the BNG-UP and the MAG-c

LCP keep-alive offload

The MAG-c offloads the LCP keep-alive function to the BNG-UP if the BNG-UP signals the LCP keep-alive offload capability during the PFCP association.

The MAG-c handles LCP keep-alive until the data plane session is created on the BNG-UP. During the data plane session creation, the MAG-c signals the LCP keep-alive offload to the BNG-UP. At that time, the MAG-c stops running timers for LCP keep-alive monitoring and relies on the LCP keep-alive failure reporting from the BNG-UP.

Detection of an LCP keep-alive failure terminates the PPPoE session.

Resiliency based on PADO delay

PADO delay is a method to provision basic but deterministic (that is, determined from first use) BNG-UP dual homing. A PADO delay value is provisioned during PADI authentication.

In BNG-UP dual homing, a PPPoE client is connected to two BNG-UP devices. The MAG-c sends the PADO packet via one BNG-UP device without delay and via the other BNG-UP device with delay. The PPPoE client chooses the first received PADO and ignores the second received PADO. In stable conditions, the PADO delay determines a primary BNG-UP choice with the option to fall back to a secondary BNG-UP. The session setup continues on the primary BNG-UP device. The feature is supported regardless of whether there is one MAG-c device for both BNG-UP devices or a different MAG-c device per BNG-UP device.

A prerequisite for deterministic BNG-UP dual homing based on PADO delay is PADI authentication. If PADI authentication is not configured, the delay value is not known.

Note: PADI authentication is configured in the authentication-flow parameter of a PPPoE BNG entry.

To configure a delay for PADO packets, you can use one of the following options.

  • Use the pado-delay command in the following context.
    configure mobile-gateway profile authentication-database entry pppoe
  • Provide the delay via the Alc-PPPoE-PADO-Delay VSA during RADIUS authentication.

The following figure shows an example of deterministic BNG-UP dual homing. A PPPoE connection is dual homed to two BNG-UP devices, called East and West. East and West share a common MAG-c. The PPPoE client broadcasts the initial PADI to both BNG-UP devices. The MAG-c handles both PADIs and creates two sessions for it because they have different session keys. The session on East has no delay while the session on West has a 500 ms delay. The PPPoE client chooses the first received PADO sent via East. The session is established on East while the session on West times out. If the setup on East fails, the PPPoE client only gets the (delayed) PADO sent via West and the session is established on West.

Figure 3. Resiliency based on PADO delay

IPCP subnet negotiation

IPCP subnet negotiation allows a BNG to assign an IPv4 subnet to a PPPoE session without the need for out-of-band provisioning (for example, using TR-69 signaling).

A prerequisite for IPCP subnet negotiation is to disable the IP address-based anti-spoofing functionality. To explicitly disable IP address-based anti-spoofing, use the ip-anti-spoof false command in the config>mobile>profile>adb>entry context.
configure mobile-gateway profile authentication-database entry
An IPCP subnet can be provisioned via an external AAA server or using local address assignment. To provision the subnet using local address assignment, use the subnet-allocation command in the following context.
configure mobile-gateway pdn local-address-assignment network-realm pool ipv4

If the client signals support for IPCP subnet allocation, the MAG-c signals the subnet using the non-standard IPCP sub-option 0x90. The MAG-c selects the main session IP address from the subnet and signals it as the regular IPv4 address in IPCP option 0x03. The main session IP address is:

  • the address in the Framed-IP-Address attribute in case of an AAA-assigned address
  • the first address of the subnet in case of a local assignment

On the BNG-UP, the session is installed with the main session IP address as the session address and the remainder of the subnet as a framed route toward the main session IP address.

In RADIUS accounting, the main session IP address is added in the Framed-IP-Address attribute and the subnet mask is added in the Framed-IP-Netmask attribute. Those attributes are included in the accounting messages if the address-information command in the following context is enabled.
configure mobile-gateway profile charging bng-charging radius session include-attribute

L2TP Access Concentrator

When a BNG-UP acts as a LAC for a PPPoE session, it does not act as an IP gateway, but sends the PPP traffic to an LNS using the L2TP protocol.

The following figure shows the L2TP LAC network components.

Figure 4. L2TP LAC network components

The functional split of the Nokia BNG CUPS LAC solution between the BNG-UP and the MAG-c is the following.

  • The MAG-c does the initial PPPoE setup and authentication.
  • The MAG-c gets the L2TP tunnels via local provisioning or via authentication protocols (for example, via RADIUS).
  • The MAG-c passes the provisioned L2TP tunnels to the BNG-UP via the PFCP protocol.
  • The L2TP protocol, including the control plane, runs on the BNG-UP. The BNG-UP signals the L2TP tunnels and the L2TP sessions within those tunnels.
  • The BNG-UP does the L2TP tunnel management, including tunnel load-balancing, deny lists maintenance, and preference-based tunnel selection.

The following figure shows an example of a LAC-enabled PPPoE session setup flow.

Figure 5. LAC-enabled PPPoE session setup flow

Setup of an L2TP LAC-enabled session is the same as the setup of a regular PPPoE session until the PPP authentication step (see PPPoE session setup flow). Passing a list of L2TP tunnel attributes or a name of a locally configured L2TP group in the authentication step enables the PPPoE session for LAC functionality. A mix of locally configured L2TP groups with L2TP tunnels provided via authentication is not supported.

To configure a local L2TP group, use the l2tp-group command in the following context.
configure mobile-gateway profile bng
The L2TP group contains a list of potential L2TP tunnels and their associated parameters.
Note: If PADI authentication is enabled and L2TP parameters are passed, the PPP setup continues on the MAG-c until the PPP authentication is done. In this case, L2TP is triggered after the authentication.

When the authentication indicates L2TP, the PFCP session modification procedure to install PPP data plane rules differs from the one for a regular PPPoE session setup as follows.

  • The data plane rules, which contain a list of candidate L2TP tunnels, instruct the BNG-UP to perform L2TP-based forwarding instead of IP-based forwarding. To prevent that the LCP and the authentication negotiation needs to restart between the client and the LNS, the MAG-c includes a list of PPP LCP and Auth proxy parameters or packets to be sent to the LNS.
  • The modified control plane rules instruct the BNG-UP to forward PPP control plane traffic such as LCP over the L2TP tunnel. The BNG-UP keeps on sending PPPoE control plane traffic such as PADT packets to the MAG-c. LCP keep-alive offload is not enabled because the BNG-UP forwards LCP keep-alive messages to the LNS.

The BNG-UP performs the following tasks to set up the session and to complete the session setup from a BNG point of view.

  1. The BNG-UP chooses an L2TP tunnel from the provisioned list based on parameters such as preference and current tunnel load. If the tunnel is not yet signaled, the BNG-UP sets it up using the Start-Control-Connection (SCC*) L2TP messages.
  2. The BNG-UP sets up an L2TP session using the Incoming-Call (IC*) L2TP Messages. It includes the LCP and Auth proxy parameters in the session setup messages.
  3. The BNG-UP forwards all PPP traffic (including control plane traffic) to the LNS and sends a PFCP Session Modification Response to the MAG-c. This response contains the selected L2TP tunnel, including some meta-data such as the tunnel ID, the session ID, and the CSN, which can be displayed on the MAG-c for operational purposes.

Because the LNS acts as the IP gateway, the MAG-c does not allocate addresses, or start any IP address assignment protocols. The MAG-c can perform accounting for a PPPoE LAC, but the accounting session does not include information that is only known by the LNS, such as IP addressing information.

Except for any LCP or NCP based triggers, the MAG-c can terminate a PPPoE LAC session in the same way as a regular PPPoE session. To terminate the session, the MAG-c deletes the PFCP session, which triggers the BNG-UP to delete the L2TP session using the L2TP Call-Disconnect-Notify message. The BNG-UP disconnects the L2TP tunnel when the last session on the tunnel is deleted and the tunnel idle-timeout has expired.

The L2TP protocol can terminate a session when the LNS disconnects the session, or when the underlying tunnel is removed (for example, because of a timeout). In this case, the BNG-UP sends to the MAG-c a PFCP Session Report Request with the User Plane Inactivity Report flag set in the Report Type IE. In response, the MAG-c sends a PFCP Session Deletion Request to the BNG-UP to clean up the session.

Interaction between PFCP and L2TP timeout

The BNG-UP runs a function to detect unreachable L2TP LNS servers:

When an L2TP LNS server is unreachable (the L2TP message times out after the last retry), the BNG-UP puts the LNS server in a temporary deny list and does not reconsider the server for this and any following sessions. When all tunnels for a session are unreachable, the BNG-UP indicates setup failure in the PFCP Session Modification message.

The MAG-c runs a function to detect PFCP message timeouts:

The MAG-c times out the PFCP Session Modification message based on the configuration of the message-retransmit command in the following context.
configure mobile-gateway profile pfcp pfcp-profile
When a PFCP timeout is detected, the MAG-c triggers a PFCP Session Deletion message to clean up the BNG-UP state. Because the BNG-UP does not know the reason of deletion, it cancels the session and, or the tunnel setup without moving the tunnel to a temporary deny list.
Because those two detection functions run in contention with each other, it is important that the L2TP message timeout is lower than the PFCP message timeout. To configure the L2TP message timeout, use the max-retries-non-established and max-retries-established commands in the following context, or their equivalents in the authentication attributes.
configure mobile-gateway profile bng l2tp-group
Those commands configure the number of retries before a non-established or established tunnel is considered unreachable. The first retry is sent after one second, the second retry after two seconds, the third retry after four seconds, and each subsequent retry after eight seconds. The total timeout must be lower than the PFCP message timeout. For example, if a maximum of two retries is configured, the total timeout is seven seconds (1 + 2 + 4).