ICAP Interface Support


ICAP Interface Support
 
 
This chapter provides information on configuring the external Active Content Filtering servers for a core network service subscriber. This chapter also describes the configuration and commands that are used to implement this feature.
It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in respective product Administration Guide, before using the procedures in this chapter.
 
Supported Networks and Platforms
This feature supports ST16 and Cisco® ASR 5000 Chassis for the core network services configured on the system.
 
Licensing
External Content Filtering Server support through Internet Content Adaptation Protocol (ICAP) interface is a licensed feature. To enable this feature on your chassis you must install the following license, along with other required core network and in-line service licenses:
 
For information on additional license requirements for this feature, please contact your local sales representative.
Important: For information on obtaining and installing licenses, refer to Managing License Keys in the System Administration Guide.
 
ICAP Interface Support Overview
This feature supports streamlined ICAP interface to leverage Deep Packet Inspection (DPI) to enable external application servers to provide their services without performing DPI, and without being inserted in the data flow. For example with an external Active Content Filtering (ACF) Platform.
A high-level view of the streamlined ICAP interface support for external ACF is shown in the following figure:
High-Level View of Streamlined ICAP Interface with external ACF
The system with ECS is configured to support DPI and the system uses this capability for content charging as well.
If a subscriber initiates a WAP (WAP1.x or WAP2.0) or Web session, the subsequent GET/POST request is detected by the DPI function. The URL of the GET/POST request is extracted and passed, along with subscriber identification information and the subscriber request, in an ICAP message to the application server. The application server checks the URL on the basis of its category and other classifications like, type, access level, content category and decides if the request should be authorized, blocked, or redirected by answering to the GET/POST with:
Depending on the response received, the system with ECS will either pass the request unmodified, or discard the message and respond to the subscriber with the appropriate redirection or block message.
Content charging is performed by the Active Charging Service (ACS) only after the request has been controlled by the application server. This guarantees the appropriate interworking between the external application and content-based billing. In particular, this guarantees that charging will be applied to the appropriate request in case of redirection, and that potential charging-based redirections (i.e. Advice of Charge, Top Up page, etc.) will not interfere with the decisions taken by the application server.
Functions of the ACF include:
 
 
Failure Action on Retransmitted Packets
ICAP rating is enabled for retransmitted packet when default ICAP failure action was taken on an ICAP request for that flow. ICAP default failure action is taken on the pending ICAP request for a connection when the connection needs to be reset and there is no other redundant connection available. For example, in the ICAP request timeout and ICAP connection timeout scenarios. In these cases the retransmitted packet in the uplink direction is sent for ICAP rating again.
In case of WAP CO, uplink retransmitted packet for the WAP transactions for which ICAP failure action was taken will be sent for ICAP rating. WSP header of the retransmitted packet is not parsed by the WSP analyzer. The URL received in the previous packet for that transaction is used for ICAP rating. If failure action was taken on multiple WTP transactions for the same flow (case: WTP concatenated GET request) then uplink retransmitted packet for each of the transaction is sent for rating again.
In case of HTTP, uplink retransmitted packets for the HTTP flow on which ICAP failure action is taken is sent for ICAP rating. The URL present in the current secondary session (last uplink request) is used for ICAP rating. However, if there were multiple outstanding ICAP request for the same flow (pipelined request) then for the retransmitted packet the URL that will be sent for rating will be that of the last GET request.
Retransmission in various cases of failure-action taken on re-transmitted packets when the ICAP response is not received for the original request and the retransmitted request comes in:
 
 
Configuring ICAP Interface Support
This section describes how to configure the Content Filtering Server Group (CFSG) through Internet Content Adaptation Protocol (ICAP) interface between ICAP client and ACF server (ICAP server).
Important: This section provides the minimum instruction set for configuring external content filtering servers on ICAP interface on the system. For more information on commands that configure additional parameters and options, refer CFSG Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the system to provide ICAP interface support for external content filtering servers:
Step 1
Step 2
Step 3
Step 4
Optional. Configure the charging action to forward HTTP/WAP GET request to external content filtering servers on ICAP interface in Active Charging Configuration mode by applying the example configuration in the Configuring Charging Action for ICAP Server Group section.
Step 5
Step 6
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
 
