Subscriber management

A fundamental consideration is whether to implement a centralized or distributed network architecture. Centralized models pool resources into a single location, simplifying management but potentially create a single point of failure. On the other hand, distributed networks decentralize resources, enhancing resiliency, but at the cost of increased management complexity. Geographical redundancy (geo-red) is another significant consideration, allowing service continuity even if a specific geographical area experiences a failure.

The customer premise may include a variety of devices, including routed and bridged Residential Gateways (RGs), that may employ Network Address Translation (NAT). Understanding the needs of different customer types (residential or business) further impacts network design, as some types of customers might require more advanced features or higher service levels. Virtual Residential Gateway (vRGW), service per Virtual Local Area Network (VLAN), subscriber per VLAN models, or even a flat (untagged) network might be used depending on the specific requirements.

Deciding on a service per VLAN, subscriber per VLAN, or flat network model can significantly impact the network design, scalability, and management. Each model can be influenced by the following network factors:

• service per VLAN

  This model associates different services with distinct VLANs. For example, Internet access, VoIP, and IPTV could each be on a separate VLAN. This design allows for easier QoS management, as different services typically have different QoS requirements.

• subscriber per VLAN

  Each subscriber is assigned to their unique VLAN. This model can provide high granularity for managing services and security since traffic from each subscriber is isolated from the others. However, this model significantly increases the number of VLANs.

• flat network (single VLAN or untagged)

  In this model, all subscribers share a single VLAN or operate in an untagged network. This simplifies the network design and management because you do not have to manage multiple VLANs. However, it offers less granularity for service and security management, and it can create larger broadcast domains, which might impact performance.

When deciding between these models, consider the following factors:

• scalability

  How many subscribers or services does the network need to support, now and in the future?

• service differentiation

  Will you need to provide different QoS levels for different services or subscribers?

• security

  How important is it to isolate traffic from different subscribers or services?

• management complexity

  How equipped are you to manage a potentially large number of VLANs?

• performance

  How does the chosen model impact network performance?

Network access methods can be wired, wireless, or hybrid access solutions that mix fixed and wireless access.

Physical access technologies include the following:

• fiber optics

  This includes Fiber to the Home (FTTH), Fiber to the Building (FTTB), Fiber to the Curb (FTTC), and Fiber to the Node (FTTN). Fiber optics offer high bandwidth, low latency, and resistance to electromagnetic interference.

• twisted pair

  This includes Digital Subscriber Line (DSL) technologies such as ADSL, VDSL, and G.fast. These technologies deliver broadband over the existing telephone lines.

• coaxial cable

  Cable broadband services, such as DOCSIS, use coaxial cables originally installed for cable TV.

• wireless

  Wireless broadband can include Wi-Fi, cellular (4G, 5G), satellite, and fixed wireless access.

• satellite

  Satellite broadband can reach areas where terrestrial broadband is not available.

Logical access protocols include:

• Asynchronous Transfer Mode (ATM)

  This is often used for DSL connections, but it is less common today because of its lower efficiency for packet data.

• Ethernet

  This is commonly used for FTTP and cable services, and for DSL services that use Ethernet over DSL (EoDSL).

• Passive Optical Network (PON)

  This is a type of fiber network that uses passive splitters to deliver broadband to multiple premises. Variants include GPON and EPON.

• Data Over Cable Service Interface Specification (DOCSIS)

  This is used for delivering broadband over coaxial cable networks.

• G.fast

  This is a DSL protocol designed for short distances with high speeds, often used for FTTC or FTTdp (Fiber to the Distribution Point).

• Point-to-Point Protocol over Ethernet/ATM (PPPoE/PPPoA)

  These are tunneling protocols often used with DSL services.

The choice of access technology and protocol depends on factors such as the existing infrastructure, required bandwidth, service area characteristics, and cost. For example, FTTH with GPON may be the best choice for a new installation in a densely populated area, while VDSL over existing telephone lines may be more cost-effective in an area with lower population density.

