Cisco SCMS Collection Manager User Guide, Release 3.7.x
Collection Manager Overview

Table Of Contents

Collection Manager Overview

Introduction

Data Collection Process

Raw Data Records

Collection Manager Software Package

Raw Data Record Server

Categorizer

Priority Queues and Persistent Buffers

Adapter Description

JDBC Adapter

Comma Separated Value Adapter

Custom Adapter

Topper/Aggregator (TA) Adapter

TA Adapter Cycles

TA Adapter Memory Requirements

Real-Time Aggregating Adapter

RAG Adapter Aggregation Buckets

Flushing a Bucket

RAG Adapter Process for HTTP Transaction Usage RDR

RAG Adapter Process for Video Transaction Usage RDR

RAG Adapter Mobile Based Reports

RAG Adapter Process for Subscriber Usage RDR

Managing OSFP support for Subscriber Usage RDR

Using Databases

Using the Bundled Database

Using an External Database


Collection Manager Overview


Introduction

This chapter is an overview of the Cisco Service Control Management Suite (SCMS) Collection Manager (CM) operating with the Cisco Service Control Engine (SCE). The Cisco Collection Manager uses the hardware capabilities of the SCE platform and identifies the combination of Cisco-specific applications that create the Cisco Service Control solution.

The Collection Manager also interoperates with the Cisco Service Control solution in combination with the Cisco ASR 1000 Series Aggregation Services Routers and Cisco IOS Flexible NetFlow. Refer to the Cisco Service Control Management Suite Collection Manager NetFlow User Guide for information on this solution.

This chapter describes the following:

How the CM works

The Raw Data Records (RDRs) that the SCE platforms generate and send to the Collection Manager

The components of the Collection Manager software package

The database used to store the RDRs.

The chapter includes the following sections:

Data Collection Process

Raw Data Records

Collection Manager Software Package

Adapter Description

Using Databases

Data Collection Process

Cisco SCE platforms generate RDRs. The application running on the SCE platform, such as the Cisco Service Control Application for Broadband (SCA BB), specifies and defines the RDRs.

1. The SCE platform streams RDRs by using the simple, reliable RDR-Protocol. Integrating the collection of data records with the Service Control Solution involves implementing RDR-Protocol support in the collection system .

2. After the Collection Manager receives the RDRs from the SCE platforms, its software modules recognize and sort the various types of RDR based on preset categories and according to type and priority. The Collection Manager queues the RDRs in persistent buffers.

3. Collection Manager adapters process each RDR. Each adapter performs a specific function on an RDR:

Stores it in a customer adapter formatted file on a local machine

Sends it to an RDBMS application

Performs custom operations

You can use preinstalled utility scripts to customize many of the parameters that influence the behavior of the Collection Manager.


Note The Cisco Collection Manager supports both RDR collector and Flexible NetFlow collector at the same time.


Raw Data Records

The SCE platforms generate Raw Data Records (RDRs). The RDRs, their fields, and their semantics depend on the specific service control protocol (SCP) application. Each RDR type has a unique ID known as an RDR tag.

Table 2-1 presents examples of RDRs produced by SCP applications:

Table 2-1 Example RDRs Produced by SCP Applications 

Report Type
Description
RDRs contain...

Periodic Subscriber usage report

SCE platforms are subscriber-aware network devices; they can report usage records per subscriber.

Subscriber identifier (such as the OSS subscriber ID), the traffic type (such as HTTP, streaming, or peer-to-peer traffic), and usage counters (such as total upstream and downstream volume). This type of usage report is necessary for usage-based billing services, and for network analysis and capacity planning.

The SCA BB application Subscriber Usage RDRs are in this category.

Transaction level report

SCE platforms perform stateful tracking of each network transaction conducted on the links on which they are located. Using this statefulness, the SCP tracks several OSI Layer 7 protocols (such as HTTP, RTSP, SIP, or Gnutella) to report on various application-level attributes.

Transaction-level parameters ranging from basic Layer 3-4 attributes (such as source IP, destination IP, and port number) to protocol-dependant Layer 7 attributes (such as user-agent, hostname for HTTP, or email address of an SMTP mail sender), and also generic parameters (such as time of day and transaction duration). These RDRs are important for content-based billing schemes and for detailed usage statistics.

SCA BB application Transaction RDRs are in this category.

SCP application activity reports

The SCP application can program the SCE platform to perform various actions on network traffic. These actions include blocking transactions, shaping traffic to certain rates and limits, and performing application-level redirections. When such an operation is performed, the SCP application can produce an RDR.

