Content Filtering Support Overview

Content Filtering Support Overview
 
 
This chapter provides an overview of the Content Filtering In-line Service feature.
This chapter covers the following topics:
 
 
Introduction
Content Filtering is an in-line service that is supported to filter HTTP and WAP requests from mobile subscribers based on the URLs in the requests. This enables operators to filter and control the content that an individual subscriber can access, so that subscribers are inadvertently not exposed to universally unacceptable content and/or content inappropriate as per the subscribers’ preferences.
 
The Content Filtering service offers the following solutions:
 
In the URL Blacklisting solution, all HTTP/WAP URLs in subscriber requests are matched against a database of “blacklisted” URLs. If there is a match, the flow is discarded, redirected, or terminated as configured. If there is no match, subscribers view the content as they would normally.
URL Blacklisting may/may not be a subscriber opt-in service, operators can enable URL Blacklisting either for all subscribers or for a subset of subscribers. Typical cases include applying a blacklisted database of child porn URLs to all subscribers so that they are inadvertently not exposed to such universally unacceptable content.
This release supports the following types of Category-based Content Filtering:
In Category-based Static Content Filtering, all HTTP/WAP URLs in subscriber requests are matched against a static URL categorization database. Action is taken based on a URL’s category, and the action configured for that category in the subscriber’s content filtering policy. Possible actions include permitting, blocking, redirecting, and inserting/altering content.
In Category-based Static-and-Dynamic Content Filtering, if static rating categorizes a URL as either “dynamic” or “unknown”, the “requested content” is sent for dynamic rating. Wherein the “requested content” is analyzed and categorized. Action is taken based on the category determined by dynamic rating, and the action configured for that category in the subscriber’s content filtering policy. Possible actions include permitting, blocking, redirecting, and inserting/altering content.
Typically Category-based Content Filtering is an opt-in service, subscribers self-choose a content-filtering policy or plan, such as Teen, Child, Adult, etc., and are subjected to content filtering as per their chosen plan. Also, the content-filtering policies of different subscribers may be different, enabling differential access of content to them. This solution provides maximum flexibility, and is also referred to as the Policy-based Content Filtering.
Both URL Blacklisting and Category-based Content Filtering support can be concurrently enabled on a system.
Content Filtering uses Deep Packet Inspection (DPI) feature of Enhanced Charging Service (ECS) to discern HTTP and WAP requests.
 
Supported Platforms and Products
 
Content Filtering is an in-line service supported on ASR5000 running 3GPP, 3GPP2, and LTE core network services.
 
Licenses
 
URL Blacklisting
URL Blacklisting is a licensed feature requiring the following license:
[600-00-7801] Blacklisting Integrated Service
 
Category-based Content Filtering
Category-based Content Filtering is a licensed feature requiring the following license:
[ 600-00-7586 ] Integrated Content Filtering Service, 1k Sessions
For information on license requirements for any customer-specific features, please contact your local sales/service representative.
Important: External Content Filtering Server support through Internet Content Adaptation Protocol (ICAP) interface is a licensed feature, requiring a separate license. For more information, see the ICAP Interface Support chapter of the System Enhanced Feature Configuration Guide.
Important: For information on obtaining and installing licenses, refer to Managing License Keys in the System Administration and Configuration Guide.
 
