|
|
This chapter provides detailed information about the general functions and features of CPC. It includes information about:
Each resource model includes a Threader, which is a function used by the services to provision paths and circuits across the managed network.
The Threader is a software component responsible for creating network 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. Using this algorithm a connection is threaded through the network to equalize bandwidth utilization over NNI gateways.In order to find and prioritize all possible paths between two endpoints, the default Threader performs the following operations in sequence:
The Threader initially looks for all internetwork connections by examining all link objects defined in the network. Acceptable connections must have the following attributes:
If these conditions are met, the Threader will continue the path selection. If either of these conditions are not acceptable the Threader will ignore the link.
The Threader enumerates all possible paths between the specified service endpoints which do not contain loops. That is, a path is rejected if it involves entering a subnetwork that has already been traversed earlier in the path.
From the set of candidate paths, paths which meet all of the following criteria are selected:
In order to select the acceptable paths from the candidate paths, the Threader must determine if the logical ports have sufficient available bandwidth to support the circuit. To do this, the Threader estimates the bandwidth requirements of the circuit from the QoS attributes. Separate calculations are performed for Frame Relay and ATM.
The required Frame Relay bandwidth is estimated as FR Bandwidth = CIR
The required ATM bandwidth is estimated as follows:
A cost is assigned to each selected path. The cost has four components:
These components determine the total cost of the path. By changing these attributes within their containing element objects (i.e. transit cost in network objects and bandwidth in logical port objects) does not cause the threader to re-thread all the connections. Re-threading occurs when you modify the individual connection and the True Modify operation cannot be performed, thus causing the connection to be dissembled and generated again. Refer to section "True Modify" in this chapter for details on True Modify situations.
The weight is a positive or negative integer that sets the priority for candidate paths in a custom callout. The Threader initially assigns a weight of zero and a custom callout assigns new weight values for individual paths. A negative weight value can be used to discard the path entirely.
The transit cost is the total of the node transit costs for all nodes that the path traverses plus the network transit costs for all opaque networks for which the ingress and egress points are on different nodes.
The hop count is one half the number of logical ports that then path uses.
The composite available bandwidth is the average of the available bandwidth in both directions for all logical ports that the path uses.
Paths will be prioritized in order to decrease path weights, assigned either by the Threader or a custom callout. Path of equal weight are prioritized in order of increasing transit cost. Paths of equal transit cost are further prioritized in order of increasing hop count. Paths of equal transit cost and equal hop count are further prioritized in order of decreasing composite available bandwidth.
Attribute values are derived from four sources:
Customers can augment the threader algorithm by adding their own callout Java code. The custom callout allows the customer to assign weights to of the candidate paths before the Threader lays them in. The weight (part of the callout's priorities) is assigned to individual paths, which will influence the path the Threader chooses. The custom callout is called after the path costing step and before the path prioritization step. The priorities that the custom callout sets will influence the prioritization step.
For more information on custom threading policies, refer to the Cisco Provisioning Center Programmer's Guide.
When you provision an ATM or Frame Relay service the Threader may select a path through a network that does not support the service you have requested. If you have not specified the quality of service parameters for the circuit, the Threader will calculate the parameters based on the required quality of service parameters that you provided to create the service.
A Frame Relay service uses the following attributes:
The values that you specify for these attributes are applied to all Frame Relay PVCs created. If these attributes are omitted, they will be estimated from the equivalent ATM QOS attributes that you have provided (if you are provisioning an ATM service). The calculations performed are:
f = 8 * 48 / 1000 cir = scr * f + 1/2 bc = mbs * f + 1/2 be = (pcr/src - 1) * mbs * f + 1/2 (if pcr>scr>0, otherwise be=0)
An ATM service uses, the following attributes:
The values that you specify for these attributes are applied to all ATM VCs and VPs that you create. If these attributes are omitted, they will be estimated from the equivalent Frame Relay attributes that you have provided (if you are provisioning a Frame Relay service). The calculations performed are:
f = 8 * 48 / 1000
g = 8 * 53 / 1000
scr = cir / f + 1/2
mcr = cir / f + 1/2
pcr = (be/bc + 1) * cir / f + 1/2 (if bc is non-zero)
pcr = <LPort speed> / g (if bc is 0 and cir >0, otherwise pcr=0)
mbs = bc / f + 1/2 (or 1, whichever is greater)
Manual threading is supported on the following Service object functions:
To manual thread, add the following attribute to an FTI list:
path=oid0,oid1,oid2,...,oidn
where oidi, i=0...n are the object IDs of the links between the subnetworks ordered in the A-Z direction.
Using this option bypasses a number of threader checks (for example, bandwidth). These checks can also be bypassed on a single subnetwork connection by adding the following to the command line:
path=" "
NNI resiliency provides the ability for the Operator to re-thread circuits that pass through a failed link which represents an NNI gateway. A resiliency policy can be associated with a link. The policy is invoked when the Operator rethreads or restores the link. Multiple policies can co-exist on different links. A resiliency priority can be associated with each service. Those with higher priorities have a higher priority of surviving a link failure.
The CPC Administrator configures the policies that are used on the various links. The configuration required depends on the resiliency policy chosen. For Release 2.0 of CPC, the only supported resiliency policy is the Shared Links Policy.
During service provisioning, CPC sets the resiliency priority specified in the Service object in the Service elements that make up the service.
An CPC Operator invokes NNI resiliency functions re-thread a failed link, and rebalance a set of links over the same link group. The actions taken depend on the resiliency policy in force on the links. These functions can be invoked from either the FTI, the CORBA interface or the GUI. For more information about invoking NNI resiliency from the Script Language or the CORBA interface, refer to the Cisco Provisioning Center Programmer's Guide.
CPC currently implements one resiliency policy, the Shared Links Policy. A group of links can be defined to share their capacity. A portion of the capacity of each is reserved so that when one or more members of the group fail, the others take on more load. When failure occurs, circuits on the failed link are moved onto others in the group. On recovery, the links are not moved, but loading on the links can be manually rebalanced. All links in the group must connect between the same two subnetworks.
To define a group of NNI links that will share their capacity, complete the following steps:
Step 2 Double-click a specific network folder to open it (i.e. Cisco Wan Network). You can select objects in the Tree Viewer Network list or you can filter your request for specific criteria. Refer to the section "Tree Viewer" in the chapter titled "GUI Navigation", for more information on filtering in the Tree Viewer.
Step 3 Double-click a node type folder to open it.
Step 4 Double-click the specific node folder to open it
Step 5 Double-click a logical port folder to open it
Step 6 Double-click the specific logical port folder to open it.
Step 7 Click the Link folder to highlight it and click the Subset Viewer button on the toolbar.
Step 8 Enter search criteria in the appropriate filter fields to find the link you want to include in a resiliency group and click the get list button on the toolbar. To list all of the links, click the get list button without any search criteria.
Step 9 Click the link you want to include and enter a 'name' (any name) for the attribute Resiliency Group. Enter 'shared1' for the attribute Resiliency Policy and click the Save button on the toolbar.
Step 10 Repeat steps 3 and 4 for all desired Links.
Step 11 Apply the Transaction by click the apply button on the toolbar.
When a link is failed, the other links in the group compensate by using bandwidth above and beyond nominal thresholds (CPC will lock the logical ports). Services which ran over the failed link are re-distributed over the other links in the group according to priority. The available bandwidth for the group is allocated over the non-failed links using an algorithm which:
The Operator can mark an NNI link as failed as follows:
Step 2 Double-click a Network folder to open it.
Step 3 Double-click the specific network folder to open it. You can select objects in the Tree Viewer Network list or you can filter your request for specific criteria. Refer to the section "Filtering" in the chapter titled "GUI Navigation", for more information on filtering in the Tree Viewer.
Step 4 Click the node type folder to highlight it. Enter search criteria in the appropriate filter fields to find the node you want and then click the get list button on the toolbar. To list all of the nodes, double-click the specific node type folder.
Step 5 Double-click on a specific node folder to open it.
Step 6 Click the logical port type folder to highlight it. Enter search criteria in the appropriate filter fields to find the logical port you want and then click the get list button on the toolbar. To list all of the logical ports, double-click the specific logical port type folder.
Step 7 Double-click a specific logical port folder to open it.
Step 8 Double-click the Link folder to open it.
Step 9 Click the link you want to fail to highlight it and click the Subset Viewer button on the toolbar.
Step 10 Click the link you want to fail and select link fail from the Element menu.
When a failed link is recovered, there is no re-distribution of services, other than the restored link being made available for use by new services and the total committed bandwidth being adjusted on the non-failed links. The total committed bandwidth on the restored link will be set such that the total available bandwidth for all links in the group is the same as it was before the failure. The algorithm used for link recovery is the same as the algorithm used for link failure. In the process, the logical ports of the failed link are unlocked. To recover a failed NNI link, complete the following steps:
Step 2 Double-click a specific Network folder to open it. You can select objects in the Tree Viewer Network list or you can filter your request for specific criteria. Refer to the section "Filtering" in the chapter titled "GUI Navigation", for more information on filtering in the Tree Viewer.
Step 3 Click the node type folder to highlight it. Enter search criteria in the appropriate fields to find the node you want and then click the get list button on the toolbar. To list all of the nodes, double-click the specific node type folder.
Step 4 Double-click on a specific node folder to open it.
Step 5 Click the logical port type folder to highlight it. Enter search criteria in the appropriate filter fields to find the logical port you want and then click the get list button on the toolbar. To list all of logical ports, double-click the specific logical port type folder.
Step 6 Double-click a specific logical port folder to open it.
Step 7 Click the Link folder to highlight it and click the Subset Viewer button on the toolbar.
Step 8 Enter the search criteria in the appropriate filter fields to find a link and click the get list button on the toolbar. To list all of the links, click the get list button on the toolbar without search criteria.
Step 9 Click the link you want to recover and select link recovery from the Element menu.
Rebalance can be invoked to manually adjust the load across links in the group. When a rebalance function is called on a highly loaded link, the service over the link will be re-distributed to other links in the group. The load across the links in the group will be adjusted evenly. CPC will re-distribute services with highest priority last. To rebalance an NNI link, complete the following steps:
Step 2 Double-click a specific Network folder to open it. You can select objects in the Tree Viewer Network list or you can filter your request for specific criteria. Refer to the section "Filtering" in the chapter titled "GUI Navigation", for more information on filtering in the Tree Viewer.
Step 3 Click the node type folder to highlight it. Enter search criteria in the appropriate fields to find the node you want and then click the get list button on the toolbar. To list all of the nodes, double-click the specific node type folder.
Step 4 Double-click on a specific node folder to open it.
Step 5 Click the logical port type folder to highlight it. Enter search criteria in the appropriate filter fields to find the logical port you want and then click the get list button on the toolbar. To list all of logical ports, double-click the specific logical port type folder.
Step 6 Double-click a specific logical port folder to open it.
Step 7 Click the Link folder to highlight it and click the Subset Viewer button on the toolbar.
Step 8 Enter the search criteria in the appropriate filter fields to find a link and click the get list button on the toolbar. To list all of the links, click the get list button on the toolbar without search criteria.
Step 9 Click the link you want to recover and select link rebalance from the Element menu.
UNI Resiliency provides the ability to specify a backup logical port to use when a failure occurs on a UNI. The Operator has the ability to specify when to move the services to a backup logical port and when to move them back to the foreground logical port. The Operator also has the ability to specify priorities such that services are moved in a pre-defined order (or not at all). Those services with higher priorities are more likely to survive a failure.
During service provisioning, CPC sets the resiliency priority specified in the Service object in the Service elements that make up the service.
A CPC Operator invokes UNI resiliency functions to move PVCs to a backup logical port when a failure occurs on a UNI and move PVCs back when a recovery is made on a UNI. These functions can be invoked from the Script Language, CORBA interface or the GUI. For more information about invoking UNI resiliency from the FTI and CORBA interface, refer to the Cisco Provisioning Center Programmer's Guide and Cisco Provisioning Center Programmer's Reference Guide.
To specify a UNI resiliency priority for a service:
Step 2 Double-click the Service Application folder to open it.
Step 3 Double-click the specific Service Application folder to open it.
Step 4 Click a Service Profile to highlight it and click the Subset Viewer button on the toolbar.
Step 5 Enter the value in the UNI Recovery Priority cell and click the Save button on the toolbar.
Step 6 Apply the Transaction by click the apply button on the toolbar.
When a foreground logical port fails, the UNI Fail function will lock the foreground logical port, unlock the backup if it is locked, and move PVCs from the foreground logical port to the backup logical port according to the UNI Resiliency priority of each PVC.
To specify a background logical port, complete the following steps:
Step 2 Double-click a Network folder.
Step 3 Double-click to select a network object. You can select objects generated by the Network list in the TreeViewer or filter your request for specific criteria.
Step 4 Double-click to select a node type.
Step 5 Double-click to select the specific node.
Step 6 Double-click to select a logical port type.
Step 7 Use the filter bar to filter your request for specific criteria and then click to highlight the specific criteria and then click to highlight the specific logical port.
Step 8 Click the Object Viewer button on the toolbar.
Step 9 Specify a backup logical port in the Backup LPort field in the Contained By tab.
Step 10 Save the backup port by clicking the save button on the toolbar.
Step 11 Apply the Transaction by clicking the apply button on the toolbar.
To perform a UNI Fail operation, complete the following steps:
Step 2 Double-click a Network folder.
Step 3 Double-click to select a network object. You can select objects generated by the Network list in the TreeViewer or filter your request for specific criteria.
Step 4 Double-click to select a node type.
Step 5 Double-click to select the specific node.
Step 6 Double-click to select a logical port type.
Step 7 Use the filter bar to filter your request for specific criteria and then click to highlight the specific logical port.
Step 8 Select uni fail form the Element menu.
When a foreground logical port recovers, the UNI Recover function will move PVCs back from the backup logical port to the foreground logical port. UNI will not lock the backup logical port because it can be used as a foreground or as a backup logical port for another foreground logical port. To recover a foreground logical port, complete the following steps:
Step 2 Double-click to select a network folder.
Step 3 Double-click to select a network object. You can select objects generated by the Network list in the TreeViewer or filter your request for specific criteria.
Step 4 Double-click to select a node type.
Step 5 Double-click to select the specific node.
Step 6 Double-click to select a logical port type.
Step 7 Use the filter bar to filter your request for specific criteria and then click to highlight the specific logical port.
Step 8 Select uni recovery from the Element menu.
The True Modify operation is designed to minimize the occurrence of service outages and to enhance performance if the EMS and NMS supports it. Service Object in CPC support this modification operation that changes the values of selected attributes. Service Objects that are modified using this feature may have their attributes modified at the Service Element level rather than deleting or recreating the service. CPC seeks to implement the True Modify operation wherever it is possible. This operation is not permitted for some Equipment Modules because of hardware restrictions.
The Threader will attempt a True Modify in the following situations:
The Threader will not attempt a True Modify in the following situations:
If all of the above tests are passed, a True Modify is attempted. If any CMS errors occur during an attempt to modify a Service, the Service will be re-threaded.
The Cisco WAN Equipment Module supports the True Modify operation on attributes within FR-FR, ATM-FR, ATM-ATM, CBR and CBR-ATM PVCs with the following exceptions listed in Table 7-1:
| Attribute | Description | Status |
|---|---|---|
ratype | Circuit Type, (VCI, VPI) | Can not be modified for ATM-ATM circuits. |
partialfill | Partial cell fill attribute | Can not be modified for CBR-CBR and CBR-ATM circuits. |
The following steps are required to discover Services:
Step 2 Create links
Step 3 Create virtual links
Step 4 Perform NC Discovery
Step 5 Perform SO Discovery
 |
Note Running the utilities out of order can lead to the creation of inappropriate objects in the database. |
All of these steps are necessary to discover Services but all steps will not be performed each time you wish to discover a new Service. For example, Fabric and Service element uploads are only necessary when configuring a new Equipment Module or when the network configuration has changed. Other steps, such as link and virtual link must be performed manually before running the NC Discovery utility.
Services are created by Operators at the Element Management Layer. These created service are subsequently uploaded into the CPC database. As a result, orphan PVCs exist in the CPC database that have no corresponding Service Object, Network Connection, or Link Connection objects.
CPC can create Services from Service elements that exist in the database. These Service elements build on top of each other to create Services. Following an upload, the NC Discovery utility finds the largest spanning groups of related orphan PVCs and creates the missing Network Connection and Link Connection Objects. After the NCs are created, a separate SO Discovery Utility can be used to look for the orphan NCs and create the appropriate Service Objects (i.e. DSL Discovery or IP-VPN Service Discovery).
Figure 7-1 shows the Network objects CPC uses to discover Services.
The NC Discovery utility must be run from the command line of an CPC client host. To execute the NC Discovery utility the following command must be entered:
$ java Xmx400m com.syndesis.frrm.NCDiscovery
The NC Discovery program attaches to the view manager session on the display from which it is run. An open Transaction in the session is used and will remain open if the run is successful. If no Transactions are open, a Transaction will be created and it will be applied if the run is successful. Errors occurring during the execution of the program will result in the CR being closed and rejected in either case.
The NC Discovery utility finds orphan PVCs to create Network Connections and Link Connections by:
DSL and IP-VPN Service Discovery can be used to create Services based on the network connections formed by NC Discovery. For more information on DSL Service Discovery and IP-VPN Service Discovery refer to the chapters titled "Provisioning DSL Services" and "Provisioning IP-VPN Services"
CPC manages a database which contains an accurate representation of the state of the network(s) being managed. This is called the Current view of the network.
When a user opens a Transaction and then creates or modifies database objects, a Pending view of the network is created.
When the user applies the Transaction, CPC converts the changes in the database's Pending view into one or more translation files. These files contain instructions to the Element Management System (EMS) or Network Management System (NMS) which cause the nodes to be modified. CPC then `delivers' the translate files to the EMS or NMS, which executes the instructions thereby provisioning the service. When the delivery is successful the Pending view becomes the new Current view in the database.
If delivery to any site in a Transaction should fail, CPC will then reverse the changes to all sites in that Transaction. This process is called rollback.
CPCs engine supports pre-provisioned equipment by allowing existing Equipment Modules to upload from pre-provisioned nodes and switches. Service Elements that are uploaded from pre-provisioned network elements are made available for use by new Services created using CPC Service Applications.
Node Objects and Network Objects included an attribute indicating whether or not they are pre-provisioned. The attribute Pre-provisioned can be found in Node and Network Object Viewers as a pull-down menu with the following options:
When the Pre-provisioned attribute is set to Full or Init, CPC Service Objects will be able to use the existing unassigned Service Elements on the node or within the network instead of creating new elements. The Service Object will look for a suitable existing Service Element that is unassigned and assign it as a part of that service. In Init mode, if a suitable existing Service Element is not found, the Equipment Module will attempt to create a new one and download it to the managed equipment.
In Full mode, the Equipment Module will not allow any modifications (i.e. creation, modification deletion) to any objects in order to prevent a Service Object from modifying a Service Element that can not be downloaded.
If a Service Object is deleted and the associated Service Element is contained by a Network/Node in Full mode, the Service Element will be returned to the pool of available elements. A Service Element will be deleted if its associated Node/Network is in Init mode and the containing Service Object is deleted.
Service Element "suitability" is determined partially by Service Objects and their associated Threaders that thread the service throughout network elements. Both searches are unique in their execution.
Service Objects can use any criteria in order to choose a suitable Service Element to use. Criteria lookup can be configured using NetProvision Service Designer. Refer to the NetProvision Service Designer User Guide for more information on configuration selection criteria for Service Objects.
Service Objects will use the names of Service Element profiles to determine suitability. Selection of a suitable element is accompanied by filtering Service Elements for the following criteria:
You must first create a profile for the pre-provisioned Service Element manually using the CPC GUI or through an FTI script. If the Service Element exists in Full mode, the Equipment Module will only allow the Service Element Profile to be modified in the profile values exactly match the existing values in the object. If these values were not exact, the Service Element would be expected to download the modified values, which can not be accomplished since download is not allowed in Full mode.
Posted: Thu Aug 3 16:38:06 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.