Introducing the Subscriber Manager

This module describes the Subscriber Manager solution, the handling of subscribers, and the fundamentals and management of the SM application.

Information About the Subscriber Manager

The Subscriber Manager (SM) is a middleware software component that supplies subscriber information for multiple SCE platforms in deployments where dynamic subscriber awareness is required. It does this in one of two ways:

•

By serving as a stateful bridge between an AAA system or a provisioning system and the SCE platforms

The SCE platforms use subscriber information to provide subscriber-aware functionality, per-subscriber reporting, and policy enforcement.

Some Cisco Service Control solutions can also operate without subscriber awareness:

•

Subscriber-less—Control- and link-level analysis functions are provided at a global device resolution.

•

Anonymous subscriber—The system dynamically creates "anonymous" subscribers per IP address. User-defined IP address ranges may then be used to differentiate between anonymous subscribers policies.

•

Static subscriber awareness—Subscriber awareness is required, but allocation of network IDs (mainly IP addresses) to subscribers is static.

In these three modes, the SCE platform handles all subscriber-related functionality and an SM module is not required.

Note Starting with SM version 2.2, you can configure the SM to operate either with or without a cluster of two SM nodes. The added functionality when operating in a cluster topology provides powerful new features such as fail-over and high availability . The information in most of this module is applicable whether using a cluster or not. However, for clarity, information that is applicable only when using a cluster is presented in the Subscriber Manager Fail-Over module.

Subscribers in the Cisco Service Control Solution

A subscriber is defined as a managed entity on the subscriber side of the SCE platform, to which accounting and policy are applied individually. The subscriber side of the SCE platform is the side that points to the access or downstream part of the topology, as opposed to the network side of the SCE platform, which points to the core of the network.

Information About Handling Subscribers

•

Mapping—The SCE platform encounters flows with network IDs (IP addresses) that change dynamically, and it requires dynamic mapping between those network IDs and the subscriber IDs. The SM database contains the network IDs that map to the subscriber IDs. This is the main functionality of the SM.

•

Policy—The SM serves as a repository of policy information for each subscriber. The policy information may be preconfigured to the SM, or dynamically provisioned when the mapping information is provided.

•

Capacity—The SCE platform or platforms may need to handle (over time) more subscribers than they can concurrently hold. In this case, the SM serves as an external repository for subscriber information, while only the online or active subscribers are introduced to the SCE platform.

•

Location—The SM supports the functionality of sending subscriber information only to the relevant SCE platforms, in case such functionality is required. This is implemented using the domains mechanism or the Pull mode (see Pull Mode ).

•

As the only source for subscriber information when the SM works in standalone mode

•

As a subscriber information cache when the SM serves as a bridge between a group of SCE devices and the customer Authentication, Authorization, and Accounting (AAA) and Operational Support Systems (OSS).

Flow of Subscriber Information

–

Automatically upon the subscriber going online—A Login Event Generator (LEG) software module that integrates with the customer AAA system (such as DHCP Server, RADIUS, or Network Access System (NAS)) identifies a subscriber login event, and sends it to the SM by using the SM API.

–

Manual setup—Subscriber information is imported into the SM from a file or by using the Command-Line Utilities (CLU).

•

Automatic and manual modes can be combined. For example, all subscribers may be loaded to the SM via manual setup, and a subset of the subscriber record (domain, network ID, and so on) changed automatically through the SM API.

•

In automatic mode, the SCMS SM Java or C/C++ APIs are used for delegating subscriber information to the SM (see the Cisco SCMS SM Java API Programming Guide or the Cisco SCMS SM C/C++ API Programming Guide ).

•

The information may be passed automatically to the SCE platform, or it may reside in the SM database until the SCE platform requests the information.

The SM may be configured with more than one SCE platform. These SCE platforms may be grouped into domains. Each domain represents a group of SCE platforms that serve the same group of subscribers.

Number of Subscribers in the SM

The subscribers of the service provider may be divided into the following logical types (at any given moment):

•

Offline subscriber—A subscriber that currently does not have any IP address and as such does not generate any IP traffic. Such subscribers are not stored in the SCE platform.

•

Online subscriber—A subscriber that is currently online. At any particular time, a certain number of online subscribers will be idle, that is, connected to the service provider but not generating any IP traffic.

•

Active subscriber—An online subscriber that is generating IP traffic (such as by browsing the Internet or downloading a file).

In addition, the total number of subscribers is all the subscribers whose IP traffic might be traversing through the SCE platforms in a specific deployment.

•

Total number of subscribers can be statically stored in a single SCE platform.

This is the simplest, most reliable scenario. It may not require the use of the SM.

•

Total number of subscribers exceeds the capacity of the SCE platform, but the number of online subscribers predicted at any time can be statically stored in the SCE platform.

•

Number of online subscribers exceeds the capacity of the SCE platform, but the number of active subscribers predicted at any one time can be statically stored in the SCE platform.

•

Number of active subscribers predicted at any one time exceeds the capacity of the SCE platform.