The SCA BB application Breaching RDRs and Blocking RDRs are in this category. Breaching RDRs are generated when the system changes its active enforcement on a subscriber (because usage exceeded a certain quota). Blocking RDRs are generated when an SCE platform blocks a network transaction (according to rules contained in the current service configuration).


Collection Manager Software Package

The Collection Manager software package contains a group of processing and sorting modules. These modules include the following components:

Raw Data Record Server

Categorizer

Priority Queues and Persistent Buffers

Raw Data Record Server

As each incoming raw data record (RDR) arrives from an SCE platform, the RDR server adds an arrival timestamp and the ID of the source SCE platform, and then sends the RDR to the categorizer.

Categorizer

A categorizer classifies each RDR according to its RDR tag. It determines the destination adapter for the RDR and the priority queue through which the RDR is sent.

An RDR can be mapped to more than one adapter. A qualified technician defines the flow in a configuration file, based on user requirements.

Priority Queues and Persistent Buffers

Each adapter has one or more priority queues; a persistent buffer is assigned to each priority queue.

A priority queue queues each RDR according to its priority level and stores it in a persistent buffer until the adapter processes it.

A persistent buffer is a nonvolatile storage area that ensures that the system processes RDRs even in cases of hardware, software, or power failures.

Adapter Description

Adapters are software modules that transform RDRs to match the requirements of the target system. The adapter distributes the RDRs upon request. Currently, the following adapters are shipped with the system:

JDBC Adapter

Comma Separated Value Adapter

Custom Adapter

Topper/Aggregator (TA) Adapter

Real-Time Aggregating Adapter

Some of the adapters send data to the database or write data to CSV files. The structures of the database tables, and the location and structures of these CSV files are described in Cisco Service Control Application for Broadband Reference Guide.

Each adapter has its own configuration file. All the configuration files are similar in structure. For a sample RAG adapter configuration file, see the "ragadapter.conf File" section.

JDBC Adapter

The Java Database Connectivity (JDBC) adapter receives RDRs, processes them, and stores the records in a database.

This adapter is compatible with any database server that is JDBC-compliant, and transforms the records accordingly. You can configure the JDBC adapter to use a database operating on a remote machine.

The JDBC adapter is preconfigured to support the following databases:

Sybase Adaptive Server Enterprise (ASE) 12.5 and 15.0

Oracle 9.2, 10.2, and 11


Note Disable the recycle bin feature available in Oracle 10 and later versions. You can set the initial value of the recyclebin parameter in the text initialization file init<SID>.ora, for example:
recyclebin=off


MySQL 4.1, 5.0, and 5.1

Comma Separated Value Adapter

The comma-separated-value (CSV) adapter receives RDRs, processes them, and writes the records to files on the disk in the CSV format. Using standard mechanisms such as FTP, a service provider OSS or a third-party billing system can retrieve these records to generate enhanced accounting and network traffic analysis records.

Custom Adapter

The Custom Adapter allows you to configure the RDR format. The Custom Adapter receives records with specified fields from the RDR.

You can configure only a few fields of TUR. Some of the configurable fields are Sub-ID, Upstream + Downstream and Application. The corresponding RDR is processed with those specific fields and stored in a CSV file. The Custom Adapter also supports basic arithmetic operations (add, sub, maul) on a few of the RDR fields.

The Custom Adapter process is disabled by default. Edit the ~scmscm/cm/config/cm.conf file and restart the Cisco Collection Manager to enable the Custom Adapter. For more information on enabling Custom Adaptor, see "Enabling Adapters" section.

Topper/Aggregator (TA) Adapter

The topper/aggregator (TA) Adapter receives subscriber usage RDRs, aggregates the data that they contain, and outputs Top Reports to the database and aggregated daily statistics of all the subscribers (not just the top consumers) to the CSV files. Top Reports are lists of the top subscribers for different metrics (for example, the top 500 volume or session consumers in the last hour).

The TA Adapter maintains a persistent saved state (saved to disk) to minimize any data loss in case of failure.

You can configure the TA Adapter, which uses the JDBC adapter infrastructure, to use any JDBC-compliant database, either locally or remotely.

For Release 3.7.2 and later, Package based aggregation has been added to the TA Adapter along with the existing service based aggregation. Now, the TA Adapter aggregates the records and lists the top subscribers for each service/package combination with different metric. The package based aggregation is disabled by default. To enable the package based aggregation in the TA Adapter the user has to update the agg_pkg_level property as true in the ~scmscm/cm/config/taadapter.conf file and restart the Cisco Collection Manager


