Overview
Available Languages
Table Of Contents
Enhanced Interoperability with Cisco Service-Aware GGSN
Configurable Reauthorization Threshold
Features from Previous Releases
Single CDR Support for WAP Connectionless and HTTP
Service-Level CDR Summarization
Prepaid/Envelope Support for SMTP
Advice of Charge and Related Features
User Profile Retrieval from RADIUS Access Accept or Accounting Request
User Cleanup on RADIUS Accounting Start
Processing Multiple RADIUS Accounting Stops
HTTP Pipelining and Chunked Transfer Encoding
HTTP Records Reporting Flexibility
Header Mapping and URL Mapping
Passthrough Mode and the Default Quota
Stateful Redundancy and Failover
Support for the Cisco Persistent Storage Device
Prepaid Content Billing and Accounting
Report Billing Plan ID to BMA and Quota Server
Support for Port Number Ranges
Learning Client IP Addresses Using Inspection of X-Forwarded-For Headers
Overview
The Cisco Content Services Gateway (CSG) is a high-speed processing module that brings content billing and user awareness to the Cisco Catalyst 6500 series switch or Cisco 7600 series router platforms. The CSG is typically located at the edge of a network in an Internet service provider (ISP) Point of Presence (POP), or Regional Data Center.
The CSG offers more than standard IP flow accounting; the CSG also examines various protocol requests (Wireless Application Protocol [WAP], Mail, FTP, RTSP, and HTTP) to gather URLs and other header information for accounting purposes. Additionally, the CSG gathers information on usernames and usage statistics, and enables differentiated billing for individual transactions based on hostname, on the directory accessed, or on individual files.
The CSG inspects IP traffic at levels deeper than typical routers. When doing so, the CSG behaves partly as a proxy server. As such, you should design your network security strategy to protect the CSG as you would any proxy or server.
This section includes the following information:
•
Features from Previous Releases
•
What's New
The CSG 3.1(3)C6(2) includes the following new features:
•
•
•
•
•
Additional features are described in the "Features from Previous Releases" section.
CSG Interface Awareness
Many provider networks offer data access, control over user addressing, and dedicated Virtual Routing and Forwarding (VRF) over the wireless network to enterprises and Mobile Virtual Network Operators (MVNOs). Interface awareness enables the CSG to distinguish between users and sessions that share the same IP address on different VLANs (that is, users and sessions with overlapping IP addresses).
The CSG binds contents to specific VLANs, and configures those VLANs with a table ID. When user packets match a content and a session is created, the CSG uses the table ID of the content as part of the user search. When a table is configured on a VLAN, the contents that are bound to each VLAN are associated with the table ID of that VLAN.
To support traffic segregation across VLANs, the CSG uses next-hop to bind flows to uplink and downlink routing hops. The CSG routes uplink packets (from the Network Access Server [NAS]) by applying next-hop policies to the contents on each NAS VLAN. The CSG routes downlink packets via the downlink address supplied by the NAS in the RADIUS accounting start message.
To associate a table name with a VLAN, use the table command in module CSG VLAN configuration mode.
To associate a table name with a particular RADIUS proxy or endpoint, use the radius proxy and radius endpoint commands in module CSG configuration mode.
Quota Push
This feature enables operators to "push" quota for a user or service to the CSG. This enables quota servers to provide quota for a user or service before traffic from that user or service reaches the CSG. This eliminates the delay that can occur when quota is obtained through a service authorization request and response. A sophisticated quota server could also use quota push for better control of quota levels during active sessions.
The CSG accepts a quota push for a user at any point after the user and billing plan are known to the CSG (that is, when a User Table element exists for the user). For example, the CSG accepts a quota push after receiving an accounting start but does not require an existing service for the user (one is created). The CSG does not begin charging against quota until traffic begins to arrive and a session is created. Zero-quota might be granted so that cause code and authorization actions can be set (for example, for a free service). A quota download message is sent to the BMA in response to receiving a quota push.
The service idle timer starts whenever quota is pushed, in case the expected traffic never arrives.
There are no commands required to enable quota push.
Tariff Switch
Tariff switch is a prepaid feature in which the CSG 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 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 CSG 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. The CSG 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 should choose the timeout carefully to avoid causing a flood of Quota Return messages at a given time. At any given time, the CSG 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.
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 CSG sends intermediate records to the BMA for transactions that span a tariff switch time and do not terminate quickly.
There are no commands required to enable tariff switch. The output of the show module csg accounting users all detail command displays information about the tariff switch.
Prepaid Support for POP3
The CSG supports prepaid billing for POP3. For basis fixed prepaid billing, the CSG treats each e-mail download as a transaction and a prepaid debit subject to weighting.
The CSG 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 CSG to provide refunding for POP3, specify return code 554 on the retcode command in CSG refund configuration mode for the POP3 refund definition.
Prepaid Support for IMAP
The CSG supports prepaid billing for IMAP.
There are no commands required to enable prepaid support for IMAP.
Transaction Support for IMAP
The CSG provides transaction support for IMAP. The CSG defines an IMAP transaction as a tagged response from an IMAP server that contains TEXT. TEXT is the part of the e-mail that follows the envelope; the presence of TEXT results in a classification of BODY. The CSG includes IMAP transaction counts in the Completed Transactions TLV. The CSG does not include any envelope information in the IMAP transaction CDRs.
For requests and responses that are not transactions (they do not contain TEXT), the CSG accumulates the bytes and includes them in the next transaction. When the IMAP session ends, the CSG reports any remaining bytes.
Consider the following simple example of an IMAP transaction with BODY:
Client request: 1 FETCH 5 BODY[]
Server response: * 5 FETCH (BODY[]{55}cr-lf-55-bytes-of-e-mail-followed-by-cr-lf)cr-lf
1 OK FETCH COMPLETE
The CSG handles this request and response as follows:
Step 1
Step 2
Step 3
Here is a more complicated example:
Client request: 8 FETCH 1:100 BODY[]<0.5>
Server response: * 1 FETCH (BODY[]<0> ". . . . . ")cr-lf
* 2 FETCH (BODY[]<0> ". . . . . ")cr-lf
* 3 FETCH (BODY[]<0> ". . . . . ")cr-lf
* 4 FETCH (BODY[]<0> ". . . . . ")cr-lf
...
* 100 FETCH (BODY[]<0> ". . . . . ")cr-lf
8 OK FETCH COMPLETE
The CSG handles this request and response as follows:
Step 1
Step 2
Step 3
The CSG categorizes bytes as BODY, HEADER, and OTHER, determined as follows:
•
–
–
–
–
–
–
–
–
–
–
•
–
–
–
–
–
•
–
–
–
–
–
To specify which IMAP bytes are billed for when doing prepaid debits (BODY only, BODY and HEADER only, or BODY and OTHER only), use the meter imap command in CSG service configuration mode.
Because IMAP metering is byte-based, you cannot configure both meter imap and basis fixed or basis second in the same service. Only basis byte is meaningful with meter imap.
If you specify basis fixed, each IMAP transaction counts as a quadran, subject to weights.
To specify that the CSG is to refund quota for IMAP quota for application return codes, use the retcode command in CSG refund configuration mode.
Note
Enhanced Interoperability with Cisco Service-Aware GGSN
The CSG can couple with a Cisco GGSN to form a service-aware GGSN. When operating in this mode, the CSG 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.
CSG RADIUS Proxy Enhancements
The CSG RADIUS interface recognizes the following Cisco-specific VSAs:
•
•
For RADIUS endpoint and RADIUS proxy configurations, you can prevent the CSG from acknowledging the following errors by entering the no form of the radius ack error command in CSG user group configuration mode:
1.
2.
3.
4.
5.
For errors 3, 4, and 5, the CSG can parse the configuration VSA from the Access-Accept. If the CSG uses any attribute from the Access-Accept that does not match the CSG configuration, the CSG does not send a RADIUS response to the Accounting Request.
For RADIUS accounting requests processed as a result of matching a radius endpoint command, the CSG does not send a RADIUS acknowledgement.
For RADIUS accounting requests processed as a result of matching a radius proxy command, the CSG does not forward the Accounting Request to the RADIUS server.
Supplemental Usage Reports
You can configure the CSG to report supplemental usage to the quota server when sending a Service Stop, Quota Return, or Service Reauthorization Request message. The supplemental usage data reports the uploaded bytes, downloaded bytes, usage time in seconds, and time stamps for the first and last billable sessions. The data is incremental from the last report.
If a tariff switch timeout occurs during the interval, the CSG sends the tariff switch TLVs along with the supplemental usage TLVs. The supplemental usage TLVs cover the data from the tariff switch time to the end of the interval.
Supplemental usage reporting always reports IP bytes, even if the billing basis is configured for TCP bytes.
To enable supplemental usage reporting, use the report usage command in CSG accounting configuration mode.
Quota Balance Replacement
By default, when the CSG receives a quota grant from the quota server, the CSG adds the granted quota to the current balance for a subscriber's service. Quota balance replacement enables the quota server to instruct the CSG to replace the current quota balance with the amount of granted quota for a subscriber's service. Note that if the replacement grant is provided in a Service Authorization Response, the CSG subtracts the amount of quota used since the Service Reauthorization Requests from the granted quota before replacing the balance.
There are no commands required to enable quota balance replacement.
Delayed Quota Reauthorization
The CSG accepts the Reauthorization Delay TLV, which specifies the number of seconds the CSG delays its next reauthorization request to the quota server for the service specified in the message. This TLV also specifies the action the CSG is to take for the service between the time the message is received and the next reauthorization:
•
•
Note
Quota servers can use delayed quota reauthorization to deny subscribers access to CSG categories without having to continually deny authorization requests (that is, for blacklisting services). To do so, the quota server sends a grant of 0 quadrans in a Service Authorization Response, Quota Push Request, or Service Verification Response message, with a long reauthorization delay timer (0xFFFFFFFF), a Deny action, and a cause code of 0x03.
There are no commands required to enable delayed quota reauthorization.
Configurable Reauthorization Threshold
You can configure the thresholds of available quota that trigger service reauthorization by specifying the following CSG variables on the variable command in module CSG configuration mode:
•
•
•
You can configure the thresholds for volume-, time-, and transaction-based billing, and the CSG can also accept a threshold specified by the quota server in a quota grant to the CSG.
Enhanced Quota Reconciliation
During internal quota reconciliation, the CSG might drop packets for some prepaid users, which can affect user throughput.
To prevent this problem, set the CSG_QUOTA_BLOCK environment variable to 0, using the variable command in module CSG configuration mode. Setting this variable to 0 enables the CSG to forward packets for a prepaid user during quota reconciliation, regardless of whether quota is available for the user. When quota reconciliation is complete, if the CSG determines that the user has no quota available, the CSG terminates the connection.
The CSG supports enhanced quota reconciliation for all accounting types.
If you want the CSG to continue to drop packets that arrive during quota reconciliation, set the CSG_QUOTA_BLOCK to 1. This is the default setting.
Features from Previous Releases
In addition to new features introduced in this release, the CSG provides the following features and functionality that were introduced prior to the CSG 3.1(3)C6(2):
•
•
•
•
•
•
CDR Support
The CSG provides the following Call Detail Record (CDR) support:
•
•
•
Fixed CDR Support for HTTP
The CSG provides fixed CDR support for HTTP as well as for WAP. This support generates one fixed CDR for every HTTP transaction, instead of two CDRs that are typically generated at the beginning and end of the transaction.
The single CDR contains all fields included in the HTTP header and HTTP statistics records, in a fixed format. In addition, the same fixed format service TLVs that were included for WAP are also included for HTTP.
The single CDR also includes RADIUS TLVs, in ascending order, based on the RADIUS TLVs configured using the report radius attribute command in CSG accounting configuration mode. This is a change from the CSG 3.1(3)C5(1), in which you hard-coded up to 10 specific RADIUS attributes which were included in the CDR in a predefined order. This scheme is very flexible, enabling you to add RADIUS attributes as you go. This change in the handling of RADIUS TLVs applies to both WAP and HTTP fixed CDRs.
Fixed CDR support does not support RADIUS attribute 26 (the Vendor-Specific Attribute, or VSA), because the list of attributes defined within the VSA is in itself variable. Therefore, a predefined "fixed" list of attributes cannot be determined when RADIUS attribute 26 is configured.
To enable the fixed format feature for HTTP and for WAP, use the records format fixed command in CSG accounting configuration mode.
The CSG also supports fixed HTTP intermediate records. The fixed intermediate record format is identical to the format of the fixed record created at the end of the transaction, except for the message type, which is necessary to differentiate the two records. The intermediate statistics, such as TCP byte counts, are per intermediate period, and are not cumulative. This differs from the existing HTTP intermediate support for variable format CDRs, in which the TCP byte counts are cumulative.
The Content Delivered TLV contains a value of 0x00 (not delivered) if the HTTP response code is greater than or equal to 400, or if the TCP byte download count is less than 12 bytes.
Fixed CDR Support for IMAP
The CSG now supports postpaid billing for the Internet Message Access Protocol (IMAP), in addition to postpaid billing for Post Office Protocol, version 3 (POP3) and Simple Mail Transfer Protocol (SMTP). This feature enables the CSG to report service-level fixed format CDRs for IMAP. The service-level CDR includes the following IMAP-specific counts:
•
•
•
•
•
•
•
•
•
•
The CSG 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 CSG generates intermediate CDRs every 15 minutes, then the CSG reports the delta of the total byte count from the point in which the last CDR was reported to the point at which the current CDR is reported. So, the first CDR would report 100 KB and the second would report 50 KB.
With fixed format CDRs, they 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.)
To enable the CSG to support IMAP, use the records format fixed command in CSG accounting configuration mode, and the accounting type imap command in CSG policy configuration mode.
When configuring CSG support for IMAP, keep in mind the following considerations:
•
•
•
Fixed CDR Support for RTSP
This feature enables the CSG to send the existing RTSP stream CDRs in a fixed format. The same fixed format service TLVs that were included for WAP are also included for RTSP.
To enable the fixed format feature for RTSP, use the records format fixed command in CSG accounting configuration mode.
Single CDR Support for WAP Connectionless and HTTP
The CSG already reduces the multiple CDRs generated for WAP connection-oriented traffic down to a single CDR, which is reported at the end of the transaction. This feature is extended to WAP connectionless traffic and HTTP traffic.
The single CDR contains the standard variable format, and it also includes a comprehensive list of TLVs containing all pertinent information for the transaction. For WAP connectionless transactions, it includes everything that is included in a WAP GET and REPLY CDR. For HTTP transactions, it includes everything in the HTTP header and HTTP statistics records.
To enable single CDR support for WAP connection-oriented, WAP connectionless, and HTTP traffic, use the variable-single-cdr keyword on the records format command in CSG accounting configuration mode.
When you configure single CDR support, the CSG suppresses HTTP intermediate record generation.
Service-Level CDR Summarization
By default, the CSG generates billing records for each transaction. This has the potential to overwhelm the charging gateway (CG) or the collector. To prevent this situation, the CSG can summarize CDRs at the service level, instead of at the transaction level.
For example, if a user is accessing the open Internet service, and the data is billed solely on the basis of volume, generating records for each HTTP transaction is of little use. With service-level CDR summarization enabled, the CSG generates only consolidated records containing service-level usage. Information from individual events is no reported (for example, no URLs).
The CSG supports the following protocols in both fixed and variable format: IP, HTTP, SMTP, POP3, and IMAP. (POP3 and IMAP are supported in postpaid mode only.)
Service-level CDRs are generated only for subscribers with entries in the CSG User Table entry. If a subscriber does not have an entry in the User Table, the CSG generates transaction-level CDRs.
To enable service-level CDR summarization, use the records granularity command in CSG service configuration mode.
Note
Prepaid/Envelope Support for SMTP
The CSG provides SMTP postpaid and prepaid support, including the addition of 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 mail envelope information as well as IP byte counts, TCP byte counts, and mail data (X-CSG-SIZE) byte counts for each mail message. When multiple e-mails are sent over a single TCP connection, each mail message is assigned byte counts until the start of the next mail message. The last mail is assigned bytes from the start of that 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 mail message. If the CSG 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 mail not being sent). If the CSG receives a QUIT before receiving any return code, it reports a default return code of 554 (Transaction failed). This enables the CSG to apply refunding via the SMTP return code value.
If the user 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 mail was received, and the authentication failure bit is set in the TCP flags field.
The CSG no longer uses the TCP Stats CDR, which was generated at the end of the TCP connection, because the information in the TCP Stats CDR duplicates the information in the SMTP CDR.
Fixed Attribute CDRs for WAP
In support of some legacy billing systems, the CSG provides a fixed attribute format for WAP CDRs. The same set of attributes are reported in each CDR regardless of 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.
Advice of Charge and Related Features
Advice of Charge (AoC) is a function that enables a service provider to provide messaging and authorization prompts to its subscribers. The CSG's support for AoC uses a quota server and a customer-provided notification server to host the actual messaging:
•
•
The CSG's role in the AoC process is to redirect user data requests to the notification server. The CSG provides two modes for redirecting to the notification server. The choice of mode, and the requirements that mode imposes on the notification server, varies by protocol. The two modes supported by the CSG are:
•
•
A complete AoC implementation depends heavily on the notification server. With URL-redirect, the notification server can be a standard Web server, because the CSG does the redirection at the protocol level. This is the easiest deployment to implement. With NAT-redirect, the CSG just forwards the connection directly to the notification server. The notification server must therefore be able to accept the packets, interpret the protocol, drive an AoC on its own, and properly manage the rest of that user's flow for that connection.
The CSG allows the redirection for AoC to be triggered once per service (when the first access to the service is made by the subscriber), or at the start of any new data transaction. The former is accomplished using the CSG's service verification function, the latter using the CSG's content authorization function. The URL can be pre-configured, or it can be provided dynamically by the quota server (the more flexible option). You can configure content authorization to request a pass/fail authorization for any transaction (for example, for individual SMTP e-mails), but the CSG does not honor redirect requests from the quota server in the middle of a TCP connection.
In general, the method by which the notification server communicates success or failure of the AoC to the quota server is outside the scope of the CSG's role in the process. However, the CSG does provide some additional assists for URL-redirects that greatly ease the burden on the backend systems. For example, the CSG provides the ability to strip trailing tokens from a URL. Therefore, an HTTP-based notification server can be deployed such that it will append the results of the AoC to the user HTTP request when redirecting the subscriber to the final requested content. The CSG reports this URL, token and all, to the quota server on the next content authorization request. If configured to do so, upon successfully receiving permission from the quota server to forward the flow, the CSG strips the token from the request so that the content server is not confused by the extra data.
You can instruct the CSG to get authorization from the quota server for each subscriber request for content.
The CSG's support for AoC has the following restrictions:
•
•
•
•
To enable the CSG's support for AoC, use the authorize content command in CSG service configuration mode.
The CSG provides the following AoC-related features:
URL Redirect
In a redirect scenario, the CSG responds to the HTTP or WAP client with response code and a URL to which the client should redirect. You can configure the redirect URL using the redirect command in CSG user group configuration mode, or the quota server can provide the redirect URL during service authorization (or reauthorization) or content authorization processing.
In the case of service authorization or content authorization, the quota server reply contains the REDIRECT-URL action code and the redirect URL. In some network configurations, you might want the quota server to return a single redirect URL for both WAP and HTTP. If you do not want to use a single redirect URL, the service authorization and content authorization requests identify whether the request is for HTTP or WAP.
A redirect URL returned from the quota server in a service authorization response, or in a content authorization response with the REDIRECT_URL action code, takes precedence over a redirect URL that is configured using the redirect command. The CSG uses the redirect-specified URL when the quota server responds with the FORWARD action code.
To control the amount of time and the number of redirects that the CSG allows, specify the following environment variables using the variable command in module CSG configuration mode:
•
•
The CSG starts the interval timer when the first request is redirected after it has received no quota. This counter is reset, and the timer is stopped after another quota grant of zero is given.
For example, if CSG_REDIRECTS_MAX is set to 15 and CSG_REDIRECTS_INTERVAL is set to 8 seconds, and you receive a Service Auth Response with zero quadrans, and you have redirect information, then redirection occurs when you run out of quota (assuming you have not received quota since). The CSG_REDIRECTS_INTERVAL 8-second timer starts after your first redirect. Therefore, request 1 is redirected, and up to 14 more requests can be redirected, if they occur within the 8 seconds after the first redirect.
URL Rewriting
When direct communication is not possible between the quota server and the notification server, payment decision information can be shared indirectly by modifying the URL in the client request. The notification server appends a string beginning with a token to the originally requested URL and sends it to the client as part of a redirect reply after the client has agreed to pay. The CSG receives the subsequent GET request containing the rewritten URL and sends it to the quota server in a content authorization request. The quota server recognizes the token string and understands that the client has agreed to pay for the request. It responds to the CSG with a FORWARD action code in the content authorization response. The CSG detects the token, creates a new GET request containing the original URL with the token and any characters following it removed, and sends the GET on behalf of the client. The token must be known by the CSG, the quota server, and the notification server. It is administratively defined on the CSG using the CLI. The token should be chosen carefully to ensure that it is only present in URLs rewritten by the notification server and not in other client requests.
The CSG supports URL rewriting for HTTP, WAP 1.x, and WAP 2.x.
To define a URL-rewriting token for CSG, use one of the following commands in CSG user group configuration mode:
•
•
WAP URL Appending
Whenever a content authorization response contains a REDIRECT_URL action code for a WAP content authorization request, the CSG can optionally append the originally requested URL to the one returned by the quota server.
For example, if the client originally requested the following URL:
http://www.yahoo.com/home.wml
and the quota server returns the following URL in a REDIRECT_URL content authorization response:
http://www.yahoo.com/charges.wml
then the CSG would send the following URL as part of a redirect message to the client:
http://www.yahoo.com/charges.wml?www.yahoo.com/home.wml
The default behavior is to pass the redirect URL to the client as specified by the quota server without modification.
To enable WAP URL appending, set the CSG_WAP_APPEND_AOC_URL environment variable using the variable command in module CSG configuration mode.
SMTP Content Authorization
The CSG handles content authorization for SMTP in a slightly different manner than for other protocols.
Typically, the CSG sends the content authorization request immediately after performing service authorization. The CSG can do this because all of the information in the content authorization request is contained in the initial flow received by the CSG.
However, for SMTP, the information needed in the content authorization request—number of recipients with a good return code, number of recipients with a bad return code, size of mail in bytes (if present) and the sender of the e-mail—are not known until after the CSG processes the SMTP envelope. Therefore, when content authorization is configured, the CSG allows all envelope information to flow through, even if the user has no quota (however, access is not permitted if the user is not authorized). The CSG initiates the content authorization request when it receives the DATA command. The CSG queues the packet containing the DATA command until content authorization processing is resolved.
If the CSG receives a DROP or REDIRECT in the content authorization response, it drops the DATA command packet, terminates the session, and generates a CDR containing the envelope information and an invalid application return code.
If the CSG receives a FORWARD, it uses the weight that is returned in the response for prepaid processing.
Multiple e-mails over the same TCP connection result in multiple content authorization requests. Each mail is treated as a separate transaction.
To enable content authorization for SMTP, use the authorize content command in CSG service configuration mode.
Redirect Flexibility
A quota server can request a redirect for multiple reasons (for example, top-up, "sorry" indication, login request, and so on). The CSG allows the quota server to return the IP address and port number for each redirect. Thus, a different port number, or even a different server, can be used for every reason that the quota server might request the redirect. The CSG stores the most recent redirect address and port number for each service under each user, and uses that address and port instead of the globally defined default.
Service Verification
Service verification is a capability like AoC, provided the first time a user accesses a service using HTTP or WAP. A Service Verify Request quota management message supplies the quota server with content from the user request (the URL, header information, user agent, and so on). The quota server responds with a Service Verification Response that includes a decision to redirect the request to a notification server, to forward it, or to drop it.
Service verification provides the same URL-rewriting capabilities that are provided by AoC. An administrator uses CLI to define the service confirmation token that is used in URL-rewriting.
To enable or disable service verification, use the verify command in CSG service configuration mode. Service verification is also disabled when the quota server sends a Service Verify Tag-Length-Value (TLV) in a Service Authorization Response or Service Verification Response.
Service verification is supported only for HTTP and WAP.
As long as service verification is enabled, sessions of any type for this user do not trigger service reauthorization requests. Service reauthorization resumes for the user when service verification is disabled.
Service verification supports forward, redirect-URL, and drop authorization action codes sent in a Service Verification Response. Service verification also supports optional downloading of quota for a user in a Service Verification Response. The CSG sends service verification requests even when no quota is supplied in the Service Verification Response, if the service authorization response contains the cause TLV with value 0x04 (user low on quota, but service access is permitted). Quota Download Call Detail Records (CDRs) are sent to the BMA, as appropriate, whenever the quota server supplies quota in a Service Verification Response.
Service verification can be used in conjunction with existing AoC functionality.
RADIUS Features
The CSG provides the following RADIUS features:
•
•
•
See "Configuring RADIUS Support: Learning Who the Subscriber Is" section for more information on configuring RADIUS features.
User Profile Retrieval from RADIUS Access Accept or Accounting Request
The user profile (billing plan) can be specified in a RADIUS message using the Cisco subattribute 1 VSA. The format of the VSA is:
csg:billing_plan= billing_plan_name
The billing_plan_name can be null, to indicate a postpaid user. Otherwise, the billing plan name must be sent as an uppercase string to match a configured billing plan on the CSG.
The billing plan is included in the RADIUS Access-Accept or RADIUS Accounting-Request message.
If the RADIUS Access-Accept includes the billing plan, the user ID (RADIUS attribute 1 or 31, as configured) must also be included; otherwise, the CSG is not able to associate the billing plan with the user.
Use the user-profile server radius command to retrieve the billing plan from the RADIUS message.
Reporting RADIUS Attributes
You can specify a set of attributes to be extracted from RADIUS Accounting Start messages for each subscriber, and reported with each transaction record. The CSG reports these attributes to the BMA and to the quota server. The CSG extracts these attributes from the RADIUS Accounting Start, and refreshes (replaces) its stored attributes whenever a RADIUS Interim Accounting message is received, to ensure that the latest user information is stored.
You can use Arbitrary RADIUS attributes to understand where a user is connecting to the network, and for correlation purposes. Examples of these attributes and their uses include:
•
•
•
The attributes are configured by their standard number, as shown in the following example:
ip csg accounting USER-BMA1user-group GROUP1agent activate 2 sticky 30agent 210.0.0.102 3386 1report radius attribute 3report radius attribute 5report radius attribute 7report radius attribute 44inserviceYou can specify as many attributes as you want. If you specify so many attributes that the total message size is greater than a single UDP packet, the CSG supports continuation messages. A continuation message includes a correlator, a continuation number (so messages received out of order can be reordered), and an indication of the final message.
Note
If the configured attributes change, only new RADIUS requests are subject to the new attributes. Attributes already saved for a user continue to be reported.
When a RADIUS Start request is received, any attributes received from a previous Start request are deleted. If there are multiple instances of an attribute, they are all reported. Attributes are reported in the order they exist in the RADIUS message.
User Cleanup on RADIUS Accounting Start
A subscriber's connectivity attributes might change over time without a RADIUS Accounting Stop arriving to close down the previous accounting. Instead, it is possible that a new RADIUS Accounting Start or Interim Accounting message might arrive with the updated information. Some customers might choose to close all of the user's services if a significant change has occurred in the user's status.
With the radius start restart session-id command configured, the CSG deletes the user entry as if it had received a stop, closes all of the subscriber's services, and creates a new entry.
To avoid deleting the user entry because of a retransmission of the RADIUS message, the radius start restart session-id command specifies an attribute to detect duplicate messages. If the contents of the attribute in the message match the contents of the previous message, the existing entry is not deleted.
Processing Multiple RADIUS Accounting Stops
For enhanced network connectivity options, such as secondary packet data protocol (PDP) contexts, the NAS sends multiple RADIUS Accounting Stop messages. In the case of secondary PDP contexts, for example, the NAS sends a RADIUS Accounting Stop as each context is terminated.
The CSG removes the subscriber from the User Table when it receives the final stop, which contains an attribute indicating it is final. The CSG support for this functionality allows the specific attribute to be configured. If this function is configured, the CSG processes only the RADIUS Accounting Stop that contains the configured attribute. The contents of the specified attribute are not examined.
RADIUS Monitor
RADIUS monitor provides a way to insert the CSG into the RADIUS flow without changing the authentication, authorization, and accounting (AAA) or Network Access Server (NAS) addresses in the network. The CSG monitors the traffic between the RADIUS client and the RADIUS server, and watches for RADIUS messages flowing through it that match the configured rule. The address of the server must be configured.
Optionally, a RADIUS key is configured. If the key is configured, the CSG parses and acts on the message only if the RADIUS Authenticator is correct. If the key is not configured, the CSG always parses the message. The message is forwarded regardless of the key being configured or correct.
Here is a sample configuration:
ip csg user-group U1radius userid User-Nameradius monitor 10.2.3.4 1234 key cisco --> Address, Port, and Key for RADIUS AAA Server.radius monitor 10.2.3.9 1234 key cisco2radius monitor 10.2.7.4 3901 key cisco --> Multiple AAA destinations can be monitored.All RADIUS messages, including Access messages, are forwarded, except when the IP or UDP headers specify a length larger than the physical packet size.
All RADIUS messages, including access messages, are forwarded, except when the IP or UDP headers specify a length larger than the physical packet size.
When configuring RADIUS monitor for a server that is in the same subnet as a CSG interface, you must first configure a dummy route for that server, such as:
route ip-address 255.255.255.255 gateway gw-ip-address
where:
•
•
Add a RADIUS monitor configuration only after you have added the dummy route.
RADIUS Endpoint
To configure the CSG as a RADIUS Accounting endpoint, and to use RADIUS PoD with RADIUS endpoint, use the radius endpoint command in module CSG configuration mode.
To support RADIUS endpoint, the CSG requires a route to 255.255.255.255. You can configure the route by using the gateway (module CSG VLAN) command or the route (module CSG VLAN) command. For example:
gateway 31.0.0.6
or:
route 255.255.255.255 255.255.255.255 gateway 31.0.0.6
RADIUS Proxy
The CSG can act as a RADIUS proxy, forwarding all RADIUS accounting messages it receives to a configured RADIUS server. When the RADIUS server acknowledges a message with an ACK, the CSG forwards the ACK back to the client. RADIUS proxy supports both RADIUS Access and RADIUS Accounting.
The CSG allows you to specify only one RADIUS server, and the same RADIUS password must be used throughout.
RADIUS proxy can operate with clients that use large numbers of port numbers. The RADIUS client sends messages to the configured CSG (virtual) address. The CSG accepts messages for all ports on the configured address. The address of the RADIUS server is also configured. Optionally, a RADIUS key is configured. If the key is configured, the CSG parses and acts on the message only if the RADIUS Authenticator is correct. If the key is not configured, the CSG parses the message with no conditions. The message is forwarded regardless of the key being configured or correct.
All RADIUS messages (including Access messages) are forwarded except when the IP or UDP headers specify a length larger than the physical packet size.
To configure a CSG as a RADIUS proxy, use the radius proxy command in module CSG configuration mode. Keep in mind the following considerations:
•
•
•
•
•
RADIUS Handoff
In networks that do not use Cisco Home Agents (HAs), the CSG's RADIUS handoff feature can manage handoffs for roaming users.
The User Table identifies all users known to the CSG. The 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. When RADIUS handoff is configured, and a RADIUS Accounting Stop is received, the CSG starts a handoff timer instead of deleting the CSG User Table entry for the roaming user immediately.
•
•
•
To configure RADIUS handoff support, use the radius handoff command in CSG user group configuration mode.
RADIUS Packet of Disconnect
The quota server can instruct the CSG to disconnect a user. The CSG then sends a RADIUS Packet of Disconnect (PoD) message to the NAS identifying the user, and the NAS then sends a RADIUS Accounting Stop message, which also clears the User Table entry.
The quota server instructs the CSG to disconnect a user using one of the following methods:
•
•
–
–
–
The CSG sends the PoD message to the NAS that is specified by the NAS-IP-Address attribute (4) in the Accounting Start.
To configure RADIUS PoD support, use the following commands in CSG user group configuration mode:
•
•
•
The CSG can send PoD messages only if the CSG received the user information on a virtual interface configured using the radius proxy or radius endpoint command in module CSG configuration mode.
HTTP Features
The CSG provides the following HTTP features:
•
•
HTTP Pipelining and Chunked Transfer Encoding
The CSG supports full HTTP pipelining and chunked transfer encoding.
Support for full HTTP pipelining and chunked transfer encoding required extensive redesign of the TCP engine and of HTTP parsing, which in turn impacted the way the CSG counts bytes. For HTTP billing, the CSG reports only TCP byte counts. To maintain backward compatibility, the CSG still reports IP byte counts, but the values reported are the same as the TCP byte counts. 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 CSG, and a failover occurs, the CSG does not increment the content counters for traffic flowing through these connections. The CSG 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 CSG 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.
HTTP 1.0 Content Billing
The CSG enables you to bill users for individual transactions by discriminating on a per-object basis, and on a per-user 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 end user.
HTTP 1.1 Content Billing
The CSG records each request over a persistent HTTP 1.1 session separately.
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 (as well as by IP address) immediately, without having to wait for the HTTP Statistics record.
You can configure the CSG to send the HTTP Header message as soon as it is generated, rather than batching it until an entire packet is filled. This reduces latency and notifies the BMA about the client's transaction as quickly as possible. This type of reporting is more efficient, but provides less information, and should be used only when the BMA needs to react to the client's activity very quickly.
You can configure the CSG to not send the HTTP Statistics message. This 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 CSG 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 CSG reports HTTP-specific information about the request, such as the URL, as well as HTTP error codes (that is, response codes of 300 or higher).
WAP Features
The CSG provides the following WAP features:
WAP Traffic
The CSG 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 CSG supports WAP 2.0—a specific dialect of XML that can be transported over HTTP to convey content to the mobile devices. The incomplete WAP 2.0 standard specification defines five network flows in which mobile devices might participate. The first four flows described below are generally implemented over WAP 2/HTTP/TCP across a WAP 2.0 Proxy/Push Proxy Gateway (PPG). The last flow (Flow number 5, TO-TCP) is not supported.
General flows supported in the CSG
1.
2.
3.
Push flows generally implemented as WAP 2 over SMS OTA-Push
These flows are generally implemented as WAP 2/SMS rather than WAP 2/HTTP.
4.
5.
Note
The CSG supports billing WAP 2.0 traffic (the first three flows above) using existing configuration commands. WAP 2.0 mobile devices might be configured to use or to ignore the WAP 2.0 proxy; 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 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/HTTP and MMS/WAP 2.0/HTTP.
Differentiated Billing of MMS Over WAP 2.0
WAP 2.0 mobile devices generally implement support for extensive Multimedia Messaging Service (MMS). This is generally implemented over WAP 2.0. Service providers use MMS to differentiate and promote their products, which necessitates differentiating the billing of MMS over WAP 2.0 from other WAP 2.0 billing.
The CSG supports the ability to bill MMS over the supported WAP 2.0 flows at a differentiated rate. When WAP 2.0 billing is configured, MMS might be differentiated by using the capabilities of the http accounting type to detect some or all of the following characteristics of MMS/WAP 2/HTTP traffic:
•
•
•
MMS over WAP 2.0 allows the following three types of notification:
1.
2.
3.
The CSG Layer 7 billing for MMS relies entirely on options one and three. TO-TCP is not supported.
Note
WAP Cutoff
When a user's quota is entirely depleted in the middle of a transaction, the corresponding action varies depending on the protocol. For WAP, the current transaction is allowed to complete, and the user is charged for all bytes used in the transaction. The result is that the user has a negative quota balance. On the next transaction request, the user is redirected to the top-off server. While this behavior provides the best user experience, it also allows some leakage. For small transactions, the leakage is minimal; however, for large transactions the leakage can be significant.
Because there is a trade-off between end-user experience and leakage, a CSG configuration option allows you to choose what behavior you want to enforce. To configure this feature, enter the zero-quota abort type command in global configuration mode. The configuration option is enabled on a per-service basis. This option is only supported for WAP, and the default is to not terminate a transaction midstream when the user runs out of quota. For all other protocols, the user is cut off midstream.
Note
When configured, this condition causes the existing transaction to be aborted. The CSG sends aborts to both the client and server, terminating the transaction. A BMA record for the transaction is generated with a flag setting in the Wireless Transaction Protocol (WTP) information record that indicates the transaction was intentionally aborted. In the report, the user is charged for the number of bytes that were processed for the transaction, including the bytes that caused it to exceed the quota balance. Typically, the user should not be charged for this transaction because it was not allowed to complete. The user is reimbursed by the billing agent for transactions with the 0x04 flag set, or by the prepaid refund feature.
Concatenated WAP PDUs
The CSG 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 should be assigned. Here is how the CSG assigns the IP bytes:
•
•
•
For example, a CONNECT/GET concatenated PDU that contains one-byte PDU length fields yields the following byte count totals:
•
•
RTSP Features
The CSG provides the following Real Time Streaming Protocol (RTSP) features:
RTSP Billing
The RTSP Billing feature adds the following functionality to the CSG:
•
•
RTSP uses four different protocols for streaming to the client. The client presents the server with a choice of acceptable protocols and port numbers, 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 CSG sends a contentAuthorizationRequest at the beginning of the TCP session. For each transaction involving a data stream, the CSG sends a contentAuthorizationRequest before allowing the data stream. This request allows the quota server to inspect the filename before granting authorization.
The CSG only allows Network Address Translation (NAT-based) redirection for RTSP traffic.
RTSP allows multiplexing multiple data streams over the same transport. For example, audio and video presentations can be multiplexed over the same UDP flows. In these cases, the quota server must ensure that it does not send contradictory responses to the various contentAuthorizationRequests. For example, if one request is allowed and the other one denied, the CSG's behavior is undefined.
Correlation
The CSG provides RTSP correlation at the RTSP session level. All TCP/UDP flows associated with an RTSP session share a correlator.
The CSG 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 audio and video stream for a movie. For instance, if M is the media server, a client (C) can perform the following operations over the same RTSP session:
In this example, all the streams share the RTSP session and the session ID. There is one RTSP control TCP session, and four UDP streams associated with it. The CSG is able to correlate all these four UDP streams together 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 CSG has no easy way to find out that these two streams are related. A typical situation is when 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. The following interactions take place:
In the previous example, there are three concurrent sessions:
•
•
•
All of the sessions (TCP and UDP) 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 no correlation 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 end-user presentation are present. A container file represents an RTSP presentation, with each of its components being RTSP streams. 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 describing the contents of a container file.
The CSG does not correlate the streams within a container file.
Interleaved RTSP
Interleaved RTSP passes RTSP data in the TCP control session. Because the CSG parses the control session, it could cause a large performance bottleneck.
To avoid a bottleneck, the CSG does the following for interleaved RTSP sessions:
•
•
•
This method provides some RTSP level information, but avoids making the RTSP path a target of DoS attacks. If most of the RTSP streaming billing applications are in the walled garden, customers have some control over the servers to ensure that the use of interleaved RTSP is not too much.
CDRs
The CSG generates the following the CDRs for RTSP:
•
•
•
Note
RTSP billing in the CSG is based on inspection of the RTSP SETUP and TEARDOWN messages that are exchanged between the client and server. The CSG builds the RTSP CDR immediately after the RTSP TEARDOWN signal if the URL exactly matches that from the RTSP SETUP signal. Otherwise, the CSG builds the CDR after any condition that causes the flows to be terminated. Examples include:
•
•
Session Processing
RTSP control session processing is similar to FTP control sessions. The RTSP control session is assigned an 8-byte correlator. 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 CSG keeps track of RTSP sessions and an RTSP session is used to correlate multiple streams associated with the session.
Note
When the client sends a setup command, the CSG notes the client ports and extracts server ports 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 CSG actions are annotated after various steps.
In this example, client C requests a presentation from 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 CSG makes sure that X+i is even. 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 the various flows for an RTSP transaction together, and also enable 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, so the CSG lets the streams idle out and sends usage records when the streams idle out.
POP3 Support
The CSG 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 CSG no longer generates a final TCP Stats record. If a user downloads multiple e-mails during a single TCP session, the CSG generates a CDR for the previous e-mail each time it processes a new RETR or TOP command. The CSG generates a CDR for the last e-mail when it processes the STATS command (for TCP termination).
The CSG supports POP3 in both prepaid and postpaid mode.
If a user tries to download e-mail and no e-mail exists, the CSG generates a POP3 CDR that contains an application return code TLV with a value of 554. This is the only condition in which the CSG includes a non-zero return code in a POP3 CDR.
To define the POP3 accounting type for a billing policy, use the accounting type pop3 command in CSG policy configuration mode.
SMTP and POP3 Data Mining
SMTP is the Internet mail transfer protocol that operates over TCP with port 25. End users send messages using SMTP, and it is also used to transfer messages between SMTP gateways (or relays). POP3 is a common protocol used to retrieve Internet mail from a mail server. POP3 also operates over TCP and typically uses port 110.
SMTP and POP3 messages consist of the following parts:
•
•
•
The CSG 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, with the exception of 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 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 CSG 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 CSG Report String Attribute reports also has a continuation option. This means that information for a single header might span multiple CSG Report String Attribute reports which might span multiple CSG Data Records.
Note
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 Mapping and URL Mapping
The CSG uses maps to match headers or URLs against a pattern, to determine whether flows are to be processed by the CSG accounting services.
•
•
Passthrough Mode and the Default Quota
For prepaid users, when a quota server is not available for authorization grant of quota, sessions are blocked. In passthrough mode, the CSG grants quota for services and their sessions when a quota server is not available. The CSG allows all traffic to pass, and CDRs are flagged for special consideration by the BMA.
For each service that you want to use passthrough mode, you must enable it using the passthrough command in CSG service configuration mode.
If you enable passthrough mode for a service, do not disable quota server reassignment for user groups associated with that service. That is, do not configure no quota server reassign in CSG user group configuration mode for user groups associated with the service.
You also use this command to specify the size of each quota grant (the default quota) to assign to a service. When passthrough mode is enabled for a service, and a session for a service needs quota, and no quota server is active, the CSG grants the service the amount of quadrans specified on the passthrough command. (There are three types of quadrans: basis byte for volume-based billing, basis fixed for event-based billing, and basis second for duration-based billing.) The CSG continues to grant quota as long as a quota server is inactive.
When the service becomes idle, the CSG generates and stores a ServiceStopRequest message, containing the total usage for this instance of the service. When a quota server becomes active, the CSG forwards all stored ServiceStopRequest messages to the quota server.
This section contains the following additional information about passthrough mode:
Flagging of Messages
To facilitate billing recovery, some messages to the quota server and the BMA include a QuotaServerFlags TLV. The CSG adds this TLV whenever it grants a passthrough mode quota to a service.
User Profile Requests
When the CSG learns of new users, it typically sends a UserProfileRequest to an active quota server. This enables the CSG to learn the billing plan to use for each user. If the quota server returns a NULL billing plan, a user is postpaid.
When passthrough mode is in use for any service, the CSG changes the way it processes UserProfileRequests. When there is no active quota server, the CSG assigns all new users to postpaid processing. The CSG reports all sessions for these users as postpaid, and does not flag generated CDRs with a QuotaServerFlags TLV.
If a user is still on the network when the quota server becomes active, the CSG sends a normal UserProfileRequest to the quota server for the user. When the CSG receives a response, it updates the user's billing plan. If the updated billing plan is now a prepaid billing plan, the CSG blocks new IP sessions started by the user until the quota server grants a quota. IP sessions that were active before the billing plan was updated to prepaid are kept as postpaid, and generate postpaid CDRs until they end.
Quota Server Recovery
When a quota server becomes active, the CSG forwards stored ServiceStopRequests to it. Additional actions taken by the CSG depend on user traffic.
When a user who was forced to postpaid while the quota server was absent creates a new IP session, the CSG issues a UserProfileRequest followed by a ServiceAuthorizationRequest, and blocks new traffic until quota has been granted.
Prepaid users might have some services that were granted quota in passthrough mode. For those services, when quota runs low, the CSG sends a ServiceReauthorizationRequest to the quota server, flagging the request with the QuotaServerFlags TLV. The usage TLV and remaining TLV contain the sum total of quota granted to the service since it began. This total might be a combination of quota granted by the quota server before the failure and quota granted by the CSG in passthrough mode. The requested quadrans TLV contains a request for an additional quota amount.
When the quota server responds to a ServiceStopRequest or a ServiceReauthorizationRequest, the CSG moves the service out of passthrough mode. If the quota server denies quota when it sends a ServiceAuthorizationResponse message, the CSG blocks the traffic. The CSG also flags CDRs generated by traffic for these services, which received passthrough mode quota grants, with QuotaServerFlags TLVs, until a ServiceStop is sent. That is, once a service is granted a passthrough mode quota, the CSG flags all CDRs for that serviced, up to and including the ServiceStop. Again, this only applies to prepaid users. Postpaid users CDRs are never flagged.
Service Duration Billing
The Service Duration Billing feature enables the CSG to deduct quota based on the time of network usage for prepaid (or "managed") users. With this feature, the user is charged for the time duration of the CSG service. The charging is performed according to the following rules:
•
•
•
•
Usage = LBT - FBT
If the service object is destroyed due to an asynchronous event such as user logoff, the calculation for usage is:
Usage = LBT - FBT
or
Usage = Async Event Timestamp - FBT
whichever is smaller.
If the service object runs out of quota, the calculation for usage is:
Usage = LBT - FBT
or
Usage = OutOfQuota Timestamp - FBT
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 CSG module, you cannot modify the basis or meter configuration. You are instructed at the console to configure no inservice on the downloaded Accounting definitions.
Reporting to the BMA
For service duration billing, the unit for quadrans reported to the quota server and BMA is 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 individual sessions or the sum of durations of individual sessions.
Out of Quota
When a subscriber runs out of quota, the CSG terminates the user sessions mapped to the service using the same asynchronous session kill mechanism that is used when a subscriber User Table entry is deleted. The CSG 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 CSG to deduct quota based on the time that a user is logged on to the IP network. That differs from Service Duration Billing, which charges based on the duration of a service. Because the service measures the duration of subscriber access, the service is never idle—it is destroyed only when the user logs out, or when a Service Stop Request is received from the quota server.
The CSG charges based on the following rules:
•
–
–
If the user has quota, the FBT is typically the same time as the RADIUS Accounting-Start.
•
–
–
Usage = LBT - FBT
or
Usage = OutOfQuota Timestamp - FBT
whichever is smaller.
Therefore, if the service does not run out of quota, the algorithm is simply:
Usage = LBT - FBT
If the user 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 user runs out of quota, existing prepaid and postpaid IP sessions for the subscriber are terminated. If the user does not have quota to proceed, no IP sessions for the user are allowed to proceed. The CSG provides enforcement for only those policies that have accounting configured.
To configure Connection Duration Billing, use the activation and basis second commands in CSG service configuration mode.
Postpaid Service Tagging
This feature enables the CSG to map postpaid content to a CSG service, and to report the service name in a CSG Service ID TLV in transaction-level CDRs to the BMA. (The CSG Service Session ID TLV is not sent in variable-format records for postpaid service tagging.)
The service must be associated with a billing plan configured for postpaid mode. As in the case of prepaid billing plans, the user 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 user is automatically associated with any billing plan configured for postpaid mode. In such cases, we strongly recommend that you configure only one billing plan for postpaid mode.
Stateful Redundancy and Failover
The CSG supports stateful redundancy for FTP, HTTP, IMAP, POP3, SMTP, TCP, and WAP connections.
Stateful redundancy is the configuration of the CSG to share information related to billing with its backup CSG in the event of a failure. That is, the session continues to be billed even when the primary CSG fails and the backup CSG takes over.
As described in the "Configuring Fault Tolerance" section, the primary and backup CSGs use a private VLAN to exchange connection and billing status information. The configurations must be the same on each CSG. The quota server, BMA, and user ID database definitions should also be the same, although this is not required.
During normal operation, connection and billing state information is sent by the primary CSG to the backup CSG, and from the primary quota server to the backup quota server. Both the primary and the backup CSGs maintain state information for the configured BMAs, and the primary CSG keeps the backup CSG informed as to which BMAs and quota servers are being used. If the primary CSG fails, the backup CSG takes over operation and tries to use the same BMAs or quota servers, if it has connectivity. Otherwise, the backup CSG selects the BMAs or quota servers with the highest priority.
The primary CSG also informs the backup CSG when user IDs are added to or removed from the User Table, and sends the correlators to the backup CSG 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 CSG, and a failover occurs, the CSG does not increment the content counters for traffic flowing through these connections. The CSG does increment the content counters for new connections created after the failover.
The CSG provides full stateful failover for FTP and IMAP sessions.
The CSG provides limited stateful failover for HTTP, POP3, SMTP, and WAP sessions. User information and quota information is maintained on the backup CSG; however, in-flight transactions are not. If the primary CSG fails, the user transaction completes on the backup, but no quota is charged for the transaction. Normal billing resumes with the user's next transaction.
The CSG also supports stateful redundancy for TCP connections. That is, the session continues to be billed even when the primary CSG fails and the backup CSG takes over.
The CSG does not support stateful redundancy for IP, RTSP, or UDP connections.
Note
"Default" Policy
The CSG matches content on a best-match basis, based on Layer 3 and Layer 4 information. When there is a successful content match, the CSG then matches against the policies configured within that content, linearly, on a first-match basis. If no policy within the content matches, the CSG 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.
For example, given the following policy and content configuration:
ip csg policy PHTTP1accounting type http customer-string HTTP-POL1ip csg policy PHTTP1accounting type http customer-string HTTP-POL2ip csg content HTTPpolicy PHTTP1policy PHTTP2The output from the show module contentServicesGateway 5 content name HTTP detail command is as follows:
HTTP, state = OPERATIONAL, index = 10destination = 198.133.219.0/24:80, TCPidle = 3600, replicate = none, vlan = ALL, pending = 30max parse len = 4000, persist rebalance = TRUEconns = 0, total conns = 0policy total conn client pkts server pkts-----------------------------------------------------PHTTP1 0 0 0PHTTP2 0 0 0(default) 4760 30056 26534In this example, any TCP traffic that does not match either the PHTTP1 policy or the HTTP2 policy matches the "default" policy, and is reflected in the (default) row.
Prepaid Error Reimbursement
The Prepaid Error Reimbursement feature allows the CSG to automatically refund quota for failed transactions, as defined by the CLI. Refund conditions can be configured using session flag (IP, TCP or WAP) settings and application return codes.
The CSG also adds a refund TLV to the statistics records on the BMA interface. The refund TLV is added for transactions that meet one of the refund conditions. 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
If refund is enabled for a CSG prepaid service, you cannot download more than 0x6FFFFFFF bytes of data in a given transaction.
Support for the Cisco Persistent Storage Device
The CSG supports the Cisco Persistent Storage Device (PSD). The PSD provides persistent storage capabilities to the CSG, and allows the CSG to store data on the PSD's internal hard drive.
Under normal conditions, the CSG sends content billing records to the mediation partners' servers. If, for any reason, those servers become unreachable, records are sent to the PSD for safekeeping until contact is reestablished with the Billing Mediation Agent (BMA). Once contact is reestablished, the CSG retrieves the records from the PSD, and forwards them to the BMA.
Storage
Under normal conditions, the PSD provides backup capabilities when necessary—for example, during network outages. The PSD stores the payload from the packet in a queue, and is unaware of the content or format of that data, so that the data can be retrieved exactly as it was sent.
Retrieval
Once the CSG determines that the regular data server is again reachable (in this case, the BMA), it retrieves the stored data from the PSD. The data is returned to the CSG in the same order and form as it was deposited. The CSG is responsible for maintaining order, if necessary, or of mixing retrieved data with incoming "live" records. Once the CSG acknowledges to the PSD that it has successfully sent the data to the client server (the BMA), the PSD deletes that data. The PSD stores the data until it receives this acknowledgement.
Postpaid Billing
Figure 1-1 illustrates simple traffic flows between the various components in a simple postpaid CSG environment.
Figure 1-1 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 CSG monitors data flows and generates accounting records that can be used to bill customers at a content-level granularity. The CSG 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.
BMA Load Sharing
The CSG can support multiple BMAs. This is useful in environments in which the number of billing records sent by the CSG could overwhelm a single BMA.
Note
The CSG maintains GTP' sequence numbers for each BMA.
All of the billing records for a given user are sent to the same BMA.
Quota Server Load Sharing
The CSG supports multiple quota servers. This is useful in environments in which the number of quota transactions sent by the CSG could overwhelm a single quota server. Multiple quota servers can be simultaneously active, and the CSG assigns a quota server to each user. All quota transactions for the user are done with the same quota server.
When a quota server fails, all users associated with that quota server are distributed among other quota servers.
Note
Prepaid Content Billing and Accounting
In addition to postpaid billing, the CSG 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 CSG uses a BMA to interface with a billing server. At the end of each transaction, the CSG sends a billing record to the BMA, indicating the content accessed and the amount deducted. The BMA logs the information in the user's bill.
The CSG uses a quota server to keep track of the quota that is left in the user's account. Each CSG supports one quota server and multiple idle backup quota servers. The CSG allows multiple groups of users on each quota server, with one quota manager for each user. Figure 1-2 illustrates a typical CSG prepaid content billing network.
Figure 1-2 CSG Prepaid Content Billing Network
Quota is provided by the Quota Manager, on request for quota by the CSG. This quota is either for an initial service connection, or for subsequent re-authorization when the original/last quota grant is depleted. The Quota Manager is allowed to provide a value in the range of 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 user can no longer access the service.
Quota is held on a per-service basis. Therefore, if a user is connected to more than one service, the CSG stores quota for each service that is open.
Once the user finishes a session by closing the bearer session (a RADIUS Accounting Stop 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.
The following example flow illustrates a basic prepaid flow between the CSG and the Quota Manager:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Obtaining User IDs
The CSG uses two methods to obtain user IDs:
•
•
After identifying a user, the CSG associates the user's IP address with the user ID, and, if a quota server has been defined, tries to download the user's profile. The profile indicates whether the user is postpaid or prepaid, as well as the user's billing plan. If the user is a prepaid user, the CSG downloads also the user's quota, then forwards the user's flows.
Filtering Accounting
Filtering lets you configure the following functionality:
•
•
•
Per-Event Filtering
The CSG supports the following per-event actions that require instruction from the billing system, and are supported as variations of the same design:
•
To enable these functions, use the authorize content command in CSG service configuration mode.
Intermediate Billing Records
Typically, the CSG 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 CSG 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 CSG and the standby CSG.
The CSG supports intermediate billing for FTP, HTTP, IP, TCP, and UDP. The CSG does not support intermediate billing for WAP or e-mail protocols (such as IMAP, POP3, and SMTP). The CSG does not support intermediate billing for RTSP control sessions unless the video/audio traffic is also transported over the control session.
Packet Forwarding
The CSG configurations allow users to specify multiple gateways; one for each of the VLANs. However, only one default gateway can be in effect at a time. So, the second default gateway configured does not take effect until the first default gateway is unconfigured. Generally, you should only specify one default gateway to avoid confusing which default gateway is being used by the CSG at any given moment.
All traffic that passes through the CSG (including the traffic to and from the CSG [GTP' traffic]) is routed and forwarded based on the VLAN interface, route, and gateway statements specified under the module CSG commands.
For example:
Module ContentServicesGateway 6vlan 10 serverip address 10.250.0.1 255.255.0.0gateway 10.250.1.1vlan 251 clientip address 10.251.0.1 255.255.0.0route 10.200.0.0 255.254.0.0 gateway 10.251.2.11For packet forwarding, the following logic applies:
1.
2.
3.
For packets that originated from the CSG (GTP'), the CSG uses the VLAN interface that resulted from the above forwarding logic to forward the packet. In the configuration example above, if a packet is forwarded using the default gateway, it uses the source interface of 10.250.0.1 to forward the packet.
In general, the default gateway is used to specify on the server VLAN to direct client traffic to the Internet. This prevents you from having to specify lots of subnets, as some of them are not easily identified. However, the default gateway can be placed in either the client or server VLAN.
In addition to using route/gateway to forward the traffic, client/server traffic can also be forwarded using next-hop as specified in the billing policy. For example:
ip csg policy FORWARD_PKTaccounting customer-string CLIENT-TRAFFICnext-hop 1.1.1.1ip csg content FORWARD-INTERNET-TRAFFICip anypolicy FORWARD_PKTinserviceIn the above example, if traffic hits this content and policy, the traffic is forwarded to next-hop router that has an IP address of 1.1.1.1.
The CSG supports next-hop packet forwarding for all protocols.
Miscellaneous Features
The CSG provides the following miscellaneous features:
•
•
•
Support for the CSG MIB
The CSG supports the CISCO-CSG-MIB implemented in Cisco IOS.
Note
Non-HTTP Traffic
For non-HTTP traffic, the CSG records information about data transfer based on flow information.
Fragment Support
The CSG supports IP fragments for both TCP and non-TCP flows, including fragments that arrive out of order.
Report Billing Plan ID to BMA and Quota Server
The CSG reports the billing plan identifier string in BMA records, and in messages to the quota server.
Asynchronous Quota Return
The Asynchronous Quota Return feature allows the quota server to request the CSG return quota for a defined user and service, and send a Quota Return.
Prior to CSG 3.1(3)C6(2), the quota returned via a Quota Return message did not include quota reserved for ongoing transactions. Beginning in CSG 3.1(3)C6(2), the quota reserved for ongoing transactions is recalled from the transactions and included in the quota returned in the Quota Return message.
Asynchronous Service Stop
The Asynchronous Service Stop feature allows the quota server to request the CSG to stop a prepaid service for a defined user and service, and send a Service Stop.
Support for Port Number Ranges
When you define content on the CSG, you can define a single port number, or a range of port numbers. This eliminates the need to define 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 accounting type http means that the CSG 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 CSG, as well as generating many CDRs that the customer had not planned for.
Learning Client IP Addresses Using Inspection of X-Forwarded-For Headers
If your network is configured with a gateway or proxy placed between the client and the CSG, you can configure the CSG to determine the client's IP address by inspecting the X-Forwarded-For header (for HTTP connections only).
Packet Counts
The CSG 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 CSG 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 CSG might report this negative balance to the quota server as a negative number in the Remaining Quota TLV.
Dependencies and Restrictions
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
–
–
–
One such choice is to interleave the stream with the control channel. In this mode, the CSG cannot map the transport connection to a different policy, and URL mapping cannot be supported.
The other shared mode for RTSP is to use a single HTTP connection. RTSP tunneled over HTTP has the same limitation as interleaved RTSP: The stream cannot be mapped to a policy different from the control connection, as both of them share the same transport.
–
–
–
–
–
–
–
–
•
–
–
–
–
•
•
•
•
•
•
•
•
•
–
–
–
•
•
•
•
–
–
–
–
–
–
–
–
- The first request (GET, POST, any other method) from the client—headers plus the part of the message that arrives before quota is granted.
- The headers plus one packet of the response from the server.
–
–
•
–
–
–
•
Note
•
–
–
–
•
–
–
•
•
•
•
–
–
–
–
–
–
–
–
–
–
•
•
–
–
–
•
•
•
0x03:xx:yy:00:zz:zz
where:
–
–
Feedback