- Introduction
- Raw Data Records Overview
- Universal RDR Fields
- ADDITIONAL_INFO Field
- Transaction RDR
- Transaction Usage RDR
- HTTP Transaction Usage RDR
- Anonymized HTTP Transaction Usage RDR
- RTSP Transaction Usage RDR
- VoIP Transaction Usage RDR
- Video Transaction Usage RDR
- Generic Usage RDR
- Using the Generic Usage RDR to Report IPv6 Usage
- Subscriber Usage RDR
- Real-Time Subscriber Usage RDR
- Link Usage RDR
- Zone Usage RDR
- Package Usage RDR
- Virtual Links Usage RDR
- Blocking RDR
- Quota Breach RDR
- Quota Status RDR
- Quota Threshold Breach RDR
- Session Creation RDRs
- DHCP RDR
- RADIUS RDR
- Flow Start RDR
- Flow End RDR
- Ongoing Flow RDR
- Media Flow RDR
- Attack Start RDR
- Attack End RDR
- Malicious Traffic Periodic RDR
- Spam RDR
- Information About RDR Enumeration Fields
- RDR Tag Assignment Summary
- Periodic RDR Zero Adjustment Mechanism
Raw Data Records: Formats and Field Contents
Introduction
This chapter contains a list of the Raw Data Records (RDRs) produced by the SCE platform and a full description of the fields contained in each RDR.
The chapter also contains field-content information for those fields that are generated by Service Control components.
•
Anonymized HTTP Transaction Usage RDR
•Video Transaction Usage RDRGeneric Usage RDR
•Using the Generic Usage RDR to Report IPv6 Usage
•Real-Time Subscriber Usage RDR
•Malicious Traffic Periodic RDR
•Information About RDR Enumeration Fields
•Periodic RDR Zero Adjustment Mechanism
Raw Data Records Overview
RDRs are the collection of fields that are sent by the Service Control Engine (SCE) platforms to the Cisco Service Control Management Suite (SCMS) Collection Manager (CM).
Fields that are common to many of the RDRs are described in the next section, before the individual RDRs are described.
Universal RDR Fields
This section contains descriptions of fields that are common to many RDRs. The first two fields, SUBSCRIBER_ID and PACKAGE_ID, appear in almost all the RDRs. The other fields are listed in alphabetical order.
•SUBSCRIBER_ID—Subscriber identification string, introduced through the subscriber management interfaces. It may contain up to 64 characters. For unknown subscribers this field may contain an empty string.
•PACKAGE_ID—ID of the Package assigned to the subscriber whose traffic is being reported. An assigned Package ID is an integer value between 0 and maximum_number_of_packages. The value maximum_number_of_packages is reserved for unknown subscribers.
•ACCESS_STRING—Layer 7 property, extracted from the transaction. For possible values see String Fields.
•BREACH_STATE—Indicates whether the subscriber's quota was breached.
–0—Not breached
–1—Breached
•CLIENT_IP—IP address of the client side of the reported session. (The client side is defined as the initiator of the networking session.) The IP address is in a 32-bit binary format.
•CLIENT_PORT—Port number of the client side (initiator) of the TCP/UDP-based networking session. For non-TCP/UDP sessions, this field has the value zero.
•CONFIGURED_DURATION—Configured period, in seconds for periodic RDRs, between successive RDRs.
•END_TIME—Ending time stamp of this RDR. The field is in UNIX time_t format, which is the number of seconds since midnight of 1 January 1970.
•FLAVOR_ID—ID of the flavor associated with this session. This is for protocol signatures that have flavors.
•INFO_STRING—Layer 7 property extracted from the transaction. For possible values see String Fields.
•INITIATING_SIDE—Side of the SCE platform on which the initiator of the transaction resides.
–0—The subscriber side
–1—The network side
•PROTOCOL_ID—Unique ID of the protocol associated with the reported session.
Note The PROTOCOL_ID is the Generic IP / Generic TCP / Generic UDP protocol ID Note value, according to the specific transport protocol of the transaction, unless a more specific protocol definition (such as a signature-based protocol or a port-based protocol), which matches the reported session, is assigned to a service.
•PROTOCOL_SIGNATURE—ID of the protocol signature associated with this session.
•REPORT_TIME—Ending time stamp of this RDR. The field is in UNIX time_t format, which is the number of seconds since midnight of 1 January 1970.
•SERVER_IP—Destination IP address of the reported session. (The destination is defined as the server or the listener of the networking session.) The IP address is in a 32-bit binary format.
•SERVER_PORT—Destination port number of the TCP/UDP-based networking session. For non-TCP/UDP sessions, this field contains the IP protocol number of the session flow.
•SERVICE_ID—Service classification of the reported session. For example, in the Transaction RDR this field indicates which service was accessed, and in the Breaching RDR this field indicates which service was breached.
•TIME_FRAME—Time frame during which the RDR was generated. The field's value can be in the range 0 to 3, indicating which of the four time frames was used.The system supports time-dependent policies, by using different rules for different time frames.
•ZONE_ID—ID of the zone associated with this session.
Note All volumes in RDRs are reported in Layer 3 bytes.
Related Topics
ADDITIONAL_INFO Field
This bit map field supplies additional information regarding subscriber, event or system configuration.
Transaction RDR
This section contains descriptions of transaction RDRs
•RDR Purpose—Analyzes a sampling of network transactions in order to estimate the network's behavior based on statistics.
•RDR Default destination—Sent to the CM, inserted into the database, and used by the Reporter tool for statistical reports, such as the Traffic Discovery report.
•RDR Content—Describes a single transaction; its connection attributes, extracted L7 attributes, duration and volume.
•RDR Generation Logic—Generated at the end of a session, according to a configurable sampling mechanism, you configure the number-of-transaction-RDRs-per-second which sets the number of Transaction RDRs (TRs) generated per-second.
The Transaction RDR is not generated for sessions that were blocked by a rule.
You can disable TRs, which invalidates TR-based reports.
See the Sizing Tool for the appropriate sample rate; a sample rate which is too high may cause CM sizing problems. A sample rate which is too low reduces the accuracy of TR-based reports.
•RDR tag— 0xf0f0f010 / 4042321936
Table 2-2 lists the Transaction RDR fields and their descriptions.
Related Topics
Transaction Usage RDR
•RDR Purpose—Log network transactions for transaction-based billing or offline data mining.
•RDR Default destination—Sent to the CM, and stored in CSV files.
•RDR Content—Describes a single transaction; its connection attributes, extracted L7 attributes, duration and volume.
•RDR Generation Logic—Generated at the end of a session, for all transactions on packages and services that are configured to generate such an RDR.
This RDR is not generated for sessions that were blocked by a rule.
•RDR tag—0xf0f0f438 / 4042323000
By default, packages and services are disabled from generating this RDR. They can be enabled for specific packages and services. You can disable generating Transaction Usage RDRs (TURs) for very short flows by setting a volume threshold. You can enable generating interim TURs for very long transactions.
The Transaction Usage RDR is designed for services and packages where specific, per-transaction RDRs are required (such as, transaction level billing). It is easy to configure this RDR, in error, so that it is generated for every transaction, which may result in an excessive RDR rate. See the Sizing Tool.
Note Configure the generation scheme for this RDR with extra care.
Table 2-3 lists the Transaction Usage RDR fields and their descriptions.
Related Topics
HTTP Transaction Usage RDR
The HTTP_TRANSACTION_USAGE_RDR is a TUR specifically used for HTTP transactions.
•RDR Purpose—Log HTTP network transactions for transaction-based billing or offline data mining.
•RDR Default destination—Sent to the CM, and stored in CSV files.
•RDR Content—Describes a single HTTP transaction; its connection attributes, extracted L7 attributes, duration, and volume.
•RDR Generation Logic—Generated at the end of an HTTP session, for all transactions on packages and services that are configured to generate a Transaction Usage RDR.
This RDR is not generated for sessions that were blocked by a rule.
•RDR tag—0xf0f0f43C / 4042323004
By default, packages and services are disabled from generating this RDR. You can enable them for specific packages and services.
This RDR is designed for services and packages where specific, per-transaction RDRs are required (such as, transaction level billing). It is easy to configure this RDR, in error, so that it is generated for every transaction, which may result in an excessive RDR rate.
Note Configure the generation scheme for this RDR with extra care.
Table 2-4 lists the HTTP Transaction Usage RDR fields and their descriptions.
Related Topics
Anonymized HTTP Transaction Usage RDR
The ANONYMIZED_HTTP_TRANSACTION_USAGE_RDR is a TUR specifically used for HTTP transactions.
•RDR Purpose—Log HTTP network transactions for transaction-based billing or offline data mining without personal subscriber data.
•RDR Default destination—Sent to the CM, and stored in CSV files.
•RDR Content—Describes a single HTTP transaction; its connection attributes, extracted L7 attributes, duration, and volume.
•RDR Generation Logic—Generated at the end of an HTTP session, for all transactions on packages and services that are configured to generate a Transaction Usage RDR.
This RDR is not generated for sessions that were blocked by a rule.
•RDR tag—0xf0f0f53C / 4042323260
By default, packages and services are disabled from generating this RDR. You can enable them for specific packages and services.
This RDR is designed for services and packages where specific, per-transaction RDRs are required (such as, transaction level billing). It is easy to configure this RDR, in error, so that it is generated for every transaction, which may result in an excessive RDR rate.
Note Configure the generation scheme for this RDR with extra care.
Table 2-5 lists the RDR fields and their descriptions.
RTSP Transaction Usage RDR
The RTSP_TRANSACTION_USAGE_RDR is a TUR specifically used for RTSP Transactions.
•RDR Purpose—Log RTSP network transactions for transaction-based billing or offline data mining.
•RDR Default destination—Sent to the CM, and stored in CSV files.
•RDR Content—Describes a single RTSP transaction; its connection attributes, extracted L7 attributes, duration, and volume.
•RDR Generation Logic—Generated at the end of a session, for all RTSP transactions on packages and services that are configured to generate a Transaction Usage RDR.
This RDR is not generated for sessions that were blocked by a rule.
•RDR tag—0xf0f0f440 / 4042323008
By default, packages and services are disabled from generating this RDR.
This RDR is designed for services and packages where specific, per-transaction RDRs are required (such as, transaction level billing). It is easy to configure this RDR in error, so that it is generated for every transaction, which may result in an excessive RDR rate.
Note Configure the generation scheme for this RDR with extra care.
Table 2-6 lists the RTSP Transaction Usage RDR fields and their descriptions.
Related Topics
VoIP Transaction Usage RDR
The VOIP_TRANSACTION_USAGE_RDR is a TUR specifically used for VoIP transactions.
•RDR Purpose—Log VOIP network transactions for transaction-based billing or offline data mining.
•RDR Default destination—Sent to the CM, and stored in CSV files.
•RDR Content—Describes a single RTSP transaction; its connection attributes, extracted Layer 7 attributes, duration, and volume.
•RDR Generation Logic—Generated at the end of a session, for all transactions on packages and services that are configured to generate such an RDR.
This RDR is not generated for sessions that were blocked by a rule.
•RDR tag—0xf0f0f46a / 4042323050
By default, packages and services are disabled from generating this RDR. You can enable them for specific packages and services.
The VoIP Transaction Usage RDR is enabled automatically when the Transaction Usage RDR is enabled; both RDRs are generated when the session ends. Currently, the VoIP Transaction Usage RDR is generated for H323, Skinny, SIP, and MGCP sessions.
This RDR is designed for services and packages where specific, per-transaction RDRs are required (for example, transaction level billing). It is easy to configure this RDR, in error, so that it is generated for every transaction, which may result in an excessive RDR rate.
Note Configure the generation scheme for this RDR with extra care.
Table 2-7 lists the VoIP Transaction Usage RDR fields and their descriptions.
|
|
|
|
|---|---|---|
SUBSCRIBER_ID |
STRING |
Subscriber identification string, introduced through the subscriber management interfaces. It may contain up to 64 characters. For unknown subscribers this field may contain an empty string. |
PACKAGE_ID |
INT16 |
ID of the Package assigned to the subscriber whose traffic is being reported. An assigned Package ID is an integer value between 0 and maximum_number_of_packages. The value maximum_number_of_packages is reserved for unknown subscribers. |
SERVICE_ID |
INT32 |
Service classification of the reported session. For example, in the Transaction RDR this field indicates which service was accessed, and in the Breaching RDR this field indicates which service was breached. |
PROTOCOL_ID |
INT16 |
Unique ID of the protocol associated with the reported session. |
SKIPPED_SESSIONS |
UINT32 |
Number of unreported sessions since the previous RDR. Since a VoIP Transaction Usage RDR is generated only at the end of a flow, this field always has the value 1. |
SERVER_IP |
UINT32 |
Destination IP address of the reported session. (The destination is defined as the server or the listener of the networking session.) The IP address is in a 32-bit binary format. |
SERVER_PORT |
UINT16 |
Destination port number of the TCP/UDP-based networking session. For non-TCP/UDP sessions, this field contains the IP protocol number of the session flow. |
ACCESS_STRING |
STRING |
Layer 7 property, extracted from the transaction. |
INFO_STRING |
STRING |
Layer 7 property extracted from the transaction. |
CLIENT_IP |
UINT32 |
IP address of the client side of the reported session. (The client side is defined as the initiator of the networking session.) The IP address is in a 32-bit binary format. |
CLIENT_PORT |
UINT16 |
Port number of the client side (initiator) of the TCP/UDP-based networking session. For non-TCP/UDP sessions, this field has the value zero. |
INITIATING_SIDE |
INT8 |
Side of the SCE platform on which the initiator of the transaction resides. • • |
REPORT_TIME |
UINT32 |
Ending time stamp of this RDR. The field is in UNIX time_t format, which is the number of seconds since midnight of 1 January 1970. |
MILLISEC_DURATION |
UINT32 |
Duration, in milliseconds, of the transaction reported in this RDR. |
TIME_FRAME |
INT8 |
Time frame during which the RDR was generated. The field's value can be in the range 0 to 3, indicating which of the four time frames was used. The system supports time-dependent policies, by using different rules for different time frames. |
SESSION_UPSTREAM_ |
UINT32 |
Upstream volume of the transaction, in bytes. The volume refers to the aggregated upstream volume on both links of all the flows bundled in the transaction. |
SESSION_DOWNSTREAM_ |
UINT32 |
Downstream volume of the transaction, in bytes. The volume refers to the aggregated downstream volume on both links of all the flows bundled in the transaction. |
SUBSCRIBER_COUNTER_ID |
UINT16 |
Counter to which each service is mapped. There are 32 subscriber usage counters. |
GLOBAL_COUNTER_ID |
UINT16 |
Counter to which each service is mapped. There are 64 global usage counters. |
PACKAGE_COUNTER_ID |
UINT16 |
Counter to which each package is mapped. There are 1024 package usage counters. |
IP_PROTOCOL |
UINT8 |
IP protocol type. |
PROTOCOL_SIGNATURE |
INT32 |
ID of the protocol signature associated with this session. |
ZONE_ID |
INT32 |
ID of the zone associated with this session. |
FLAVOR_ID |
INT32 |
ID of the protocol signatures with flavor associated with this session. |
FLOW_CLOSE_MODE |
UINT8 |
The ITU-U vendor ID of the application. A value of 0xFFFFFFFF indicates that this field was not found in the traffic. |
APPLICATION_ID |
UINT32 |
ITU-U vendor ID of the application. A value of 0xFFFFFFFF indicates that this field was not found in the traffic. |
UPSTREAM_PACKET_LOSS (see Note, page 22) |
UINT16 |
Average fractional upstream packet loss for the session, taken from the RTCP flow. (See the note following this table for an explanation of this value.) A value of 0xFFFF indicates that this field is undefined (no RTCP flows were opened). |
DOWNSTREAM_PACKET_ |
UINT16 |
Average fractional downstream packet loss for the session, taken from the RTCP flow. (See the note following this table for an explanation of this value.) A value of 0xFFFF indicates that this field is undefined (no RTCP flows were opened). |
UPSTREAM_AVERAGE_ |
UINT32 |
Average upstream jitter for the session in units of 1/65 millisecond, taken from the RTCP flow. (See the note following this table for an explanation of this value.) A value of 0xFFFFFFFF indicates that this field is undefined (no RTCP flows were opened). |
DOWNSTREAM_AVERAGE_ |
UINT32 |
Average downstream jitter for the session in units of 1/65 millisecond, taken from the RTCP flow. (See the note following this table for an explanation of this value.) A value of 0xFFFFFFFF indicates that this field is undefined (no RTCP flows were opened). |
CALL_DESTINATION |
STRING |
Q931 Alias address of the session destination. A value of N/A indicates that this field was not found in the traffic. |
CALL_SOURCE |
STRING |
Q931 Alias address of the session source. A value of N/A indicates that this field was not found in the traffic. |
UPSTREAM_PAYLOAD_ |
UINT8 |
Upstream RTP payload type for the session. A value of 0xFF indicates that this field was not available (no RTP flows were opened). |
DOWNSTREAM_PAYLOAD_ |
UINT8 |
Downstream RTP payload type for the session. A value of 0xFF indicates that this field is undefined (no RTP flows were opened). |
CALL_TYPE |
UINT8 |
Call type (taken from H225 packet). A value of 0xFF indicates that this field is undefined (no RTP flows were opened). |
MEDIA_CHANNELS |
UINT8 |
Number of data flows that were opened during the session. |
Note Packet Loss
This field is taken from the RTCP field "fraction lost". It is the average value of all RTCP packets seen during the flow life for the specified direction. The value is the numerator of a fraction whose denominator is 256. To get the packet loss value as percentage, divide this value by 2.56.
Note Average Jitter
This field is taken from the RTCP field "interval jitter". The reported value is the average value of all RTCP packets seen during the flow life for the specified direction. This value is multiplied by the NTP time-stamp delta (middle 32 bits) and divided by the RTCP time-stamp delta to convert it to normal time units. These two time stamps are also taken from the RTCP packet. The reported value is the average jitter in units of 1/65536 second. To convert to milliseconds, divide by 65.536.
For more information about the RCP/RTCP standard, see RFC 1889.
Related Topics
Video Transaction Usage RDR
The VIDEO_TRANSACTION_USAGE_RDR is a TUR used specifically for video transactions.
•RDR Default destination—Sent to the CM and stored in CSV format
•RDR Content—Describes a single video transaction
•RDR Generation Logic—Generated at the end of a session, for all transactions on all packages and all services if:
–The packages and services are configured to generate the VIDEO_TRANSACTION_USAGE_RDR.
–VIDEO_TRANSACTION_USAGE_RDRs are enabled.
This RDR is not generated for sessions that were blocked by a rule.
•RDR tag-0xf0f0f480 / 4042323072
By default, packages and services are disabled from generating this RDR. You can enable them for specific packages and services.
This RDR is designed for services and packages where specific, per-transaction RDRs are required (for example, transaction level billing). It is easy to configure this RDR in error, so that it is generated for every transaction, which may result in an excessive RDR rate.
Note Configure the generation scheme for this RDR with extra care.
Table 2-8 lists the VIDEO_TRANSACTION_USAGE_RDR fields and their descriptions.
Generic Usage RDR
GENERIC_USAGE_RDR has a fixed structure with a unique tag, which allows the one-time creation of a database table to be used for various future RDRs.
The Generic Usage RDR is composed of universal fields like any other RDR, generic fields for all GUR RDRs, and fields for future use.
•RDR Purpose—Provides a generic template from which other Usage RDRs can be created.
•RDR Default destination—Varies depending on the specific Usage RDR created from this template
•RDR Content—Varies depending on the specific Usage RDR created from this template.
•RDR Generation Logic—Not generated, is provided as a template for creating other RDRs.
•RDR tag—0xf0f0f090 / 4042322064
Table 2-9 lists the Generic Usage RDR fields and their descriptions.
Using the Generic Usage RDR to Report IPv6 Usage
The GUR is used to report both pure-IPv6, and tunneled IPv6. The former is reported per device, and the latter per RUC.
Both reports use the GUR type '1'.
•RDR Generation Logic— based on the user defined configuration of the Link Usage Report.
Table 2-10 describes the specific fields of the pure-IPv6 and tunneled-IPv6 reports. (Any GUR fields not listed in the table are not used.)
Subscriber Usage RDR
The SUBSCRIBER_USAGE_RDR summarizes the activity of a single subscriber on a specific service for the last user-configured number of minutes.
•RDR Purpose—Compare subscribers for the Top Subscribers report, and create daily subscriber usage summary records.
•RDR Default destination—Sent to the CM, and processed by the Topper Adapter, which stores the processing results in the database and in CSV files. The Reporter tool uses the database records for creating the Top Subscribers reports.
•RDR Content—Summary of the activity of a single subscriber on a defined service for the last user-configured number of minutes, including aggregated number of flows, total volume, and duration.
•RDR Generation Logic—Generated periodically, at user-configured intervals, for each subscriber. A separate RDR is generated for each service usage counter. The RDR is generated only if the subscriber consumed resources associated with the service usage counter during the current reporting period.
At fixed, user-configurable intervals (for example, every 30 minutes), there is a periodic SUBSCRIBER_USAGE_RDR generation point. Whether or not a Subscriber Usage RDR for a particular subscriber is actually generated depends on the following:
–If the subscriber consumed resources associated with a service usage counter since the previous RDR generation point, a Subscriber Usage RDR is generated.
–If the subscriber did not consume resources associated with a service usage counter since the previous RDR generation point, no Subscriber Usage RDR is generated.
Note Unlike other Usage RDRs, the generation logic for Subscriber Usage RDRs does NOT use the zeroing methodology.
Subscriber Usage RDRs may also be generated in the following situation:
•The subscriber performed a logout in a subscriber-integrated installation or was un-introduced from the SCE platform:
–If the subscriber consumed resources associated with a service usage counter since the previous Subscriber Usage RDR, a Subscriber Usage RDR is generated.
–If the subscriber did not consume resources since the previous RDR, no RDR is generated for that service usage counter.
•RDR tag—0xf0f0f000 / 4042321920
The Subscriber Usage RDRs are enabled by default. Disabling the RDRs disables Top Subscriber reports. The default interval for SUR is every 10 minutes.
The default total rate is 200 SURs per second. Consult the sizing tool for the appropriate interval and rate.
Table 2-11 lists the Subscriber Usage RDR fields and their descriptions.
Related Topics
•Periodic RDR Zero Adjustment Mechanism
Real-Time Subscriber Usage RDR
The REALTIME_SUBSCRIBER_USAGE_RDR summarizes the activity of a single subscriber on a specific service for the last user-configured number of minutes.
•RDR Purpose—Create detailed subscriber-level reports of network usage per service.
•RDR Default destination—Sent to the CM, stored in the database, and used by the Reporter tool for subscriber usage reports such as the Subscriber Bandwidth per Service report.
•RDR Content—Summary of the activity of a single subscriber on a specific service for the last user-configured number of minutes, including aggregated number of flows, total volume, and duration.
•RDR Generation Logic—Generated periodically, at user-configured intervals, for each subscriber that has real-time monitoring enabled. A separate RDR is generated for each service usage counter. The RDR is generated only if the subscriber consumed resources associated with the service usage counter during the current reporting period.
Note A Real-Time Subscriber Usage RDR is generated only for those subscribers with real-time monitoring enabled. For information about enabling real-time monitoring, see the "Additional Management Tools and Interfaces" chapter of Cisco Service Control Application for Broadband User Guide.
At fixed, user-configurable intervals (for example, every 5 minutes), there is a periodic REALTIME_SUBSCRIBER_USAGE_RDR generation point. The REALTIME_SUBSCRIBER_USAGE_RDR reports the same usage information as the SUBSCRIBER_USAGE_RDR, but is generated more frequently to provide a more detailed picture of subscriber activity. It is used by the Cisco Service Control Application Reporter to generate reports on the activities of single subscribers over time.
Whether or not a Real-Time Subscriber Usage RDR for a particular subscriber is actually generated depends on the following:
•If the subscriber consumed resources associated with a service usage counter since the previous RDR generation point, a Real-Time Subscriber Usage RDR is generated.
•If the subscriber did not consume resources associated with a service usage counter since the previous RDR generation point, no Real-Time Subscriber Usage RDR is generated now.
However, the generation logic for Subscriber Usage RDRs uses the zeroing methodology (as described in Periodic RDR Zero Adjustment Mechanism). If the subscriber consumes resources associated with the service usage counter at some later time, this causes the immediate generation of either one or two zero-consumption Real-Time Subscriber Usage RDRs. (In addition to the eventual generation of the Real-Time Subscriber Usage RDR associated with this latest consumption of resources).
–If there was only one interval (for example, 0805-0810) for which there was no subscriber consumption of resources, only one zero-consumption Real-Time Subscriber Usage RDR is generated.
–If there were multiple consecutive intervals (for example, 0805-0810, 0810-0815, 0815-0820, 0820-0825) for which there was no subscriber consumption of resources, two zero-consumption Real-Time Subscriber Usage RDRs are generated: one for the first such time interval (0805-0810) and one for the last (0820-0825).
Real-Time Subscriber Usage RDRs may also be generated in the following situation:
•The subscriber performed a logout in a subscriber-integrated installation or was un-introduced from the SCE platform:
–If the subscriber consumed resources associated with a service usage counter since the previous Real-Time Subscriber Usage RDR, a Real-Time Subscriber Usage RDR is generated and then a zero-consumption Real-Time Subscriber Usage RDR is generated.
–If the subscriber consumed resources associated with a service usage counter since the previous Real-Time Subscriber Usage RDR, a Real-Time Subscriber Usage RDR is generated and then a zero-consumption Real-Time Subscriber Usage RDR is generated.
A zero-consumption Real-Time Subscriber Usage RDR is also be generated for a subscriber in the following situation:
•The subscriber performed a login in a subscriber-integrated installation or was introduced from the SCE platform:
–Before the first Real-Time Subscriber Usage RDRs reporting actual consumption are generated, a zero-consumption Real-Time Subscriber Usage RDR is generated.
•RDR tag—0xf0f0f002 / 4042321922
Real-Time Subscriber Usage RDRs (RTSUR) are generated only for those subscribers with real-time monitoring enabled. By default, it is disabled for all subscribers. The default interval is RTSUR every 1 minute. The default total rate is 100 RTSURs per second. See the Sizing Tool for the appropriate interval, rate, and the number of subscribers for which you should enable it.
Table 2-12 lists the Real-Time Subscriber Usage RDR fields and their descriptions.
Related Topics
•Periodic RDR Zero Adjustment Mechanism
Link Usage RDR
The LINK_USAGE_RDR summarizes the activity on one of the SCE links for a specific service for the last user-configured number of minutes.
•RDR Purpose—Create link-level reports of network usage per service.
•RDR Default destination—Sent to the CM, stored in the database, and used by the reporter for global usage reports such as the Global Bandwidth per Service report, and subscriber demographics reports, such as the Active Subscribers per Service report.
•RDR Content—Summary of the activity on one of the SCE links for a specific service for the last user-configured minutes, including aggregated number of flows, total volume, duration, and active subscribers.
•RDR Generation Logic—Generated periodically, at user-configured intervals, for each link. A separate RDR is generated for each service usage counter. The RDR is generated only if resources associated with the service usage counter were consumed during the current reporting period.
At fixed, user-configurable intervals (for example, every 30 minutes), there is a periodic LINK_USAGE_RDR generation point. Whether or not a Link Usage RDR is actually generated depends on the following:
–If network resources associated with a service usage counter were consumed since the previous RDR generation point, a Link Usage RDR is generated.
–If network resources associated with a service usage counter were not consumed since the previous RDR generation point, no Link Usage RDR is generated.
However, the generation logic for Link Usage RDRs uses the zeroing methodology (as described in Periodic RDR Zero Adjustment Mechanism). If network resources associated with the service are again consumed at some later time, this causes the immediate generation of either one or two zero-consumption Link Usage RDRs. (In addition to the eventual generation of the Link Usage RDR associated with this latest consumption of network resources).
–If there was only one interval (for example, 0830-0900) for which there was no consumption of network resources, only one zero-consumption Link Usage RDR is generated.
–If there were multiple consecutive intervals (for example, 0830-0900, 0900-0930, 0930-1000, 1000-1030) for which there was no consumption of network resources, two zero-consumption Link Usage RDR are generated: one for the first such time interval (0830-0900) and one for the last (1000-1030).
Note A separate RDR is generated for each link (on a single traffic processor) in the SCE platform, where each RDR represents the total traffic processed and analyzed by that processor (for the specified service usage counter). To compute the total traffic in any given time frame, take the sum of traffic of the RDRs of all the processors.
•RDR tag—0xf0f0f005 / 4042321925
Link Usage RDRs (LUR) are enabled by default. Disabling LURs eliminates global usage reports as well as subscriber demographics reports. LURs default interval is every 5 minutes. Increasing this interval can enhance the time granularity of LUR-based reports.
Table 2-13 lists the Link Usage RDR fields and their descriptions.
Related Topics
•Periodic RDR Zero Adjustment Mechanism
Zone Usage RDR
The ZONE_USAGE_RDR summarizes the activity on one of the SCE zones for a specific service for the last user-configured number of minutes.
•RDR Purpose—Create zone-level reports of network usage per service.
•RDR Default destination—Sent to the CM, stored in the database, and used by the reporter for global usage reports such as the Global Bandwidth per Service report, and subscriber demographics reports such as the Active Subscribers per Service report.
•RDR Content—Summary of the activity on one of the SCE zones for a specific service for the last user-configured minutes, including aggregated number of flows, total volume, duration, and active subscribers.
•RDR Generation Logic—Generated periodically, at user-configured intervals, for each zone. A separate RDR is generated for each service usage counter. The RDR is generated only if resources associated with the service usage counter were consumed during the current reporting period.
At fixed, user-configurable intervals (for example, every 30 minutes), there is a periodic ZONE_USAGE_RDR generation point. Whether or not a Zone Usage RDR is actually generated depends on the following:
–If network resources associated with a service usage counter were consumed since the previous RDR generation point, a Zone Usage RDR is generated.
–If network resources associated with a service usage counter were not consumed since the previous RDR generation point, no Zone Usage RDR is generated.
However, the generation logic for Zone Usage RDRs uses the zeroing methodology (as described in Periodic RDR Zero Adjustment Mechanism). If network resources associated with the service are again consumed at some later time, this causes the immediate generation of either one or two zero-consumption Zone Usage RDRs in addition to the eventual generation of the Zone Usage RDR associated with this latest consumption of network resources.
–If there was only one interval (for example, 0830-0900) for which there was no consumption of network resources, only one zero-consumption Zone Usage RDR is generated.
–If there were multiple consecutive intervals (for example, 0830-0900, 0900-0930, 0930-1000, 1000-1030) for which there was no consumption of network resources, two zero-consumption Zone Usage RDRs are generated—One for the first such time interval (0830-0900) and one for the last (1000-1030).
Note A separate RDR is generated for each Zone (on a single traffic processor) in the SCE platform, where each RDR represents the total traffic processed and analyzed by that processor (for the specified service usage counter). To compute the total traffic in any given time frame, take the sum of traffic of the RDRs of all the processors.
•RDR tag—4042321928
Zone Usage RDRs (ZUR) are enabled by default. Disabling ZURs eliminates global usage reports as well as subscriber demographics reports. The default interval for ZURs is every 5 minutes. Increasing this interval can enhance the time granularity of ZUR-based reports.
Table 2-14 lists the Zone Usage RDR fields and their descriptions.
Related Topics
•Periodic RDR Zero Adjustment Mechanism
Package Usage RDR
The PACKAGE_USAGE_RDR summarizes the activity of a specific group of subscribers (belonging to the same package) for a specific service in the last user-configured number of minutes.
•RDR Purpose—Create reports about network usage per service for a group of subscribers.
•RDR Default destination—Sent to the CM, stored in the database, and used by the Reporter tool for package usage reports such as the Package Bandwidth per Service report.
•RDR Content—Summary of the activity of a specific group of subscribers (belonging to the same package) for a specific service for the last user-configured number of minutes, including aggregated number of flows, total volume, and duration.
•RDR Generation Logic—Generated periodically, at user-configured intervals, for each package usage counter. A separate RDR is generated for each service usage counter. The RDR is generated only if resources associated with the service usage counter were consumed during the current reporting period. The RDR contains aggregated network usage information for all subscribers to the package or group of packages represented by the package usage counter.
At fixed, user-configurable intervals (for example, every 5 minutes), there is a periodic PACKAGE_USAGE_RDR generation point. Whether or not a Package Usage RDR is actually generated depends on the following:
–If network resources associated with a service usage counter were consumed by a subscriber of the Package since the previous RDR generation point, a Package Usage RDR is generated.
–If a subscriber of the Package has not consumed network resources associated with a service usage counter since the previous RDR generation point, no Package Usage RDR is generated.
However, the generation logic for Package Usage RDRs uses the zeroing methodology (as described in Periodic RDR Zero Adjustment Mechanism). If network resources associated with the service usage counter are again consumed by any subscriber of the package at some later time, this causes the immediate generation of either one or two zero-consumption Package Usage RDRs. (In addition to the eventual generation of the Package Usage RDR associated with this latest consumption of network resources).
–If there was only one interval (for example, 0805-0810) for which there was no consumption of network resources by any subscriber of the package, only one zero-consumption Package Usage RDR is generated.
–If there were multiple consecutive intervals (for example, 0805-0810, 0810-0815, 0815-0820, 0820-0825) for which there was no consumption of network resources by any subscriber of the package, two zero-consumption Package Usage RDR are generated: one for the first such time interval (0805-0810) and one for the last (0820-0825).
Note Each traffic processor in the SCE platform generates a separate RDR, where each RDR represents the total traffic processed and analyzed by that processor (for the specified service usage counter). To compute the total traffic (for a package) in any given time frame, take the sum of the traffic of the RDRs of all the processors.
•RDR tag—0xf0f0f004 / 4042321924
Package Usage RDRs (PURs) are enabled by default. Disabling LURs eliminates package usage reports. The default interval for PURs is every 5 minutes. Increasing this interval can enhance the time granularity of PUR-based reports.
Table 2-15 lists the Package Usage RDR fields and their descriptions.
Related Topics
•Periodic RDR Zero Adjustment Mechanism
Virtual Links Usage RDR
The VIRTUAL_LINKS_USAGE_RDR summarizes the activity on one of the virtual links for a specific service for the last user-configured number of minutes. For information on virtual links, see Cisco Service Control Application for Broadband User Guide.
•RDR Purpose—Create reports relating to network usage per service for a specific virtual link.
•RDR Default destination—Sent to the CM, stored in the database, and used by the reporter for virtual link reports such as the Virtual Link Bandwidth per Service report.
•RDR Content—Summary of the activity on one of the virtual links for a specific service for the last user-configured number of minutes, including aggregated number of flows, total volume, and duration.
•RDR Generation Logic—Generated periodically, at user-configured intervals, for each service usage counter. A separate RDR is generated for each virtual link. The RDR is generated only if resources associated with the virtual link were consumed during the current reporting period. The RDR contains aggregated network usage information for all subscribers to the same virtual link.
At fixed, user-configurable intervals (for example, every 5 minutes), there is a periodic VIRTUAL_LINKS_USAGE_RDR generation point. Whether or not a Virtual Links Usage RDR is actually generated depends on the following:
–If network resources associated with the service usage counter were consumed by any subscriber of the virtual link since the previous RDR generation point, a Virtual Links Usage RDR is generated.
–If no subscriber of the virtual link has consumed network resources associated with the service usage counter since the previous RDR generation point, no Virtual Links Usage RDR is generated.
However, the generation logic for Virtual Links Usage RDRs uses the zeroing methodology (as described in Periodic RDR Zero Adjustment Mechanism). If network resources associated with the service usage counter are again consumed by subscribers of the virtual link at some later time, this causes the immediate generation of either one or two zero-consumption Virtual Links Usage RDRs. (In addition to the eventual generation of the Virtual Links Usage RDR associated with this latest consumption of network resources by subscribers of the virtual link.)
–If there was only one interval (for example, 0805-0810) for which there was no consumption of network resources by any subscriber of the virtual link, only one zero-consumption Virtual Links Usage RDR is generated.
–If there were multiple consecutive intervals (for example, 0805-0810, 0810-0815, 0815-0820, 0820-0825) for which there was no consumption of network resources by any subscriber of the virtual link, two zero-consumption Virtual Links Usage RDR are generated: one for the first such time interval (0805-0810) and one for the last (0820-0825).
Note Each traffic processor in the SCE platform generates a separate RDR, where each RDR represents the total traffic processed and analyzed by that processor (for the specified service usage counter and the specified virtual link). To compute the total traffic (for a virtual link) in any given time frame, take the sum of the traffic of the RDRs of all the processors.
•RDR tag—0xf0f0f006 / 4042321926
Virtual Link Usage RDRs (VLURs) are disabled by default. You can enable VLURs when working with virtual links to facilitate virtual link usage reports. The recommended value for intervals between VLURs is 5 minutes.
Table 2-16 lists the Virtual Links Usage RDR fields and their descriptions.
Related Topics
•Periodic RDR Zero Adjustment Mechanism
Blocking RDR
The SERVICE_BLOCK_RDR is generated each time a transaction is blocked, and the profile and the rate/quota limitations indicate that this RDR should be generated.
•A Blocking RDR is generated when a session is blocked. A session may be blocked for various reasons; for example, access is blocked or concurrent session limit is reached.
•Generation of Blocking RDRs is subject to two limitations:
–Quota—Maximum number of Blocking RDRs that SCA BB can generate for a subscriber in a specific aggregation period (day, week, month, and so forth). The quota is package-dependent; its value is set according to the package assigned to the subscriber.
–Rate—Global, maximum number of Blocking RDRs that an SCE platform can generate per second. The rate is a global value that sets an upper limit for the total number of RDRs that are generated for all subscribers.
The RDR tag of the SERVICE_BLOCK_RDR is 0xf0f0f040 / 4042321984.
Table 2-17 lists the Blocking RDR fields and their descriptions.
Related Topics
Quota Breach RDR
The QUOTA_BREACH_RDR is generated each time a bucket is breached.
This RDR does not have a rate limit; it is generated whenever a quota breach occurs, provided that the RDR is enabled.
The RDR tag of the QUOTA_BREACH_RDR is 0xf0f0f072 / 4,042,322,034.
Table 2-18 lists the Quota Breach RDR fields and their descriptions.
|
|
|
|
|---|---|---|
QUOTA_MODEL_TYPE |
UINT8 |
Quota model type: • • • |
RDR_REASON |
UINT8 |
Reason the RDR was sent. Not in use, RESERVED - 0xfe |
SUBSCRIBER_ID |
STRING |
Subscriber identification string, introduced through the subscriber management interfaces. It may contain up to 40 characters. For unknown subscribers this field may contain an empty string. |
PACKAGE_ID |
INT16 |
ID of the Package assigned to the subscriber whose traffic is being reported. An assigned Package ID is an integer value between 0 and maximum_number_of_packages. The value maximum_number_of_packages is reserved for unknown subscribers. |
ADDITIONAL_INFO |
UINT32 |
See ADDITIONAL_INFO Field for details. |
END_TIME |
UINT32 |
Ending time stamp of this RDR. The field is in UNIX time_t format, which is the number of seconds since midnight of 1 January 1970. |
BUCKET_ID |
UINT16 |
Bucket ID to report. |
BUCKET_TYPE |
UINT16 |
Bucket type: • Only the upstream volume is reported in the RDR. UNIT_AMOUNT_IN is 0 and UNIT_AMOUNT_OUT indicates the upstream volume. • Only the downstream volume is reported in the RDR. UNIT_AMOUNT_IN indicates the downstream volume and UNIT_AMOUNT_OUT is 0. • The sum of downstream and upstream volumes, that is, the total volume consumed, and the remaining volume, that is, bucket size - total volume is reported in the RDR. UNIT_AMOUNT_IN indicates the total volume consumed and UNIT_AMOUNT_OUT indicates the remaining volume. • Both upstream and downstream volumes are reported in the RDR. UNIT_AMOUNT_IN indicates the downstream volume and UNIT_AMOUNT_OUT indicates the upstream volume. • UNIT_AMOUNT_IN indicates the number of sessions that has used the bucket. UNIT_AMOUNT_OUT indicates the remaining number of sessions for the bucket. • UNIT_AMOUNT_IN indicates how long a bucket has been used. This unit is represented in seconds. The UNIT_AMOUNT_OUT field is 0. Note – – – |
UNIT_AMOUNT_IN |
UINT32 |
Consumed downstream volume in volume units/ Seconds/ Sessions. |
UNIT_AMOUNT_OUT |
UINT32 |
Consumed upstream volume in volume units. For Internal/QM quota models - remaining quota as 32-bit integer value (may be negative). |
BUCKET_SIZE_IN |
UINT32 |
Original bucket size in volume units/ Seconds/ Sessions. For GY quota model - downstream bucket size in volume units. |
BUCKET_SIZE_OUT |
UINT32 |
Valid for Gy quota model only - upstream bucket size in volume units. |
Quota Status RDR
The QUOTA_STAUS_RD reports consumed quota of subscriber for all associated buckets. If one RDR cannot contain all associated buckets, then two or more consecutive RDRs are sent.
The user can set a limit on the total number of these RDRs that are generated per second.
If a bucket is not in use, 0xFFFF appears in BUCKET_ID, BUCKET_TYPE, UNIT_AMOUNT_IN, and UNIT_AMOUNT_OUT fields.
Note The QUOTA_STAUS_RDR is generated only for those subscribers whose policy requires the generation of such RDRs.
The following events trigger the sending of this RDR:
•Periodically, at user-configured intervals. The intervals are defined globally.
Applies to all quota models, including internal and QM external quota models.
•Package switch event: Indicates consumed quota before the package switch.
Applies to all quota models.
•Subscriber logout event.
Applies to all quota models.
•Quota Validity Time/Quota Holding Time expiration.
Applies to Gy quota model only.
The RDR tag of the QUOTA_STAUS_RDR is 0xf0f0f071 / 4,042,322,033.
Table 2-19 lists the Quota Status RDR fields and descriptions.
|
|
|
|
|---|---|---|
QUOTA_MODEL_TYPE |
UINT8 |
Quota model type: • • • |
RDR_REASON |
UINT8 |
Reason the RDR was sent: • • • • |
SUBSCRIBER_ID |
STRING |
Subscriber identification string, introduced through the subscriber management interfaces. It may contain up to 40 characters. For unknown subscribers this field may contain an empty string. |
PACKAGE_ID |
INT16 |
ID of the Package assigned to the subscriber whose traffic is being reported. An assigned Package ID is an integer value between 0 and maximum_number_of_packages. The value maximum_number_of_packages is reserved for unknown subscribers. |
ADDITIONAL_INFO |
UINT32 |
See ADDITIONAL_INFO Field for details. |
END_TIME |
UINT32 |
Ending time stamp of this RDR. The field is in UNIX time_t format, which is the number of seconds since midnight of 1 January 1970. |
BUCKET_ID |
UINT16 |
Bucket ID to report. |
BUCKET_TYPE |
UINT16 |
Bucket type: • Only the upstream volume is reported in the RDR. UNIT_AMOUNT_IN is 0 and UNIT_AMOUNT_OUT indicates the upstream volume. • Only the downstream volume is reported in the RDR. UNIT_AMOUNT_IN indicates the downstream volume and UNIT_AMOUNT_OUT is 0. • The sum of downstream and upstream volumes, that is, the total volume consumed, and the remaining volume, that is, bucket size - total volume is reported in the RDR. UNIT_AMOUNT_IN indicates the total volume consumed and UNIT_AMOUNT_OUT indicates the remaining volume. • Both upstream and downstream volumes are reported in the RDR. UNIT_AMOUNT_IN indicates the downstream volume and UNIT_AMOUNT_OUT indicates the upstream volume. • UNIT_AMOUNT_IN indicates the number of sessions that has used the bucket. UNIT_AMOUNT_OUT indicates the remaining number of sessions for the bucket. • UNIT_AMOUNT_IN indicates how long a bucket has been used. This unit is represented in seconds. The UNIT_AMOUNT_OUT field is 0. Note – – – |
UNIT_AMOUNT_IN |
UINT32 |
Consumed volume in volume units/ Seconds/ Sessions. For Gy quota model - downstream volume. |
UNIT_AMOUNT_OUT |
UINT32 |
For Gy quota model - consumed upstream volume in volume units. For QM/Internal quota models - remaining quota in 32-bit integer format (may be negative). |
Note The following fields report information per bucket:
•BUCKET_ID
•BUCKET_TYPE
•UNIT_AMOUNT_IN
•UNIT_AMOUNT_OUT
This section of four fields is repeated 16 times, one time for each of the 16 buckets, for a total of 64 fields. (Added to the 6 header fields results in a total of 70 fields in the RDR.)
Quota Threshold Breach RDR
The QUOTA_THRESHOLD_BREACH_RDR is generated each time a bucket exceeds the bucket threshold is defined per package.
This RDR does not have a rate limit; it is generated whenever a threshold is exceeded, provided that the RDR is enabled.
The RDR tag of the QUOTA_THRESHOLD_BREACH_RDR is 0xf0f0f073 / 4,042,322,035.
Table 2-20 lists the Quota Threshold Breach RDR fields and their descriptions.
|
|
|
|
|---|---|---|
QUOTA_MODEL_TYPE |
UINT8 |
Quota model type: • • • |
RDR_REASON |
UINT8 |
Reason the RDR was sent. Not in use, RESERVED - 0xfe |
SUBSCRIBER_ID |
STRING |
Subscriber identification string, introduced through the subscriber management interfaces. It may contain up to 40 characters. For unknown subscribers this field may contain an empty string. |
PACKAGE_ID |
INT16 |
ID of the Package assigned to the subscriber whose traffic is being reported. An assigned Package ID is an integer value between 0 and maximum_number_of_package. The value maximum_number_of_packages is reserved for unknown subscribers. |
ADDITIONAL_INFO |
UINT32 |
See ADDITIONAL_INFO Field for details. |
END_TIME |
UINT32 |
Ending time stamp of this RDR. The field is in UNIX time_t format, which is the number of seconds since midnight of 1 January 1970. |
BUCKET_ID |
UINT16 |
Bucket ID to report. |
BUCKET_TYPE |
UINT16 |
Bucket type: • Only the upstream volume is reported in the RDR. UNIT_AMOUNT_IN is 0 and UNIT_AMOUNT_OUT indicates the upstream volume. • Only the downstream volume is reported in the RDR. UNIT_AMOUNT_IN indicates the downstream volume and UNIT_AMOUNT_OUT is 0. • The sum of downstream and upstream volumes, that is, the total volume consumed, and the remaining volume, that is, bucket size - total volume is reported in the RDR. UNIT_AMOUNT_IN indicates the total volume consumed and UNIT_AMOUNT_OUT indicates the remaining volume. • Both upstream and downstream volumes are reported in the RDR. UNIT_AMOUNT_IN indicates the downstream volume and UNIT_AMOUNT_OUT indicates the upstream volume. • UNIT_AMOUNT_IN indicates the number of sessions that has used the bucket. UNIT_AMOUNT_OUT indicates the remaining number of sessions for the bucket. • UNIT_AMOUNT_IN indicates how long a bucket has been used. This unit is represented in seconds. The UNIT_AMOUNT_OUT field is 0. Note – – – |
UNIT_AMOUNT_IN |
UINT32 |
Consumed downstream volume in volume units/ Seconds/ Sessions. |
UNIT_AMOUNT_OUT |
UINT32 |
Consumed upstream volume in volume units. For QM/Internal quota models - remaining quota in 32-bit integer format (may be negative). |
BUCKET_SIZE_IN |
UINT32 |
Original bucket size in volume units/ Seconds/ Sessions. For GY quota model - downstream volume/total volume/sessions/seconds. |
BUCKET_SIZE_OUT |
UINT32 |
For GY quota model - original upstream volume. |
THRESHOLD_SIZE_IN |
UINT32 |
Threshold of the bucket in volume units/ Seconds/ Sessions. |
THRESHOLD_SIZE_OUT |
UINT32 |
Threshold of the bucket in volume units/ Seconds/ Sessions. Valid for Gy quota models only - upstream bucket threshold. |
Session Creation RDRs
Typically the SESSION_CREATION_RDR is sent on subscriber login event. This RDR replaces the legacy QUOTA_STATE_RESTORE_RDR.
If a bucket is not in use, 0xFFFF appears in BUCKET_ID, and '0' appears in BUCKET_TYPE, UNIT_AMOUNT_IN, and UNIT_AMOUNT_OUT fields.
The following events trigger the sending of this RDR:
•Subscriber that associates with package with external quota management (Gy or Qm)
•Package switch event - transition from internal package to external one or in Gy.
The RDR tag of the SESSION_CREATION_RDR is 0xf0f0f070 / 4,042,322,032.
Table 2-21 lists the Session Creation RDR fields and their descriptions.
|
|
|
|
|---|---|---|
QUOTA_MODEL_TYPE |
UINT8 |
Quota model type: • • • |
RDR_REASON |
UINT8 |
Reason the RDR was sent: • • |
SUBSCRIBER_ID |
STRING |
Subscriber identification string, introduced through the subscriber management interfaces. It may contain up to 40 characters. For unknown subscribers this field may contain an empty string. |
PACKAGE_ID |
INT16 |
ID of the Package assigned to the subscriber whose traffic is being reported. An assigned Package ID is an integer value between 0 and maximum_number_of_packages. The value maximum_number_of_packages is reserved for unknown subscribers. |
ADDITIONAL_INFO |
UINT32 |
See ADDITIONAL_INFO Field for details. |
END_TIME |
UINT32 |
Ending time stamp of this RDR. The field is in UNIX time_t format, which is the number of seconds since midnight of 1 January 1970. |
BUCKET_ID |
UINT16 |
Use for Gy quota model only. If request quota upon login is specified for the bucket, this field contains bucket id. This indicates to the server that quota should be provided to specified bucket id. '0xFFFF' - reserved. |
BUCKET_TYPE |
UINT16 |
Not used. 0 |
UNIT_AMOUNT_IN |
UINT32 |
Not used. 0 |
UNIT_AMOUNT_OUT |
UINT32 |
Not used. 0 |
Note The following fields report information per bucket:
•BUCKET_ID
•BUCKET_TYPE
•UNIT_AMOUNT_IN
•UNIT_AMOUNT_OUT
This section of four fields is repeated 16 times, one time for each of the 16 buckets, for a total of 64 fields. (Added to the 6 header fields results in a total of 70 fields in the RDR.)
DHCP RDR
The DHCP_RDR is generated each time a DHCP message of a specified type is intercepted.
Note DHCP RDRs are generated only if activated by a subscriber integration system, such as the SCMS Subscriber Manager (SM) DHCP LEG.
For each message read, the Cisco Service Control Application for Broadband (SCA BB) extracts several option fields. You can configure which fields to extract. An RDR is generated even if none of the fields were found.
The RDR tag of the DHCP_RDR is 0xf0f0f042 / 4042321986.
Table 2-22 lists the DHCP RDR fields and descriptions.
RADIUS RDR
The RADIUS_RDR is generated each time a RADIUS message of a specified type is intercepted.
Note RADIUS RDRs are generated only if activated by a subscriber integration system, such as the SCMS-SM RADIUS LEG.
For each message read, SCA BB extracts several option fields. You can configure which fields to extract. An RDR is generated even if none of the fields were found.
The RDR tag of the RADIUS_RDR is 0xf0f0f043 / 4042321987.
Table 2-23 lists the RADIUS RDR fields and descriptions.
Flow Start RDR
The FLOW_START_RDR is generated when a flow starts, as follows:
•Any flow on packages and services that are configured to generate such an RDR.
•When a SIP INVITE request for voice and video traffic is received.
This RDR is designed for services and packages where specific, per-transaction RDRs are required (for example, transaction-level billing). It is easy to configure this RDR, in error, so that it is generated for every transaction, which may result in an excessive RDR rate. Configure the generation scheme for this RDR with extra care.
The RDR tag of the FLOW_START_RDR is 0xf0f0f016 / 4042321942.
Table 2-24 lists the Flow Start RDR fields and their descriptions.
Flow End RDR
The FLOW_END_RDR is generated when a flow stops, for any flow that generated a FLOW_START_RDR.
This RDR is designed for services and packages where specific, per-transaction RDRs are required (for example, transaction level billing). It is easy to configure this RDR, in error, so that it is generated for every transaction, which may result in an excessive RDR rate. Configure the generation scheme for this RDR with extra care.
The RDR tag of the FLOW_END_RDR is 0xf0f0f018 / 4042321944.
Table 2-25 lists the Flow End RDR fields and their descriptions.
Ongoing Flow RDR
The FLOW_ONGOING_RDR is generated at set time intervals during the life of a flow, for any flow that generated a FLOW_START_RDR, if the system is configured to issue such RDR.
This RDR is designed for services and packages where specific, per-transaction RDRs are required (for example, transaction level billing). It is easy to configure this RDR, in error, so that it is generated for every transaction, which may result in an excessive RDR rate. Configure the generation scheme for this RDR with extra care.
The RDR tag of the FLOW_ONGOING_RDR is 0xf0f0f017 / 4042321943.
Table 2-26 lists the Ongoing Flow RDR fields and their descriptions.
Media Flow RDR
The MEDIA_FLOW_RDR is generated at the end of every SIP, Skype, or MGCP media flow:
•For SIP, this RDR is generated when a media channel is closed.
•For Skype, this RDR is generated when an end-of-call is detected.
•For MGCP, this RDR is generated when a media flow is closed.
Note SIP includes all SIP-based applications (such as Vonage and Yahoo Messenger VoIP).
The RDR tag of the MEDIA_FLOW_RDR is 0xF0F0F46C / 4042323052.
Table 2-27 lists the Media Flow RDR fields and their descriptions.
Note Packet Loss Note
This field is taken from the RTCP field "fraction lost". It is the average value of all RTCP packets seen during the flow life for the specified direction. The value is the numerator of a fraction whose denominator is 256. To get the packet loss value as percentage, divide this value by 2.56.
Average Jitter
This field is taken from the RTCP field "interval jitter". The reported value is the average value of all RTCP packets seen during the flow life for the specified direction. This value is multiplied by the NTP time-stamp delta (middle 32 bits) and divided by the RTCP time-stamp delta to convert it to normal time units. These two time stamps are also taken from the RTCP packet. The reported value is the average jitter in units of 1/65536 second. To convert to milliseconds divide by 65.536.
For more information about the RCP/RTCP standard, see RFC 1889.
Attack Start RDR
The ATTACK_START_RDR is generated at the beginning of an attack for all attack types that are configured to generate such an RDR. (To enable and configure the generation of these RDRs, see "The Service Security Dashboard" section in the "Using the Service Configuration Editor: Additional Options" chapter of Cisco Service Control Application for Broadband User Guide.)
The RDR tag of the ATTACK_START_RDR is 0xf0f0f019 / 4042321945.
Table 2-28 lists the Attack Start RDR fields and their descriptions.
Attack End RDR
The ATTACK_END_RDR is generated at the end of an attack for any attack that caused the generation of an ATTACK_START_RDR.
The RDR tag of the ATTACK_END_RDR is 0xf0f0f01a / 4042321946.
Table 2-29 lists the Attack End RDR fields and their descriptions.
Malicious Traffic Periodic RDR
The MALICIOUS_TRAFFIC_PERIODIC_RDR is generated when an attack is detected, periodically, at user-configured intervals, for the duration of the attack, and at the end of the attack. The MALICIOUS_TRAFFIC_PERIODIC_RDR reports the details of the attack or malicious traffic.
The RDR tag of the MALICIOUS_TRAFFIC_PERIODIC_RDR is 0xf0f0f050 / 4042322000.
Table 2-30 lists the Malicious Traffic Periodic RDR fields and their descriptions.
Note You can identify the type of attack (scan, DDOS, or DOS) from Malicious Traffic Periodic RDR data:
Scan—OTHER_IP=-1 and ATTACK_TYPE=1 (the RDR contains the source (attacker) IP address)
DDOS attack—OTHER_IP=-1 and ATTACK_TYPE=0 (the RDR contains the destination (attacked) IP address)
DOS attack—OTHER_IP contains an IP address (the RDR contains two IP addresses)
Spam RDR
The SPAM_RDR is generated when mass-mailing activity is detected.
The RDR tag of the SPAM_RDR is 4042322048.
Table 2-31 lists the Spam RDR fields and their descriptions.
Related Topics
Information About RDR Enumeration Fields
The following sections list possible values for the RDR enumeration fields.
Block Reason (uint8)
The BLOCK_REASON field is a bit field. Table 2-32 lists the meanings of the bits of this field.
String Fields
Table 2-33 lists the ACCESS_STRING and INFO_STRING field values.
Aggregation Period (uint8)
Table 2-34 lists the AGG_PERIOD field values.
Flow Close Mode (uint8)
Table 2-35 lists the FLOW_CLOSE_MODE field values.
Time Frames (unint16)
Table 2-36 lists the TIME_FRAME field values.
|
|
|
|
|---|---|---|
TIME_FRAME_0 through TIME_FRAME_3 |
0-3 |
ID of active time frame. A number from 0 to 3 that indicates the time frame internal index. |
RDR Tag Assignment Summary
Table 2-37 summarizes RDR tag assignments.
RDR categories are the mechanism by which different types of RDRs can be sent to different collectors. You can configure the RDR categories using the SCE CLI. For more information, see the following relevant document:
•"Raw Data Formatting: The RDR Formatter and NetFlow Exporting" chapter of Cisco SCE 2000 and SCE 1000 Software Configuration Guide.
•"Raw Data Formatting: The RDR Formatter and NetFlow Exporting" chapter of Cisco SCE8000 10GBE Software Configuration Guide.
•"Raw Data Formatting: The RDR Formatter and NetFlow Exporting" chapter of Cisco SCE8000 GBE Software Configuration Guide.
Table 2-38 summarizes the RDR tag default categories.
Periodic RDR Zero Adjustment Mechanism
The Periodic RDRs (or Network Usage RDRs) include the Link Usage, Package Usage, and Real-Time Subscriber Usage RDRs. When there is traffic for a particular service or package, the appropriate Usage RDRs are generated periodically, according to user-configured intervals. The RDR includes a time stamp of the end of the interval during which the traffic was recorded.
When there is no traffic (and therefore no consumed resources) for a particular service or package during a given period of time, the SCA BB application uses the Periodic RDR Zero Adjustment Mechanism, also called the zeroing methodology, to reduce the number of Usage RDRs generated for that service or package. This technique also simplifies collection for external systems by reducing the number of RDRs that they need to handle.
Note Unlike other Usage RDRs, the generation logic for Subscriber Usage RDRs does not use the zeroing methodology.
The zeroing methodology algorithm works as follows: for any number of consecutive time intervals having no traffic for a particular service or package, zero-consumption RDRs are generated for the first and last zero-consumption time intervals, but not for the intermediate time intervals. These two zero-consumption RDRs are generated when the next traffic arrives.
Example 1
The Real-Time Subscriber Usage RDR (for a given subscriber) has a generation period of 30 minutes. There is subscriber traffic during the interval 1200-1230, no subscriber traffic during the following five intervals (1230-1300, 1300-1330, 1330-1400, 1400-1430, 1430-1500), and the next subscriber traffic occurs at 1522. The following Real-Time Subscriber Usage RDRs are generated:
•At 1230, one RDR with the values of the consumed resources for the interval 1200-1230, and with the time stamp 1230.
•At 1522, one zero-consumption RDR having the time stamp (1300) of the end of the first interval (1230-1300) with no traffic for that subscriber.
•At 1522, one zero-consumption RDR having the time stamp (1500) of the end of the last interval (1430-1500) with no traffic for that subscriber.
No RDR is generated for the three intermediate zero-consumption intervals (1300-1330, 1330-1400, and 1400-1430).
•At 1530, one RDR with the values of the consumed resources for the interval 1500-1530, and with the time stamp 1530.
Example 2
The Real-Time Subscriber Usage RDR (for a given subscriber) has a generation period of 30 minutes. There is subscriber traffic during the interval 1200-1230, no subscriber traffic during the following interval 1230-1300, and the next subscriber traffic occurs at 1322. The following Real-Time Subscriber Usage RDRs are generated:
•At 1230, one RDR with the values of the consumed resources for the interval 1200-1230, and with the time stamp 1230.
•At 1322, one zero-consumption RDR having the time stamp (1300) of the single interval (1230-1300) with no traffic for that subscriber.
•At 1330, one RDR with the values of the consumed resources for the interval 1300-1330, and with the time stamp 1330.
Feedback