Cisco Provisioning Center User's Guide, 4.2
Key Features of Cisco Provisioning Center
Downloads: This chapterpdf (PDF - 194.0 KB) | Feedback

Key Features of Cisco Provisioning Center

Table Of Contents

Key Features of Cisco Provisioning Center


Service Discovery

Topology and Threading

NNI Resiliency

UNI Resiliency

Non-Disruptive Service Modification


Error Reporting

Pre-Provisioning Support


Service Profiles

Service and Network Element Profiles

Prioritization of Attribute Values


Server Hold

Key Features of Cisco Provisioning Center

This chapter provides a brief outline of Cisco Provisioning Center's main features:


Cisco Provisioning Center uploads information (nodes, ports, QoS parameters, cross connects, etc.) from the network and maps that data into the Cisco Provisioning Center Resource Models. It then uses that information as the basis for its end-to-end service provisioning decisions.

Cisco Provisioning Center features various upload options, including single physical port, individual node, and network-wide uploads. To ensure scalable performance during network-wide uploads, Cisco Provisioning Center retrieves data from multiple nodes in parallel wherever possible.

Cisco Provisioning Center's ability to track the network's actual logical and provisionable physical inventory enables accurate service provisioning and minimal order fall out. The uploaded inventory data are also available through the Cisco Provisioning Center GUI, published API, and SQL interfaces to facilitate effective customer care, troubleshooting, asset management, billing reconciliation, and service reporting.

Service Discovery

Through its Upload process, Cisco Provisioning Center loads the detailed configuration of nodes, ports, and service elements into its database. With expected connection service configuration data, typically fed from an external billing system, Cisco Provisioning Center also discovers end-to-end services created using other management vehicles (e.g., manual activation via craft interfaces). Based on an input file, Cisco Provisioning Center's automated Service Discovery process first creates the identified service instances in the Cisco Provisioning Center database. It then matches these service instances to their constituent service elements (loaded during Upload) by following connection identifiers and discovering the service path between termination points.

Through this Service Discovery process, Cisco Provisioning Center also verifies known service instances, identifying and flagging any discrepancies between the network "as planned" and the network "as is". Such discrepancies might include services which are recognized by the billing system but do not exist in the network, or services with missing service elements (i.e., "damaged" services). Where possible, Cisco Provisioning Center automatically repairs damaged services by re-provisioning the service based on its knowledge of network topology and available resources.

While Cisco Provisioning Center automatically performs verification and repair as part of its automated Service Discovery process, these functions are also available for use independently of Service Discovery. You can, for example, explicitly request the verification and/or repair of a specific service instance when you are troubleshooting a problem report.

Topology and Threading

Large networks are often comprised of different subnetworks, such as Frame Relay and ATM networks, connected by links, such as ATM or Frame Relay NNI links. Cisco Provisioning Center maintains this overall network topology by storing the links in its database. Links can exist between networks (inter-networking) or between nodes in a network (intra-networking).

Cisco Provisioning Center automatically determines an optimum path for a new Service object by examining the capacity and availability of the links. This process is called Threading.

Each resource model includes a Threader, which is a function used to choose the best provisioning path for a service across the managed or unmanaged networks. The default Threader performs the following operations in sequence:

1. NNI link discovery—Logical ports must be unlocked, and must support the same protocol

2. Candidate path enumeration—A path must not involve entering a subnetwork that has already been traversed earlier in the path

3. Selection of acceptable paths—For example, all logical ports must have sufficient available bandwidth

4. Assessment of the path cost—weight, transit cost, hop count and composite available bandwidth

5. Prioritization of the paths.

Also, if both endpoints are in the same Local Access Transport Area (LATA) then all intermediate logical ports in the service must be in the same LATA, the geographic area over which the Local Exchange Carrier may provide toll calls.

Manual threading is also supported, altering or bypassing a number of Threader checks (for example, bandwidth). For more information, see the Cisco Provisioning Center Programmer's Guide.

Also, the Threader algorithm can be customized by creating and calling your own Java code. This then becomes custom Threading. For more information, see the Cisco Provisioning Center Programmer's Guide.