The aggregation network is an optional layer that groups or aggregates multiple customer connections toward the BNG. Without an aggregation network, access nodes connect directly to the BNG. If an aggregation network is used, it could be native Ethernet or an overlay such as VPNs, Virtual Private LAN Service (VPLS), with various transport options such as Multiprotocol Label Switching (MPLS), Segment Routing over IPv6 (SRv6), or Generic Routing Encapsulation (GRE).

The decision to implement an aggregation network or directly connect access nodes to BNGs depends on several factors:

• scale

  In a large network with numerous access nodes, an aggregation network can simplify management by reducing the number of direct connections to the BNG. Each BNG can connect to several aggregation switches, which in turn connect to multiple access nodes. However, for a small network, direct connections from the access nodes to the BNG may be simpler and more cost-effective.

• geographical distribution

  If access nodes are widely dispersed, it may be more efficient to connect them to a local aggregation switch and then connect the aggregation switches to a centralized BNG. This can reduce long-haul links and save costs.

• redundancy and resilience

  An aggregation network can provide additional paths between the access nodes and the BNG, enhancing network resilience. If a direct link to the BNG fails, traffic can be rerouted through another aggregation switch.

• service management

  Aggregation networks can also offer service-specific features. For instance, they may support Multiprotocol Label Switching (MPLS) for traffic engineering or Virtual Private LAN Service (VPLS) for Layer 2 VPNs.

• cost

  Aggregation networks require additional equipment and potentially more complex management, which can increase costs. However, they can also reduce the number of required BNG ports, which may offset some of these costs.

• future-proofing

  An aggregation network can offer more flexibility to accommodate future growth or changes. For example, it can be easier to add, remove, or relocate access nodes without disturbing the BNG.

Subscriber terminations occur on the BNG, usually located in the central office. The design could be centralized or distributed. Centralized BNGs host a large number of subscribers, making redundancy critical to prevent service disruption. Distributed BNGs could provide better scalability and resiliency, but may require more sophisticated management and orchestration.

Resilience and redundancy are critical aspects of any network design strategy. How and where to implement redundancy depends on several factors, including the expected reliability, the cost of downtime, and the available budget. Here are some redundancy strategies:

• redundancy at the customer premise level

  This scenario involves setting up dual connections from the Customer Premises Equipment (CPE) to the network. These connections may be to the same network device (such as a dual-homed connection to a single access node) or to two different devices (a multihomed connection). The advantage here is that a single failed connection does not disrupt the service of the customer. However, the cost is higher as it requires more equipment.

• redundancy at the access node level

  In this scenario, each access node could have redundant connections to the BNG or to the aggregation network. This can provide a higher level of redundancy as it protects against both a connection failure and an access node failure. However, it requires more network resources (more connections and potentially more BNG ports) and it increases complexity, which could impact network performance or troubleshooting.

• redundancy in the aggregation network or the BNG

  This scenario could involve redundant connections, redundant devices, or both. For example, the aggregation network could have a redundant path to each BNG, and each BNG could have a redundant connection to the core network. Moreover, for a highly critical BNG, there could be a backup BNG that can take over if the primary BNG fails.

In all cases, network designers must balance the cost and complexity of redundancy against the cost and impact of potential downtime. Redundancy can significantly improve network reliability, but it comes with increased cost and complexity. Therefore, it is essential to understand the business needs and expectations before deciding where and how to implement redundancy.

Subscriber management in the routed central office (RCO) model, shown in RCO, represents one of the most widely adopted approaches, that offers support for various device types such as IPoEv4/v6 and PPPoEv4/v6. In this model, subscribers are typically terminated on the BNG located within a local central office. The use of an aggregation network in this setup is optional; access nodes can be directly connected to the BNG without an aggregation network or connected via such a network.