Note When several Collection Manager servers use a single database, the TA Adapter information might not be accurate because it is aggregated locally on each of the Collection Managers.



Note RDR type SUR populates CSV TAAdapter file.


TA Adapter Cycles

TA Adapter Memory Requirements

TA Adapter Cycles

The TA Adapter works in three cycles: short, long, and peak hours (specific hour range). Cycles are fixed intervals. This data is temporily stored in a persistent buffer directory with a default location of ~scmscm/cm/adapters/TAAdapter. At the end of an interval, the adapter outputs its aggregated information to the database and to a CSV file. The default interval for the short cycle is 1 hour and the long cycle is 24 hours (every day at midnight). You can configure an interval (defined in minutes) and its start and end time. Configure the interval for the peak hours cycle. At the end of the peak hours, the adapter aggregates and outputs details of the top subscribers to the database.


Note The long-cycle interval must be a multiple of the short-cycle interval.


The activities in each cycle differ slightly, as follows:

Short cycle—At the end of each short cycle, the adapter:

Adds the aggregated Top Reports of the cycle to the short cycle database table

Saves the current state file in case of power failure

Long cycle—At the end of each long cycle, the adapter:

Adds the aggregated Top Reports of the cycle to the long cycle database table

Saves the current state file in case of power failure

Creates a CSV file to contain the aggregated statistics for the long-cycle period

Peak-hour cycle—At the end of each peak-hour cycle, the adapter:

Adds the aggregated Top Reports of the cycle to the peak hour cycle database table

Saves the current state file in case of power failure


Note The long cycle data is saved every hour, so the .sav file has 0-23:00 hours of data if a power shutdown happens between 23:00 hrs to 24:00. The CSV file contains aggregated data and .sav file to save the current state in a non-readable format.


TA Adapter Memory Requirements

The TA Adapter functions correctly only if you dedicate a sufficient amount of memory to the TA Adapter. Configure the value in the cm.conf file in the following location:

[adapter_mem] 
com.cisco.scmscm.adapters.topper.TAAdapter=<Memory for TA Adapter>

To calculate the recommended amount of memory for the TA Adapter, use the following formula:

Memory (MB) = (3.5 * TOTAL_SUBSCRIBERS * (AVG_SUBS_ID_LENGTH + 32 * ACTIVE_SERVICES) / (1024 * 1024)) * MAX_NO_OF_PKGS.

Where:

TOTAL_SUBSCRIBERS is the total number of subscribers.

AVG_SUBS_ID_LENGTH is the average character length of a subscriber.

In most cases, the average character length is approximately 20.

ACTIVE_SERVICES is the average number of active services used per subscriber.
The default value is 10.

MAX_NO_OF_PKGS is the maximum number of packages used by a particular subscriber among all subscribers. If package based aggregation is disabled then the property value should be 1.


Note For example, if there are 100 subscribers out of which 40 of them use 5 packages, 50 of them use 10 packages and 10 of them use 12 packages. In this case MAX_NO_OF_PKGS property set to 12, It's the highest of all packages among all the subscribers. Though the maximum limit is set to12 in this case, the package based aggregation will happen only for the number of packages allocated to that particular subscriber.



Note For Linux JRE 32 bit, the configured memory should not exceed 2 GB.
For Linux JRE 64 bit, you can set higher values for the configured memory.



Note For Solaris JRE 32 bit, the configured memory should not be over 3.5 GB.
For Solaris JRE 64 bit, you can set higher values for the configured memory. To configure the TA or RAG adapters to run with the JRE 64 bit, see the "[adapter_mem] Section" section.


Real-Time Aggregating Adapter

The RAG adapter processes RDRs of one or more types and aggregates the data from predesignated field positions into buckets. The contents of the buckets are written to CSV files.

RAG Adapter Aggregation Buckets

Flushing a Bucket

RAG Adapter Process for HTTP Transaction Usage RDR

RAG Adapter Process for Video Transaction Usage RDR

RAG Adapter Process for Subscriber Usage RDR

Managing OSFP support for Subscriber Usage RDR

RAG Adapter Aggregation Buckets

A RAG adapter aggregation bucket is indexed by combining values from fields in the RDR. The indexing relation can be one-to-one or many-to-one.