NNI Resiliency

Links between subnetworks may fail for various reasons. If a link fails, Cisco Provisioning Center can re-thread the services on the failed link to other available links, based on priorities and policies defined by the service provider. Cisco Provisioning Center provides NNI fail, recover, and rebalance functions as part of an NNI resiliency feature.

For more information, see the "Configuring NNI Resiliency" section.

UNI Resiliency

If a connection failure occurs on a Service endpoint, Cisco Provisioning Center can move the services to a backup logical port, based on priorities defined by the administrator. You can specify the following fail and recover options:

a backup logical port to use when a UNI failure occurs

when to move the services to a backup logical port

when to move them back to the primary logical port.

You can also specify priorities, so that the services are moved in a pre-defined order (or not at all). Those services with higher priorities are more likely to survive a failure.

For more information, see the "Configuring UNI Resiliency" section.

Non-Disruptive Service Modification

The non disruptive service modification (formerly called True Modify) allows you to modify a Service without causing a Service disruption. This minimizes the occurrence of service outages and enhances performance, if the EMS and/or NMS supports the non disruptive service modification operation.

Cisco Provisioning Center implements non-disruptive service modification operations whenever possible. Certain Equipment Modules cannot support these operations or, they may impose specific restrictions on its usage. Restrictions, if any, will be found in specific Equipment Module Configuration Guides.


Cisco Provisioning Center maintains a database which contains a representation of the state of the network(s) being managed. This representation is called the Current view of the network.

When you open a transaction and then create, modify or delete database objects, a Pending view of the object is created in the database. The pending version is tied to the transaction. When the transaction is applied, Cisco Provisioning Center delivers instructions to the EMS or NMS, making the required configuration changes and provisioning the service.

If the delivery is successful, the Pending view becomes the new Current view in the database. However, if delivery to any site affected by a transaction fails, then Cisco Provisioning Center reverses the changes to all sites in that transaction. This process is called rollback. It removes changes made to the network within the context of the transaction.

Under some circumstances, such as EMS failure during processing, rollback may fail, leaving unwanted Service elements in the network. Manual intervention is then required to remove these elements from the network.

Error Reporting

In addition to delivering specific error messages when a transaction fails, Cisco Provisioning Center accumulates errors from the network in transaction specific logs (e.g. audit logs and site error logs). To troubleshoot failed transactions more effectively, you can view a detailed error report from a specific transaction or upload request.

For specific configuration information, refer to the relevant Equipment Module or Service Application documentation.

Pre-Provisioning Support

Cisco Provisioning Center supports pre-provisioned equipment by allowing existing Equipment Modules to upload from pre-provisioned nodes and switches. Service elements that are uploaded from the pre-provisioned network elements are made available for use by new Services created through the Service Applications.

Node objects and network objects include an attribute that can be set to indicate whether or not they are pre-provisioned.

For more information, see the "Configuring Pre-Provisioned Service Elements" section.


Profiles are used to store attribute values for creating service elements and objects, so that it is not necessary to supply values for all of the attributes when activating a service. There are four types of profiles in Cisco Provisioning Center:

Service profiles

Service element profiles

Fabric profiles

Network element profiles

A profile contains most of the same attributes as the corresponding object. Those attributes of the object that are not included in the profile, are expected to be unique for each object. For example, the DLCI on a Frame Relay PVC cannot be a profiled attribute. Similarly, an object's name cannot be profiled.

The attributes of a profile are referred to as initial value attributes because they are used to assign the initial values to the corresponding object. Once a new object has been created based on a profile, changes to profile attribute values do not cause any changes to objects that have already been created. The only time the profile attributes affect the object is when you create a new object or when you reassign a profile to an existing object.

Service Profiles

Service profiles are used to store attribute values that are normally used when activating a service. You simply supply the name of a service profile, and the Service Application itself retrieves the attribute values from the profile.

Service and Network Element Profiles

Service element, network and node profiles are used to store the vendor-specific attributes for service and network elements. There is a corresponding profile for each type of service element, network and node that the Equipment Module supports.