URL Blacklisting Support
In the URL Blacklisting solution, a blacklist is a list of known URLs/URIs, which for some reason are being denied recognition. The blacklist can be obtained from a known source such as the National Center for Missing & Exploited Children (NCMEC, http://www. missing kids.com), or any other IP source. The blacklist is a clear text file, the file must be named cumulative.csv, and must use the same format as the blacklist file from NCMEC. For more information on the blacklist file, please contact your local service representative.
 
Unlike the Category-based Content Filtering solution, which categorizes URLs as per a static database and takes different actions based on the different policies associated with subscribers, URL Blacklisting is applicable to all subscribers associated with a blacklisting-enabled rulebase. The same blacklist database is used for all subscribers, and for a specific URL, the same action is taken for all subscribers.
The blacklist file is downloaded and converted into a non human-readable optimized format (OPTBLDB) and then made available in the system. Once in place, all HTTP and WAP requests from subscribers are inspected in order to determine the requested destination URL/URI. If the URL/URI is not present in the blacklist then the request is passed on as usual. If the URL/URI is present in the blacklist, the request is dropped, or the flow is redirected or terminated as configured. There is no indication/messaging sent to the requesting subscribers that the requested HTTP/WAP URL/URI was rejected due to a blacklist match.
The URL Blacklisting match-method can be configured to either be generic or to look for any URL/URI in its exact, literal form.
The system generates usage/event data that can be utilized as the basis for blacklist reporting. The offline reports consist of, at a minimum, a running total of the number of times a match was made against the blacklist without any information regarding the specifics of the request.
The default/configured number of versions of the Blacklist database are maintained on the chassis (both the SPCs). This enables reverting to a particular version if required.
The following figure shows the high-level URL Blacklisting architecture with ECS, and other components in a deployment scenario.
 
High-Level Architecture of URL Blacklisting with ACS
 
URL Blacklisting Solution Components
The URL Blacklisting solution uses the deep-packet inspection capabilities of ECS for URL/URI extraction.
 
ECS functionality is managed by the following components:
 
Session Controller (SessCtrl): The SessCtrl runs on the primary SPC/SMC and is responsible for managing ECS and URL Blacklisting services.
Session Manager (SessMgr): A single SessMgr treats ECS charging and URL Blacklisting that is applicable to common subscriber sessions.
Apart from ECS, the URL Blacklisting solution uses the following components:
 
 
Web Element Manager (WEM)
The WEM is a server-based application enabling complete element management of the system. The UNIX-based server application works with the network elements within the system using the Common Object Request Broker Architecture (CORBA) standard.
 
Important: For information on WEM administration, refer to the Web Element Manager Installation and Administration Guide.
The WEM server must be set up with access to the following networks:
 
The WEM application includes the following features:
 
Downloads the URL Blacklist database (cumulative.csv) from the specified source at configured schedule
Converts the URL Blacklist database (cumulative.csv) file to Starent Master Database (SFMDB) file
 
Central Decision Point (CF-CDP)
The URL Blacklisting solution includes the CF-CDP consisting of a geographically-redundant server hosting the CDP application that may be the same as the External Storage Server in ESS.
In the URL Blacklisting solution, the CF-CDP serves as a repository and distribution node for the Blacklisting database and its updates (OPTCMBLDB). There are no incremental updates in the URL Blacklisting feature as a new Full database will be supplied by WEM daily.
 
How URL Blacklisting Works
 
This section describes how URL Blacklisting works.
 
Blacklist Updates
The following steps describe how the blacklist is updated in the system:
Step 1
Step 2
The CDP pushes the optblk.bin file to the chassis (to the flash/pcmcia device) at pre-determined intervals. The optblk.bin file contains the full blacklist. If this file is verified to be correct it replaces the optblk.bin file on the chassis, and the last optblk.bin is rolled over.
Step 3
The new blacklist is loaded only if it has been received properly. If the full Blacklist database is not found, corrupted, or if the loading fails, traps are generated. Correspondingly clear traps are also generated on a valid Blacklist database being available, and after a successful load.
Step 4
Important: The URL Blacklisting feature is enabled only if the url-blacklisting action is set in any of the rulebases. Thus, the automatic detection of the Blacklist database, storing it in memory, and loading onto the SessMgrs will happen only if the url-blacklisting action is set in any of the rulebases.
Step 5
When the SessMgrs start for the first time or after recovery, if URL Blacklisting is set in any of the rulebases, the stored Blacklist database at SessCtrl is loaded onto the SessMgrs. This holds true for standby managers as well i.e., when standby managers come up the Blacklist database is loaded onto them.
Whenever a SessMgr is killed, standby manager which already has the Blacklist database loaded takes its place, and a new standby manager is created which loads the Blacklist database as part of SessMgr getting started for the first time.
If SessCtrl is killed, while recovering it checks if URL Blacklisting is set in any of the rulebases, if set it will store the Blacklist database onto itself and load all the SessMgrs as well.
Step 6
 
URL Blacklisting Action
The following steps describe how the URL Blacklisting feature works:
Step 1
Step 2
If a match is found for the URL in the Blacklist database, the packets are treated as per the blacklisting action configured—Discard, Redirect, or Terminate flow.
In case of multiple HTTP requests in the same TCP packet, if any of the URLs match the packet is treated as per the blacklisting action configured.
If a match is not found, the request is allowed to pass through.
 
Category-based Content Filtering Support
The Category-based Content Filtering application is a fully integrated, subscriber-aware in-line service provisioned on chassis running HA services. This application is transparently integrated within the ECS, and utilizes a distributed software architecture that scales with the number of active HA sessions on the system.
 
Content Filtering policy enforcement is the process of deciding if a subscriber should be able to receive some content. Typical options are to allow, block, or replace/redirect the content based on the rating of the content and the policy defined for that content. For the list of content categories, refer to the Category List appendix in the Content Filtering Services Administration Guide.
 
Benefits of Category-based Content Filtering
The Category-based Content Filtering solution enables operators to ensure a simplified end-to-end traffic flow with a simple network topology. In-line deployment of Content Filtering provides a more attractive solution in contrast to out-of-line solutions where the filtering and policy enforcement is provided at some offload point that is decoupled from the bearer-processing layer.
 
The out-of-line model forces a session to make multiple hops through a redundant array of equipment which has a negative impact on traffic latency and limits subscriber and network visibility. In addition, the out-of-line model requires all subscriber sessions to be steered to the adjunct Content Filtering platform for policy enforcement regardless of whether this additional processing is needed. This leads to increased bandwidth provisioning requirements on gateway routers.
To facilitate network simplicity, it makes sense to leverage the benefits of deep packet inspection at a single policy enforcement point that is tied to the bearer processing layer. The advantages of this approach implemented in include the following benefits:
 
Reduced processing latency: In-line service processing eliminates unnecessary hand-offs and forwarding to external network elements.
Simplified policy provisioning: Enables all policies like Content Filtering, ECS and QoS to be retrieved from same AAA/Policy Manager signaling interface thus reducing total volume of control transactions and associated delay.
Simplified provisioning and complete service integration: Provisioning of separate resources like packet processing cards for processing subscriber data sessions and discrete services are eliminated. The same CPU can contain active Session Manager tasks for running Content Filtering and ECS charging.
Integration with Content Service Steering (CSS) architecture: Enables applicable sessions to be forwarded to the in-line content filtering subsystem while delay and time sensitive voice/multimedia services immediately forwarded to Internet.
Service control: Precise control over the interaction and service order handling of bearer flows with required applications like Content Filtering, ECS, Subscriber-aware Stateful Firewall, integrated Policy Charging and Rules Function (PCRF) for Service Based Bearer Control.
Apart from the advantages described previously, Category-based Content Filtering service reduces the requirement of over-provisioning of capacity at neighboring gateway routers. It also eliminates requirements of external Server Load Balancers and enhances the accuracy in subscriber charging records.
The Category-based Content Filtering solution has the following logical functions:
 
 
Static-and-Dynamic Content Filtering
With Static Category-based Content Filtering, the filtering is only as good as the collection of URLs in the database. Even the largest URL database covers only a fraction of the Surface Web and virtually none of the Deep Web. It is quite impossible to find, review, and categorize enough of the available Web sites to keep the database current.
 
Also, many mobile sites are classified as dynamic sites. A dynamic site may return either acceptable or inappropriate content from the same URL. For example, search engines, news portals, or auction sites that return variable results depending upon subscriber requests.
When the Content Filtering subsystem receives a request for dynamic content it becomes necessary to categorize pages in real-time to determine how to classify content the provider is delivering at that moment. The “Static Rating” solution that relies exclusively on previously categorized rating for sites may fail to categorize dynamic sites appropriately.
Dynamic Content Filtering enables on-the-fly content analysis of Web traffic using different content analysis techniques. When a Web page is received, it is analyzed and then categorized according to the content found in the page. Whether a Web site has existed for five months or for five minutes does not matter since determination of the category to which the Web page belongs is made just at the time of request. Therefore, dynamic filters have no problem keeping up with the growth and changing content of the Internet. A combination of static filtering and dynamic inspection provides real accuracy and scalability as the Web weaves an increasingly sophisticated network of sites.
Important: Category-based Content Filtering can only work in static-only or in static-and-dynamic modes. Dynamic-only Content Filtering mode is not supported.
In Static-and-Dynamic Content Filtering, every URL will first undergo static rating, if the URL cannot be rated by the static database, or if the URL’s statistic rating is categorized as DYNAM, then it will go for dynamic rating. After the content has been analyzed, as with static content filtering, dynamic rating actions include acceptance, blocking, redirection, and/or replacement of content.
Static-and-Dynamic Content Filtering must be enabled at the global and rulebase levels. Before enabling static-and-dynamic rating in the rulebase, it must be enabled at the global level as the resources required for dynamic rating are allocated at the global level. When enabled in a rulebase, it is applied for subscribers using that rulebase.
 
Limitations of Dynamic Content Filtering
 
 
ECS and Content Filtering Application
The Category-based Content Filtering solution is provided as an integrated subsystem within the Enhanced Charging Service (ECS). Although it is not necessary to provision content-based charging in conjunction with content filtering, it is highly desirable as it enables a single point of deep-packet inspection for both services. It also enables a single policy decision and enforcement point for both services thereby streamlining the required number of signaling interactions with external AAA/Policy Manager servers. Utilizing both services also increases billing accuracy of charging records by insuring that mobile subscribers are only charged for visited sites content.
 
The Category-based Content Filtering solution uses Content Filtering Policy to analyze the content requested by subscribers. Content Filtering Policy provides a decision point for analyzed content on the basis of its category and priority.
The Category-based Content Filtering solution also utilizes ACS rulebases in order to determine the correct policy decision and enforcement action such as accept, block, redirect, or replace. Rulebase names are retrieved during initial authentication from the AAA/Policy Manager. Some possible examples of rulebase names include Consumer, Enterprise, Child, Teen, Adult, and Sport. Rulebase names are used by the ACS subsystem to instantiate the particular rule definition that applies for a particular session. Rulebase work in conjunction with a content filtering policy and only one content filtering policy can be associated with a rulebase.
Important: For more information on rulebases and rule definitions, refer to the Enhanced Charging Services Administration Guide.
The ACS subsystem includes L3–L7 deep packet inspection capabilities. It correlates all L3 packets with higher layer criteria such as URL detection within an HTTP header, it also provides stateful packet inspection for complex protocols like FTP, RTSP, and SIP that dynamically open ports for the data path.
The Content Filtering subsystem uses the deep-packet inspection capabilities of ECS for URL/URI extraction.
ECS functionality is managed by the following components:
 
Session Controller (SessCtrl): The SessCtrl runs on the primary SPC/SMC and is responsible for managing ECS and Content Filtering services.
Session Manager (SessMgr): A single SessMgr treats ECS charging and Content Filtering that is applicable to common subscriber sessions.
 
Components of Category-based Content Filtering Solution
The Category-based Content Filtering solution uses the following components:
 
 
The following figure shows a high-level view of the Category-based Content Filtering architecture with ECS, and other components in a deployment scenario.
 
High-Level Architecture of Category-based Content Filtering
 
Category-based Content Filtering Subsystem
The Content Filtering solution comprises the following content rating and category databases:
 
 
 
Static Rating Categorization Database (SRDB)
This is an internal categorization database (periodically synchronized with an external server) that provides ratings for publicly accessible traditional and mobile Web sites. When the SessMgr passes a URL/URI to internal list server, the list server returns a list of matching category ratings.
 
The list server is used to determine whether a Web site has already been classified. When the list server passes back a category rating to the filtering application, the rating is compared against the Category Policy ID applied for the subscriber to determine the appropriate action like accept, block, redirect, or replace. If the list server returns a clean rating, there is no need to perform a real-time analysis of any content delivered by the site.
When a blocked or rejected content rating is returned, the SessMgr can insert data such as a redirect server address into the bearer data stream. If no rating is returned this means the site is capable of returning either clean or unacceptable content. In this case, the Content Filtering application uses the real-time dynamic analysis engine to examine additional content served by the site.
Each SRDB contains a replication object consisting of hash tables that map known Web sites and their subdirectories to their respective category ratings. The SessCtrl reads the index of SRDB tables with a data structure that associates keys with URL rating values and loads it onto the SRDB managers.
To boost performance and provide high availability, SRDB Manager provides functionality to load the Optimized Content Rating Master Database (OPTCMDB) volumes from its peer SRDB task. If the peer SRDB task is not in loading state then the OPTCMDB loading is done through SessCtrl to the recovered SRDB task.
 
Dynamic Static Rating Categorization Database
When Static-and-Dynamic Content Filtering is enabled, Dynamic SRDB tasks are spawned based on available packet processing cards.
Important: To support dynamic rating, a minimum of three active packet processing cards are required, that will have one Dynamic SRDB. The number of Dynamic SRDBs may increase with an increase in the number of packet processing cards. The load for rating dynamic responses is distributed equally across all the Dynamic SRDBs created.
First one Dynamic SRDB task is created with two Standby SRDBs on the same CPU, then eight Static SRDBs are created, and then more Dynamic SRDB tasks are created if memory is available. A Dynamic SRDB is always created with two Standby SRDBs with it on the same CPU.
The Dynamic Rater Package, which contains the model files (used for language detection and category recognition) and feature counters (used to decide whether or not to evaluate the Web page against the respective model file) are loaded on the SRDB Managers. The rater package is loaded only on the active SRDB and not on the standbys.
The Rater package containing the model files (used for language detection and category recognition) and feature counters (used to decide whether or not to evaluate the Web page against the respective model file) is stored at pcmcia1/cf. After loading the static database, ACS will read the Rater package and load it onto the Dynamic SRDB Managers.
The Rater package will also be loaded on SRDBs on recovery/reconciliation if static-and-dynamic Content Filtering is enabled.
The rater package loaded onto SRDBs can be upgraded using an upgrade CLI, that will look for the upgrade file in the form “rater_f.pkg” at a specific location and if found load the new package onto the SRDBs. On successful loading, the “rater_f.pkg” is replaced with “rater.pkg” and versioned. In case of loading or upgrade failures, appropriate traps are generated.
 
Rater Package Model Files
The real-time analyzer requires a model file that defines the features which are necessary to classify a Web page as belonging to a specific category and language. A model file per category is created by analyzing the traits of thousands of pages of that category and thousands of pages that does not belong to that category. For some categories, a feature counter file is used to decide whether or not to evaluate the Web page against the respective model file.
When URL Blacklisting solution is the only content filtering enabled on a system, no SRDB tasks are spawned at startup. Only when either Category-based Content Filtering is enabled in isolation, or with URL Blacklisting, the SRDB tasks are spawned.
 
Content Rating Rules Update Server
This is a third-party content rating solution for exporting content filtering rules database information to the Category-based Content Filtering system. In addition, while exporting database updates, it collects reports of URLs processed by ECS and Content Filtering services that are reported as unknown in the deployed static rating database. This server analyzes these URLs and provides the rating in future updates for static rating database.
 
This server provides the following supports to Master Content Rating Database Server (MCRDBS) for the content rating function:
 
 
Master Content Rating Database Server (MCRDBS)
The Category-based Content Filtering solution provides a Master Content Rating Database Server to convert the VFMDB to SFMDB. It handles both full and incremental updates and processes them on a configured schedule.
 
This server is also responsible for distribution of SFMDB data files to WEM servers in the customer support infrastructure on a configured interval.
The server is responsible for following functionality as the MCRDBS solution:
 
 
ECS Storage System
The local and remote external storage servers are part of ECS Storage System in the ECS solution architecture.
 
The L-ESS and R-ESS are storage application running on redundant highly available servers that collect and process EDRs and UDRs from which billing events and reports are generated. Either the system pushes the EDR/UDR files to the L-ESS, or the L-ESS fetches them from the system and processes them into formats suitable for billing mediation servers, Report Engine at CDP, and the R-ESS. The R-ESS consolidates the processed EDR/UDR files into a database for report generation through UDR Report Generator or EDR Report Generator at CDP.
When Content Filtering is deployed in conjunction with ECS, the operator has an option of collocating the Central Decision Point (CF-CDP) with an ESS thereby eliminating the requirement of the CF-CDP to fetch a copy of the CF-EDRs from each system running ECS and Content Filtering service. The database generated on an ESS by processing EDR/UDR records is a superset of the database required by a CF-CDP.
Important: For more information on External Storage Systems, refer to the ESS Installation and Administration Guide.
 
RADIUS Server and Policy Manager
The function of the RADIUS Server/Policy Manager in the Content Filtering solution is to provide per-subscriber Content Filtering provisioning information when a subscriber’s session is established. It can also issue a Change-of-Authorization (CoA) to update an in-progress session to modify the Content Filtering policy for a subscriber.
 
The following are the basic functions provided by a RADIUS Server/Policy Manager in the Content Filtering solution:
 
 
Customer-Care Management Interface (CF-CCI)
The Content Filtering solution provides a GUI to provide information to support staff in the operator’s customer-care support center. This interface allows support personnel to quickly address subscribers questions or concerns about policies on their account.
 
The tool provides the following capabilities in real-time:
 
Fields currently supported to display per URL are:
 
Web Element Manager (WEM)
The WEM is a server-based application providing complete element management of the system. The UNIX-based server application works with the network elements within the system using the Common Object Request Broker Architecture (CORBA) standard.
 
Important: For information on WEM administration, refer to the Web Element Manager Installation and Administration Guide.
WEM server must be set up with access to the following networks:
 
For Category-based Content Filtering, the WEM application includes the following features:
 
 
Central Decision Point (CF-CDP) and Report Engine (RE)
The Category-based Content Filtering solution also includes a Central Decision Point (CF-CDP) with Report Engine that can be integrated in an R-ESS of ECS Storage System. The CF-CDP consists of a geographically redundant server hosting the CDP application that may be the same as Remote-External Storage Server in ESS.
 
In the Category-based Content Filtering solution, the CF-CDP performs the following major functions:
 
The primary activity of the CF-CDP is to process CF-EDRs into a database that supports report generation by the WEM, and query processing by the Customer-Care Management application.
In addition, the CF-CDP serves as a repository and distribution node for the optimized content rating master database and incremental updates (OPTCMDB/OPTCMDB-INC). CF-System uses the OPTCMDB to perform the actual Content Rating Function on subscriber traffic. The OPTCMDB database is also used by an instance of the static and dynamic rating engines running on the CF-CDP to provide a functional rating service that is leveraged by the Customer-Care application to display the static rating of a URL and/or corresponding dynamic rating for the URL’s content.
The CF-CDP server provides updated configuration files to the CF-System with the latest revisions to the static categorization database. The Content Filtering application also provides a mechanism to properly distinguish between release versions. The configuration updates are securely transmitted via SFTP over SSH via the out-of-band management network to a SPIO interface and the local management context of the chassis.
Updates to the CF-System occurs on requests or configured periodicity. To further reduce the volume of traffic over the management network, instead of retransmitting the entire SRDB at each update, it is also possible to send small incremented differential files that include only the additional URLs that were added since the previous update.
 
Report Engine (RE)
The Report Generator utility in CF-CDP is a script-based tool responsible for report generation and CF-EDR parsing. A script-based utility generates reports in XML format for content filtering subscribers and the Report Engine server takes care of EDR parsing. The script can be used with cron job for periodic report generation in background. Reports can also be generated from the WEM GUI.
CF-EDR files are pushed from L-ESS to CF-CDP server at a configured time interval and stored in specified data directory on the CF-CDP server.
The Report Engine generates the following types of reports in XML format on the basis of user parameters, event records, and criteria.
 
Overall Summary Report: This is a short summary report of all the activities done between a duration of time. This report includes following schema for subscriber activity summary report:
Subscriber Detailed Report: This is a detailed report in which operators get detailed information about subscriber activities on a Content Filtering system. This report includes all information about a subscriber’s request with following schema for each URL requested:
URL Summary Report: This is a high-level report which provides the list of URLs and the number of times a URL was visited with the following additional schema along with the schema of Summary Report:
 
How Category-based Content Filtering Works
 
The Content Filtering Subsystem integrated into the ACS subsystem consists of two primary elements; an onboard static categorization database and a dynamic rating engine. The filtering service uses the Deep Packet Inspection (DPI) capabilities of the ACS subsystem to classify and partition application or protocol specific flows into virtual sessions.
Content analyzers are used to identify various types of flows such as HTTP, MMS/WAP, and POP3 E-mail. A typical HTTP request for a Web page, for example, invokes TCP and HTTP traffic analyzers. Any HTTP field including URLs or URIs can be identified. When a subscriber session is bound by CSS to an ECS running content filtering service, the URL/URI is extracted and compared against the static categorization database.
The following figure and the steps describe how Category-based Content Filtering works during a subscriber call:
 
Content Filtering Call Flow
Step 1
Step 2
Step 3
Step 4
Step 5
The Policy Manager and/or AAA include following attributes in the Access Accept message:
 
Filter ID or Access Control List Name: Applied to subscriber session. It typically contains the name of the Content Service Steering (CSS) ACL. The CSS ACL establishes the particular service treatments such as Content Filtering, ECS, Traffic Performance Optimization, Stateful Firewall, VPN, etc. to apply to a subscriber session and the service order sequence to use in the inbound or outbound directions. Real-time or delay sensitive flows are directly transmitted to the Internet with no further processing required. In this case, no CSS ACL or Filter ID is included in the Access Response.
SN-CF-Category-Policy: Applied to the subscriber content flow. Policy ID included in this attribute overrides the policy identifier applied to subscriber through rulebase or APN/Subscriber configuration. This content filtering policy determines the action to be taken on a content request from subscriber on the basis of its category. At anytime only one content filtering policy can be associated with a rulebase.
SN1-Rulebase Name: This custom attribute contain information such as consumer, business name, child/adult/teen, etc.). The rulebase name identifies the particular rule definitions to apply. Rulebase definitions are used in ECS as the basis for deriving charging actions such as prepaid/postpaid volume/duration/destination billing and charging data files (EDRs/UDRs). Rulebase definitions are also used in content filtering to determine whether a type of user class such as teenagers should be permitted to receive requested content belonging to a particular type of category such as adult entertainment, gambling or hate sites. Rulebase definitions are generated in the Active Charging Configuration Mode and can be applied to individual subscribers, to domains or on per-context basis.
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Within the system, if the bearer flow is treated by Content Filtering or other in-line services, the SessMgr feeds it to the Content Service Steering (CSS) API. If Content Filtering is the first service touch point, TCP and HTTP traffic analyzers within a given SessMgr utilize deep-packet inspection to extract the requested URL.
Step 13
When only Static Content Filtering is enabled, first the URL is looked-up in the cache maintained at SessMgr for static URL requests, if there is a hit, the category is returned, if its a miss, a URL look-up is performed by an onboard SRDB for static rating.
The redirect server may prompt the subscriber to send additional security credentials in order to access the requested content.
When Static-and-Dynamic Content Filtering is enabled:
 
 
When a request must be sent for dynamic rating, only a single packet in which the HTTP header is complete is sent to any one of the dynamic SRDBs for dynamic rating.
Before sending the response for dynamic rating, the “content-type” is checked and sent only if the content-type is one of the following:
Handling for concatenated and pipelined responses is the same as in Static Content Filtering. The action taken is based on the highest priority category among the pipelined responses.
 
