Basic Features and Functionality
Shallow Packet Inspection
Shallow packet
inspection is the examination of the layer 3 (IP header) and layer
4 (for example, UDP or TCP header) information in the user plane
packet flow. Shallow packet analyzers typically determine the destination
IP address or port number of a terminating proxy.
Deep Packet Inspection
Deep-packet
inspection is the examination of layer 7, which contains Uniform
Resource Identifier (URI) information. In some cases, layer 3 and
4 analyzers that identify a trigger condition are insufficient for
billing purposes, so layer 7 examination is used. Whereas, deep-packet
analyzers typically identify the destination of a terminating proxy.
For example, if the
Web site “www.companyname.com” corresponds to
the IP address 1.1.1.1, and the stock quote page (www.companyname.com/quotes) and
the company page (www.companyname.com/business) are chargeable
services, while all other pages on this site are free. Because all
parts of this Web site correspond to the destination address of
1.1.1.1 and port number 80 (http), determination of chargeable user
traffic is possible only through the actual URL (layer 7).
DPI performs packet
inspection beyond layer 4 inspection and is typically deployed for:
Charging Subsystem
ECS has protocol analyzers
that examine uplink and downlink traffic. Incoming traffic goes
into a protocol analyzer for packet inspection. Routing rules definitions
(ruledefs) are applied to determine which packets to inspect. This
traffic is then sent to the charging engine where charging rules
definitions are applied to perform actions such as block, redirect,
or transmit. These analyzers also generate usage records for the
billing system.
Traffic Analyzers
Traffic analyzers in
ECS are based on configured ruledefs. Ruledefs used for traffic
analysis analyze packet flows and create usage records. The usage
records are created per content type and forwarded to a prepaid
server or to a billing system.
The Traffic Analyzer
function can perform shallow (layer 3 and layer 4) and deep (above layer
4) packet inspection of IP packet flows. It is able to correlate
all layer 3 packets (and bytes) with higher layer trigger criteria
(for example, URL detected in an HTTP header). It also performs stateful
packet inspection for complex protocols like FTP, RTSP, and SIP
that dynamically open ports for the data path and this way, user
plane payload is differentiated into “categories”.
Traffic analyzers can also detect video streaming over RTSP, and
image downloads and MMS over HTTP and differential treatment can
be given to the Vcast traffic.
Traffic analyzers
work at the application level as well, and perform event-based charging without
the interference of the service platforms.
The ECS content analyzers
can inspect and maintain state across various protocols at all layers
of the OSI stack. The ECS supports inspecting and analyzing the
following protocols:
Apart from the above
protocols, ECS also supports analysis of downloaded file characteristics
(for example, file size, chunks transferred, and so on) from file
transfer protocols such as HTTP and FTP.
How ECS Works
This section
describes the base components of the ECS solution, and the roles
they play.
Content Service Steering
Content Service
Steering (CSS) enables directing selective subscriber traffic into
the ECS subsystem (in-line services internal to the system) based
on the content of the data presented by mobile subscribers.
CSS uses Access Control
Lists (ACLs) to redirect selective subscriber traffic flows. ACLs
control the flow of packets into and out of the system. ACLs consist
of “rules” (ACL rules) or filters that control
the action taken on packets matching the filter criteria.
ACLs are configurable
on a per-context basis and applies to a subscriber through either
a subscriber profile (for PDSN) or an APN profile (for GGSN) in
the destination context.
IMPORTANT:
Protocol Analyzer
The Protocol
Analyzer is the software stack responsible for analyzing the individual
protocol fields and states during packet inspection.
The Protocol Analyzer
performs two types of packet inspection:
The Protocol Analyzer
performs a stateful packet inspection of complex protocols, such
as FTP, RTSP, and SIP, which dynamically open ports for
the data path, so the payload can be classified according to content.
The Protocol Analyzer
is also capable of determining which layer 3 packets belong (either directly
or indirectly) to a trigger condition (for example, URL). In cases
where the trigger condition cannot be uniquely defined at layers
3 and 4, then the trigger condition must be defined at layer 7 (that
is, a specific URL must be matched).
Protocol Analyzer Software Stack
Every packet
that enters the ECS subsystem must first go through the Protocol
Analyzer software stack, which comprises of individual protocol
analyzers for each of the supported protocols.
Rule Definitions
Rule definitions
(ruledefs) are user-defined expressions based on protocol fields
and protocol states, which define what actions to take on packets
when specified field values match.
Rule expressions may
contain a number of operator types (string, =, >, and so
on) based on the data type of the operand. For example, “string” type
expressions like URLs and host names can be used with comparison
operators like “contains”, “!contains”, “=”, “!=”, “starts-with”, “ends-with”, “!starts-with” and “!ends-with”.
In 14.0 and later releases, ECS also supports regular expression
based rule matching. For more information, refer to the Regular Expression Support
for Rule Matching section.
Integer type expressions
like “packet size” and “sequence number” can
be used with comparison operators like “=”, “!=”, “>=”, “<=”.
Each ruledef configuration consists of multiple expressions applicable
to any of the fields or states supported by the respective analyzers.
Ruledefs are of the
following types:
IMPORTANT:
When a ruledef is
created, if the rule-application is not specified for the ruledef,
by default the system considers the ruledef as a charging ruledef.
Ruledefs support a
priority configuration to specify the order in which the ruledefs
are examined and applied to packets. The names of the ruledefs must
be unique across the service or globally. A ruledef can be used
across multiple rulebases.
IMPORTANT:
Ruledef priorities
control the flow of the packets through the analyzers and control
the order in which the charging actions are applied. The ruledef
with the lowest priority number invokes first. For routing ruledefs,
it is important that lower level analyzers (such as the TCP analyzer)
be invoked prior to the related analyzers in the next level (such
as HTTP analyzer and S-HTTP analyzers), as the next level of analyzers
may require access to resources or information from the lower level.
Priorities are also important for charging ruledefs as the action
defined in the first matched charging rule apply to the packet and
ECS subsystem disregards the rest of the charging ruledefs.
Each ruledef can be
used across multiple rulebases, and up to 2048 ruledefs can be defined in
a charging service.
Ruledefs have an expression
part, which matches specific packets based upon analyzer field variables.
This is a boolean (analyzer_field operator value) expression
that tests for analyzer field values.
Example
The following is an
example of a ruledef to match packets:
–or–
In the following example
the ruledef named “rule-for-http” routes packets
to the HTTP analyzer:
Where, rule-for-http has
been defined with the expressions: tcp either-port = 80
The following example
applies actions where:
ruledef port-80
tcp
either-port = 80
rule-application routing
exit
ruledef bbc-news
http
url starts-with http://news.bbc.co.uk
rule-application charging
exit
ruledef catch-all
ip
any-match = TRUE
rule-application charging
exit
charging-action free-site
content-id 100
[ ... ]
exit
charging-action charge-by-duration
content-id 101
[ ... ]
exit
rulebase standard
[ ... ]
route
priority 1 ruledef
port-80 analyzer http
action
priority 101 ruledef
bbc-news charging-action free-site
action
priority 1000 ruledef
catch-all charging-action charge-by-duration
[ ... ]
exit
The following figure
illustrates how ruledefs interact with the Protocol Analyzer Stack
and Action Engine to produce charging records.
Packets entering the
ECS subsystem must first pass through the Protocol Analyzer Stack where
routing ruledefs apply to determine which packets to inspect. Then
output from this inspection is passed to the charging engine, where
charging ruledefs apply to perform actions on the output.
Routing Ruledefs and Packet Inspection
The following figure
and the steps describe the details of routing ruledef application
during packet inspection.
- The packet is redirected to ECS based on the ACLs in the subscriber’s template /APN and packets enter ECS through the Protocol Analyzer Stack.
-
Packets entering
Protocol Analyzer Stack first go through a shallow inspection by
passing through the following analyzers in the listed order:
- Bearer Analyzer
- IP Analyzer
-
ICMP, TCP, or UDP
Analyzer as appropriate
IMPORTANT:
- The fields and states found in the shallow inspection are compared to the fields and states defined in the routing ruledefs in the subscriber’s rulebase. The ruledefs’ priority determines the order in which the ruledefs are compared against packets.
- When the protocol fields and states found during the shallow inspection match those defined in a routing ruledef, the packet is routed to the appropriate layer 7or 7+ analyzer for deep-packet inspection.
-
After the packet
has been inspected and analyzed by the Protocol Analyzer Stack:
- The packet resumes normal flow and through the rest of the ECS subsystem.
- The output of that analysis flows into the charging engine, where an action can be applied. Applied actions include redirection, charge value, and billing record emission.
Charging Ruledefs and the Charging Engine
This section describes
details of how charging ruledefs are applied to the output from
the Protocol Analyzer Stack.
The following figure
and the steps that follow describe the process of charging ruledefs
and charging engines.
- In the Classification Engine, the output from the deep-packet inspection is compared to the charging ruledefs. The priority configured in each charging ruledef specifies the order in which the ruledefs are compared against the packet inspection output.
- When a field or state from the output of the deep-packet inspection matches a field or state defined in a charging ruledef, the ruledef action is applied to the packet. Actions can include redirection, charge value, or billing record emission. It is also possible that a match does not occur and no action will be applied to the packet at all.
Regular Expression Support for Rule Matching
This section describes
ECS support for regular expression (regex) rule matching.
In this release, ECS supports
regex rule matching only for the following string-based rules:
The following table lists
the special characters that you can use in regex rule expressions.
Table 1. Special Characters
Supported in Regex Rule Expressions
| Regex Character | Description |
|---|---|
|
*
|
Zero or more characters
|
|
+
|
Zero or more repeated
instances of the token preceding the +
|
|
?
|
Match zero or one character
For example, if you want
to match the string “xyz<any one character>pqr”, you
must configure it as:
http host regex “xyz\077pqr”
In another example, if
you want to exactly match the string “url?resource=abc”,
you must configure it as:
http uri regex "url\\\077resource=abc"
Where, the first “\” (backslash)
is for the escaping of “?”, and then “\077” for specifying “?” to
the CLI.
|
|
\character
|
Escaped character
|
|
\?
|
Match the question mark
(\<ctrl-v>?) character
|
|
\+
|
Match the plus character
|
|
\*
|
Match the asterisk character
|
|
\a
|
Match the alert (ASCII
7) character
|
|
\b
|
Match the backspace (ASCII
8) character
|
|
\f
|
Match the form-feed (ASCII
12) character
|
|
\n
|
Match the new line (ASCII
10) character
|
|
\r
|
Match the carriage return
(ASCII 13) character
|
|
\t
|
Match the tab (ASCII 9)
character
|
|
\v
|
Match the vertical tab
(ASCII 11) character
|
|
\0
|
Match the null (ASCII
0) character
|
|
\\
|
Match the backslash character
|
|
Bracketed range [0-9]
|
Match any single character
from the range
|
|
A leading ^ in
a range
|
Do not match any in the
range. All other characters represent themselves.
|
|
.\x##
|
Any ASCII character as
specified in two-digit hex notation.
For example, \x5A
yields a “Z”.
|
|
|
|
Specify OR regular expression
operator
For example, if you want
to match the string pqr OR xyz, you must configure it as:
http host regex "pqr|xyz".
|
The following are some
examples of the use of regex characters in rule expressions:
How it Works
This section describes
how regex rule matching works.
Limitations and Dependencies
This section lists
known limitations and restrictions to regex rule matching.
-
Addition, modification, and deletion of regex ruledefs will result in rebuilding of regex engines, which is time consuming and resource intensive. While the engines are being rebuilt, rule-matching based on the old engines and old configurations may yield inconsistent results.Addition, modification, and deletion of action priority lines inside the rulebase has no impact on the regex engines. The regex engines remain intact and the removed action priorities from the rulebase are ignored during rule matching. Similarly, addition, modification (adding or removing ruledefs from it), or deletion of a group-of-ruledefs has no impact on regex engines.
-
-
Avoid configuring “xyz*” or “*xyz*” type of regex rule expressions as they are known to consume large memory. Instead, configure Aho-Corasick rules using "starts-with xyz" or "contains xyz" constructs, which comparatively consume less memory. The “starts-with” and “contains” operators are specially tailored for these types of operations, and work much faster (with lot less memory) than the corresponding “regex xyz*” or “regex *xyz*” operators. Hence, it is recommended that the “starts-with” and “contains” approach be preferred.
-
-
-
Avoid deleting ruledefs at heavy loads, instead remove them from the required rulebases using the no action priority <action_priority> CLI command in the ACS Rulebase Configuration Mode. Doing so has no impact on regex building, although it uses additional memory there is no impact on traffic processing.
-
Group-of-Ruledefs
Group-of-Ruledefs
enable grouping ruledefs into categories. When a group-of-ruledefs
is configured in a rulebase, if any of the ruledefs within the group
matches, the specified charging-action is applied, any more action
instances are not processed.
A group-of-ruledefs
may contain optimizable ruledefs. Whether a group is optimized or
not is decided on whether all the ruledefs in the group-of-ruledefs
can be optimized, and if the group is included in a rulebase that
has optimization turned on, then the group will be optimized.
When a new ruledef
is added, it is checked if it is included in any group-of-ruledefs,
and whether it needs to be optimized, and so on.
The group-of-ruledefs
configuration enables setting the application for the group (group-of-ruledefs-application
parameter). When set to gx-alias the group-of-ruledefs is expanded
only to extract the rule names out of it (with their original priority
and charging actions) ignoring the field priority set within the
group. This is just an optimization over the PCRF to PCEF interface
where there exists a need to install/remove a large set
of predefined rules at the same time. Though this is possible over
the Gx interface (with a limit of 256) it requires a lot of PCRF
resources to encode each name. This also increases the message size.
This aliasing function
enables to group a set of ruledef names and provides a simple one name
alias that when passed over Gx, as a Charging-Rule-Base-Name AVP,
is expanded to the list of names with each rule being handled individually.
From the PCEF point of view, it is transparent, as if the PCRF had
activated (or deactivated) those rules by naming each one.
Rulebase
A rulebase
allows grouping one or more rule definitions together to define
the billing policies for individual subscribers or groups of subscribers.
A rulebase is a collection
of ruledefs and their associated billing policy. The rulebase determines
the action to be taken when a rule is matched. A maximum of 512 rulebases
can be specified in the ECS service.
It is possible to
define a ruledef with different actions. For example, a Web site
might be free for postpaid users and charge based on volume for
prepaid users. Rulebases can also be used to apply the same ruledefs
for several subscribers, which eliminate the need to have unique
ruledefs for each subscriber.
Rulebase List
A rulebase list
allows grouping one or more rulebases together, enabling the Online
Charging System (OCS) to choose the rulebase for a subscriber from
the rulebase list.
A rulebase list enables
a list of rulebases to be sent to the OCS over the Gy interface
using a buffer. The OCS can then select a specific rulebase from
the rulebase list, and apply the ruledefs and billing policies associated
with that rulebase to subscribers.
Rulebase lists are
created and configured in the ACS Configuration Mode. The number
of rulebase lists and rulebases added is limited to 256 bytes. When
a subscriber call is connected, the Session Manager provides the
list of rulebase names to the OCS, which chooses the rulebase to
be used for the subscriber session from the list.
In case the OCS is
not reachable, the rulebase configured as the default will be used.
CAUTION