|
|
Table Of Contents
Information About Subscriber Integration Models
Concepts and Terms
This module describes various terms and concepts that are utilized when working with the SCMS SCE Subscriber API.
•
Information About Subscriber Integration Models
Subscriber Characteristics
One of the fundamental entities in the Service Control Application for Broadband (SCA BB) solution is a subscriber . A subscriber is the entity that the SCA BB solution individually monitors, accounts, and enforces a service configuration. The following sections briefly describe the characteristics of the subscriber in the SCA BB. For more information about the format and usage of the subscriber's characteristics, see the Getting Familiar with the API Data Types module.
•
Subscriber ID
Subscriber ID is a subscriber unique identifier, for example, a user name, IMSI (International Mobile Subscriber Identity), or other codes that uniquely identify a subscriber.
Anonymous Subscriber ID
When working in the Pull Model integration, the SCE assigns each unknown subscriber IP address with a temporary Subscriber ID, Anonymous Subscriber ID, until it receives the real Subscriber ID from the Policy Server.
For more information on the Pull Model integration, see the Information About Subscriber Integration Models section.
Network ID
The SCE correlates a certain traffic flow to a subscriber by mapping a network identifier, for example, IP address, IP range, or VLAN, to the subscriber entity.
Policy Profile
A Policy Profile includes a set of parameters used by the SCA BB solution to define what policy is enforced on the subscriber.
Quota
A quota includes the quota-bucket values of the service quota or quotas available for the usage of the subscriber.
Information About Subscriber Integration Models
The following terms describe two models of a dynamic subscriber integration that the SCE platform supports.
Push Model
In push model integration, an external server introduces (pushes) the subscribers to the SCE platform. This is performed whenever a new subscriber logs in to the network or the external server presumes to know all subscribers and introduces them to the SCE box when they connect.
Figure 2-1 Push Model Schematic
Pull Model
In pull model integration, the SCE platform requests subscriber data from the external entity when it encounters traffic of an unknown subscriber, known as an anonymous subscriber. The external entity retrieves the required subscriber information and sends it back to the SCE platform.
Figure 2-2 Pull Model Schematic
Non-blocking Model
The SCE Subscriber API is implemented using a non-blocking model. Non-blocking methods return immediately, even before the completion of a subscriber provisioning operation. The Non-blocking Model method is advantageous when the operation is lengthy and involves I/O. Performing the operation in a separate thread allows the caller to continue doing other tasks and it improves overall system performance.
The operation results are either returned to an Observer object (Listener) or may not be returned at all.
The API supports retrieval of operation results using an operation result handler described in the Information About Result Handling section.
The following diagram illustrates the Non-blocking Model method during a subscriber provisioning operation:
Figure 2-3 Non-blocking Model
Operation results can be used for operation result error logging or for inspection of the parameters used by the operation.
Indications Listeners
The API provides the user with the ability to receive an indication when certain events occur on the SCE platform. The API dispatches the indications received from the SCE tothe interested entities, called listeners , by activating the relevant Listener's callback methods. The indications are separated into several logical groups when only one listener can be defined for each group of indications.
Figure 2-4 Indication Listeners
To receive certain indications, you need to register a listener to the API that implements the required callback functions. After the listener is registered, the API can dispatch the required indications to the listener. The SCMS SCE Subscriber API provides three types of indications when separate listeners are registered to the following types of the indications:
•
•
•
For more information about listener indications, see the API Events module.
Supported Topologies
The following topologies are recommended to use with the SCMS SCE Subscriber API:
•
Figure 2-5 Supported Topologies - One Policy Server
•
Figure 2-6 Supported Topologies - Three Policy Servers
•
Figure 2-7 Supported Topologies - Two Policy Servers
•
Figure 2-8 Supported Topologies - DHCP Lease Query LEG
•
Figure 2-9 Supported Topologies - SM
Note
Multi-threading Support
The API supports an unlimited number (limited by the available memory) of threads calling its methods simultaneously.
Note
Auto-reconnect Support
The API supports auto-reconnection to the SCE in case of connection failure. When this option is activated, the API can determine when the connection to the SCE is lost. When the connection is lost, the API activates a reconnection task that tries to reconnect to the SCE again in a configurable interval time until reconnection is successful.
Reliability Support
The SCMS SCE Subscriber API is implemented as a reliable API. The API ensures that no requests to the SCE are lost and no indication from the SCE is lost. The API maintains an internal storage for all API requests that were sent to the SCE. Only after receiving an acknowledgement from the SCE that the request was handled, it considers the request as committed and the API can remove the request from its internal storage. If a connection failure occurs between the API and the SCE, the API accumulates all requests in its internal storage until the connection to the SCE is reestablished. On reconnection, the API resends all non-committed requests to the SCE, ensuring that no requests are lost.
Note
High Availability Support
The API provides high availability support. It assumes that the high availability scheme of the policy server is a two-node cluster type where only one server is active at any given time. The other server, in standby, is not connected to the SCE. For more information, see the Implementing High Availability.
Synchronization
The SCE and Policy Server must be kept synchronized concerning the subscribers for which the SCE is handling their internal parameters. Otherwise, the SCE might confuse one of the subscriber's traffic to another subscriber, or the subscriber's SLA (Service Level Agreement) will not be enforced because of a change in the policy that did not reach the SCE. For more information, see Information About SCE-API Synchronization.
Practical Tips
When implementing the code that integrates the API with your application you should consider the following practical tips:
•
•
•
•
•
•
•
Posted: Thu May 31 00:58:58 PDT 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