Creating ICAP Server Group and Address Binding
Use the following example to create the ICAP server group and bind the IP addresses:
configure
  context <icap_ctxt_name> [ -noconfirm ]
     content-filtering server-group <icap_svr_grp_name> [ -noconfirm ]
        origin address <ip_address>
        end
Notes:
 
<ip_address> is local IP address of the CFSG endpoint.
 
Configuring ICAP Server and Other Parameters
Use the following example to configure the active content filtering (ICAP server) and other related parameters:
configure
  context <icap_context_name>
     content-filtering server-group <icap_server_grp_name>
        icap server <ip_address> [port <port_number>][max <max_msgs>][priority <priority>]
        deny-message <msg_string>
        response-timeout <timeout>
        connection retry-timeout <retry_timeout>
        failure-action {allow | content-insertion <content_string> | discard | redirect-url <url> | terminate-flow}
        dictionary {custom1 | custom2 | standard}
        end
Notes:
 
The maximum outstanding request per ICAP connection configured using the optional max <max_msgs> keyword is limited to one. Therefore, any other value configured using the max keyword will be ignored.
Optional. To configure the ICAP URL extraction behavior, in the Content Filtering Server Group configuration mode, enter the following command:
url-extraction { after-parsing | raw }
By default, percent-encoded hex characters in URLs sent from the ACF client to the ICAP server will be converted to corresponding ASCII characters and sent.
 
Configuring ECS Rulebase for ICAP Server Group
Use the following example to configure the content filtering mode to ICAP server mode in the ECS rulebase for content filtering:
configure
  require active-charging [optimized-mode]
  active-charging service <acs_svc_name> [-noconfirm]
     rulebase <rulebase_name> [-noconfirm]
        content-filtering mode server-group <cf_server_group>
        end
Notes:
 
In StarOS 8.1, the optimized-mode keyword enables ACS in the Optimized mode, wherein ACS functionality is managed by SessMgrs. In StarOS 8.1, ACS must be enabled in the Optimized mode.
In StarOS 8.3, the optimized-mode keyword is obsolete. With or without this keyword ACS is always enabled in Optimized mode.
In StarOS 8.0 and StarOS 9.0 and later, the optimized-mode keyword is not available.
 
Configuring Charging Action for ICAP Server Group
Use the following example to configure the charging action to forward HTTP/WAP GET request to ICAP server for content processing:
configure
  active-charging service <acs_svc_name>
     charging-action <charging_action_name> [ -noconfirm ]
        content-filtering processing server-group
        end
 
Verifying the ICAP Server Group Configuration
This section explains how to display and review the configurations after saving them in a .cfg file as described in Verifying and Saving Your Configuration chapter of this guide and also to retrieve errors and warnings within an active configuration for a service.
Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.
These instructions are used to verify the configuration for this feature.
Step 1
show content-filtering server-group
The following is a sample output. In this example, an ICAP Content Filtering server group named icap_cfsg1 was configured.
Content Filtering Group:     icap_cfsg1
  Context:                     icap1
  Origin Address:              1.2.3.4
  ICAP Address(Port):          1.2.3.4(1344)
  Max Outstanding:             256
  Priority:                    1
  Response Timeout:      30(secs)      Connection Retry Timeout:      30(secs)
  Dictionary:                   standard
  Timeout Action:               terminate-flow
  Deny Message:                 "Service Not Subscribed"
  URL-extraction:                after-parsing
  Content Filtering Group Connections: NONE
Total content filtering groups mathing specified criteria:  1
Step 2
show configuration errors
 

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883