Cisco Service Control Subscriber Manager LEGs User Guide, Release 4.0.x

About the Internet Protocol Detail Record (IPDR) Login Event Generator

Introduction

This chapter describes the Internet Protocol Detail Record (IPDR) Login Event Generator (LEG) software module.

This chapter contains these sections:

•Information About the IPDR LEG

•IPDR Messages—Example

•Learning Cable Modem and Associated Bonding Groups Through SNMP Query

Information About the IPDR LEG

The Service Control Management Suite (SCMS) Subscriber Manager (SM) IPDR LEG is a software module that is used in cable deployments in which, cable modem termination systems (CMTS) or other service elements can send the information over the IPDR streaming protocol.

The IPDR streaming protocol is used by the CMTS to send per-subscriber records to the IPDR database. These records are later used for reporting or billing purposes. The IPDR records include the information required to map the cable modems and customer premises equipment (CPE) to Virtual Links. For IPDR/SP Protocol specification, see the http://www.ipdr.org/public/DocumentMap/SP2.2.pdf.

The IPDR LEG processes the IPDR messages and translates the relevant messages into the Subscriber Manager log on events.

The IPDR LEG can replace or enhance the DHCP sniffer role in a CMTS-aware environment by adding the subscriber log on capabilities based on the IPDR records.

The CMTS generates IPDR record for each cable modem periodically (usually every 15 minutes). These records include all the required information, including the IP address of the cable modem. CMTS also generates IPDR records based on events related to the cable modem registration and the CPE type. These records contains the details of a CPE connected to a cable modem. These records are received by the IPDR Leg which are then translated into a Subscriber Logon Information record.

IPDR records are generated periodically for all Cable Modems, this helps SCE to support dynamic changes of Cable Modems between QAM channels. To support dynamic changes, IPDR LEG retrieves VLINK ID from the mapping table after receiving a record.

The SCMS Subscriber Manager IPDR LEG is an extension of the Subscriber Manager software and runs as part of the Subscriber Manager.

From Service Control Management Suite (SCMS) Subscriber Manager Release 3.7.2:

•IPDR LEG supports Adhoc-based IPDR sessions. This feature is applicable only for Cisco CMTS. For details, see the "Configuring the IPDR LEG to Use Adhoc IPDR Sessions" section.

•You can use IPDR LEG together with SNMP to learn Cable Modem and Associated Bonding Groups.

IPDR Messages—Example

The following is an example of an IPDR message:

<CmMacAddr>00-18-9b-8d-fc-cd</CmMacAddr> 

<CmIpv4Addr>10.12.150.138</CmIpv4Addr> 

<CmtsMdIfName>Cable6/0/0</CmtsMdIfName> 

<CmtsMdIfIndex>1031</CmtsMdIfIndex> 

<CmtsRcsId>53</CmtsRcsId> 

<CmtsTcsId>3</CmtsTcsId>

<CMTSupIfName>'Ca7/0/0-upstream1'</CMTSupIfName> 

<CMTSdownIfName>'Ca7/0/0-downstream'</CMTSdownIfName>

In this example, 53 is the downstream channel index and 3 is the upstream channel index. The cable modem with MAC address 00 18 9b 8d fc cd and IP address 10.12.150.138 is associated with the CMTS.

Fair Usage Policy

When a subscriber logs in through the IPDR LEG, that subscriber is mapped to an appropriate package ID based on the mapping defined in the IPDR configuration file. If Quota Manager is used to define quota for each subscriber, at some point of time, the subscriber may move to a penalty package based on the usage, as defined in the Quota Manager configuration.

IPDR LEG does not change the package ID if the subscriber is in a penalty package.

To use this feature, you need to add the list of penalty packages to the IPDR configuration file by using the attribute ignore_policy_list. For details on ignore_policy_list, see the "Information About Configuring the IPDR LEG" section.

If the penalty packages are added to the configuration file, the Subscriber Manager checks whether the subscriber is in any of the penalty package defined in the ignore policy list. If the subscriber is in any of the penalty package, the Subscriber Manager will not update the new package and continue with the existing penalty package until the penalty period is over.

If you have configured default_policy, do not use the same value for the ignore_policy_list.

Learning Cable Modem and Associated Bonding Groups Through SNMP Query

Caution Do not to enable SNMP-BG query option during the initial deployment. Enabling the SNMP query for bonding groups may increase the number of SNMP queries to the CMTS and this may impact the CMTS CPU performance. We recommend that you enable this feature after the Vlink association gets converged for most of the subscribers in the Subscriber Manager. We also recommend an additional 60 MB of memory for each CMTS in the SM memory to accommodate the SNMP queue.

IPDR LEG usually expects SAMIS message every 15 minutes for details of cable modem and channel set association. Instead of allowing the IPDR LEG to wait for 15 minutes to get the SAMIS message, you can configure the IPDR LEG to query the CMTS by using the SNMP query to get the bonding group details after receiving the cable modem registration template.

IPDR LEG receives cable modem mac address and the CMTS information from the cable modem registration template messages.

<CmtsHostName>

<CmtsMdIfIndex>

<CmtsRcsId>

<CmtsTcsId>

<CmMacAddr>

<CmIpv4Addr>

<RecType>