In RCO models, subscribers are terminated on Layer 3 interfaces. In SR OS, a conventional Layer 3 service interface is associated with a single SAP representing a single VLAN or VLAN pair. To accommodate multiple SAPs, that is multiple VLANs or VLAN pairs, under a single interface, two new interface types are introduced: subscriber and group interfaces. While subscriber interfaces define subscriber IP subnets, group interfaces play a pivotal role in aggregating SAPs. For a detailed explanation of group and subscriber interfaces and their respective roles, see Subscriber interface and Group interface.

Within each IES or VPRN service, users have the flexibility to create multiple subscriber interfaces, each of which must include at least one subnet. The distribution of these subscriber subnets into routing protocols is determined by user-defined import or export route policies.

Group interfaces are provisioned within the subscriber interface and share the associated subscriber subnets. These group interfaces can represent either a collection of subscribers on an Access Node (AN) or the AN itself.

Static SAPs are configured under the group interface. Managed (or dynamic) SAPs are automatically created under the group interfaces. For more information, see Managed SAP and Capture SAP. For example, in a VLAN-per-AN model, only one SAP per group interface is required. In contrast, in a VLAN-per-subscriber model, each subscriber on the AN necessitates its own SAP. All SAPs on a group interface must be on the same physical port or Link Aggregation Group (LAG).

For more information about static SAPs see the SAPs section in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Overview Guide.

Various subscriber-related features, including DHCP relay, DHCP snooping, PPPoE parameters, IPv6 parameters, anti-spoofing filters, and more, are enabled at the group interface level.

Because the RCO model serves as the primary deployment model, all examples provided in this guide are contextualized within the RCO model.

For more information, see Appendix: Subscriber management in distributed access aggregation devices.

A broadband subscriber represents a residential or a small business user. At a nodal level, a subscriber is typically defined by a unique subscriber identifier to which an assortment of policies (or subscriber profiles) can be applied. This uniquely identifies a billable entity for the service provider.

In Nokia BNG, a subscriber is identified by a subscriber identification string (subscriber-id) of maximum 64 characters long. This subscriber ID can then be passed to the external systems where management, troubleshooting, and billing operations require the subscriber ID name. In Nokia BNG, the subscriber ID can be assigned by several means:

• Use RADIUS, DIAMETER, or a Local User Database (LUDB), which are commonly referred to as authentication sources, during the authentication phase to assign the subscriber ID.
• Use a Python script during the instantiation process of the subscriber.
• Configure explicit defaults on a SAP level, which take effect if the subscriber ID is not provided by the previous two methods. On the SAP level, subscriber-id can be:
  • provisioned statically as a string
  • mapped to a SAP-id
  • automatically derived as a concatenation of user-defined subscriber identification
• Implicit default is enabled on the system level and it takes effect if none of the preceding methods are enabled. The subscriber-id is a 10-character string consisting of the characters A-Z and 0-9 autogenerated based on the subscriber identification fields.

Although the subscriber ID can be configured in multiple places, the value that takes effect in the system is selected from a single source that is determined in the order of priority. For more information about prioritization of authentication sources, see Prioritization of authentication sources.

A subscriber session in the BNG represents a user device to which the subscriber management functions are applied. This device can be a single stack device (IPv4 or IPv6) or dual-stack device (IPv4 or IPv6 with various combinations of IPv6 addresses, SLAAC, DHCP-IA-NA, DHCP-IA-PD).

A subscriber session can be either statically configured or dynamically learned in the BNG based on trigger packets. Trigger packets are typically DHCP and PPPoE control packets starting with DHCPv4 Discover, DHCPv6 Solicit, or PPPoE Active Discovery Initiation (PADI) messages. However, they can also be as simple as an ARP packet, IPv6 Router Solicitation, or even a generic IP data packet.

The subscriber sessions are instantiated on a SAP and are uniquely identified by various fields such as MAC address, IP address, circuit ID, remote ID, and others. Subscriber sessions of the same subscriber can be instantiated on a single SAP or spread across multiple SAPs on the same port.