Content Filtering EDRs are the same as for static rating. However if static rating fails and the request goes for dynamic rating, then Content Filtering EDRs will be generated only after dynamic rating has been completed and not when static rating failed.
If the SRDB task is timed out or some other failure happens, the action configured for failure is taken.
Step 14
Step 15
Step 16
 
How URL Blacklisting and Category-based Content Filtering Work Concurrently
Both URL Blacklisting and Category-based Content Filtering can be concurrently enabled in a system. The following describes how URL blacklisting and content filtering are performed on HTTP/WAP traffic when concurrently enabled on a system:
Step 1
When an HTTP/WAP request comes for ACS processing, a check is made to see if the URL Blacklisting feature is enabled. If enabled, the URL is extracted from the incoming request and is matched with the local Blacklist database.
 
Step 2
 
Content Filtering Server Group Support
ECS supports the streamlined ICAP interface to leverage Deep Packet Inspection 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.
In the case of Category-based Content Filtering solution, the application server checks the URL on the basis of its category and other classifications like type, access level and 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 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.
The ACF performs the following functions:
 
For information on configuring the ICAP interface support for external ACF servers, refer to the ICAP Interface Support chapter of the System Enhanced Feature Configuration Guide.
 
External Storage System
ECS supports generation of EDRs/UDRs/FDRs (xDRs). To store generated xDR files, on the ASR 5000 chassis, the system allocates 512 MB of memory on the packet processing card’s RAM. The generated xDRs are stored in CSV format in the /records directory on the packet processing card RAM. These generated xDRs can be used for billing as well as for generation of reports to analyze network usage and subscriber trends. As this temporary storage space (size configurable) reaches its limit, the system deletes older xDRs to make room for new xDRs. Setting gzip file compression extends the storage capacity by approximately 10:1.
 