The values in the bucket-identifying fields are processed using closures (equivalence classes), which are configured per type of RDR.

Example:

Bucket-identifying field = field number 3 
Closures: 4 = 4,5,6; 10 = 8,10,11 
Value in field 3 = 4, 5, or 6; field reported as 4 
Value in field 3 = 8, 10, or 11; field reported as 10

You can configure the adapter to monitor the values in certain fields for change relative to the values in the first RDR that entered the bucket. For each monitored field, an action is performed when a value change is detected. The supported actions are:

Checkpoint the bucket without aggregating this RDR into it, and start a new bucket with this RDR

Issue a warning to the user log

Buckets, closures, triggers, and trigger actions are defined in an XML file. For a sample XML file, see the "ragadapter.xml File" section.

Flushing a Bucket

When a bucket is flushed, it is written as one line to a CSV file.

The trigger for flushing a bucket (a checkpoint) is the earliest occurrence of any of the following:

Time elapsed since the creation of the bucket reaches a configured duration

Volume in an accumulated field in the bucket exceeds a configured amount

Adapter, or the entire Collection Manager, goes down

RDR arrives at the bucket with some new value (relative to the bucket contents) in some field

The trigger to close a CSV file is the earliest occurrence of one of the following:

Time elapsed since the creation of the file has reached a set duration

Number of lines in the file has reached a set number

Adapter, or the entire Collection Manager, goes down

RAG Adapter Process for HTTP Transaction Usage RDR

If a corresponding RDR TAG is configured under the RAG adapter section in the queue.conf file before the Collection Manager is started, the RAG adapter processes HTTP_TUR RDRs.

An XML file specific to HTTP_TUR is included in the Collection Manager distribution for the RAG adapter to manage HTTP_TUR RDR fields. The aggregation period for processing the RDRs is specified in the http_TURs.xml file.

Aggregation is based on the domain, package, and service for the corresponding HTTP Transaction Usage RDR. At the end of the aggregation period, the adapter adds the aggregated Top Reports for hosts to the RPT_TOP_HTTP_HOSTS database table. The adapter adds the aggregated Top Reports for domains to the RPT_TOP_HTTP_DOMAINS database table.

RAG Adapter Process for Video Transaction Usage RDR

If you configure a corresponding RDR TAG under the RAG adapter section in queue.conf file before you start the Collection Manager, the RAG adapter processes VIDEO_TUR RDRs.

The Collection Manager distribution includes an XML file specifically for VIDEP_TUR, which enables the RAG adapter to manage VIDEO_TUR RDR fields. The aggregation period for processing the RDRs is specified in the video_TURs.xml file.

Aggregation is based on the domain, package, and service for the corresponding VIDEO Transaction Usage RDR. At the end of the aggregation period, the adapter adds the aggregated Top Reports for hosts to the RPT_TOP_VIDEO_HOSTS database table. Also, the adapter adds the aggregated Top Reports for domains to the RPT_TOP_VIDEO_DOMAINS database tables.

RAG Adapter Mobile Based Reports

The Cisco Collection Manager supports either GSM or CDMA mobile based reports. GSM reports are enabled by default.

The ~scmscm/cm/config/ragadapter.conf

file property (vsa_type=gsm or cdma) configures the mobile report type processed.

The user has to place the related xml files in ~scmscm/cm/config/ragadapter for the Cisco Collection Manager process. By default all the XML files are available in the ~scmscm/cm/config/ragadapter/repository directory.

RAG Adapter Process for Subscriber Usage RDR

If a corresponding RDR TAG is configured under the RAG adapter section in queue.conf before the Collection Manager is started, the RAG adapter processes NUR RDRs. The Subscriber Usage RDRs are processed in two ways:

Aggregation Based on VSA Fields

Aggregation Based on Package

Aggregation Based on VSA Fields

Aggregation Based on GSM specific VSA Fields

Aggregation Based on CDMA specific VSA Fields

The Collection Manager supports any one of the Mobile based Reports (either GSM or CDMA). By default, GSM reports are enabled. In ~scmscm/cm/config/ragadapter.conf file a new property (VSA_Type = gsm or cdma) is added to configure which mobile report the Cisco Collection Manager needs to process.

During restart, based on the vsa_type configuration the Cisco Collection Manager will copy the corresponding xml config file to the ~scmscm/cm/config/ragadapter for processing.

Aggregation Based on GSM specific VSA Fields