A service element profile can be specified when you are creating service elements. You can also specify a service element profile to be used when activating services.

Note Default profiles are included with Cisco Provisioning Center and can be used when activating Services. These profiles are intended for evaluation purposes only. You should create your own profiles based on your own network configuration and service offerings.

Prioritization of Attribute Values

Attribute values for Services can be derived from various sources (i.e., from the Service object Object View, the Service profile, or the Service element profile). For more information on how attribute values from different sources are prioritized and used by the Threader, refer to the relevant Equipment Module or Service Application documentation.


To enhance system security, passwords and other sensitive data that are listed in system files, output files and in database tables are now encrypted. This feature is intended to hide sensitive data from unauthorized users. Data encryption is used to scramble sensitive data, such as passwords, after the data has been created as clear text.

Sensitive data will always be encrypted when the data is written to the database.

The following information will now be encrypted automatically:

The CORBA pass phrase file

The value of the environment variable $CCPPASSWORD will be the encrypted version of the database password, and the configuration variable SYRTM.dbUserPassword will expect the password to be encrypted.

Sensitive data, as defined by type=ENCRYPT in the object description files (ODF), will always be encrypted automatically before it is written to the database.

Sensitive data must be encrypted before it can be used as search criteria by getList or getFullList. Data that is encrypted can only be used as search criteria with the "equals" operator. Refer to the Cisco Provisioning Center Programmer's Reference for details on using getList or getFullList.

Note Encrypted data is never decrypted automatically after it is read from the database. Therefore, getValue and getAttributes will always return sensitive data in an encrypted form.

Sensitive data transferred from the GUI Web Client to GUI Web Server are encrypted using standard web-based encryption in the Web Client and decryption in the Web Server, if SSL is enabled.

Sensitive data is always encrypted by the Upload engine before it is compared against the encrypted value of the attribute in the database.

Data decryption is used to unscramble the sensitive data when the original, clear text is required. This may be the case if you are passing information to an EMS/NMS that is expecting the unencrypted data.

SYCCSServer and the standard database utilities (such as sycheckdb, syconvertoid, sydumptable, sysearchdb, etc.) will decrypt the database password specified by $CCPPASSWORD before accessing the database.

Refer to the Cisco Provisioning Center Programmer's Guide for details on using the encryption utility.

Server Hold

In many cases, it would be useful to suspend Cisco Provisioning Center activity without actually shutting down the system.

When the system load rises increased beyond what the system can support and it is no longer initiating CR or UR processing.

When implementing graceful shutdown, i.e. permit existing processes to complete, but disallow new processes from starting prior to shutdown.

Suspending the system prior to backup. This is done instead of a shutdown, since terminating Cisco Provisioning Center may require that the OSS and gateway systems also be shutdown, thus requiring an expensive global restart.

Currently, there are three hold types:

SY: PROCESSING_HOLD - stop Cisco Provisioning Center from processing requests.

SY: SESSION_HOLD - prevent you from opening a session.

SY: SYSTEM_HOLD - prevent Cisco Provisioning Center from initiating new work of any kind.

For the Cisco Provisioning Center engine, these hold types are used to provide the following actions actions:

NO_PROCESS—Uses two hold types (SY: PROCESSING_HOLD and SY: SYSTEM_HOLD) to prevent CRs/URs from starting. CRs and URs that are already processing will be allowed to run to completion. Specifically, when this action is performed:

scheduled CRs which have not already started, are delayed

applied CRs are blocked, i.e. set to Waiting state

applied URs are blocked, i.e. set to Waiting state

NO_SESSION Also uses two hold types (SY: SESSION_HOLD and SY: SYSTEM_HOLD) to prevent sessions from modifying the database. Specifically:

requests for new sessions are failed with an error. There are exceptions for AbortCleanUp, ChangeInitiator and FFS GuardianAngel.

attempts to open a CR result in an error

existing sessions which have an already open CR will not be affected.

Refer to the CPC Administration Guide for more details on using these features.