Because of the volatile nature of the memory, xDRs can be lost due to overwriting, deletion, or unforeseen events such as power or network failure or unplanned chassis switchover. To avoid loosing charging and network analysis information, configure the CDR subsystem in conjunction with the External Storage System (ESS) to offload the xDRs for storage and analysis.
For more information on the ESS, refer to the ESS Installation and Administration Guide.
 
Minimum System Requirements and Recommendations
This section identifies the minimum system requirements for components of the URL Blacklisting / Category-based Content Filtering solutions.
 
Important: The hardware required for these components may vary, depending on the number of clients that require access, components managed, and other variables like EDR generation rate or CDR storage and processing requirements.
Certain basic server requirements for WEM and inPilot are recommended to exploit the CF solution. For information on these system requirements, refer to WEM Installation and Administration Guide and inPilot Installation and Administration Guide.
 
System Requirements for WEM
For information on system requirements for the WEM, refer to the WEM Installation and Administration Guide.
 
System Requirements for CF-CDP
System requirements for CF-CDP:
 
 
1 x 1.2GHz 8 core UltraSPARC T2 processor with 16GB RAM or
Important: If you plan to install software and maintain the servers and applications remotely, it is recommended that you use an X-Windows client.
 
Special Software Requirement for CF-CCI Server Application
 
Apart from other software requirements for CF-CCI application installation, Java Development Kit 5 is required on the server side.
 
WEM Client System Requirements
This sections lists the WEM client system requirements.
 
 
 
CF Customer Care Interface Client Recommendations
Content Filtering - Customer Care Interface Client recommendations:
 
 
 
Additional Requirements on Chassis
The chassis requires the following additional hardware and memory to handle the Content Rating Master Databases; for example, for Category-based Content Filtering OPTCMDB. The memory required may vary with the size of rating databases used for content rating service.
 
 
 

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