Multiple SCE devices must be installed to divide the subscribers among the SCE platforms. If the system is divided into domains (see Domains ), so that the SM knows in advance to which SCE platform a particular subscriber should be sent, Push mode may be used. Otherwise, Pull mode is required.

SM Database

The SM uses a commercial relational database from TimesTen, optimized for high performance and with a background persistency scheme. The In-Memory Database efficiently stores and retrieves subscriber records.

A subscriber record stored in the SM Database (SM-DB) consists of the following components:

•

Subscriber name (key)—A string identifying the subscriber in the SM. Maximum length: 64 characters. This can be case-sensitive or case-insensitive depending on the configuration file. By default, the database is case-sensitive. If the database is case-insensitive, the SM will convert the name to lower case when updating or querying the database.

•

Domain (secondary key)—A string that specifies which group of SCE devices handles this subscriber.

•

Subscriber network IDs (mappings)—A list of network identifiers, such as IP addresses or VLANs. The SCE uses these identifiers to associate network traffic with subscriber records.

•

Subscriber policy—A list of properties that instruct the SCE what to do with the network traffic of this subscriber. The content of this list is application specific.

•

Subscriber state (for example, quota used)—A field that encodes the subscriber state, recorded by the last SCE, to handle the network traffic of this subscriber.

Note that in cluster redundancy topology, the active machine database replicates the subscriber data to the standby machine database. For additional information, see the Subscriber Manager Fail-Over module.

Subscriber ID

The Subscriber ID is a string representing a subscriber that is a unique identifier for each subscriber from the customer perspective. For example, it may represent a subscriber name or a CM MAC address. This section lists the formatting rules of a subscriber ID.