Note The Subscriber Manager can learn the subscribers and its associated bounding group through SNMP query only if the cable modem mac address is configured as a subscriber ID.

Based on the configured interval, IPDR LEG aggregates the MAC address of the cable modems and then sends a single bulk query to the CMTSs for the DOCSIS MIBs:

If no time interval configured, then the LEG does an immediate query to the CMTS for each cable modem registration message. IPDR LEG queries DOCSIS standard MIBs as an aggregated or immediate query based on the configuration.

After the IPDR LEG receives the cable modem MAC address, the LEG adds those MAC addresses to a first-in-first-out (FIFO) queue.

The cable modems in the FIFO queue are processed during each interval and the IPDR LEG triggers a bulk query to the CMTS. If the bonding group details are found, then the IPDR LEG checks for the mapping table for UpVlink and DownVlink IDs.

If mapping is not found, then those cable modems are moved to a separate queue. These cable modems are again queried during the next interval. If the mapping is not found in the subsequent queries, information on these cable modems are removed from the queue.

Note Although a cable modem can be associated with multiple bonding groups to facilitate different service flows, the Subscriber Manager can learn about the association of a cable modem with only one bonding group.

The IPDR LEG handles a maximum of 100,000 messages at a given time. While handling these messages the queue is synchronized between update and removing the messages to it. The synchronization uses two different FIFO queues for each device. We recommend that you test the memory and performance impact before enabling this feature.

For details on how to configure IPDR LEG to learn the cable modem and associated bonding group information through SNMP query, see the "Configuring the IPDR LEG to Learn the Cable Modem and Associated Bonding Groups Through an SNMP Query" section.

Note Enabling SAMIS session along with SNMP BG option may lead to a scenario where obsolete Vlink IDs are associated to the subscribers. This is because SAMIS message may be generated after a delay. We recommend that you remove all SAMIS sessions before enabling SNMP BG option. After the SAMIS sessions are removed SM may not detect the dynamic channel changes on a cable modem.

The following known caveats in CMTSs may cause partial or no Vlink mappings for subscriber:

•Channel Set ID may not be mapped to the upstream channels in the docsIf3UsChSetChList.

•docsIf3DsChSetChList may not populate the channel set of the bonding group.

•The Cisco CMTS router generates a CPE 'stop' IPDR messages (<RecType> 2 </RecType>) for the affected CPE, and no login messages (<RecType> 3 </RecType>) corresponding to that CPE are generated during dynamic channel changes.

Functional Flow of Cable Modem Registration for DOCSIS 2.0 Cable Modems

1. The Cable Modem Registration 2.0 template reaches IPDR LEG.

2. IPDR LEG ignores the IP mapping; but updates the SM Database with the SubID, UP Vlink, and Down Vlink details.

3. The CPE type template reaches IPDR LEG.

4. IPDR LEG updates the SM Database with the IP mapping.

Functional Flow of Cable Modem Registration for DOCSIS 3.0 Cable Modems

1. The IPDR LEG receives the Cable Modem Registration 3.0 template.

2. The IPDR LEG updates the SM database with the subscriber ID.

3. The IPDR LEG updates the primary queue process with CM Mac Address (Subscriber ID) for DOCSIS 3.0 subscribers.

4. The SNMP query is triggered for the corresponding subscriber from the primary queue.

5. On successful SNMP response, the SM receives UpVlink and DownVlink channel details from the CMTS.

6. The IPDR LEG associates the subscribers with the corresponding UpVlink ID and DownVlink ID.

7. The IPDR LEG updates the SM database with the information on subscribers with an associated Vlink ID.

8. The IPDR LEG receives the CPE template.

9. The IPDR LEG parses the CPE template and updates the SM database with the IP mappings.

Functional Flow of Cable Modem Registration When the CPE Templates Arrives SM Without the Corresponding CM Registration Template

Note This scenario is applicable to both DOCSIS 2.0 and DOCSIS 3.0 subscribers.

1. The IPDR LEG updates the Subscriber ID and IP mappings after receiving the CPE Template.

2. If there are no UpVlink or DownVlink associated with a Subscriber ID, the IPDR LEG updates the primary queue process with those CM Mac Address (Subscriber ID).

3. The SM triggers an SNMP query, from the primary queue, for the corresponding Subscriber details.

4. On successful SNMP response, the SM receives the UpVlink and DownVlink Channel details.

5. The IPDR LEG associates the subscriber with the corresponding UpVlink and DownVlink details.

6. The IPDR LEG updates the SM database with the Vlink details of the corresponding subscriber.

Understanding the Primary Queue Process

With the default configuration, the Subscriber Manager sends only a maximum of 100 SNMP queries each second to the CMTS.

1. The IPDR LEG updates the SM database with the Subscriber ID and IP mapping.

2. The IPDR LEG updates the Primary Queue Process with Subscriber ID and IPmapping to run a query for the Vlink IDs associated with the subscriber ID.

3. The Primary Queue Process run a query.

4. The Primary Queue process fails to fetch the corresponding information from the CMTS.

5. The Primary Queue Process moves the query to the Retry Queue Process.

6. The Retry Queue Process runs the query.

7. On successful SNMP response, the SM receives the UpVlink and DownVlink Channel details.

8. The Retry queue process updates the IPDR LEG with the details.

9. The IPDR LEG updates the SM Database with the Vlink IDs.