General session functionality

Get a high-level overview of the core protocol of session management.

The core of session management is the PFCP protocol as defined in 3GPP TS 29.244, with BNG-specific extensions defined in BBF TR-459.

The cMAG-c supports bundling a group of sessions for a single subscriber.

Grouping of sessions is useful in cases where a subscription consists of multiple directly connected devices. For example, a subscription may consist of a routed residential gateway for Internet access, VoIP phones, and set-top boxes. The residential gateway bridges traffic for voice and video services to the VoIP phones and to the set-top boxes. The cMAG-c automatically creates a subscriber based on keys it derives from the session types, and allocates an auto-generated subscriber ID to the sessions.

See Subscriber identification for fixed access sessions and for more information about how the subscriber ID is generated.

A subscriber ID alias can be provided via AAA interfaces, but this alias cannot change the scope of a subscriber. For example, if the key of a subscriber contains a Layer 2 circuit (l2-circuit), the AAA subscriber ID alias cannot group two sessions with two different l2-circuit values.

The cMAG-c enables the appropriate HQoS configuration by sending subscriber profiles and SLA profiles to the MAG-u.

A BNG connection uses HQoS structures, in which there are multiple levels of rate limiting and scheduling. For example, one structure has an aggregate rate per MSAN, a second structure has an aggregate rate per subscriber level, and a third structure has an aggregate rate per session.

The following figure shows an example of an HQoS model.

HQoS models can be complex and very hardware specific, the cMAG-c signals the MAG-u profiles to enable the appropriate HQoS configuration. The Nokia cMAG-c signals a subscriber profile and an SLA profile in the PFCP message. The profiles are provisioned during authentication.

The subscriber profile should be kept consistent for all sessions of a subscriber, but the cMAG-c does not enforce consistency. Short-lived inconsistencies are allowed while changing a subscriber profile; for example, when sending a CoA message to all sessions of the subscribers. However, long-lived inconsistencies may lead to unexpected behavior, including reverting to an old subscriber profile.

The cMAG-c service model is based on a locally significant service and a network instance.

The cMAG-c service model is based on two concepts:

• A locally significant service defines the service to be delivered; for example, high speed Internet (HSI), video, or voice services. Each service can be associated with service-specific parameters, including a default set of IP pool names for address management. Use the following command to configure services.

  subscriber-management services service

• A network instance defines the forwarding context in which the session is installed on the MAG-u, typically a routing instance. The network instance also serves as the context for provisioning IP pool details. Use the following command to configure network instances.

  subscriber-management services network-instance

Each service must be associated with a network instance, and network instances can be shared across multiple services. The following example shows three services ("hsi", "voice", and "video"), all using the same network instance "base" but with distinct default IPv4 pools for address assignment.

# info from running with-context /subscriber-management services
    subscriber-management {
        services {
            network-instance base {
                pool hsi {
                    ipv4 {
                        micro-net-length 28
                        prefix 192.168.0.0/24 {
                        }
                    }
                }
                pool video {
                    ipv4 {
                        micro-net-length 28
                        prefix 192.168.1.0/24 {
                        }
                    }
                }
                pool voice {
                    ipv4 {
                        micro-net-length 28
                        prefix 192.168.2.0/24 {
                        }
                    }
                }
            }
            service hsi {
                network-instance base
                address-assignment-defaults {
                    local-dynamic {
                        ipv4-pool hsi
                    }
                }
            }
            service video {
                network-instance base
                address-assignment-defaults {
                    local-dynamic {
                        ipv4-pool video
                    }
                }
            }
            service voice {
                network-instance base
                address-assignment-defaults {
                    local-dynamic {
                        ipv4-pool voice
                    }
                }
            }
        }
    }

Use the commands in the show, clear, and tools contexts to display cMAG-c sessions and subscribers, remove a session, and debug a failing session setup. Use the call trace feature for advanced debugging.

show subscriber-management session

subscriber-management statistics

# info depth 0 detail from state /subscriber-management statistics
    subscriber-management {
        statistics {
            active-sessions 1
            standby-sessions 0
            ipoe-sessions 1
            pppoe-sessions 0
            ipv4-stacks 1
            ipv6-stacks 0
            ipv6-slaac 0
            ipv6-na 0
            ipv6-pd 0
        }
    }

show subscriber-management subscriber

subscriber-management ref-points up statistics ibcp

tools subscriber-management session clear

show subscriber-management log subsystem session-manager

For scalability and redundancy, the Nokia cMAG-c distributes the session state functionality across multiple pods. This section provides a high-level overview of how the cMAG-c handles session state in a distributed environment. See cMAG-c Overview Guide for a high-level view of the architecture.

To efficiently handle a distributed system where multiple pods operate on the same session state, the cMAG-c employs a stateless model, storing all session state in a database. This database serves as the sole stable state for a session and is maintained in a consistent manner. Multiple types of pods use the database state in different ways:

• session management pods

  Session management pods are the only pods that can update (write) session state in the database. They use transactions, including session setup, DHCP lease renewal, charging update, or session removal, to update the session state. At the start of each transaction, a session management pod retrieves the necessary session state from the database and locks the session. At the end of the transaction, the session management pod writes to the database, releases the lock, and removes all local in-memory session state. The lock guarantees that no other session management pod can start transactions for the same session, thereby preventing conflicting state. Because a session management pod removes all local session state at the end of a transaction, any subsequent transaction can be handled by any session management pod in the cMAG-c, without requiring it to be the same pod.

• session orchestration pods
  Session orchestration pods guarantee that the shared resources are correctly managed by the cMAG-c, primarily to prevent duplicate resource assignments to sessions. Examples of orchestration pods include the following:

  • gatekeeper pod

    The gatekeeper pod assigns a session to a new or existing subscriber and allocates a unique session and subscriber ID. It also applies session limits, such as per-subscriber, per-UP, or per-Layer 2 access ID limits.

  • ODSA pod

    The ODSA pod assigns addresses to sessions for local address assignment.

  These pods maintain partial session state in memory to track allocations. For example, the ODSA pod retains in-memory records of allocated addresses to avoid overlap when assigning new addresses. When these pods need to restart (for example, because of upgrade or pod relocation), they retrieve the necessary session state from the database records.
• other pods
  A lot of other pods interact with session state in a read-only fashion. Similar to session management pods, these pods do not maintain any session state in long-lived memory, but remove any local state upon completion of a specific work item. Examples include:

  • session state pod

    The session state pod collects session state directly from the database and reflects it back to the requesting application. This is used, for example, to retrieve data when executing the info from state subscriber-management subscriber command, or its equivalent through external interfaces (Netconf or gNMI).

  • timer pod

    The timer pod scans the database for expired timers (for example, lease timeout, RADIUS interim update interval) and triggers a session management pod to start a transaction to handle the timer.

When configured properly, the cMAG-c can signal a PD prefix as a framed route to the MAG-u.

When a PD prefix is allocated to a session, the cMAG-c can be configured to signal the PD prefix as a framed route instead of as an explicit session address to the MAG-u. When the PD prefix is signaled as a framed route, the MAG-u cannot identify that the signaled prefix originated from a DHCPv6 PD lease, and treats it as any other IPv6 framed route.

subscriber-management authentication-database entry address-assignment pd-as-framed-route

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

When no other IPv6 stack is available, the cMAG-c automatically installs the PD prefix as a regular IP address and not as a framed route on the MAG-u.