During the subscriber session instantiation process, resources such as queues, filters, and counters are associated with the session. Although the queues, filters, and counters are not the only resource allocated with the session, they are the primary ones through which various policies are applied.

A subscriber can have a single or multiple sessions instantiated, depending on the configuration of the user premise. It is expected that all sessions of a subscriber originate from the same site and are reached by the same port on the BNG. The following three figures show some of the configurations:

• Subscriber sessions in residential deployment with bridged RG shows the residential premise with a bridged residential gateway (RG), where home devices are directly exposed to the BNG. For example, the BNG is directly involved in their IP address assignment through DHCP and PPPoE control packets. In this configuration, a subscriber is associated with multiple sessions, each representing a device within a residence.

  

• Subscriber sessions in residential deployment with routed RG shows the residential premise with routed RG where the residential homes are assigned the IP addresses by the RG and in this sense their control packets never reach the BNG. The IP address of the RG is managed by the BNG and therefore, the RG represents the subscriber session. In this configuration, a subscriber has a single session that represents the RG itself. The RG may or may not run a NAT that hides the IP addresses of devices in the residence.

  

• Subscriber sessions in small business deployments with routed CPE shows the small business deployment with routed CPE. This scenario is similar to the previous one, where the service offered to the subscribers are different.

  

The Service Level Agreement (SLA) profile contains QoS, security and other settings that are applicable to one, a subset, or all session in a home. An SLA profile is a template that can be shared by many subscriber sessions. Some of the settings in the SLA profile include:

• egress and ingress QoS configuration

• egress scheduler policy HQoS

• egress and ingress IP filters

• session limits

• idle timeout for the sessions

• statistics collection

• credit control parameters

The SLA profile becomes instantiated when the resources defined in the template are allocated, at which point the SLA profile becomes an SLA profile instance (SPI). By default, SPIs are created during the session setup process for every unique combination of:

• SLA profile name
• SAP
• Subscriber-ID

If the SLA profile does not explicitly define an ingress or egress QoS policy or filters, the default SAP ingress or default SAP egress QoS policy or filter is used.

Use the commands in the following context to configure SLA profile.

configure subscriber-mgmt sla-profile

For the complete list of command options for the configure subscriber-mgmt sla-profile command, see the following:

• 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide

• 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide

[ex:/configure subscriber-mgmt sla-profile "demo"]
A:admin@node-2# info
    credit-control-policy "demo-cc-policy"
    egress {
        ip-filter "demo-filter-egress"
        qos {
            sap-egress {
                policy-name "demo-qos"
            }
        }
    }
    session-limits {
        ipoe 8
        overall 10
        pppoe {
            local 8
        }
    }
    ingress {
        ip-filter "demo-filter-ingress"
    }
    

A:node-2>config>subscr-mgmt>sla-prof# info
----------------------------------------------
            credit-control-policy "demo-cc-policy"
            session-limits
                ipoe 8
                pppoe-local 8
                overall 10
            exit
            ingress
                ip-filter 11
            exit
            egress
                qos 20
                exit
                ip-filter 10
            exit
----------------------------------------------

The subscriber profile is a template that contains the applicable settings for all sessions that belong to the same subscriber. Examples include:

• ingress and egress QoS scheduler policy and policer control policy
• egress aggregate rate limit
• RADIUS accounting policy
• IGMP policy
• MLD policy
• PIM policy
• session limits

Subscribers are either explicitly mapped to a subscriber profile template or are dynamically associated with a subscriber profile.

Attempting to delete any subscriber profile (including the profile named "default") while in use by an existing active subscriber, fails.

Use the commands in the following context to configure a subscriber profile.

configure subscriber-mgmt sub-profile

For the complete list of command options for the configure subscriber-mgmt sub-profile command, see the following:

• 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide

• 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide

[ex:/configure subscriber-mgmt sub-profile "demo"]
A:admin@node-2# info
    egress {
        qos {
            agg-rate {
                rate 100000
            }
        }
    }
    radius-accounting {
        policy ["acct-1"]
    }
    session-limits {
        ipoe 10
    }