It can contain up to 64 characters. All printable characters with an ASCII code between 32 and 126 (inclusive) can be used; except for 34 ("), 39 ('), and 96 (`).

Information About SM Fundamentals

The SM API

The SM API is provided in C, C++, and Java. It serves as the bottom-most layer of every LEG.

SM API programmer references are provided in the Cisco SCMS SM C/C++ API Programmer Guide and the Cisco SCMS SM Java API Programmer Guide .

The SM Login Event Generators

The SM Login Event Generators (LEGs) are software components that use the SM API to generate subscriber-record update messages (such as login/logout) and send them to the SM. LEGs are usually installed with AAA/OSS platforms, or with provisioning systems. They translate events generated by these systems to Cisco Service Control subscriber update events.

The unique functionality of each LEG depends on the specific software package with which it interacts. For example, RADIUS LEGs, DHCP LEGs, or some provisioning third party system LEGs may be implemented. LEGs can set up subscribers or alter any of the fields of an existent subscriber record.

You can connect multiple LEGs to a single SM. Conversely, a single LEG can generate events for multiple domains.

Information About Subscriber Introduction Modes

As illustrated in Figure 2-1, the SM introduces subscriber data to the SCE platforms. This operation functions in one of two modes:

For information detailing the configuration of the subscriber integration modes, see SM General Section.

In Push mode, immediately after adding or changing a subscriber record, the SM distributes, or pushes, this information to the relevant SCE platforms, as determined by the subscriber domain. When the subscriber starts producing traffic through the SCE platform, it is ready with the required subscriber information.

In some scenarios, factors such as capacity limitations make it impossible to use Push mode.

Note Use Push mode only if all online subscribers associated with a domain can be loaded simultaneously into all the SCE platforms in the domain.

In Pull mode, the SCE platforms are not notified in advance of subscriber information. When an SCE platform cannot associate the IP traffic with a subscriber, it will request, or pull, the information from the SM.

The advantage of Pull mode is that there is no need to know in advance which SCE platform serves which subscriber.

•

Increased load on the SM, as it processes incoming requests from both the SCE device and the LEG.

Note By default, the SCE does not request subscriber information from the SM. You must configure anonymous groups in the SCE for the set of IP ranges that should be requested from the SM. See the SCE User Guide for more details on anonymous subscriber groups.

Note Pull mode must be used when all online subscribers associated with a domain exceed the capacity of the SCE platforms in the domain (but the number of active subscribers can still be loaded into the SCE platforms in the domain).

The following table summarizes the differences between the Push mode and Pull mode:

Table 2-1 Differences Between Push Mode and Pull Mode
Aspect of Use	Push Mode	Pull Mode
When to use	For simple provisioning of subscriber information to the SCE platform	For real-time, on-demand subscriber information retrieval Used in large scale deployments: •When there is no way of knowing from the IP assignment process which SCE platform will be serving a particular subscriber •When the required number of logged-in subscribers is greater than the number of concurrently active subscribers that the SCE platform can handle
Functional flow at access time	•Subscriber network login or access •From subscriber information to LEG to SM •From SM to the relevant SCE platforms	•Subscriber network login or access •From subscriber information to LEG to SM (hold in the SM database) •When the subscriber starts producing traffic that traverses the SCE platform SCE platform asks for the subscriber information •From SM (SM database) to SCE platform
Subscriber information at the SCE platform	SCE platform always has current subscriber information: •Immediate policy enforcement •Real-time system architecture	SCE gets subscriber information on demand

SCE Subscriber Synchronization

The SM includes a mechanism to ensure that the SCE platforms' subscriber information is synchronized with the information in the SM database. This mechanism is activated in the following cases:

•

When the SM reconnects to the SCE platform and the standby SCE within the cascade pair is not synchronized.

SCE Quarantine

From SM version 3.1.0, the SM can put an SCE into a quarantine state. This action is taken in extreme cases when the SM automatically detects that the SCE has a problem and is causing back-pressure of logon events to the SM. This action prevents the SCE from causing problems for the SM when managing subscriber information for all of the other SCEs in the network.

•

After the timeout expires the connection to the SCE is re-established and the SCE is put into a post-quarantine state for another ten minutes.

If another failure occurs within the post-quarantine-timeout period, the quarantine-timeout is doubled. The quarantine state transition is logged to the user log.

Working with Cascade SCE Setups

From SM version 3.1.0, the SM handles cascaded SCEs as a cascade pair and not as two separate SCEs and utilizes the SCE's ability to duplicate the subscriber data between the SCEs by updating only the active SCE.

The SM connects to both SCEs but sends logon operations to only the active SCE. Similarly, the SM performs subscriber synchronization with only the active SCE.

The standby SCE learns about the subscribers from the active SCE, which allows stateful fail-over. The SM identifies a fail-over event and synchronizes the SCE that became active so that it will receive the most updated subscriber information.

Domains

The SM provides the option of partitioning SCE platforms and subscribers into subscriber domains.

The motivation for the domains concept is for enabling a single SM to handle several separate network sections, and for better control of subscriber introduction to the SCEs.

A subscriber domain is a group of SCE platforms that share a group of subscribers. The subscriber traffic can pass through any SCE platform in the domain. A subscriber can belong to only a single domain. Usually a single SCE platform serves a subscriber at any given time.

•

In Push mode, all the subscribers in a subscriber domain are sent to all SCEs in the domain. The main reason for the number of SCE platforms in a single domain is redundancy.

•

In Pull mode, the pull requests are handled only for subscribers in the domain of the pulling SCE platform. In Pull mode, usually a single domain covers all the subscribers.

•

From SM version 3.1.0, subscribers can be moved between domains in a process known as automatic domain roaming. After receiving an update that an existing subscriber has switched domain:

–

In Push mode, the subscriber is automatically logged out from the old domain and then logged in to the new domain.

–

In Pull mode, the subscriber is automatically logged out from the old domain.

Note Automatic domain roaming is not backward compatible with previous SM behavior.

The system is configured with one default subscriber domain called "subscribers". When adding an SCE platform to the SM, it is automatically added to this default domain, unless otherwise specified. Subscribers are also associated with this default subscriber domain, unless otherwise specified. To associate a subscriber with a different domain, first define this domain in the configuration file, and then explicitly specify it when adding the subscriber to the SM. To associate an SCE platform with a non-default subscriber domain, edit and reload the configuration file. For more information, see Configuration and Management.

Information About Communication Failures

A communication failure may occur either on the LEG-SM communication link or on the SM-SCE communication link. A communication failure may occur due to a network failure or because the SCE, SM, or LEG has failed. High availability and recovery from an SM failure are discussed in SM Cluster.

When configuring the system, you should consider three issues related to communication failures:

•

Communication failure detection—A timeout after which a communication failure is announced

•

Communication failure handling—The action to be taken when communication on the link fails

•

Communication failure recovery—The action to be taken when communication on the link resumes

•

Erase the subscriber mappings in its database and start handling flows without subscriber awareness

Erasing the mappings in the database is useful when you want to avoid incorrect mappings of subscribers to IP addresses. This configuration is implemented by requesting to clear all mappings upon failure.

The SM recovers from communication failures by resynchronizing the SCE platform with the SM database.

SM Cluster

The SM supports high availability using the Veritas Cluster Server (VCS) technology. In a high availability topology, the SM software runs on two machines, designated as the active machine and the standby machine. Subscriber data is continuously replicated from the active to the standby machine, ensuring there is minimal data loss in case of active SM failure. When the active machine fails, the standby machine discovers the failure and becomes active. For additional information, see the Subscriber Manager Fail-Over module.

SM Management

SM management includes configuration, fault management, logging management, and performance management.

•

Configuration file ( p3sm.cfg )—For setting all configuration parameters of the Subscriber Manager.

Note Changes that you make in the configuration file take effect only when you load the configuration file using the Command-Line Utilities (CLU) or when you restart the SM.

•

Command-Line Utilities (CLU)—For ongoing subscriber management and monitoring of the SM. CLU commands are shell tools that you can use to manage subscribers, install or update applications, retrieve the user log, and load the configuration file when updated.

The CLU can be invoked locally, through a Telnet (or SSH) session to the SM hosting platform.

Use the SM user log files for logging, fault, and performance management. The log file contains information regarding system events, failures, and periodic system performance reports.

Subscriber Manager Fail-Over

You can configure the SM to operate with or without a cluster. The added functionality when operating in a cluster topology provides powerful new features such as fail-over and high availability . For full details, see Subscriber Manager Fail-Over.

Table Of Contents