-
Cisco Content Services Gateway - 2nd Generation Release 2.0 Installation and Configuration Guide, for Cisco IOS Release 12.4(15)MD
-
About This Book
-
Overview
-
Configuring the CSG2
-
Configuring BMA Support
-
Configuring Quota Server Support
-
Configuring Service Support
-
Configuring IPC Support
-
Configuring PSD Support
-
Configuring iSCSI Support
-
Configuring RADIUS Support
-
Configuring Prepaid Support
-
CSG2 Command Reference
-
CSG2 Command History—CSG1 R7 to CSG2 R1
-
CSG2 Command History—CSG2 R1 to CSG2 R2
-
Protocol Compliance Statements for the CSG2
-
CSG2 R2 System Messages
-
Monitoring Notifications
-
Table Of Contents
Comparison of CSG1 and CSG2 Hardware Architectures
CSG2 Interactions with External Entities
Fixed CDR Support for HTTP, IMAP, RTSP, and WAP
Single CDR Support for HTTP and WAP Connectionless
Service-Level CDR Summarization
Prepaid and Postpaid Envelope Information Support for SMTP
Byte and Packet Counting After a Failover
HTTP Pipelining and Chunked Transfer Encoding
HTTP Records Reporting Flexibility
Learning Client IP Addresses Using Inspection of HTTP X-Forwarded-For Headers
Support for WAP Segmentation and Reassembly (SAR)
Header, Method, and URL Mapping
Charging for Service Duration Billing
Calculating Usage for Service Duration Billing
Reporting Quadrans to the Quota Server and to the BMA
Handling Out-of-Quota Conditions
Stateful Redundancy and Failover
Prepaid Content Billing and Accounting
Enhanced Interoperability with Cisco Service-Aware GGSN
IP Fragment Support for All Protocols
Support for Out-of-Order Packets for All Protocols
Support for Port Number Ranges
Overview
The Cisco Content Services Gateway - 2nd Generation, more commonly known as the Content Services Gateway 2 or CSG2, is an application that runs on the Service and Application Module for IP (SAMI), a high-speed processing module. The CSG2 provides content-aware billing, service control, traffic analysis, and data mining in a highly scalable, fault-tolerant package. The CSG2 provides the software required by mobile wireless operating companies and other billing, applications, and service customers.
The CSG2 runs on the SAMI, a new-generation high performance service module for the Cisco 7600 series router platforms. The CSG2 is typically located at the edge of a network in an Internet service provider (ISP) point of presence (POP), or Regional Data Center.
In addition to performing standard IP flow accounting, the CSG2 also examines various protocol requests—e-mail, HTTP, FTP, Real Time Streaming Protocol (RTSP), Session Initiation Protocol (SIP), wireless application protocol 1.x and 2.0 (WAP 1.x and WAP 2.0)—to gather URLs and other header information for accounting purposes. Additionally, the CSG2 gathers information on subscriber names and usage statistics, and enables differentiated billing for individual transactions based on hostname, on the directory accessed, or on individual files.
The CSG2 inspects IP traffic at levels deeper than typical routers. When doing so, the CSG2 behaves partly as a proxy server. Therefore, design your network security strategy to protect the CSG2 as you would any proxy or server.
This section includes the following information:
What's New
The CSG2 R2 includes the following new features:
•
New RADIUS Features
–
–
•
•
•
–
•
–
•
–
–
•
•
•
–
•
–
–
CSG2 Features
The CSG2 Release 12.4(11)MD provides the following basic features and functionality:
•
•
•
•
•
•
Comparison of CSG1 and CSG2 Hardware Architectures
Figure 1-1 illustrates the key differences between the CSG1 hardware architecture and the CSG2 hardware architecture.
Figure 1-1 Comparison of CSG1 and CSG2 Hardware Architectures
As can be seen, the CSG1 featured a pipelined architecture, with five IXP1200 traffic processors (TPs) running at 166MHz and one Power PC (PPC) 405GP control processor (CP) running at 166MHz.
In contrast, the CSG2 features a parallel architecture, with one IXP2800 flow-distributor TP running at 1.4GHz, five PPC 8548 TPs running at 1.25GHz, and one PPC 8548 CP running at 1.25GHz.
The benefits of the CSG2 approach include:
•
•
•
•
•
MIB Support
The CSG2 supports the following MIBs:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
CSG2 Billing Criteria
The CSG2 can bill different services based on different criteria, as shown in Table 1-1.
CSG2 Interactions with External Entities
The CSG2 communicates with several different external entities:
•
For more information about the BMA, see the "Configuring BMA Support" section on page 3-1
•
For more information about the quota server, see the "Configuring Quota Server Support" section on page 4-1
•
For more information about the XML user database, see the "Configuring the User Database" section on page 2-9.
•
For more information about the IPC module, see the "Configuring IPC Support" section on page 6-1.
•
For more information about the PSD, see the "Configuring PSD Support" section on page 7-1.
•
For more information about the iSCSI, see the "Configuring iSCSI Support" section on page 8-1.
•
For more information about RADIUS clients and servers, see the "Configuring RADIUS Support" section on page 9-1.
CDR Support
The CSG2 provides the following call detail record (CDR) support:
•
•
•
•
Fixed CDR Support for HTTP, IMAP, RTSP, and WAP
The CSG2 supports the generation of fixed format CDRs for HTTP, IMAP, RTSP, and WAP.
For more information, see the "Configuring Fixed, Variable, or Combined Format CDR Support" section on page 2-17.
Single CDR Support for HTTP and WAP Connectionless
For HTTP and WAP, the CSG2 reduces the multiple CDRs generated to a single CDR, which is reported at the end of the transaction. This feature is supported for both WAP connectionless and WAP connection-oriented traffic, as well as for HTTP traffic.
For more information, see the "Single CDR Support for HTTP and WAP" section on page 2-18.
Service-Level CDR Summarization
By default, the CSG2 generates billing records for each transaction. This large number of records might overwhelm the charging gateway (CG) or the collector. To prevent this situation, the CSG2 can summarize CDRs at the service level, instead of at the transaction level.
For more information about service-level CDR summarization, see the "Enabling Service-Level CDR Summarization" section on page 5-9.
Prepaid and Postpaid Envelope Information Support for SMTP
The CSG2 provides SMTP with prepaid and postpaid support, including envelope information in the CDR.
SMTP prepaid support includes all existing billing options (including IP bytes, TCP bytes excluding retransmissions, duration, and fixed). SMTP CDRs include e-mail envelope information as well as IP byte counts, TCP byte counts, and e-mail data (X-CSG-SIZE) byte counts for each e-mail message. When multiple e-mails are sent over a single TCP connection, each e-mail message is assigned byte counts until the start of the next e-mail message. The last e-mail is assigned bytes from the start of that e-mail until the end of the TCP connection.
The return code reported in the CDR is the one returned for the DATA portion of the e-mail message. If the CSG2 does not receive that data return code, it reports the last error return code (other than 250) received for individual recipients (because a bad recipient return code might be the cause of the e-mail not being sent). If the CSG2 receives a QUIT before receiving any return code, it reports a default return code of 554 (Transaction failed). This enables the CSG2 to apply refunding via the SMTP return code value.
If the subscriber runs out of quota in the middle of a transaction, the session is terminated and all known information is reported in a CDR. The application return code indicates whether the e-mail was received, and the authentication failure bit is set in the TCP flags field.
There are no commands required to enable this support.
Fixed Attribute CDRs for WAP
To support some legacy billing systems, the CSG2 provides a fixed attribute format for WAP CDRs. The same set of attributes is reported in each CDR regardless of the Wireless Session Protocol (WSP) protocol data unit (PDU) type. CDRs contain zero-length attributes when there is no information to report, but the same set of attributes are always reported in the same sequence.
There are no commands required to enable this support.
Byte Counting
The CSG2 reports the number of IP bytes uploaded and downloaded, the number of TCP bytes uploaded and downloaded by the application, and the packet counts (or PDU counts for WAP records). These counts exclude the IP and TCP headers, as well as retransmissions.
This section includes the following information:
•
Byte Counting Overview
This section describes how the GGSN and the CSG2 handle traffic, including the types of packets that they might drop. This section includes the following information:
Byte Counting on the GGSN
Typically, the GGSN forwards all packets to the upstream next-hop. However, the GGSN drops packets that meet one or more of the following conditions:
•
•
•
•
•
The GGSN does not forward the dropped packets to the CSG2, so the CSG2 does not count these packets.
Byte Counting on the CSG2
When the CSG2 receives a packet that matches an allowed content and service, it processes the packet and forwards it to the upstream next-hop. The CSG2 counts all forwarded packets.
There are some conditions that might cause the CSG2 to drop a packet (although these dropped packets account for only a very small percentage of the total network traffic). For example, the CSG2 drops the following types of packets:
•
•
•
•
•
•
•
•
•
•
The CSG2 does not count packets that are dropped.
The CSG2 also does not count some other types of packets, such as:
•
•
HTTP Byte Counting
HTTP 1.1 allows a client to send multiple HTTP requests without waiting for the corresponding responses. Therefore, a single IP datagram might contain requests or responses for more than one HTTP transaction. The CSG2 reports the total number of IP bytes of an HTTP transaction transferred between a client and a server.
The CSG2 counts the IP bytes for the TCP session SYN as part of the first transaction. The CSG2 counts the IP bytes for the TCP session FIN, FIN/ACK, or RST as part of the last transaction. The CSG2 counts the IP and TCP header bytes of an IP datagram that contains multiple transactions as part of the first transaction in the datagram.
If the CSG2 receives retransmitted SYN packet before it receives the first SYN/ACK from the server, it includes the IP bytes for the retransmitted SYN packet in the byte counts in the HTTP_Stats CDR.
The CSG2 discards out-of-order FIN packets, even if they contain data, and depends on retransmission of the out-of-order FIN packets to ensure correct billing.
If the final ACK on a TCP 3-way handshake is retransmitted, the CSG2 does not report the IP bytes associated with the retransmitted ACK in the HTTP_Stats CDR.
To enable the CSG2 to count fixed-format HTTP IP bytes more accurately, a new CDR and a new TLV have been added to the existing fixed HTTP intermediate CDRs.
There are no commands required to enable HTTP IP byte counting.
This section includes the following additional information:
•
•
HTTP IP Bytes vs. TCP Bytes
The CSG2 reports the total number of IP bytes of an HTTP transaction transferred between a client and a server. For a given transaction, there will always be more IP bytes than TCP bytes.
For HTTP quota management, the billing process has always managed IP bytes, not TCP bytes (for basis byte ip) and has always provided transaction grants as IP bytes.
From a system behavior point of view, the CSG2 quota management for HTTP may appear different, because the forwarding process takes the granted quota and applies it to IP bytes instead of TCP bytes.
For example, an empty TCP packet for HTTP would have previously consumed 0 bytes of IP quota - now it would take 40 (assuming standard IP and TCP header size).
Note
Configuring basis byte tcp allows counting of only TCP payload and exclusion of overhead for network retransmission. With this option, the CSG2 excludes IP and TCP headers from volume counts. Retransmitted packets are also not counted.
Counting Uncorrelated HTTP IP Bytes
Sometimes the CSG2 cannot correlate some IP bytes to any transaction at the end of a TCP session. This can include any retransmits or ACKs without payloads that are received after the CSG2 has reported the CDR for a specific transaction. You can configure the CSG2 to include these IP bytes in its reports by setting the records delay command inCSG2 content configuration mode to a non-zero value.
Packet Counts for Pipelined HTTP
Packet counts for pipelined HTTP operations are a snapshot of the number of packets detected on the connection since the previous statistics were reported. The packet count might even be zero if two pipelined operations share the same packet.
WAP Byte and Packet Counting
WAP byte counting is always IP-based.
The CSG2 reports WAP datagram sizes (including IP and UDP headers), the number of IP packets per transaction, and PDU counts. (The PDU count is not the same as the packet count. Multiple WAP PDUs can share a single packet.)
Bytes for retransmitted WAP PDUs and segments are not counted against quota, but they are counted and listed separately from non-retransmitted counts in the WAP CDRs.
Byte and PDU counts are further specified by source. Reports include the number of bytes and PDUs uploaded from source to destination and the number of bytes downloaded from destination to source.
The CSG2 splits all concatenated PDUs received from the client into multiple IP packets to be sent to the server. Therefore, packet counts are based on the number of WAP PDUs, not on the number of IP packets.
Byte counting for concatenated PDUs is complicated because multiple transactions are combined into a single IP packet. For example, a concatenated CONNECT/GET shares the same IP/UDP headers, yet they are treated as two separate transactions, they result in two separate CDRs, and they might even be charged differently from each other. In addition to the IP/UDP headers, there are several other bytes in the packet that define it as a concatenated packet. It might not be obvious to which transaction these bytes are assigned. Here is how the CSG2 assigns the IP bytes:
•
•
•
For example, a CONNECT/GET concatenated PDU that contains one-byte PDU length fields yields the following byte count totals:
•
•
IMAP Byte Counting
Service-level fixed format CDRs for IMAP include the following IMAP-specific counts:
•
•
•
•
•
•
•
•
•
•
The CSG2 reports incremental byte counts for the IMAP service-level fixed format CDRs. For example, if 100 KB of traffic is generated for the first 15 minutes, 50 KB for the next 15 minutes, and the CSG2 generates intermediate CDRs every 15 minutes, then the CSG2 reports the change in the total byte count from the point at which the last CDR was reported to the point at which the current CDR is reported. Thus, the first CDR would report 100 KB, and the second would report 50 KB.
With fixed format CDRs, the incremental byte counts might be reported at a given time interval or after a volume threshold has been reached (for example, every 15 minutes, or after every 100 KB.)
For IMAP byte counting, keep the following considerations in mind:
•
•
FTP and RTSP Byte Counting
For FTP and RTSP, the CSG2 reports the upstream and downstream IP bytes and TCP bytes.
Even though FTP and RTSP data sessions usually appear to be network-initiated, the uploaded bytes for FTP and RTSP (for example, in IP statistics) are counted from the originator of the session, the endpoint from which the first packet for the session is received.
Note
The CSG2 discards out-of-order FIN packets, even if they contain data, and depends on retransmission of the out-of-order FIN packets to ensure correct billing.
SIP Byte Counting
For SIP, the CSG2 reports the upstream and downstream IP bytes and TCP bytes.
You cannot charge SIP subscriber sessions as a function of the TCP data volume processed. (That is, you cannot configure basis byte tcp in CSG2 service configuration mode for SIP.)
You can charge SIP transactions based on transaction duration time, using the basis seconds transaction command in CSG2 service configuration mode.
POP3 and SMTP Byte Counting
For POP3 and SMTP, the CSG2 reports the upstream and downstream IP bytes and TCP bytes.
Byte and Packet Counting After a Failover
After a failover, the standby CSG2 (now the active CSG2) considers the first 32 KB TCP bytes received to be retransmitted packets and does not count TCP bytes for those packets. However, the IP byte count is counted normally.
CSG2 User Table
The CSG2 User Table identifies all subscribers known to the CSG2. The User Table is populated based on the contents of RADIUS Accounting Start messages, or from the user database, if either feature is enabled in your configuration.
The CSG2 User Table can hold up to 1,250,000 entries with the 2 GB-SAMI option, or up to 500,000 entries with the 1 GB-SAMI option.
For more information about the User Table, see the "Configuring the CSG2 User Table" section on page 2-10.
CSG2 Interface Awareness
Many provider networks offer data access, control over subscriber addressing, and dedicated Virtual Routing and Forwarding (VRF) over the wireless network to enterprises and Mobile Virtual Network Operators (MVNOs). Interface awareness uses VRF tables to enable the CSG2 to distinguish between subscribers and sessions that share the same IP address on different VLANs (that is, subscribers and sessions with overlapping IP addresses). Configurations with overlapping IP address requirements cannot use the CSG2 RADIUS user database to determine the user's identity, because user database queries do not include VRF table information.
Because the quota server can only respond to the CSG2 (that is, there can be no quota server-initiated messages), the Extended User Index TLV is required to in order to identify or trigger action for a subscriber within a CSG2 table.
To support traffic segregation across VLANs, the CSG2 uses next-hop to bind flows to uplink and downlink routing hops. The CSG2 routes uplink packets (from the Network Access Server [NAS]) by applying next-hop policies to the contents on each NAS VLAN. The CSG2 routes downlink packets via the downlink address supplied by the NAS in the RADIUS Accounting start message.
Logically, that means that a dedicated per-VLAN NAS is required for interface awareness. Physically, however, it depends on the capabilities of the NAS. Each RADIUS proxy statement can have a table name. When a User Table entry is created as a result of a Start message sent to that proxy IP address, the specified table name is associated with the subscriber. Depending on your network, you might choose to route this subscriber's traffic different from another subscriber's traffic, even when the source or destination IP addresses are the same. To do so, use the next-hop command in CSG2 content configuration mode, or specify the downlink next-hop in the Start message.
To associate a VRF table name with a particular CSG2 component, specify the vrf keyword on the appropriate ip csg command in global configuration mode. For example, to associate a VRF table name with a particular RADIUS proxy, specify the vrf keyword on the ip csg radius proxy command in global configuration mode.
When configuring Interface Awareness, keep the following considerations in mind:
•
•
•
BMA Features
The CSG2 monitors data flows and generates accounting records that can be used to bill customers at a content level. The CSG2 sends the accounting records to a Billing Mediation Agent (BMA), which formats the records as required by the customer's billing system. At the end of each transaction, a billing record indicating the content accessed and the amount deducted is sent to the BMA, so that it can be logged in the subscriber's bill.
The CSG2 provides the following BMA features:
•
•
•
•
•
•
•
For descriptions of these features, and instructions for configuring them, see the "Configuring BMA Support" section on page 3-1.
Quota Server Features
The CSG2 uses quota servers to return billing quota values for subscribers. The quota server interfaces with the billing system balance manager to reserve credit. The quota server then translates the reserved credit for the subscriber into quota based on the business and rating rules for multiple subscriber services on the CSG2.
For each CSG2 content billing service, the CSG2 downloads a separate quota, and deducts from that quota. Quotas are specified in units called quadrans. A quadran is a generic unit whose "value" is defined by each quota server. A quadran can represent, for example, a click for a per-click service (for example, an HTTP request), or a byte for a per-volume service. The value of a quadran is transparent to the CSG2; the CSG2 simply requests and downloads quadrans as needed from quota servers.
The CSG2 provides the following quota server features:
•
•
•
•
•
•
•
•
•
•
•
•
•
For descriptions of these features, and instructions for configuring them, see the "Configuring Quota Server Support" section on page 4-1.
Service Features
A CSG2 content billing service is a component of a billing plan to which subscribers subscribe.
You can configure one or more content billing services for the CSG2. Each service represents a group of content that is billed the same way, such as billing per-click (or per-request) or billing per-IP byte, and that shares part of a subscriber's quota. Grouping content into one or more services enables you to separate, for example, a subscriber's prepaid quota for Internet browsing from his quota for e-mails.
The CSG2 provides the following features for content billing services:
•
•
•
•
•
•
•
•
•
For descriptions of these features, and instructions for configuring them, see the "Configuring Service Support" section on page 5-1.
IPC Features
The CSG2 Interprocessor Communication (IPC) module provides a communication channel between the CSG2 Control Processor (CP) and Traffic Processors (TPs), and, in a redundant CSG2 deployment, between the TPs on the active CSG2 and their counterparts on the standby CSG2.
The CSG2 provides the following IPC features:
•
•
•
•
For descriptions of these features, and instructions for configuring them, see the "Configuring IPC Support" section on page 6-1.
PSD Features
The Cisco Persistent Storage Device (PSD) provides persistent storage capabilities to the CSG2, and allows the CSG2 to store data on the PSD's internal hard drive. The CSG2 provides the following PSD features:
•
•
•
•
•
•
•
For descriptions of these features, and instructions for configuring them, see the "Configuring PSD Support" section on page 7-1.
iSCSI Features
The CSG2 can use a Storage Area Network (SAN) connected to an Internet Small Computer Systems Interface (iSCSI) to store CDRs when BMAs are unreachable. The CSG2 provides the following iSCSI features:
•
•
•
For descriptions of these features, and instructions for configuring them, see the "Configuring iSCSI Support" section on page 8-1.
RADIUS Features
RADIUS is a distributed client/server system that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco routers and send authentication requests to a central RADIUS server that contains all subscriber authentication and network service access information. The RADIUS client and server retrieve subscriber correlation information (the IP address, the MSISDN, the User-Name, and the Billing Plan) for prepaid subscribers. The CSG2 acts as a RADIUS proxy or RADIUS endpoint to retrieve the subscriber correlation information. In addition, the CSG2 can report RADIUS attributes when it communicates with the BMA and quota servers.
The CSG2 provides the following RADIUS features:
•
•
•
•
•
For descriptions of these features, and instructions for configuring them, see the "Configuring RADIUS Support" section on page 9-1.
HTTP Features
The CSG2 provides the following HTTP features:
•
•
•
HTTP Pipelining and Chunked Transfer Encoding
The CSG2 supports full HTTP pipelining and chunked transfer encoding. Packet counts for pipelined HTTP operations are a snapshot of the number of packets detected on the connection since the previous statistics were reported. The packet count might even be zero if two pipelined operations share the same packet.
If pipelined connections are replicated to a standby CSG2, and a failover occurs, the CSG2 does not increment the content counters for traffic flowing through these connections. The CSG2 does increment the content counters for new pipelined connections created after the failover.
When performing AoC for a TCP connection carrying pipelined HTTP requests, the CSG2 responds with the redirect to the client as soon as the quota server requests the redirect. This could result in the redirect arriving at the client before responses for previous requests arrive, and the client might associate the redirect with a different request in the pipeline.
There are no commands required to enable this function.
Support for Multipart HTTP
For HTTP sessions, multipart content does not cause the CSG2 to invoke Layer 4 billing for the remainder of the connection. Instead, the CSG2 parses the data for the delimiter specified in the header and continues to use Layer 7 billing.
There are no commands required to enable support for multipart HTTP.
HTTP 1.0 Content Billing
The CSG2 enables you to bill subscribers for individual transactions by discriminating on a per-object basis, and on a per-subscriber basis. Unlike traditional billing models, which bill for broad classes of traffic, this service enables differentiated billing based on the actual object being requested. You can even bill objects at different rates to different customers. For example, you can bill advertisements to the advertiser, rather than to the subscriber.
HTTP 1.1 Content Billing
The CSG2 separately records each request over a persistent HTTP 1.1 session.
HTTP Records Reporting Flexibility
The client's IP address is included in the HTTP Header message. This enables the BMA to identify the client by user ID (and by IP address) immediately, without having to wait for the HTTP Statistics record.
You can configure the CSG2 to send the HTTP Header message as soon as it is generated. This reduces latency and notifies the BMA about the client's transaction as quickly as possible. Although this type of reporting is more efficient, it provides less information; use it only when the BMA needs to react to the client's activity very quickly.
You can configure the CSG2 to not send the HTTP Statistics message. This configuration reduces the load on the BMA and is useful when the billing policy depends only on the event and does not require detailed statistics. Note that the CSG2 still sends the HTTP Statistics message if the session fails (for example, if a Reset [RST] is received without a Finish [FIN], or if the session times out).
HTTP Error Code Reporting
The CSG2 reports HTTP-specific information about the request, such as the URL, as well as HTTP error codes (response codes of 300 or higher).
Learning Client IP Addresses Using Inspection of HTTP X-Forwarded-For Headers
If your network is configured with a gateway or proxy placed between the client and the CSG2, you can configure the CSG2 to determine the client's IP address by inspecting the HTTP X-Forwarded-For header.
The CSG2 can also obscure the contents of X-Forwarded-For headers, overwriting the contents with blanks, thereby preventing the exposure of potentially sensitive IP addresses.
To configure the way the CSG2 is to handle X-Forwarded-For headers, use the subscriber-ip http-header forwarded-for command in CSG2 content configuration mode.
SIP Features
The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol used for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.
The CSG2 provides detailed billing information and services for content transported over the network using SIP.
For SIP and Session Description Protocol (SDP), keep the following considerations in mind:
•
•
•
WAP Features
The CSG2 provides the following WAP features:
•
WAP Traffic
The CSG2 can intercept WAP traffic and generate reports that include contextual WAP information and counts of the bytes transferred. WAP functionality provides protocol-level prepaid and postpaid billing, including the following functionality:
•
•
•
•
•
•
•
•
WAP 2.0
The CSG2 supports billing for the following types of WAP 2.0 network flows:
•
•
•
WAP 2.0 mobile devices can participate in these flows, implemented as WAP 2.0/TCP across a WAP 2.0 Proxy or Push Proxy Gateway (PPG): WAP 2.0 mobile devices can be configured to use the WAP 2.0 proxy or to ignore it. However, if a WAP 2.0 proxy is not configured, the configuration resembles HTML over HTTP (in that you must choose the appropriate content rules so that HTTP policies can be applied to the WAP 2.0 traffic). The WAP 2.0 proxy enables you to identify WAP 2.0 traffic by configuring a content that examines traffic to and from the WAP 2.0 proxy. Using an account type of http enables billing of WAP 2.0, including support for policies based on the HTTP method, URL and HTTP header values. The current limitations of HTTP billing (with respect to Transport Layer Security [TLS]) apply to billing WAP 2.0 and MMS/WAP 2.0.
The CSG2 also supports PPG-Originated TCP (PO-TCP), implemented as WAP 2.0 over SMS OTA-PUSH rather than WAP 2.0 over HTTP. In PO-TCP, the PPG establishes a direct connection to the mobile device using prior knowledge of its IP address. The PPG negotiates an understanding of the mobile device identity and capabilities by using HTTP.request-method: OPTIONS, and then uses HTTP.request-method: POST to deliver the PUSH notification as a WAP 2.0 XML message.
WAP 2.0 mobile devices can implement support for extensive MMS over WAP 2.0. Service providers use MMS to differentiate and promote their products; thus, the billing of MMS over WAP 2.0 needs to be differentiated from other WAP 2.0 billing. The CSG2 can bill MMS over the supported WAP 2.0 flows at a differentiated rate by using HTTP billing capabilities to detect some or all of the following characteristics of MMS/WAP 2.0 traffic:
•
•
•
MMS over WAP 2.0 allows the following types of notification:
•
•
•
The CSG2 Layer 7 billing for MMS relies entirely on the PO-TCP and SMS-based notification types. TO-TCP is not supported.
Note
Support for WAP Segmentation and Reassembly (SAR)
The CSG2 applies the appropriate policy to the WAP transaction if it contains a URL that spans multiple WAP segmented packets.
There are no commands required to enable support for WAP SAR.
RTSP Features
The CSG2 provides the following Real Time Streaming Protocol (RTSP) features:
For RTSP, keep the following considerations in mind:
•
•
–
–
–
•
•
•
•
•
•
•
RTSP Billing
RTSP billing correlates all the streams that are associated with an RTSP session, and reports application-level information (for example, filename) to the billing system.
RTSP billing provides the following functionality:
•
•
RTSP uses the following protocols for streaming to the client. The client presents the server with a choice of acceptable protocols and port numbers, and the server responds with its choice of protocol that includes:
•
•
•
•
RTSP transport modes are negotiated on the control connection using the following methods:
•
•
Per-Click Authorization
Per-click authorization implements functions like AoC redirection and retrieval of price from an external server. For the control session, the CSG2 sends a Content Authorization Request at the beginning of the TCP session. For each transaction involving a data stream, the CSG2 sends a Content Authorization Request before it allows the data stream to flow. This request allows the quota server to inspect the filename before granting authorization.
RTSP allows the multiplexing of multiple data streams over the same transport. For example, audio and video presentations can be multiplexed over the same UDP flows. The quota server must ensure that it does not send contradictory responses to the various Content Authorization Requests. For example, if one request is allowed and the other one is denied, the behavior of the CSG2 is undefined.
Correlation
The CSG2 provides RTSP correlation at the RTSP session level. All TCP/UDP flows associated with an RTSP session share a correlator.
The CSG2 does not correlate RTSP streams that do not share the RTSP session ID.
Correlating Multiple Streams Controlled by a Single RTSP Session
An RTSP session can control multiple streams, such as the audio stream and the video stream for a movie. For instance, a client can perform the following operations over the same RTSP session:
•
The client requests the description of a movie. The server assigns a session ID to the client, and sends the.sdp file containing information about the movie.
•
The client requests the setup of a stream.
•
The client requests the setup of a second stream. This results in the setting up of four UDP flows.
•
In this example, all the streams share the RTSP session and the session ID. There is one RTSP control TCP session, with four associated UDP streams. The CSG2 correlates all four UDP streams with the control session.
Correlating Multiple Streams Controlled by HTTP
HTTP sessions can be used to correlate multiple related RTSP streams. Different RTSP streams could go to different servers. The CSG2 has no easy way to determine which two streams are related. For example, a web server (W) hosts the media description file, movie.sdp; a video server (V) contains the video stream; and an audio server (A) contains the audio stream. Table 1-2 identifies the interactions that occur.
In the previous example, there are five concurrent sessions:
•
•
•
All of the TCP and UDP sessions associated with an RTSP session can be correlated. In this same example, the sessions associated with the video on server V are correlated. Similarly, the sessions associated with the audio on server A are correlated; however, there is no correlation between the audio and video flows, and neither the audio flow nor the video flow is correlated with the HTTP session.
Implications of Container Files
A container file is a storage entity in which multiple, continuous media types pertaining to the same subscriber presentation are present. A container file represents an RTSP presentation; each of its components is an RTSP stream. While the components are transported as independent streams, it is desirable to maintain a common context for these streams at the server. Synchronized Multimedia Integration Language (SMIL) is an example of a programming language that can be used to describe the contents of a container file.
The CSG2 does not correlate the streams within a container file.
Interleaved RTSP
Interleaved RTSP passes RTSP data in the TCP control session. Because the CSG2 parses the control session, it could cause a large performance bottleneck.
To avoid bottlenecks, the CSG2 performs the following actions for interleaved RTSP sessions:
•
•
•
This method provides some RTSP-level information, but avoids making the RTSP path a target of denial-of-service (DoS) attacks. If most of the RTSP streaming billing applications are protected, customers have some control over the servers to ensure that interleaved RTSP is not used excessively.
CDRs
The CSG2 generates the following CDRs for RTSP:
•
•
•
Note
RTSP billing in the CSG2 is based on inspection of the RTSP SETUP and TEARDOWN messages that are exchanged between the client and server. The CSG2 builds the RTSP CDR immediately after the RTSP TEARDOWN signal if the URL exactly matches the URL from the RTSP SETUP signal. Otherwise, the CSG2 builds the CDR after any condition that causes the flows to be terminated, as when a service_stop is triggered (for example, when the access server sends a RADIUS Accounting Stop for the subscriber).
Session Processing
RTSP control session processing uses an 8-byte correlator is assigned to the RTSP control session. The most significant 6 bytes of the correlator are assigned from the session ID and the session ID sequence. The least significant 2 bytes of the correlator are zeroed (for example, 0x0000).
The CSG2 keeps track of RTSP sessions, and an RTSP session is used to correlate multiple streams that are associated with the session.
Note
When the client sends a setup command, the CSG2 notes the client ports, and extracts the server port information from the SETUP response. Data connections to these ports are processed as if they hit the content, policy definition for the control server.
The following example (from RFC 2326) uses a single RTSP session to control multiple streams. The CSG2 actions are annotated after various steps.
In this example, the client (C) requests a presentation from the media server (M). The movie is stored in a container file. The client has attached an RTSP URL to the container file.
C->M: SYN port=RTSPM->C: SYN-ACKAssign 8 byte correlator X. Lower two bytes of the correlator are 0.C->M: DESCRIBE rtsp://foo/twister RTSP/1.0CSeq: 1M->C: RTSP/1.0 200 OKCSeq: 1Content-Type: application/sdpContent-Length: 164v=0o=- 2890844256 2890842807 IN IP4 172.16.2.93s=RTSP Sessioni=An Example of RTSP Session Usagea=control:rtsp://foo/twistert=0 0m=audio 0 RTP/AVP 0a=control:rtsp://foo/twister/audiom=video 0 RTP/AVP 26a=control:rtsp://foo/twister/videoC->M: SETUP rtsp://foo/twister/audio RTSP/1.0CSeq: 2Transport: RTP/AVP;unicast;client_port=8000-8001M->C: RTSP/1.0 200 OKCSeq: 2Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001Session: 12345678Build RTSP record. Correlator = X + i. The CSG2 makes sure that X + i results in an even number. RTSP usage records for these two UDP flows carry X + i and X + i + 1 as the correlators. The correlators share 63 bits to help bind together the various flows for an RTSP transaction; that also enables you to distinguish the various interim records for one UDP flow from another.
C->M: SETUP rtsp://foo/twister/video RTSP/1.0CSeq: 3Transport: RTP/AVP;unicast;client_port=8002-8003Session: 12345678M->C: RTSP/1.0 200 OKCSeq: 3Transport: RTP/AVP;unicast;client_port=8002-8003;server_port=9004-9005Session: 12345678Build RTSP record. Correlator = X + 3. RTSP usage records generated for these two UDP flows carry the same correlator.
C->M: PLAY rtsp://foo/twister RTSP/1.0CSeq: 4Range: npt=0-Session: 12345678M->C: RTSP/1.0 200 OKCSeq: 4Session: 12345678RTP-Info: url=rtsp://foo/twister/video;seq=9810092;rtptime=3450012C->M: TEARDOWN rtsp://foo/twister RTSP/1.0CSeq: 6Session: 12345678V->C: RTSP/1.0 200 OKCSeq: 6This TEARDOWN does not correspond to the SETUP URL; therefore, the CSG2 lets the streams idle out and sends the usage records when the streams idle out.
POP3 Support
The CSG2 generates a single CDR for each POP3 e-mail. The CDR includes all necessary information, such as the IP byte count and the TCP byte count. The CSG2 no longer generates a final TCP Stats record. If a subscriber downloads multiple e-mails during a single TCP session, the CSG2 generates a CDR for the previous e-mail each time it processes a new POP3 RETR (retrieve message) or TOP (retrieve specific lines of the message body) command. The CSG2 generates a CDR for the last e-mail when it processes the POP3 STATS (statistics) command (for TCP termination).
The CSG2 supports POP3 in both prepaid and postpaid mode. For basis fixed prepaid billing, the CSG2 treats each e-mail download as a transaction and a prepaid debit subject to weighting.
The CSG2 also supports refunding for POP3. If an e-mail download request (TOP or RETR) flows from the client to the server, and the next server response is not OK, or the session ends without seeing OK, then the prepaid debit returns the prepaid quota consumed for this transaction. The refund return code used is 554; if you want the CSG2 to provide refunding for POP3, you must specify return code 554 on the retcode command in CSG2 refund configuration mode for the POP3 refund definition.
If a subscriber tries to download e-mail and no e-mail exists, the CSG2 generates a POP3 CDR that contains an application return code TLV with a value of 554. This is the only condition in which the CSG2 includes a non-zero return code in a POP3 CDR.
To define the POP3 protocol type for a billing policy, use the parse protocol pop3 command in CSG2 content configuration mode.
SMTP and POP3 Billing
SMTP is the Internet e-mail transfer protocol that operates over TCP with port 25. Subscribers send messages using SMTP. SMTP is also used to transfer messages between SMTP gateways (or relays). POP3 is a common protocol used to retrieve Internet e-mail from an e-mail server. POP3 also operates over TCP and typically uses port 110.
SMTP and POP3 messages consist of the following parts:
•
•
•
The CSG2 inspects SMTP and POP3 messages and reports all RFC 2822 header field names and bodies that appear in the header section of the message (before the body of the message). SMTP and POP3 envelope information is not reported, except for the SMTP return code from the DATA command. For SMTP, the sender and recipients in the SMTP MAIL and RCPT commands are not reported, but the values from the "To," "From," "Date," "Cc," and "Bcc" headers in the contents of the e-mail message are reported to identify senders and recipients.
Because the amount of information in the header section might be greater than an IP packet encapsulated in an Ethernet frame, the information might span multiple records by using the CSG2 Continue Data Record type. Because the amount of information in a single header field might also be greater than an IP packet over Ethernet, the CSG2 Report String Attribute reports also has a continuation option. This means that information for a single header might span multiple CSG2 Report String Attribute reports, which might span multiple CSG2 Data Records.
Note
SMTP CDR Header Removal
An SMTP CDR can be very large, as it includes a report attribute for each SMTP header embedded at the beginning of a message. The CSG2 enables you to eliminate these headers from an SMTP CDR, leaving only the SMTP envelope headers and the size attribute in the report. These are reported as X-CSG-MAIL, X-CSG-RCPT and X-CSG-SIZE.
For more information, see the "Configuring SMTP CDR Header Removal" section on page 2-20.
FTP Billing
The CSG supports both postpaid and prepaid FTP protocol-aware billing. The CSG can generate TCP billing records for FTP connections, and records that report FTP-specific information, such as the filename.
Users can define basis fixed and basis byte prepaid billing services for FTP.
Note
FTP requires a control TCP connection to well-known server port 21.
Header, Method, and URL Mapping
The CSG2 uses maps to match headers, methods, or URLs against a pattern, to determine whether flows will be processed by the CSG2 accounting services.
For more information about maps, see the "Configuring Maps for Pattern-Matching" section on page 2-21.
Service Duration Billing
The Service Duration Billing feature enables the CSG2 to deduct quota based on the time of network usage for prepaid (or "managed") subscribers. With this feature, the subscriber is charged for the time duration of the CSG2 service. The following sections describe how this feature works:
•
•
•
•
Charging for Service Duration Billing
Service Duration Billing is charged according to the following rules:
•
Because non-TCP sessions (such as UDP) do not have a Layer 4 session termination mechanism, the LBST for non-TCP sessions is determined based on the time that the last packet was forwarded for the IP session.
•
•
Calculating Usage for Service Duration Billing
The calculations for Service Duration Billing usage are as follows:
•
LBT - FBT = Usage
•
LBT - FBT = Usage
or
Asynchronous Event Timestamp - FBT = Usage
whichever is smaller.
•
LBT - FBT = Usage
or
Out Of Quota Timestamp - FBT = Usage
whichever is smaller.
Note
When a Service Duration Billing service is a member of a billing plan, and an accounting definition is in service and downloaded to a CSG2 module, you cannot modify the billing basis or meter configuration. You are instructed at the console to configure no inservice on the downloaded accounting definitions.The following examples show how Service Billing Duration usage is calculated in different situations. In these examples:
•
•
In Figure 1-2, the CSG2 calculates usage for Service 1 as:
(T2 - T0) + (T6 - T4) = Usage
and the usage for Service 2 as:
T7 - T1 = Usage
Figure 1-2 Service Duration Billing—Layer 7 Inspection, Two Services, Overlapping Transactions, Example One
In Figure 1-3, the CSG2 calculates usage for Service 1 as:
T5 - T0 = Usage
and the usage for Service 2 as:
T7 - T1 = Usage
Figure 1-3 Service Duration Billing—Layer 7 Inspection, Two Services, Overlapping Transactions, Example Two
In Figure 1-4, the CSG2 calculates usage for Service 1 as:
(T2 - T0) + (T6 - T4) = Usage
and the usage for Service 2 as:
T7 - T2' = Usage
Figure 1-4 Service Duration Billing—Layer 7 Inspection, Two Services, Non-Overlapping Transactions, Example One
In Figure 1-5, the CSG2 calculates usage for Service 1 as:
T5 - T0 = Usage
and the usage for Service 2 as:
T7 - T2' = Usage
Figure 1-5 Service Duration Billing—Layer 7 Inspection, Two Services, Non-Overlapping Transactions, Example Two
In Figure 1-6, if T4 - T2 > SIT, the CSG2 calculates usage for Service 1 as:
(T2 - T0) + (T6 - T4) = Usage
Figure 1-6 Service Duration Billing—Layer 7 Inspection, One Service, Example One
In Figure 1-7, if T3 - T2 < SIT, the CSG2 calculates usage for Service 1 as:
T4 - T0 = Usage
Figure 1-7 Service Duration Billing—Layer 7 Inspection, One Service, Example Two
In Figure 1-8, if the SIT does not time out, the CSG2 calculates usage for Service 1 as:
T6 - T0 = Usage
Figure 1-8 Service Duration Billing—Layer 7 Inspection, One Service, Example Three
In Figure 1-9, if the SIT does not time out, the CSG2 calculates usage for Service 1 as:
T6 - T0 = Usage
Figure 1-9 Service Duration Billing—Layer 7 Inspection, One Service, Example Four
Reporting Quadrans to the Quota Server and to the BMA
For Service Duration Billing, quadrans are reported to the quota server and to the BMA in seconds. In messages sent to the BMA on a per-IP-session basis (such as TCP statistics), the prepaid TLVs (Session ID, Service ID, Quadran) are present; the value for quadrans in the Quadran TLV is zero because the duration is based on service, not on individual sessions or on the sum of the durations of the individual sessions.
Handling Out-of-Quota Conditions
When a subscriber runs out of quota, the CSG2 ends the subscriber sessions that are mapped to the service. The sessions are ended using the same asynchronous session mechanism that is used when a subscriber User Table entry is deleted. The CSG2 reauthorizes when the remaining time is low (instead of 0) in order to more quickly determine session processing when zero quota is reached.
Connection Duration Billing
Connection Duration Billing enables the CSG2 to deduct quota based on the time that a subscriber is logged on to the IP network. That differs from Service Duration Billing, which charges on the basis of a service duration. Because the service measures the duration of subscriber access, the service is never idle—it is ended only when the subscriber logs out, or when a Service Stop Request is received from the quota server.
The CSG2 charges on the basis of the following rules:
•
–
–
If the subscriber has quota, the FBT is typically the same time as the RADIUS Accounting Start message.
•
–
–
LBT - FBT = Usage
or
Out Of Quota Timestamp - FBT = Usage
whichever is smaller.
Therefore, if the service does not run out of quota, the algorithm is simply as follows:
LBT - FBT = Usage
If the subscriber runs out of quota, but refreshes the quota before the service times out, the periods of zero quota are not included in the usage calculation. When the subscriber runs out of quota, existing prepaid and postpaid IP sessions for the subscriber are terminated. If the subscriber does not have quota to proceed, no IP sessions are allowed for the subscriber. The CSG2 provides enforcement only for the policies that have accounting configured.
Connection Duration Billing requires an external quota server. Connection Duration Billing is not supported for internal quota servers, such as a gateway general packet radio service (GPRS) support node (GGSN) for postpaid subscribers. Therefore, you cannot use Connection Duration Billing if your quota servers are GGSNs.
To configure Connection Duration Billing, use the activation command and the basis second command in CSG2 service configuration mode.
When configuring Service Duration Billing, make sure the content idle timer duration, set using the idle command in CSG2 content configuration mode, does not exceed the service idle timer duration, set using the idle command in CSG2 service configuration mode.
Postpaid Service Tagging
This feature enables the CSG2 to map postpaid content to a CSG2 service, and to report the service name in a CSG2 Service ID TLV in transaction-level CDRs to the BMA. (The CSG2 Service Session ID TLV is not sent in variable-format records for postpaid service tagging.)
The service must be associated with a billing plan that is configured for postpaid mode. As with prepaid billing plans, the subscriber can be associated with a billing plan via a RADIUS message or a User Profile Response from the quota server. If no quota server is configured, and the billing plan cannot be determined from RADIUS messages, the subscriber is automatically associated with any billing plan configured for postpaid mode. We strongly recommend that you configure only one billing plan for postpaid mode.
Stateful Redundancy and Failover
The CSG2 supports stateful redundancy for HTTP, IMAP, POP3, SMTP, TCP, and WAP connections.
Stateful redundancy is the configuration of the active CSG2 to share information related to billing with its standby CSG2 in the event of a failure. That is, the session continues to be billed even when the active CSG2 fails and the standby CSG2 takes over.
During normal operation, connection and billing state information is sent by the active CSG2 to the standby CSG2, and from the active quota server to the standby quota server. The active CSG2 and the standby CSG2s maintain state information for the configured BMAs. The active CSG2 keeps the standby CSG2 informed about which BMAs and quota servers are being used. If the active CSG2 fails, the standby CSG2 takes over operation and tries to use the same BMAs or quota servers, if it has connectivity. Otherwise, the standby CSG2 selects the BMAs or quota servers that have the highest priority.
The active CSG2 also informs the standby CSG2 when user IDs are added to or removed from the User Table, and sends the correlators to the standby CSG2 to ensure consistency when sending billing records for recovered connections to the BMAs. Quota use is also correlated.
If connections are replicated to a standby CSG2, and a failover occurs, the CSG2 does not increment the content counters for traffic flowing through these connections. The CSG2 does increment the content counters for new connections created after the failover.
The CSG2 provides full stateful failover for IMAP sessions.
The CSG2 provides limited stateful failover for FTP, HTTP, POP3, RTSP, SIP, SMTP, and WAP sessions.
•
•
The CSG2 also supports stateful redundancy for TCP connections. That is, the session continues to be billed even when the active CSG2 fails and the standby CSG2 takes over.
The CSG2 does not support stateful redundancy for IP or UDP connections.
Note
The CSG2 counts and charges packets that complete CSG2 feature processing and are scheduled for forwarding. It is possible for these packets to be dropped in the SAMI module due to incomplete ARP entry, incorrect IP routing, or output queue contention. For example, when an active CSG2 fails over to a standby CSG2 in a redundant configuration, some ARP entries on the standby CSG2 might not yet be populated, and the CSG2 might drop packets. In many cases, you can resolve the problem with incomplete ARP entries by routing subscriber traffic and GTP' control traffic to a common default gateway IP address. Typically, this default gateway IP address is an address on the Supervisor Engine.
The CSG1 and CSG2 cannot act as stateful standbys for each other.
"Default" Policy
The CSG2 matches content on a best-match basis, based on Layer 3 and Layer 4 information. When there is a successful content match, the CSG2 matches against the policies configured within the content, linearly, on a first-match basis. If no policy within the content matches, the CSG2 matches against an implicit "default" policy, which matches all traffic. Matching this "default" policy does not generate a CDR, because no accounting policies can be configured for the "default" policy.
Note
Tariff Switch
Tariff switch is a feature in which the CSG2 tracks the total quota usage for a prepaid service at the time of a tariff-time change. The tariff-time change is specified on a per-service basis by the quota server.
The CSG2 supports tariff switch for all prepaid protocols. The CSG2 sends tariff switch TLVs only for transaction-level CDRs, not for service-level CDRs.
The tariff switch usage for the prepaid service is reported to the quota server in the next Service Reauthorization, Quota Return, or Service Stop message sent for this service. The tariff switch usage for a tariff-time change is sent once and is sent in addition to the cumulative usage at the time of the message to the quota server. If the Supplemental Usage Reporting feature is enabled for a service at the tariff switch time, the CSG2 also reports supplemental usage at the tariff switch time in addition to the tariff-time switch usage.
The life of a prepaid service instance might span multiple tariff switch times. For a given service instance associated with a subscriber, the CSG2 can handle only one tariff switch time value.
If a transaction spans multiple tariff switches, the CSG2 reports only the most recent tariff switch information in its record, unless an intermediate record was generated between tariff-switch times.
The CSG2 might not generate a Service Reauthorization Request between tariff switch times. The quota server can force a report of the tariff switch time usage by specifying a quota timeout value in the Service Authorization Response that will force a Quota Return before the next tariff switch time. The quota server must choose the timeout carefully to avoid causing a flood of Quota Return messages at a given time. At any given time, the CSG2 service can track usage for a single tariff switch time; after reporting the usage for a tariff switch, the quota server can specify the time of the next tariff-time change in a Service Authorization Response.
If CSG2 refunding is configured for a prepaid service, the tariff switch usage might not include usage on existing IP sessions at the tariff switch time. This is because the usage cannot be charged until the session ends and the refund conditions are evaluated.
Tariff switch usage for individual transactions is reported to the BMA in the records containing quota usage (typically intermediate and stats records). Note that intermediate records might be sent to the BMA to report tariff switch usage, even without configuration of intermediate records; this is necessary because transactions might span multiple tariff switch times. To avoid flooding the BMA with records, the CSG2 sends intermediate records to the BMA for transactions that span a tariff switch time and do not terminate quickly. If a transaction is configured for BMA reporting using a fixed-format record, the tariff switch usage information is not reported in the record.
The "tariff switch qualified usage" field in the CDR is the cumulative usage since the creation of the service instance.
There are no commands required to enable tariff switch. The output of the show ip csg users all detail command displays information about the tariff switch.
Prepaid Error Reimbursement
The Prepaid Error Reimbursement feature (also known as CSG2 quota refund) allows the CSG2 to automatically refund quota for failed transactions, as defined by the CLI.
•
•
The CSG2 also adds a refund TLV to the statistics records on the BMA interface. The refund TLV is added for transactions that meet a refund condition. The refund amount contains the quota amount to be refunded for the transaction. The refund amount is the same number that is reported in the quadrans TLV. Thus, the full charge for the transaction is always refunded for these protocols.
Note
Prepaid Error Reimbursement is not supported for duration-based services.
Service-level CDRs do not contain quota reimbursement information.
Postpaid Billing
Figure 1-10 shows simple traffic flows between the various components in a simple postpaid CSG2 environment.
Figure 1-10 Traffic Flow Between Client and Server
Clients send requests that pass through a private network, or through a GGSN, before they reach the Internet.
The CSG2 monitors data flows and generates accounting records that can be used to bill customers at a content level. The CSG2 sends the accounting records to a Billing Mediation Agent (BMA), which formats the records as required by the customer's billing system.
User IDs are obtained from RADIUS Accounting records, or by querying the user database.
Prepaid Content Billing and Accounting
In addition to postpaid billing, the CSG2 provides prepaid content billing and accounting. You can configure multiple prepaid billing plans, and subscribers can choose the plan that best meets their needs. Each subscriber can use only one billing plan.
The CSG2 uses a BMA to interface with a billing server. At the end of each transaction, the CSG2 sends a billing record to the BMA, indicating the content accessed and the amount deducted. The BMA logs the information in the subscriber's bill.
The CSG2 uses a quota server to keep track of the quota that is left in the subscriber's account. Each CSG2 supports one quota server and multiple idle standby quota servers. The CSG2 allows multiple groups of subscribers on each quota server, with one quota manager for each subscriber. Figure 1-11 illustrates a typical CSG2 prepaid content billing network.
Figure 1-11 CSG2 Prepaid Content Billing Network
Quota is provided by the Quota Manager, on request for quota by the CSG2. This quota is either for an initial service connection, or for reauthorization when the original or last quota grant is depleted. The Quota Manager can provide a value ranging from 0 to 2,147,483,647 (0x00000000 to 0x7FFFFFFF). This value— called "quadrans"— comes in three forms: basis byte for volume-based billing, basis fixed for event-based billing, and basis second for duration-based billing.
When quota is depleted to zero, the subscriber can no longer access the service.
Quota is held on a per-service basis. Therefore, if a subscriber is connected to more than one service, the CSG2 stores quota for each service that is open.
After the subscriber finishes a session by closing the bearer session (a RADIUS Accounting Stop message is sent from a GGSN), the service is stopped, and any unused quota is returned to the Quota Manager.
While this prepaid system is in operation, the normal postpaid system runs by sending CDRs to the BMA.
CSG2 prepaid differs from CSG1 mostly due to the greatly reduced use of reserved quota. HTTP reserves a small amount of quota while processing a single TCP packet; other protocols do not reserve quota at all. This has the following benefits:
•
•
•
•
The following flow example describes a basic prepaid flow between the CSG2 and the Quota Manager:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Obtaining User IDs
The CSG2 uses two methods to obtain user IDs:
•
•
After identifying a subscriber, the CSG2 associates the subscriber's IP address with the user ID. If a quota server has been defined, the CSG2 tries to download the subscriber's profile. The profile indicates whether the subscriber is postpaid or prepaid and indicates the subscriber's billing plan. If the subscriber is prepaid, the CSG2 also downloads the subscriber's quota, and then forwards the subscriber's flows.
Filtering Accounting
Filtering lets you specify the following items:
•
•
•
The CSG2 supports Per-Event Filtering, which permits or denies a transaction as directed by the quota server.
To enable Per-Event Filtering, use the aoc enable command in CSG2 service configuration mode.
Intermediate Billing Records
Typically, the CSG2 sends two billing records for each HTTP session. The CGS sends one record for all non-HTTP sessions, when the sessions end. However, for long-lived sessions, you might want to monitor the progress of the session. To monitor long-lived sessions, you can configure the CSG2 to send intermediate billing records after a specified number of seconds, or after a specified number of bytes, whichever occurs first.
Intermediate counts are also correlated between the active CSG2 and the standby CSG2.
The CSG2 supports intermediate billing for FTP, HTTP, IP, SIP, TCP, and UDP. The CSG2 does not support intermediate billing for WAP or e-mail protocols (such as IMAP, POP3, and SMTP). The CSG2 does not support intermediate billing for RTSP control sessions unless the video/audio traffic is also transported over the control session.
Packet Forwarding
The CSG2 forwards client/server traffic using next-hop, as specified in the content. For example:
ip csg content FORWARD-INTERNET-TRAFFICip anynext-hop 1.1.1.1policy FORWARD_PKTinserviceIn this example, if traffic matches this content and policy, the CSG2 forwards the traffic to the next-hop router that has an IP address of 1.1.1.1.
The CSG2 supports next-hop packet forwarding for all protocols.
Note
URL-Redirect
You can configure the CSG2 to respond to an HTTP or WAP subscriber with a response code and a URL to which the subscriber must redirect. For more information about URL-redirect, see the "Configuring URL-Redirect" section on page 2-12.
Supplemental Usage Reports
You can configure the CSG2 to report supplemental usage to the quota server when sending a Service Stop, Quota Return, or Service Reauthorization Request message.
For more information, see the "Configuring Supplemental Usage Reporting" section on page 2-20.
Enhanced Interoperability with Cisco Service-Aware GGSN
The CSG2 can couple with a Cisco GGSN to form a service-aware GGSN. When operating in this mode, the CSG2 gets quota from the GGSN. For more information, see the Cisco GGSN Release 5.2 Configuration Guide.
There are no new commands required to enable enhanced interoperability.
Miscellaneous Features
The CSG2 provides the following miscellaneous features:
•
•
•
IP Fragment Support for All Protocols
The CSG2 supports IP fragmentation for all protocols, including fragments that arrive out of order.
There are no commands required to enable IP fragment support.
Support for Out-of-Order Packets for All Protocols
The CSG2 buffers packets that are received out of order, and processes and forwards them in the proper order.
There are no commands required to enable support for out-of-order packets.
Asynchronous Service Stop
The Asynchronous Service Stop feature allows the quota server to request the CSG2 to stop a prepaid service for a defined subscriber and service, and to send a Service Stop.
Support for Port Number Ranges
When you configure content on the CSG2, you can define a single port number, or a range of port numbers. This eliminates the need to configure a content for each port.
When defining a range of port numbers, choose a range that is applicable to the associated policies. For example, defining a range of port numbers from 80 to 8080 for parse protocol http means that the CSG2 must perform intensive HTTP inspection on many intermediate ports, ports that might not be expected to carry HTTP flows. HTTP inspection of such a high volume of non-HTTP flows can result in excessive processing by the CSG2, as well as generating many CDRs that the customer had not planned for.
Packet Counts
The CSG2 reports the number of IP bytes uploaded and downloaded, the number of TCP bytes uploaded and downloaded by the application, and the packet counts (or PDU counts for WAP records). These counts exclude the IP and TCP headers, as well as retransmissions.
Negative Quadrans
The quota balance in a prepaid service can become a negative value when the user's quota is being depleted, and the billing basis is byte ip or byte tcp. This can occur because the CSG2 forwards the entire received packet as long as the service's available quota is greater than 0. If the forwarded packet has more bytes than the quota balance, the balance becomes negative. Note that the CSG2 might report this negative balance to the quota server as a negative number in the Remaining Quota TLV.
Enhancements for Layer 2
The CSG2 processes "Hello" messages for Hot Standby Router Protocol (HSRP) version 1 and version 2.
If the MAC address of a directly-attached client is unknown, the CSG2 uses the Address Resolution Protocol (ARP) to get the IP address of the client dynamically. A "dummy" route for the client is no longer needed.
There are no commands required to enable these enhancements for Layer 2.
CSG2 Prerequisites
•
•
•
•
•
CSG2 Restrictions
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
–
–
–
–
•
•
•
