-
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
Configuring Quota Server Support
Configuring the Quota Server Local Port
Configuring the Quota Server Keepalive Time
Configuring the Quota Server GTP' Message Buffer
Configuring the Quota Server Retransmit Time
Configuring the Quota Server Retry Number
Configuring the Quota Server Window Size
Configuring Quota Server Load Sharing
Reassigning Subscribers to a New Quota Server
Delaying Quota Reauthorization
Reporting the Billing Plan ID to the Quota Server
Pricing by Quota Server Configuration Example
Differentiating Prices Configuration Example
Reducing the Number of Services Configuration Example
Configuring Quota Server Support
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 features for the quota server:
•
Configuring the Quota Server Local Port
•
•
•
•
•
•
•
•
•
•
•
•
Configuring the Quota Server Local Port
The first step when configuring CSG2 support for the quota server is to configure the local port on which the CSG2 is to communicate with the quota server.
For prepaid billing, you must configure at least one quota server local port, the local port on which the CSG2 is to communicate with quota servers.
To configure a local port for quota servers, enter the following command in global configuration mode:
Configuring a Quota Server
For prepaid billing, you must configure at least one quota server.
You can configure up to 10 quota servers. Each quota server must have a unique priority and a unique IP address (or a unique IP address-VRF name combination, if VRF is configured).
The CSG2 differentiates quota servers on the basis of their IP addresses and port numbers. When you configure a quota server, make sure that its IP address and port number match on both the active CSG2 and the standby CSG2.
If you have enabled interface awareness, you can also associate a VLAN's Virtual Routing and Forwarding (VRF) table name with the quota server.
To configure a quota server, enter the following command in global configuration mode:
Configures the CSG2 quota servers that return billing quota values for subscribers.
Configuring the Quota Server Keepalive Time
By default, the CSG2 sends keepalive messages to the quota servers once every 60 seconds. That setting is sufficient in most environments, but the CSG2 also allows you to change the time between keepalive messages, if necessary.
Note
To change the keepalive timer for the quota servers, enter the following command in global configuration mode:
(Optional) Defines the quota server keepalive time interval for the CSG2.
Configuring the Quota Server GTP' Message Buffer
By default, the CSG2 can buffer up to 10,000 general packet radio service (GPRS) tunneling protocol prime (GTP') messages for the quota servers. That setting is sufficient in most environments, but the CSG2 also allows you to change the quota server GTP' message buffer, if necessary.
Note
To change the maximum number of GTP' messages, enter the following command in global configuration mode:
(Optional) Specifies the maximum number of GTP' messages that the CSG2 can buffer for all quota servers.
Configuring the Quota Server Retransmit Time
By default, the CSG2 retransmits packets to a quota server once every four seconds. That setting is sufficient in most environments, but the CSG2 also allows you to change the time between retransmits, if necessary.
Note
To change the quota server retransmit time interval for the CSG2, enter the following command in global configuration mode:
(Optional) Defines the quota server retransmit time interval for the CSG2.
Configuring the Quota Server Retry Number
By default, the CSG2 retries communication with a quota server three times before determining that the link has failed. That setting is sufficient in most environments, but the CSG2 also allows you to change the number of retries, if necessary.
Note
To change the maximum number of quota server retries allowed before the CSG2 determines that the link has failed, enter the following command in global configuration mode:
(Optional) Defines the maximum number of quota server retries allowed before the CSG2 determines that the link has failed.
Configuring the Quota Server Window Size
By default, the CSG2 sets the maximum quota server transmit window size to 128 packets, and sets the minimum quota server transmit window size automatically. Those settings are sufficient in most environments, but the CSG2 also allows you to change the maximum and minimum quota server transmit window sizes, if necessary.
Note
To define the quota server transmit window size for the CSG2, enter the following command in global configuration mode:
(Optional) Defines the quota server transmit window size for the CSG2.
Configuring Quota Server Load Sharing
The CSG2 allows load sharing among quota servers. This support is useful in environments in which the number of quota transactions sent by the CSG2 could overwhelm a single quota server. Multiple quota servers can be simultaneously active, and the CSG2 assigns a quota server to each subscriber. All quota transactions for the subscriber are handled by the same quota server.
If a quota server fails, all subscribers associated with that quota server are distributed among the other active other quota servers.
Note
To configure quota server load sharing, enter the following command in global configuration mode:
Activates one or more quota servers.
Reassigning Subscribers to a New Quota Server
If a quota server fails, you can reassign the subscribers to a different quota server.
To reassign subscribers to a different quota server, enter the following command in global configuration mode:
csg2(config)# ip csg quota-server reassign(Optional) Reassigns subscribers to a different CSG2 quota server after a failure.
Quota Push
This feature enables operators to "push" quota for a service instance associated with an individual subscriber. This enables quota servers to provide quota for a subscriber or service before traffic from that subscriber or service reaches the CSG2. 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 CSG2 accepts a quota push for a subscriber at any point after the subscriber and billing plan are known to the CSG2 (that is, when a CSG2 User Table element exists for the subscriber). For example, the CSG2 accepts a quota push after receiving an accounting start but does not require an existing service for the subscriber (one is created). The CSG2 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.
The CSG2 rejects the Quota Push message if the "Replace current balance" flag is not set in the Granted Quadrans TLV.
There are no commands required to enable quota push.
Replacing Quota Balance
By default, when the CSG2 receives a quota grant from the quota server, the CSG2 adds the granted quota to the current balance for a subscriber's service. Quota balance replacement enables the quota server to instruct the CSG2 to replace the current quota balance with the amount of granted quota for a subscriber's service. If the replacement grant is provided in a Service Authorization Response, the CSG2 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.
Delaying Quota Reauthorization
The CSG2 accepts the Reauthorization Delay TLV, which specifies the number of seconds the CSG2 delays its next reauthorization request to the quota server for the service specified in the message. This TLV also specifies the action the CSG2 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 CSG2 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.
Asynchronous Quota Return
The Asynchronous Quota Return feature allows the quota server to request the CSG2 to return quota for a defined subscriber and service, and to send a Quota Return. The quota reserved for ongoing transactions is recalled from the transactions and included in the quota returned in the Quota Return message.
The Quota Return message can include the following fields: "remaining quota", "qualified quadrans", "qualified usage", "qualified quota remaining", "reserved quota", and "pending quota". For fixed-cost billing, the "reserved quota" field is not included. For time-based billing, neither the "reserved quota" field nor the "pending quota" field is included. The "qualified usage" field identifies quota that is known to have been consumed, and is the only value that is safe to commit to a back-end system.
Because all of the quota is returned, there is no longer any reserved quota to process ongoing pending transactions. Packets received for pending transactions are dropped. However, time-based billing holds back 5 seconds of quota, so transactions can proceed while returning quota for time-based billing.
There are no commands required to enable delayed quota reauthorization.
Reporting the Billing Plan ID to the Quota Server
The CSG2 reports the billing plan identifier in messages to the quota server. The CSG2 also reports the billing plan ID in billing records.
There are no commands required to enable billing plan ID reporting.
Pricing by Quota Server Configuration Example
The following example shows a CSG2 configuration in which the quota server performs all pricing. In this example:
•
•
–
–
•
•
ip csg content C1policy P1inservice!ip csg content C2policy P2inservice!ip csg service PERCLICKbasis fixedcontent C1 policy P1!ip csg service PERBYTEbasis byte ip exclude mmscontent C2 policy P2!ip csg billing REGULARservice PERCLICKservice PERBYTEWhen Subscriber X, with a subscription to billing plan REGULAR, tries to access content that matches C1, the CSG2 tries to download quota for Subscriber X for service PERCLICK.
The quota server borrows money from Subscriber X's $10.00, and returns some quadrans to the CSG2. Each quadran is good for one object download, or one click. If the quota server is configured for the CSG2 to query for each click, it can choose to send just one quadran at a time, so that the CSG2 queries the quota server each time. However, if the quota server is configured to grant $2.00 worth of quadrans to the CSG2 in one shot, it can send 200 quadrans to the CSG2, which the CSG2 keeps using for Subscriber X's access to C1.
When Subscriber X tries to access content that matches C2, the CSG2 makes another request to the quota server to get Subscriber X's quota for C2. C2 is billed per IP byte. The quota server borrows another $5.00 from Subscriber X's account, and sends 500000 quadrans to the CSG2. As Subscriber X continues to access C2, his traffic is metered for volume. For each byte, the CSG2 deducts one quadran.
Differentiating Prices Configuration Example
The following example extends the previous example by adding a content type that is priced differently. In this example:
•
•
–
–
–
•
•
This configuration requires an additional service type, MP3, which allows the quota server to price object downloads (clicks) differently for MP3 files.
ip csg content C1policy P1inservice!ip csg content C2policy P2inservice!ip csg content MP3policy P1inservice!ip csg service PERCLICKbasis fixedcontent C1 policy P1!ip csg service PERBYTEbasis byte ipcontent C2 policy P2!ip csg service MP3basis fixedcontent C1 policy P1!ip csg billing REGULARservice PERCLICKservice PERBYTEservice MP3When Subscriber X tries to download an MP3 file (that is, a file that matches content type MP3), the CSG2 requests the MP3 quota for Subscriber X. Each download of an MP3 file costs $0.05, so the quota server borrows $1.00 from Subscriber X's account, and returns 20 quadrans to the CSG2 for service MP3. The CSG2 can use the quadrans for 20 downloads of MP3 files.
Alternatively, the quota server could send just one quadran, which is enough for only one transaction. This would force the CSG2 to ask for quota before each download of an MP3 file.
Reducing the Number of Services Configuration Example
The "Differentiating Prices Configuration Example" section shows that you can create a new service for one type of content and differentiate its billing from other types of content.
However, with each new service, the subscriber's quota fragments further, and traffic between the CSG2 and the quota server increases.
You can reduce traffic by specifying a symbolic weight on the CSG2. In the following example, each MP3 download ($0.05) costs five times as much as each JPG download ($0.01). By assigning a weight of 5 to MP3 downloads, you can keep both content C1 and content MP3 under service PERCLICK, thereby reducing the overall number of services and reducing the traffic between the CSG2 and the quota server.
ip csg content C1policy P1inservice!ip csg content C2policy P2inservice!ip csg content MP3policy P1inservice!ip csg service PERBYTEbasis byte ipcontent C2 policy P2!ip csg service PERCLICKbasis fixedcontent C1 policy P1content MP3 policy P1 weight 5!ip csg billing REGULARservice PERCLICKservice PERBYTEWhen the quota server borrows $1.00 from Subscriber X's account and sends 100 quadrans for service PERCLICK, the CSG2 can use the quadrans for 100 JPG files, or for 20 MP3 files, or for a mix of the two content types.
