The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco Policy Suite
(CPS) provides a framework for building rules that can be used to enforce
business logic against policy enforcement points such as network routers and
packet data gateways. For example, a prepaid customer (one who pays as they go)
might be denied service or prompted to top-up when their quota has expired,
whereas a postpaid customer (one who has an ongoing billing relationship with
the service provider) might only have their service downgraded or be
automatically billed for additional data when their particular quota has
expired.
CPS allows service
providers to create policies that are customized to their particular business
requirements through the use of the CPS Policy Builder, a web-based tool with a
graphical user interface (GUI) that allows for rapid development of innovative
new services.
The Policy Builder GUI
supports both configuration of the overall CPS cluster of virtual machines
(VMs) as well as the configuration of services and advanced policy rules. The
following sections introduces the main aspects of the PB GUI as laid out in
three tabs on the upper right of the interface: Reference Data, Services and
Policies.
Reference
Data
The Reference Data tab
of the PB GUI provides access for configuring various aspects of the system in
order to make the system ready for operation. Reference Data are used to not
only configure the system, but are also used to provide settings and parameters
that are referenced by policy rules across various services; for example,
Account Balances and Notifications are configured as Reference Data but are
then referenced and reused by multiple services as needed. Details of the
various Reference Data configuration options are described in more detail in
other chapters of this guide.
The Reference Data tab
contains static system, network, and template definition. It is not directly
related to policy, services, or use cases, but does define the reference points
for the following types of information:
Systems, cluster,
and instance data
Jdbc query string
definitions
Balance and quota
definitions
Diameter agents,
clients, and defaults information
Query strings
Custom reference
data tables (custom look up tables such as apn names)
Notification
addresses and text templates
Policy reporting
criteria
Subscriber data
repositories
Tariff switch
times
Fault list - For
more information, refer to
CPS Operations
Guide
for this release.
Services
The Services tab
allows for creation of reusable policy rules that control how subscribers are
granted network services, quota and notifications. Services are broken down
into three core areas: Domains, Services and Use Case Templates. The following
section provides an overview of the Services tab, however detailed instructions
on how to build a service are covered in later chapters of this guide.
The creation of a new
service begins with creating a Use Case Template (UCT) for the service. UCTs
consist of Service Configurations specific to the service that will be created.
For example, a Service Configuration might provide for the setup of a Gx Rule
or Basic QoS. The UCT is also used to configure Use Case Initiators (UCI) which
are instructions on when a specific Service Configuration should be in effect.
An example of the UCI might be “only send this Gx Rule when the account balance
is depleted”. Multiple UCIs can be configured for each Service Configuration
allowing for complex logic as to when the configuration should or should not be
in effect.
Once a UCT and
associated UCIs are defined, it becomes the basis for Service Options, which
are specific instances of the UCT that are populated with data specific to the
service. Multiple Service Options can be created from a single UCT; for
example, a UCT that provides for passing QoS parameters can be reused with
different QoS values for different customers. Multiple Service Options can be
layered to create the end Service.
The Domains panel
within the Services tab handles the initial interaction of the client device
with the policy engine, and covers tasks including client authentication,
default provisioning of unknown clients and qualifying a client for particular
system defaults and services.
For more information on the
Services tab, refer to the
Services
chapter.
Policies
While the Services
tab, through Use Case Templates and Service Options, makes it easy to create
reusable and extensible services, the Policies tab allows direct access to the
underlying policy engine. The Policies tab holds the CPS core system Blueprint,
which is composed of various Extension Points that break the policy engine flow
into sections that occur within the execution of the policy. For example, the
point in the policy flow where a Gx connection is received, parsed, and
processed before the point in the policy flow where the related subscriber data
is evaluated.
Within the various
Extension Points are Policies that define Conditions (events and data from the
policy flow and external systems) that can then trigger Actions (manipulation
of data and communication back to external systems).
Note that the
configuration of services for most deployments will be handled through use of
the Reference Data and Services tabs; advanced policies as defined on the
Policies tab and discussed above are only required for complex deployments. It
is recommended that only experienced users access the Policies tab as errors in
custom policies can have negative impact on the operation of the system.
Detailed discussion of custom policies is outside of the scope of this
document.
By default, the Policies and Blueprint tabs are disabled.
Important
The Policy Builder offers the Blueprint section under Policies tab to enable Cisco recommended changes to the Policy Engine. Changes made without Cisco guidance are not supported and can
result in poor performance, platform instability, or reduced capacity.
Enabling POLICIES tab
In Policy Builder, Tools > Preferences to open Preferences pop-up window.
Select Show Policies (custom configuration) editing options? and click Apply.
Warning pop-up dialog box opens up.
Click Accept so that POLICIES tab is visible in Policy Builder.
Enabling BLUEPRINTS tab
For BLUEPRINTS tab to be visible in Policy Builder, Show Policies (custom configuration) editing options? must be checked.
Select Show blueprint editing options? and click Apply.
Warning pop-up dialog box opens up.
Click Accept so that BLUEPRINTS tab is visible in Policy Builder.
Note
In case the POLICIES checkbox is unchecked while BLUEPRINTS checkbox is checked, the BLUEPRINTS checkbox is unchecked forcefully and the BLUEPRINTS tab is not visible.
Summary of Policy
Tab Capabilities
Conditional rules within
specified Extension Points (Condition/Action)
Trigger specific actions from an extensive catalog of Use Case
Initiators
Evaluate and manipulate session data as part of making policy
decisions and returning services data to downstream systems
Advantages
Allows for handling complex
policy situations without writing custom code
Support for custom or unusual business rules
Considerations
Building custom policies requires
a deep understanding of the call flow and underlying CPS platform
Due to the flexibility of the Policy Builder, it is possible to
create conflicting policies that can have a negative impact on system
performance
Accessing the Policy
Builder
The Policy Builder is the web-based client interface for the configuration of policies to the Cisco Policy Suite. Initial
accounts are created during the software installation with the default CPS install username as qns-svn and password as cisco123.
URL to Access Policy Builder Interface:
For HA: https://<lbvip01>:7443/pb
CPS enables users to be aware of its current privileges while accessing Policy Builder as described below:
If a user has read-write privilege then ADMIN is displayed adjacent to user name in the GUI.
If a user has read-only privilege then READONLY is displayed adjacent to user name in the GUI.
The hostname is displayed in the login dialog box and system banner to differentiate between open windows while performing
any operation of the CPS system. It indicates which system is being modified and prevents any errors or misconfigurations.
The hostname is displayed when the parameter -Dhostname=lab is configured in pb/qns.conf files. If it is not configured in the qns.conf file, it is displayed as a result of the command
"hostname" on the server.
The hostname is displayed in the login panel only when the following argument is set to true:
-DshowSitenameLogin
Enable TACACS+ authentication for Policy Builder by enabling PAM authentication (set -DdisablePAMAuthentication to false)
and enabling TACACS+ along with tacacs_on_ui flag set to true in Configuration.csv file.
Enabling Logout Option
To enable the logout option in Policy Builder, the following parameter must be configured in /etc/broadhop/pb/pb.conf file.
–DlogoutLinkVisibility
To view the Logout link on Policy Builder banner, set the parameter to true value.
To support backward compatibility, -DlogoutLinkVisibility flag is not present in pb.conf by default. If flag is not present, then the value is considered as false.
When the parameter is configured or updated, restartall.sh is required.
Caution
Executing restartall.sh will cause messages to be dropped.
Policy Builder Field Value Validation
The Policy Builder uses the eCore framework to configure UI fields and their data types. The Policy Builder validation is
triggered when a field is updated. The validation depends on the data type and valid value that you have defined for the field.
When you start the Policy Builder, the last recorded valid value defined in the eCore is set as the default value. If the
value is not set in the eCore, the valid value is taken based on the eCore data type. For numeric data types, the Policy Builder
displays 0 as a default value. For string data types, the Policy Builder displays null (empty) as a default value.
The Policy Builder validates the value that is configured in the field.
When you enter a value in the field and the value passes validation, the newly entered value is recorded as the last valid
value. If the validation fails, the last recorded valid value is reverted.