A:node-2>config>subscr-mgmt>sub-prof# info
----------------------------------------------
            session-limits
                ipoe 10
            exit
            radius-accounting
                policy "acct-1"
            exit
            egress
                agg-rate-limit 100000
            exit
----------------------------------------------

A subscriber identification policy is used by dynamically created sessions and it contains:

• URL pointers to the Python scripts used for dynamic session identification based on the information present in the DHCPv4 ACK message. These scripts represent a legacy method for dynamic DHCP session identification. For more information on Python scripting in ESM on the BNG , see Python script support for ESM.
• A subscriber profile map and an SLA profile map. The subscriber profile map creates a mapping between the sub and SLA profile strings returned by the Python script, LUDB, RADIUS or NASREQ and the profile names configured in the BNG. See SLA and subscriber profile mapping.
• DHCP options from which the subscriber identification strings can be derived. Some deployments require that DHCPv4 server provides subscriber strings necessary for subscriber identification.

A subscriber identification policy is defined using the following command:

• MD-CLI

  configure subscriber-mgmt sub-ident-policy name "sub-ident-policy-1"

• classic CLI

  configure subscriber-mgmt sub-ident-policy "sub-ident-policy-1"

A subscriber interface is a special type of interface under which subscriber sessions are instantiated. This is an internal loopback interface that supports multiple IP subnets that can be shared across many access nodes on different ports within the BNG. Those subnets aggregating subscribers are advertised via routing protocols on the network side for downstream reachability. Optionally, this interface can be unnumbered, in which case each subscriber session is advertised individually into the network. A subscriber interface contains IP addressing configuration as well as session-specific configurations.

Group interfaces are configured under the subscriber interfaces and they allow multiple SAPs on the same port to be part of the same interface. This is in contrast to traditional interfaces where each interface is associated with a single SAP. This aggregation of SAPs is also relevant in multichassis redundancy where states of the SAPs can be communicated between the nodes on an aggregate level instead of on an individual SAP level. The group interface is an unnumbered interface. The interface is operationally up if it is administratively enabled and if at least one SAP has been defined and is up and the parent subscriber interface is administratively up. The first SAP defined determines the port for the group interface. If the user attempts to define a subsequent SAP that is on a different port, it results in an error. When the subscriber interface or the group interface is administratively disabled, no packets are delivered or received to or from the subscriber session. However, the subscriber sessions, both dynamic and static, are maintained as long as the lease times are still valid.

Multiple group interfaces under the same subscriber interface share the same IP subnets. Each group interface can accommodate subscribers from a single port on the BNG, whether it is a faceplate, LAG, or a PW-port. The first SAP associated with the group interface determines the port for the group interface.

The concept of subscriber and group interface is shown in the figure that follows.

[ex:/configure service vprn "esm" subscriber-interface "sub-int-1"]
A:admin@node-2# info
    admin-state enable
    ipv4 {
        address 10.10.0.254 {
            prefix-length 24            
        }
        address 10.10.1.254 {
            prefix-length 24            
        }
    }
    ipv6 {
        delegated-prefix-length variable
        prefix 2001:db8:bbbb::/56 {
            host-type wan
        }
        prefix 2001:db8:bbbb:100::/56 {
            host-type pd
        }
    }
    group-interface "group-int-1" {
        admin-state enable
        oper-up-while-empty true
        ipv4 {
            dhcp {
                admin-state enable
                server [192.168.0.1]
                trusted true
                gi-address 10.10.0.254
                match-circuit-id true
                option-82 {
                    action keep
                    vendor-specific-option {
                        pool-name true
                    }
                }
                lease-populate {
                    max-leases 100
                }
                client-applications {
                    dhcp true
                }
            }
        }
        ipv6 {
            auto-reply {
                neighbor-solicitation true
                router-solicitation true
            }
            dhcp6 {
                pd-managed-route {
                }
                relay {
                    admin-state enable
                    server ["2001:db8::1"]
                    client-applications {
                        dhcp true
                        ppp true
                    }
                }
            }
            router-advertisements {
                admin-state enable
                force-mcast ip-mac
                options {
                    managed-configuration true
                    reachable-time 10000
                    retransmit-timer 3
                }
            }
            router-solicit {
                admin-state disable
            }
        }
        ipoe-session {
            admin-state enable
            ipoe-session-policy "ipoe-session-policy-1"
            user-db "demo-1"
            sap-session-limit 100
        }
        pppoe {
            admin-state enable
            policy "ppp-policy-1"
            session-limit 100
            sap-session-limit 100
            user-db "demo-1"
        }
        local-address-assignment {
            admin-state enable
            ipv4 {
                server "dhcpv4"
                client-applications {
                    ppp true
                }
            }
        }
    }