The vsa_SURs.xml file manages GSM specific VSA fields in Subscriber Usage RDRs. The aggregation period for processing the RDRs is specified in this file. Aggregation is based on the GSM specific VSA fields (APN, SGSN, NETWORK_TYPE, DEVICE_TYPE, and USER_LOCATION). At the end of the aggregation period, the adapter adds the aggregated Top Reports for the GSM specific VSA fields to their corresponding database tables:

RPT_TOP_APN

RPT_TOP_SGSN

RPT_TOP_NETWORK_TYPE

RPT_TOP_DEVICE_TYPE

RPT_TOP_USER_LOCATION

Aggregation Based on CDMA specific VSA Fields

The cdma_SURs.xml file manages CDMA specific VSA fields in Subscriber Usage RDRs. The aggregation period for processing the RDRs is specified in this file. Aggregation is based on the CDMA specific VSA fields (PCF ,HOME AGENT, MEID). At the end of the aggregation period, the adapter adds the aggregated Top Reports for the CDMA specific VSA fields to their corresponding database tables:

RPT_TOP_PCF

RPT_TOP_HOME_ AGENT

RPT_TOP_MEID

Aggregation Based on Package

The vlink_BW_per_pkg.xml file manages upstream and downstream VLINKs in Subscriber Usage RDRs. The aggregation period for processing the RDRs is specified in this file.

Aggregation is based on the up and down VLINK fields. At the end of the aggregation period, the adapter adds the aggregated Top Reports for the up VLINKS to the RPT_UVLINK database table. Also, the adapter adds the aggregated Top Reports for the down VLINKs to the RPT_DVLINK database table.

Managing OSFP support for Subscriber Usage RDR

OSFP (Operating System Finger Printing ) is supported in the Cisco Collection Manager software release 3.7.5 and later. New fields are added to RPT_NUR.

The ~scmscm/script/updateVSAindex.sh script supports backwards compatibilty.

The following two properties were added in the ~scmscm/cm/config/ragadpater.conf file:

attr_index - index position of attribute indicator field in NUR RDR in current SCOS version

attr_shift_pos - Num of fields to be shifted

Check the VSA Attribute Indicator field index value for the current Cisco Service Control Operating System (SCOS version). This is based on the SCOS version update attr_index , attr_shift_pos properties in ~scmscm/cm/config/ragadpater.conf file. The "RAG Adapter" section details the RAG adapter configuration file ragadapter.conf. Then execute the script ~scmscm/script/updateVSAindex.sh script. The script updates the corresponding XML file (vsa_SURs.xml/cdma_SURs.xml).

Table 2-1 shows the VSA Attribute Indicator field index values.

Table 2-1 VSA Attribute Indicator Field Index Value

SCOS Version
attr_index
attr_shift_pos

3.7.5

17

0

3.7.0

14

3

Using Databases

The Collection Manager can use either a bundled database or an external database to store RDRs supplied by the SCE platforms.

Using the Bundled Database

Using an External Database

Using the Bundled Database

In bundled mode, the Collection Manager uses the Sybase Adaptive Server Enterprise database. This database enables you to do the following:

Support transaction-intensive enterprise applications

Store and retrieve information online

Warehouse needed information

The Sybase database is located on the same server as the other Collection Manager components. It uses a simple schema that includes a group of small, simple tables.

1. The JDBC adapter sends converted RDRs to the database, where the RDRs are stored in these tables.

2. You can access records by using standard database query and reporting tools. (Cisco provides a template-based reporting tool that can generate reports on subscriber usage, network resource analysis, and traffic analysis. For information about the Service Control reporting tool, see Cisco Service Control Application Reporter User Guide.)

You maintain the database by using operating system commands and scripts. The Collection Manager supports automatic purging of old records from the bundled database. By default, the Collection Manager automatically purges the report tables of every record that is more than two weeks old. The Collection Manager polls the records once every hour. You can configure database maintenance by using the dbperiodic.sh utility script. For more information, see the "Managing the CM:RDR Periodic Deletion of Old Records" section.

Using an External Database

With the JDBC adapter, you can use any JDBC-compliant database (for example, Oracle or MySQL) with the Collection Manager. In this case, the database can be local or remote. To use an external database, perform the following tasks:

Configure the JDBC adapter to use this database

Configure a database pack to supply the Collection Manager with the parameters of the database (such as its IP address and port).

Supply a JDBC driver for the database so that the adapter can connect to the database.

For details about configuring the Collection Manager to work with an external database, see Chapter 5 "Managing Databases and the Comma Separated Value Repository".