|
|
This chapter provides an overview of the Cisco Provisioning Center product. It also describes Service provisioning, and the main CPC features, including a discussion of the architecture.
Service Provisioning can be defined as the set of activities undertaken by a service provider that begins with a customer request for Service and ends when the Service is available to the customer and billing is enabled.
Cisco Provisioning Center automates the activation of telecommunications Services. This robust client/server software system plays a key role in Service provisioning. CPC is standards-based Service provisioning application with integrated change management. It is based on the industry standard TMN model defined by the ITU-T (Figure 1-1.)
The TMN model provides a management structure that defines different levels for specific functionality. The same types of functions (for example, Service provisioning) can be implemented at many layers from the highest business management layer, to the lowest network element layer. Management must be first defined at the lower layers, and then additional management applications can be built on this foundation.
The Cisco Provisioning Center is an integrated flow-through Service provisioning solution for network service providers who offer Frame Relay, ATM, Circuit Emulation, Digital Subscriber Line (DSL), Internet access and other data Services.
These Services typically are complicated to configure and involve multiple technologies. CPC provides a single, consistent interface for provisioning multiple Services across multiple network technologies comprised of multiple vendors and equipment models. As such, CPC provides the immediate benefits of reduced training costs, improved operations efficiency, and fewer provisioning errors.
CPC is designed to be the Service activation component of your Service creation system. The Service creation system will include other components, such as order fulfillment, customer care, and billing, as shown in Figure 1-2. CPC is designed to be used by your order fulfillment operators either directly, through the CPC GUI, or indirectly, through an application that uses the flow-through or CORBA interface.
In CPC, Services are represented by Service objects which can be activated, modified, and deleted by your order fulfillment system. Service objects provide a high-level, equipment-independent description of the Services managed by the order fulfillment system. Service objects include general information such as customer reference, Service endpoints (ports), and Class of Service (CoS).
Service objects allow you to view your network in terms of end-user or subscriber Services, as well as the traditional set of nodes, ports, and circuits. Thus, complex configuration changes are grouped into simple units that reflect more closely the orders received from subscribers. This simplifies and speeds up order processing and improves order consistency. In addition, Services are easier to develop and deploy.
When Services are created, CPC translates the Service objects into more detailed components, such as virtual circuits, link connections, and the commands and attributes necessary to configure these on the particular equipment in your network. This translation is automatic and is able to choose an optimum mapping of the Services across multiple subnetworks, comprising different types of equipment. Operators and applications can view how the Service was translated.
CPC incorporates multiple operator change control using Transactions. CPC ensures that Transactions are applied successfully to all elements of the network, in a coordinated manner. If any elementary action fails, the entire Transaction is rolled back.
CPC is made up of three distinct components, an Engine, Service Applications, and Equipment Modules. At least one Service Application and one Equipment Module must be added to the engine to make the product operational. Figure 1-2 shows the components of CPC.
The CPC engine provides the infrastructure which supports the Equipment Modules and Service Applications. The engine provides technology specific resource models which simplify the Service object by providing a high level interface across vendors. It supports:
The standard resource model contains objects which can be used to model any network technology, and is the base from which all technology resource models are derived. It dictates a common information model for all objects in all Equipment Modules. The standard resource model contains the following object classes:
A technology resource model is a standardized representation of a given technology, which is used by all Equipment Modules which support that technology. The resource model includes a set of object definitions, with attributes and functions, which a Service can use to request resources of that technology. This includes attributes which represent CoS in an equipment-neutral way, for use by threading functions.
An Equipment Module which supports a given resource model must support all of the attributes and functions dictated by the resource model. The Equipment Module model can also have additional objects, attributes, and functions not present in the resource model, to add vendor-specific features. This allows a service to deal with resources in a generic way, by using only those attributes and functions dictated by the resource model.
Each resource model includes a Threader, which is a function used by Services to provision Services across the managed network. The Threader chooses a path for a service based on its required CoS.
The Threader is the software component responsible for creating connections across networks. Each layer network in a layered topology has an associated Threader which creates network connections across that layer.
The route through the layer network is chosen using a threading algorithm. There is a default threading algorithm which is available to all resource models.
Customers can augment the Threader algorithm by adding their own callout Java code. The custom callout allows you to adjust the priorities of candidate paths before the Threader lays them in. CPC will create connections across networks based on the priorities set by the custom callout.
Fore more information about the Threader, refer to the chapter titled, "General Functions and Features"
Service Applications provide the ability to provision a particular Service offering (for example, ATM). Each service provider has a distinct set of Service offerings in order to differentiate the service provider from competitors. Therefore, there are likely to be a large number of Service Applications, grouped into broad categories which are similar but customized for the individual service provider clients.
A Service Application may contain multiple Service objects. A Service object represents one separately-provisionable item (for example, the Frame Relay Service Application contains the Frame Relay Service object and the Frame Relay-ATM Interworking Service object).
An Equipment Module provides access to a specific type of equipment (for example, a suite of switching nodes from a particular vendor). It encapsulates the knowledge of the specifics of the equipment and translates this into an equipment-neutral representation (in much the same way as a device driver provides a standard interface to an application and maps this onto the capabilities of the device). An Equipment Module may support a large range of products (for example, an entire vendor's suite of products) or just one specific product. An Equipment Module makes use of other products (for example, the equipment vendor's own provisioning server) or in the case where there is no intermediary management system the Equipment Module will talk directly to the managed equipment.
In order to create a complete and working application, Equipment Modules are added to CPC such that CPC can access (provision) all of the types of equipment which participate in providing the Service. Most Services will span equipment types, and hence will require the presence of more than one Equipment Module in order to be provisioned.
Each Equipment Module has a network interface that allows it to talk directly to either the switches in the network or the element or network management system managing the network.
The following is a discussion of the main features of CPC.
CPC is a scalable, client-server UNIX-based application that can support millions of network objects and dozens of concurrent operators. CPC incorporates an object-oriented data model of the Services and network resources it manages, including network hardware and topology information. This data model is stored in a commercial-grade relational database (Informix RDBMS).
Large networks are often comprised of different subnetworks, such as Frame Relay and ATM subnetworks, connected by gateway links, such as ATM or Frame Relay NNI links. CPC maintains this overall network topology by storing the gateway links in its database. CPC automatically determines an optimum path for a new Service object by examining the capacity and availability of the gateway links. This process is called threading. For more information about threading, refer to the chapter titled "General Functions and Features"
Gateway links between subnetworks can fail. If a link fails, CPC can be commanded to re-thread the Services on the failed link to other available links, based on priorities and policies that can be defined by the service provider. This command can be issued manually by an operator or by a user-written program that is triggered by the fault management system.
CPC provides NNI gateway fail, recover, and rebalance functions as part of a complete NNI resiliency feature. For more information about NNI resiliency, refer to the chapter titled, "General Functions and Features".
If a connection failure occurs on a foreground logical port, CPC can be commanded to move the services to a backup logical port, based on priorities that can be defined by the site administrator. This command is triggered by the fault management systems.
CPC supports UNI fail and recover functions as part of a complete UNI resiliency feature. For more information about UNI resiliency, refer to the chapter titled "General Functions and Features"
CPC provides a flow-through interface (FTI) allowing the service provider to flow orders directly from the order fulfillment system into CPC for immediate provisioning. This interface consists of UNIX commands that can be incorporated into user-written shell scripts or programs in a variety of languages (such as Java).
Script Language
The Script Language supports:
For more information about using the FTI, refer to the Cisco Provisioning Center Programmer's Guide.
CORBA Interface
The CORBA interface consists of CORBA methods that can be incorporated into programs in a variety of languages (such as Java). The CORBA interface supports:
For more information about using the CORBA interface, refer to the Cisco Provisioning Center Integration Guide.
In addition to the FTI, CPC offers a GUI which is used for administration tasks and can also be used for operations functions, such as provisioning Services, when the FTI is not used. The COC GUI is built on the FTI.
In order to interact with CPC, an Operator must have a session. An interactive session is created by starting a copy of the CPC Client software. An interactive session is associated with a specific Operator or a specific workstation.
For more information about using the GUI, refer to the chapter titled "GUI Navigation.."
Posted: Thu Aug 3 16:35:39 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.
