Fixed access sessions

The Layer 2 circuit (l2-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 cMAG-c assumes that the Ethernet connectivity is configured and makes an abstraction of the underlying technology and topology. The cMAG-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 MAG-u defines the content of the l2-access-id. The cMAG-c does not interpret it.

The l2-access-id is called the logical port in BBF TR-459. The cMAG-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 cMAG-c creates IBCP tunnels per Layer 2 access ID for messages between the MAG-u and cMAG-c. Initial packets use these per-Layer 2 access ID tunnels. At session creation, the cMAG-c sets up a per-session tunnel. The MAG-u selection is based on the per-Layer 2 access ID tunnel used for the triggering packet.

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

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

subscriber-management ref-points up fixed-access entry-point
subscriber-management ref-points up fixed-access ibcp-triggers

# info from running with-context /subscriber-management ref-points up fixed-access
    subscriber-management {
        ref-points {
            up {
                fixed-access {
                    entry-point fixed-access
                    ibcp-triggers {
                        ipoe-dhcp true
                        ipoe-dhcpv6 true
                        ipoe-router-solicit true
                    }
                }
            }
        }
    }

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

subscriber-management ref-points up statistics ibcp

tools subscriber-management statistics clear ref-points up ibcp

Session keys identify and match data traffic to specific sessions, using different keys for IPoE and PPPoE sessions. The cMAG-c creates sessions and maps keys to ensure packets from different MAG-u nodes match the same session.

The cMAG-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 <MAG-u, Layer 2 circuit, MAC address>, for IPoE and PPPoE. If a session is set up in the context of a resilient UP group, the MAG-u and Layer 2 circuit keys are internally mapped to a common key based on the UP group configuration. This guarantees that packets coming from different MAG-u nodes within the same UP group match the same session.

Data plane rules on the MAG-u 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>

subscriber-management authentication-database entry ip-anti-spoof

The subscriber identification is equal to the session key..

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.

The cMAG-c enforces limits on the number of sessions. These limits can be configured within a specific scope; for example, per Layer 2 access ID.

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

subscriber-management entry-point entry

1. 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 MAG-u. By default, two sessions with the same Layer 2 access ID on two different MAG-u nodes 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 MAG-u nodes in the same UP group count for the same session limit.

2. 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 MAG-u. By default, two sessions with the same Layer 2 circuit on two different MAG-u nodes 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 MAG-u nodes in the same UP group count for the same session limit.

3. per UP

   Use the session-limits per-up command to set a limit for the maximum number of sessions per MAG-u. 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 MAG-u nodes 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 MAG-u, and another 100 resilient sessions on any UP group linked to that MAG-u.

IPoE does not involve a lower-layer connectivity protocol. Address assignment protocols and upstream data packets directly trigger IPoE sessions. The cMAG-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 cMAG-c receives the initial triggering packet over the per-Layer 2 access ID IBCP tunnel, the following actions are executed:

1. The cMAG-c matches the triggering packet with an EP, and creates an IPoE session using the configured keys. The cMAG-c assigns the EP and an IPoE profile. The IPoE profile defines the following behavior of the cMAG-c:
   • The cMAG-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 cMAG-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 create an IPoE profile.

   subscriber-management profiles ipoe-profile

   Use the following command to assign an IPoE profile to a session matching an EP entry.

   subscriber-management entry-point entry ipoe profile

   Note: If no IPoE profile is provisioned for a session, setup continues as if an IPoE profile with default values was provisioned.
2. The cMAG-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 cMAG-c allocates addresses for the session.
4. The cMAG-c creates data plane rules and per-session IBCP tunnels on the MAG-u.
5. The cMAG-c assigns addresses over the per-session IBCP tunnel.
6. If accounting is provisioned, the cMAG-c starts accounting for the session.

The events in the following non-exhaustive list cause deletion of an IPoE session:

• 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.
• A session timeout has occurred.

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 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; for IPv6 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 cMAG-c, using PAP as the authentication protocol.

To initiate a PPPoE session, the residential gateway (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 cMAG-c receives the initial triggering packet over the default IBCP tunnel, the following actions are executed:

1. The cMAG-c matches the triggering packet with an entry point. The entry point provides the following PPPoE-specific properties:

   Table 1. PPPoE entry-point properties

   Property	Description	Mandatory or Optional
   pppoe-profile	The PPPoE profile contains properties for each phase in the PPPoE setup. It also specifies the dot1p value for all PPPoE control plane packets that the cMAG-c sends. If not provisioned the cMAG-c uses the default profile values.	O
   authentication-flow	The authentication flow configuration contains PADI and PAP/CHAP authentication
   	PADI authentication	O
   	PAP/CHAP authentication	M
   allocation-scope	By default, the cMAG-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 cMAG-c allocates a unique session ID per Layer 2 circuit.	—
   random	By default, the cMAG-c allocates the first free session ID within the allocation scope, starting with one. However, when randomization is configured, the cMAG-c allocates a random unique session ID within the scope.	—

   Example: PPPoE entry point configuration

   # info detail from running with-context /subscriber-management entry-point fixed-access entry default pppoe
       subscriber-management {
           entry-point fixed-access {
               entry default {
                   pppoe {
                       authentication-flow {
                           pap-chap-adb [
                               basic-adb
                           ]
                       }
                       session-id {
                           allocation-scope l2-circuit-mac
                           random false
                       }
                   }
               }
           }
       }

2. The cMAG-c 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. By default, the existing session is kept and the initial triggering PADI packet is ignored.

   To define the behavior in case of conflicts, use the following CLI.

   subscriber-management profiles pppoe-profile padi-removes-existing-session

3. If the authentication-flow configuration in the entry point requires PADI authentication, the cMAG-c performs the authentication and sends out the PADO. The following properties in the PPPoE profile apply:

   • ac-name

     By default, the AC name is the system name configured using the following CLI.

     subscriber-management system name

   • generate-ac-cookie

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

   Example: Discovery configuration of a PPPoE profile

   # info detail with-context from running /subscriber-management profiles pppoe-profile example discovery
       subscriber-management {
           profiles {
               pppoe-profile example {
                   discovery {
                       generate-ac-cookie true
                       reply-on-padt false
                   }
               }
           }
       }

   See RFC 2516 for more information

4. The cMAG-c performs LCP negotiation as defined in RFC 1661 and RFC 4638. The following properties in the PPPoE profile apply:

   Table 2. PPPoE profile LCP negotiation properties

   Property	Description	Default
   max-mtu	The cMAG-c derives a downstream PPPoE MTU based on the maximum MTU value and the MRU the PPPoE client signals. If the MRU is smaller than the maximum MTU, the cMAG-c uses the MRU, otherwise the cMAG-c uses the maximum MTU. The cMAG-c sends the derived downstream PPPoE MTU to the MAG-u. The MAG-u applies the MTU on the downstream data path. Note: The MAG-u may enforce a lower MTU than the derived downstream PPPoE MTU; for example, because of port limitations. The cMAG-c does not learn this lower MTU and cannot send it as the MRU to the PPPoE client; therefore, Nokia recommends aligning the MAG-u and cMAG-c MTU configuration.	1492
   mru	To prevent the PPPoE client from sending packets that the MAG-u dropped, Nokia recommends aligning the MRU with the maximum packet size that a MAG-u can receive.	1492
   require-max-payload-tag	The require-max-payload-tag command defines whether an MRU above 1492 is negotiated. When enabled, the cMAG-c uses the PPP-Max-Payload tag, optionally received from the PPPoE client during PPPoE discovery, for MRU negotiations. See RFC 4638 for more information. When require-max-payload-tag is disabled, the cMAG-c sends the MRU as configured and accepts any MRU value. When require-max-payload-tag is enabled, the cMAG-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 the MRU. If the received MRU is bigger than the limit, the limit is used for the MTU calculations.	true
   keep-alive	The keep-alive configuration options 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. The cMAG-c terminates the PPPoE session in that case.	false
   renegotiation	The renegotiation configuration 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.	terminate-pppoe-session

   Example: LCP negotiation properties in the PPPoE profile configuration

   # info detail with-context from running /subscriber-management profiles pppoe-profile example lcp
       subscriber-management {
           profiles {
               pppoe-profile example {
                   lcp {
                       max-mtu 1492
                       mru 1492
                       require-max-payload-tag true
                       renegotiation terminate-pppoe-session
                       keep-alive {
                           ignore-magic-numbers false
                           interval 30
                           tries 3
                       }
                   }
               }
           }
       }

5. The cMAG-c continues with authentication when the LCP stack is in the Opened state.
   The cMAG-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 cMAG-c generates a challenge with a random length within the range defined in the chap-challenge-length parameter of the PPPoE profile.

   Example: Authentication properties in the PPPoE profile configuration

   # info detail with-context from running /subscriber-management profiles pppoe-profile example authentication
       subscriber-management {
           profiles {
               pppoe-profile example {
                   authentication {
                       method pref-chap
                       chap-challenge-length {
                           min 32
                           max 64
                       }
                   }
               }
           }
       }

   Both PAP and CHAP authentication are linked to the authentication flow.

6. After successful authentication, the cMAG-c starts the NCP stacks for the allocated addresses. PPPoE sessions support basic NCP renegotiation with the following limitations.

   • The cMAG-c never triggers renegotiation.
   • Configuration Request messages received while the NCP stack is in an open state are handled as per the RFC, and do not lead to a new IP in the case of IPCP. Full IP renegotiation for IPCP requires an IPCP Terminate Request from the RG, followed by an IPCP Configuration Request.
   • When the only remaining NCP stack changes from Opened to the Closed state, LCP termination is triggered.

   After successful IP allocation and negotiation, the cMAG-c installs the PFCP session on the MAG-u, which starts forwarding data plane packets and handles LCP keepalive packets. Accounting is started if a charging profile is provisioned during authentication.

When it's necessary to terminate a PPPoE session, the cMAG-c fetches the final counters from the MAG-u 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 to terminate 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 MAG-u and the cMAG-c

subscriber-management entry-point entry pppoe authentication-flow padi-adb