A:node-2# configure service vprn "esm" subscriber-interface "sub-int-1"
A:node-2>config>service>vprn>sub-if# info
----------------------------------------------
                address 10.10.0.254/24
                address 10.10.1.254/24
                ipv6
                    delegated-prefix-len variable
                    subscriber-prefixes
                        prefix 2001:db8:bbbb::/56 wan-host
                        prefix 2001:db8:bbbb:100::/56 pd
                    exit
                exit
                group-interface "group-int-1" create
                    ipv6
                        auto-reply
                            neighbor-solicitation
                            router-solicitation
                        exit
                        router-advertisements
                            force-mcast ip mac
                            managed-configuration
                            reachable-time 10000
                            retransmit-time 3
                            no shutdown
                        exit
                        dhcp6
                            pd-managed-route next-hop ipv6
                            relay
                                server 2001:db8::1
                                client-applications dhcp ppp
                                no shutdown
                            exit
                        exit
                    exit
                    local-address-assignment
                        server "dhcpv4"
                        client-application ppp-v4
                        no shutdown
                    exit
                    dhcp
                        option
                            action keep
                            circuit-id
                            no remote-id
                            vendor-specific-option
                                pool-name
                            exit
                        exit
                        server 192.168.0.1
                        trusted
                        lease-populate 100
                        gi-address 10.10.0.254
                        match-circuit-id
                        no shutdown
                    exit
                    ipoe-session
                        ipoe-session-policy "ipoe-session-policy-1"
                        sap-session-limit 100
                        user-db "demo-1"
                        no shutdown
                    exit
                    oper-up-while-empty
                    pppoe
                        policy "ppp-policy-1"
                        session-limit 100
                        sap-session-limit 100
                        user-db "demo-1"
                        no shutdown
                    exit
                exit
----------------------------------------------

In generic terms, dynamic instantiation of a subscriber session indicates that a limited configuration is required on the node. Configuring subscriber-specific parameters, including the SAP on which subscribers are instantiated, is not required. Instead, shared profiles are configured for multiple subscribers. All specifics for a subscriber, including the profile references, are assigned through authentication and address assignment sources. SAPs are then automatically determined from incoming session initiation traffic (in which a subgroup of the session control² traffic) arriving on the capture SAP.

This contrasts with static subscribers where everything must be explicitly configured in the node. For information about static sessions, see Static subscriber hosts.

Dynamic instantiation of subscriber sessions shows a high-level workflow of where all parameters are assigned dynamically:

• 1. Session initiation traffic, for example DHCP Discover for IPv4 traffic, arrives on a capture SAP and sent to the control plane.
• 2. Control plane authenticates the user based on information in DHCP Discover (for example Opt82 – circuit-id).
• 3. IP address is allocated to the session.
• 4. Replies are sent back to the user, and the rest of the control traffic is exchanged (DHCP Offer, DHCP Request, DHCP Ack).
• 5. Subscriber session is setup in the system. Managed SAP is derived from the incoming control packets.
• 6. Accounting is optionally started.
• 7. Subscriber session data traffic flows