Fixed access sessions

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.

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.

configure mobile-gateway pdn sx-n4 interface ibcp

A:BNG-CP>config>mobile>pdn>sx-n4>if# info
----------------------------------------------
                  pfcp "system"
                  ibcp "system"
----------------------------------------------

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 mobile-gateway pdn sx-n4 signaling ibcp bng-entry-point
configure mobile-gateway pdn sx-n4 signaling ibcp triggers

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.

show mobile-gateway pdn ref-point-stats

clear mobile-gateway pdn ref-point-stats

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

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.

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>

configure mobile-gateway profile authentication-database entry ip-anti-spoof

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.

configure mobile-gateway profile bng entry-point entry subscriber-identification

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.

configure mobile-gateway profile bng entry-point entry

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. When 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 nonresilient 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 nonresilient sessions on that BNG-UP, and another 100 resilient sessions on any UP group linked to that BNG-UP.

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

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.

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.

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

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

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.

configure mobile-gateway profile authentication-database entry

configure mobile-gateway pdn local-address-assignment network-realm pool ipv4

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.

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.

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.

configure mobile-gateway profile pfcp pfcp-profile

configure mobile-gateway profile bng l2tp-group