|
|
This chapter describes the general concepts of Cisco Provisioning Center. If you will be using CPC as an Operator, Administrator, or Network Manager, the information in this chapter will help you use CPC more effectively.
The key concepts for CPC are discussed in three major functional areas:
Configuration management is the set of features that allow you to view and modify the software-definable attributes of the managed elements of your network, such as nodes and ports.
Change management is the set of features that help you to manage the general process of deploying changes in your network. Change management is not specific to any particular type of managed element, but applies to the overall change process.
To provision a network service, such as a Frame Relay service, it is often necessary to change the configuration of two or more managed elements in the network and to ensure that the resulting configurations are mutually consistent. The phrase "single-step service provisioning" refers to the ability to configure such a network service as if it was a single change to the network.
CPC provides single-step service provisioning by combining a central database with a powerful change control paradigm. The changes that can affect multiple Network elements in a single Transaction.
In CPC, you do not make configuration changes to the network directly. First you apply changes to a model of the network stored in the CPC central database. Once a set of changes is completely specified in the database and verified for correctness, you apply it to the real network as a single Transaction, which either succeeds completely or is rolled-back completely.
The CPC database models the configuration of all relevant managed elements in the network, so it is possible to configure and automatically validate complex changes, including those involving multiple switches. This leads to more reliable network management with fewer configuration errors and network outages.
CPC permits more than one Operator to specify configuration changes at the same time without creating conflicts. Each Operator is made aware of changes being specified by other Operators and is prevented from specifying a change that would impact another change being specified.
Similarly, when changes have been scheduled and are being downloaded and activated in the network, CPC prevents the kind of network outages that can occur when several related network attributes are being changed concurrently.
The CPC database stores a description of the network configuration in the form of data items called domain objects (or simply objects). Objects can represent physical Network elements such as communications ports and circuits, as well as logical Network elements that may be reflected in the attributes of several physical elements. This database representation of the network is called an object model.
The object model reflects the containment, association, and connection relationships between objects. The relationship between a node and a port is an example of a containment relationship: the node contains ports. An example of an association is the relationship between a logical port and a physical port to which it belongs. A PVC is an example of a connection relationship: the PVC connects two ports.
Even though the definition of a PVC must be configured into two separate network nodes, it is represented in the CPC object model as a single domain object. When a PVC is added, changed, or deleted, CPC automatically updates both affected nodes in the network and guarantees the consistency of the resulting configuration.
The CPC version concept presents you with different views of an object's configuration based on the object's history of configuration changes. CPC supports two versions of a particular object's configuration: current and pending.
The current version of an object corresponds to the configuration of the object as it exists in the network.
The pending version is the version being prepared by you which has not yet been sent to the network or is in the process of being applied to the network. Each domain object can have, at most, one pending version at any one time.
You can modify and save a pending version repeatedly to the CPC database without affecting the object's configuration in the network.
You can only see the pending version if the Transaction used to create that version is open for that user. You will see the current version for all other objects that have not been updated in that Transaction.
The Management Domain (MD) and Virtual Private Network (VPN) attributes are available for selected CPC objects. These attributes are represented only in the CPC database; they are not represented in the network.
The MD and VPN attributes of objects are used by CPC security, to restrict access by Operators to specific sets of domain objects. For more information about security, refer to the chapter titled "Administration" in this guide.
There are several types of objects in the database, as described below (Note that Fabric elements and Service elements are collectively known as Network elements)
Fabric elements represent the hardware and software of the network, such as nodes and ports, upon which services can be laid. These objects are maintained by Administrators, who have read/write access to them. Some objects are uploaded into the database ("discovered") whereas others representing topology are entered manually or through scripts. Fabric elements are read-only to Operators, who create Service objects attached to them.
Service elements represent the individual low-level objects (such as VCs, and PVCs) which are created and modified in order to provision services. Service elements are manipulated by Service objects and are applied to the network under change control. Service elements can also be uploaded.
Profiles are used to store default attribute values for Service elements, such that it is not necessary for a Service object to supply values for all of the attributes. Instead the Service object can supply the name of a profile, and the Service element itself retrieves the individual attribute values from the profile. In this way, reusable Service element definitions can be created.
Profiles can be used in this way to specify equipment-specific values so that the Service object does not have to be aware of the equipment that it is using.
An example is "Gold", "Silver" and "Bronze" profiles for PVCs, containing different values for Class of Service (CoS) attributes. The Service specifies whether it requires "high", "medium" or "low" CoS without having to understand the details of how CoS is implemented.
An Administrator is given write access to profiles, and can pre-create and maintain them.
Service objects represent the service being requested.
Service object profiles (or Service profiles) are used to store default attribute values for Service objects, such that it is not necessary for an Operator to supply values for all of the attributes. The Service object can supply the name of its profile, and the Service object itself retrieves the individual attribute values from the profile. In this way stock, reusable Service object definitions can be created.
Profiles can be used in this way to specify Service object default values so that the Operator does not have to specify all values.
An Administrator is given write access to profiles, and can pre-create and maintain them.
Additional objects are stored in the database by the CPC Engine in order to provide change management. These objects include Transactions, Sites and Upload Requests (URs).
The CPC Graphical User Interface (GUI) consists primarily of Subset Viewer and Object Viewers that display key attributes of objects and allow you to invoke functions with menus and buttons.
In general, an object-action paradigm is used: that is, you locate an object, then use a menu or button to perform an action on it. CPC represents Services and the underlying objects from which they are built in a similar fashion.
From a Subset Viewer, you can specify search criteria and use the get list button to search for objects that match specific criteria. The Subset Viewer displays the attributes of objects one object per row and one attribute per column. You can also created a new service and modify or delete an existing service by typing new or revised values into the attribute cells, if necessary, and then clicking on the appropriate button.
From the Object Viewer, you can perform all of the operations available within the Subset Viewer as well as access other attributes not available in the Subset Viewer.
A session is a single execution thread in CPC. CPC supports multiple parallel sessions, which can be automated (flow-through) or interactive. Each session has an associated user id. This user id defines the security permissions associated with the session. For more information about security permissions, refer to the chapter titled "Administration". in this Guide.
Service objects and configuration objects are updated within the context of a session. The Session Manager is responsible for managing sessions with tasks such as creating and deleting sessions.
The flow-through application can manage its own sessions by creating sessions as needed, distributing work among the sessions as desired, and destroying the sessions on exit. The flow-through application is able to work through the same session as the current interactive session, a specified session where there is no interactive session, or in multiple sessions at the same time.
When running in conjunction with the current interactive session, CPC works using the GUI's session (as defined by the DISPLAY environment variable) so that changes being made by CPC are visible to the Operator through the GUI. The result of sharing a session is that the GUI and the flow-through application have the same Transaction context: if the GUI has opened a Transaction prior to the start of the flow-through application, the Transaction is opened to the flow-through application as well. The flow-through application can view and modify objects under that Transaction.
Transactions in CPC are implemented using Change Requests (CR), which have an associated audit log and can be examined by an operator to determine the history of the change. Underlying each transaction is a CR that carries out the specified changes.
Figure 2-1 below illustrates the Transaction states and the functions or conditions that trigger the state transitions.
A Service Object starts a Transaction, which creates a new CR and puts it into the APPROVED state. The Service Object may now open the CR and begin updating the configuration of the network elements to be included in this CR. When all updates for a given CR are complete, the Service Objects invokes the apply function to set the CR stated the SCHEDULED.
With the CR OPEN, updates made to the database representation of the configuration will be associated with this CR. When an object is modified, CPC automatically creates a pending version of that object and associates that version with the open CR. When the Service closes the CR, it returns to the APPROVED state. Service may close and reopen the same CR indefinitely until all required network element changes have been made.
The CR state remains PROCESSING until all sites have SUCCEEDED. During processing the CR may temporarily enter a WAITING state if it must wait for resources. At the end of the processing phase, if one or more sties report a FAILED condition then the CR is sent to the REJECTING state (the CR passes through an immediate failed state, which is rejected by CPC).
Once all sites have been activated and confirmed, the system will commit the changes (i.e., make the pending versions of the network elements, the current versions.) During this activity the CR is in the COMMITTING state. On completion the CR state is set to SUCCEEDED.
If errors are encountered during the processing or committing phases, CPC discards any updates that may have been specified, deleting the pending version of each updated network element and roll-backs all sites to their previous states. During this activity, the CR is in the REJECTING state. On completion, the CR state is said to be REJECTED.
CPC contains built-in Change Management, such that all configuration changes which are applied to Network elements through the Equipment Modules are under change control. All configuration changes which are associated with the same changes to a service are applied in a single, network-wide Transaction.
A session can have multiple Transactions and the Transactions can be processed in parallel. Transactions, cannot be in the current state at the same time.
Transactions are started automatically in response to requests to activate Services, and Transactions can also be controlled directly (explicitly started and stopped) when required.
CPC also provides you with the option to schedule Transactions to be applied to the network at a later date and/or time. This feature gives you the ability to arrange a time for a selected Transaction to be applied within future minutes to future years, according to your individual needs. By using the Scheduling feature, you are able to schedule Transactions at a specified future time allowing efficient use of the network resources. The Scheduling feature is especially valuable for scheduling the activation and modification of Service object around periods of network maintenance and administration.
Under the context of a single Transaction you can add, modify, or delete multiple Service objects. However, these multiple changes are not applied to the network until the Transaction is applied. If one of the changes fails, all of the changes in the Transaction are rolled back.
Figure 2-1 illustrates the Transaction state and the functions or condition that trigger the state transitions.
The Create FTI command creates a new Transaction and leaves it in READY state. While in READY state, the Transaction is available for use in any session. Transactions can be passed between sessions while in READY state.
A Transaction may be opened from READY state, or created and opened in a single step by the Start FTI command. The opening session will see the Transaction as CURRENT, while others will see it as BUSY. A current Transaction is required to make changes to the database representation of the configuration. When an object is modified, CPC automatically creates a pending version of that object and associates that version with the current Transaction. When the Transaction is closed, it returns to the READY state. The Transaction may be closed and reopened indefinitely until all required pending configuration changes have been made.
Once the Transaction Schedule Time is specified by the user, the Transaction is set to a SCHEDULED state. The Transaction will remain in the SCHEDULED state until the Schedule Time. Once the Schedule Time arrives, CPC will then apply the Transaction that you have specified. A Transaction that is in the SCHEDULED state can be Aborted.
The Transaction is BUSY if some other session is using it, as in the case above. The Transaction will also become BUSY while it is being Applied to the network, even for the session which applied it.
Once all sites have been activated and confirmed, CPC will commit the changes (that is, make the pending versions of the modified Network elements the current versions). On completion the Transaction state is set to APPLIED.
The Transaction can be ABANDONED from READY, or CURRENT states - either by client request or if CPC detects a non-recoverable error. CPC rolls back the network to its previous state and discards any pending objects in the database. During this activity the Transaction passes through ALERT state. This is normally a transitional state. A Transaction that stays in this state for an extended period of time may require Operator intervention.
On completing network (may or not be completed) and database roll back (will be complete) the Transaction state is set to ABANDONED.
Along with Transactions and Sites, CPC's built-in Change Management also includes Upload Requests. All uploaded configuration changes which are applied to the CPC database through the Equipment Modules are under change control. All configuration changes which are associated with the same upload are controlled by an Upload Request (UR), which has an associated Audit Log and can be examined by an Operator if desired to determine the history of the upload.
Each UR is applied as an atomic Transaction, such that if any individual database change fails then all other changes are rolled-back and the UR is left in a failed state. A successful UR is left in a succeeded state. URs remain in the CPC database until they are explicitly deleted by an Administrator, thus providing an audit of uploads. Deletion is usually performed periodically, for example, weekly.
Figure 2-2 illustrates the UR states and the functions and/or conditions that trigger the state transitions.
The states are as follows:
An Administrator starts an upload manually, which creates a new UR and puts it into CREATED state. After the information needed to perform the upload is provided to the UR, the UR state is set to PROCESSING and the upload begins.
The UR state remains PROCESSING until the upload is complete, updating all current versions of the Network elements. During processing the UR may temporarily enter WAITING state if it must wait for resources. At the end of the processing phase, if one or more errors occurred then the UR is set to the FAILED state.
On completion, the UR state is set to SUCCEEDED.
If errors are encountered during the upload, CPC discards any database updates. The UR state is set to FAILED.
CPC helps maximize Transaction throughput by preventing Transactions in the ALERT state from accumulating. If Transaction concurrency is not enabled, ALERT Transactions usually block other Transactions from entering the APPLIED state. Non-terminal Transactions are handled during CPC system restart.
Once entering the processing state, a Transaction is guaranteed to proceed to one of two terminal states. APLLIED and ABANDONED , without user intervention. CPC automatically abandons Transactions that encounter errors.
ABANDONED Transactions are checked as to whether or not rollback was successful for each affected site. Failed rollbacks are logged to the system event log. Transactions enter a terminal state even if the client process that applied or scheduled the Transaction ends.
CPC handles Transactions that are not in a terminal state during system restart:
Posted: Thu Aug 3 16:36:00 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.
