|
|
The CiscoVsmBrowser module (in the CiscoVsmBrowser.idl file) defines interfaces to the various objects that are used in the VPN Service Model (VSM). Here are the VSM objects that you can manage using the CiscoVpnServiceModel::VpnInvMgr interface and object-specific interfaces in the CiscoVsmFWCreator and CiscoVsmFWModifier modules:
 |
Caution While these APIs are "thread-safe" for repository "read" and "write" operations, they are not intended for use in multiclient applications. Specifically, the VSM object-management operations do not supply transaction capabilities to ensure safe manipulation of a common repository object by multiple clients. For example, object-modifier and removal operations do not check for usage by other clients prior to execution. If you intend to use these APIs in multiclient application software, please factor this API design issue into your algorithm. |
Before implementing your VPN-support algorithm, you need an instance of the VpnInvMgr interface. To get a VpnInvMgr object, add code to your client source code that executes the following:
Step 2 Execute the CiscoVpnServiceModel::VsmServer::getVpnInvMgrWithAuthentication() operation to gain authenticated access to the VPN Inventory repository using the VpnInvMgr object that is retuned.
Creating a CiscoVsmBrowser::VsmProviderAdminDomain object is the first algorithmic step in defining the provider side of the VSM objects required to establish VPN connectivity. This object is the rudimentary VSM element that manages the provider side of the VPN service.
This section explains the following tasks as they apply to managing VsmProviderAdminDomain objects:
For information regarding the object relationships of the VPN service model, see the "Provider Administrative Domain" section.
Use the following operations to create and define a CiscoVsmBrowser::VsmProviderAdminDomain object:
Figure 4-1 shows how to use these operations. Order of execution order is only significant for the newProviderAdminDomainCreator(), addToRep(), and releaseProviderAdminDomainCreator() operations. When setting the parameters for the provider administrative domain, the execution order is not significant, except that they must be set prior to executing the addToRep() operation.
After adding a CiscoVsmBrowser::VsmProviderAdminDomain object to the VPN Inventory repository, you may need to implement algorithms in your client code to modify the VsmProviderAdminDomain object, add or remove RT and RD seed values, or simply dispose of the object when it is no longer needed.
The APIs supply the following operations to help you find a specific VsmProviderAdminDomain object or all of them, as needed:
The findProviderByName() operation returns a single VsmProviderAdminDomain object based on the name specified in the CiscoVsmFWCreator::VsmProviderAdminDomainCreator::setName() operation when the object was created. The CiscoVpnServiceModel::VpnInvMgr::getAllProviders() operation returns a sequence of all VsmProviderAdminDomain objects stored in the VPN Inventory repository; you must specify your own qualification scheme to get a specific object from the sequence. The VsmRegion::getProviderAdminDomain() operation returns the VsmProviderAdminDomain object to which the given VsmRegion object belongs.
Figure 4-2 shows how to retrieve a VsmProviderAdminDomain object from the VPN Inventory repository. Because the repository is not modified, no addToRep() or updateRep() operations are required. Use these operations to manage RT and RD seeds or to modify or dispose of a VsmProviderAdminDomain object; the VsmRegion::getProviderAdminDomain() operation is also useful for traversing the object structure of your VSM implementation.
After adding a CiscoVsmBrowser::VsmProviderAdminDomain object to the VPN Inventory repository, you can perform limited modifications on it. You can retrieve a VsmProviderAdminDomain object from the VPN Inventory repository using the operations described in the "Retrieving VsmProviderAdminDomain Objects from the Repository" section.
Here is a list of the operations you can perform to modify a VsmProviderAdminDomain objects in the VPN Inventory repository:
You cannot modify the AS number or the name of the VsmProviderAdminDomain object. If you need to change either of these VsmProviderAdminDomain features, you must create a new object.
Figure 4-3 shows how to use these operations to modify a VsmProviderAdminDomain object from the VPN Inventory repository. The retrieveVsmProviderAdminDomain() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmProviderAdminDomain Objects from the Repository" section.
Route distinguisher (RD) and route target (RT) seeds are expressed using the custom types, CiscoVsmBrowser::VsmRDSeed and CiscoVsmBrowser::VsmRTSeed, respectively. Each CiscoVsmBrowser::VsmProviderAdminDomain object may have many RD and RT seeds and values. There are two sets of addition and removal operations that support the RD and RT seeds for CiscoVsmBrowser::VsmProviderAdminDomain objects. They are:
These operations do not require an addToRep() or updateRep() operation and operate directly a specified VsmProviderAdminDomain object in the VPN Inventory repository. Figure 4-4 shows how to use these operations to manage the use of RD and RD seeds for a given VsmProviderAdminDomain object. The retrieveVsmProviderAdminDomain() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmProviderAdminDomain Objects from the Repository" section.
There are two types of removal operations that support the cleanup portion of the VSM object management task. They are:
The CiscoVpnServiceModel::VpnInvMgr::releaseProviderAdminDomain() operation simply releases a specified CiscoVsmBrowser::VsmProviderAdminDomain object on the server. Client software can also remove a VsmProviderAdminDomain object from the VPN Inventory repository but only if no CiscoVsmBrowser::VsmRegion objects belong to it.
You can determine whether or not the VsmProviderAdminDomain object to be removed has any VsmRegion objects using the CiscoVsmBrowser::VsmProviderAdminDomain::getAllRegions() operation. This operation returns a sequence of VsmRegion objects that belong to the specified VsmProviderAdminDomain object.
The CiscoVpnServiceModel::VpnInvMgr::removeProviderAdminDomainFromRep() operation implicitly calls the releaseProviderAdminDomain() operation for the VsmProviderAdminDomain object passed to it though the providerAdminDomain parameter. Clients that execute this operation, therefore, need not execute the releaseProviderAdminDomain() operation. To do so raises a RepException, because the VsmProviderAdminDomain object, at that point, does not exist in the VPN Inventory repository.
Figure 4-5 shows how to use these operation to dispose of a VsmProviderAdminDomain object. The retrieveVsmProviderAdminDomain() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmProviderAdminDomain Objects from the Repository" section.
Create a CiscoVsmBrowser::VsmRegion object and assign it to a VsmProviderAdminDomain object in the VPN Inventory repository. The VsmRegion object represents a specific geographic region of the provider backbone network.
This section explains the following tasks as they apply to managing VsmRegion objects:
For information regarding the object relationships of the VPN service model, see the "Region" section.
Use the following operations to create and define a CiscoVsmBrowser::VsmRegion object:
Figure 4-6 shows the use of these operations. The order of execution is only significant for the newRegionCreator(), addToRep(), and releaseRegionCreator() operations. The setName() operation must execute prior to the addToRep() operation. The retrieveVsmProviderAdminDomain() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmProviderAdminDomain Objects from the Repository" section.
After adding a CiscoVsmBrowser::VsmRegion object to the VPN Inventory repository, you may need to implement algorithms in your client code to modify the VsmRegion object, add or remove IP address pools, or simply dispose of the object when it is no longer needed.
The APIs supply the following operations to help you find a specific VsmRegion object or all of them, as needed:
The findRegionByName() operation returns a single VsmRegion object based on the name specified in the CiscoVsmFWCreator::VsmRegionCreator::setName() operation when the object was created. The CiscoVsmBrowser::VsmProviderAdminDomain::getAllRegions() operation returns a sequence of all VsmRegion objects stored in the VPN Inventory repository; you must specify your own qualification scheme to get a specific object from the sequence. The VsmPE::getRegion() operation returns the VsmRegion object to which the given VsmPE object belongs.
Figure 4-7 shows how to retrieve a VsmRegion object from the VPN Inventory repository. Because the repository is not modified, no addToRep() or updateRep() operations are required. Use these operations to manage IP address pools or to modify or dispose of a VsmRegion object; the VsmPE::getRegion() operation is also useful for traversing the object structure for your VSM implementation.
After adding a CiscoVsmBrowser::VsmRegion object to the VPN Inventory repository, you can modify it. You can retrieve a VsmRegion object from the VPN Inventory repository using the operations described in the "Retrieving VsmRegion Objects from the VPN Inventory Repository" section.
Here is a list of the operations you can perform to modify a VsmRegion object in the VPN Inventory repository:
Figure 4-8 shows how to use these operations to modify a VsmRegion object from the VPN Inventory repository. The retrieveVsmRegion() operation is shown in italics to represent the two operations supplied by the CiscoVsmBrowser::VsmProviderAdminDomain interface that are listed and described in the "Retrieving VsmRegion Objects from the VPN Inventory Repository" section.
For router interfaces, each CiscoVsmBrowser::VsmRegion object maintains pools of /30 and /32 subnet IP addresses, respectively, using the CiscoVsmBrowser::VsmIPAddressPool custom type. The pools of /30 subnet addresses support autoallocation of IP addresses for the IP-numbered PE and CE interfaces for each service request, while the pools of /32 subnet addresses support autoallocation for IP-unnumbered (loopback) interfaces.
There are two sets of addition and removal operations that support the /30 and /32 IP address pools for CiscoVsmBrowser::VsmRegion objects. They are:
Because addresses from each pool become unavailable for allocation when they are assigned, each VsmRegion object also maintains a list of free IP addresses for each supported subnet for autoallocation processes during provisioning. As an allocated IP address is released or freed from its assignment, it is returned to the appropriate pool of free IP addresses for reuse by the provisioning system.
These operations do not require an addToRep() or updateRep() operation and operate directly a specified VsmProviderAdminDomain object in the VPN Inventory repository. Figure 4-9 shows how to use these operations to manage the use of IP addresses for /30 and /30 subnets for a given VsmRegion object. The retrieveVsmRegion() operation is shown in italics to represent the two operations supplied by the CiscoVsmBrowser::VsmProviderAdminDomain interface that are listed and described in the "Retrieving VsmRegion Objects from the VPN Inventory Repository" section.
Within a VPN or extranet, all IP addresses must be unique. Customer IP addresses must not overlap the provider IP addresses. Overlapping addresses are only supported for devices that are in isolated VPNs.
Each VsmRegion object has the following two operations to determine whether or not a specific IP address overlaps one of the indicated pools for the region:
Use these operations in your client application code to ensure that any customer-allocated IP addresses—primarily applicable for CEs that are not provider managed, as specified by an SRVC—do not overlap the IP address pools assigned to the VsmRegion object.
There are two types of removal operations that support the cleanup portion of the object-management task for VsmRegion objects. They are:
The CiscoVpnServiceModel::VpnInvMgr::releaseRegion() operation simply releases a specified CiscoVsmBrowser::VsmRegion object on the server. Client software can also remove a VsmRegion object from the VPN Inventory repository if no CiscoVsmBrowser::VsmPE objects belong to it.
You can determine whether or not the VsmRegion object to be removed has any VsmPE objects using the CiscoVsmBrowser::VsmRegion::getAllPEs() operation. This operation returns a sequence of VsmPE objects that belong to the specified VsmRegion object.
The CiscoVpnServiceModel::VpnInvMgr::removeRegionFromRep() operation implicitly calls the releaseRegion() operation for the VsmRegion object passed to it though the region parameter. Clients that execute this operation, therefore, need not execute the releaseRegion() operation. To do so raises a RepException, because the VsmRegion object, at that point, does not exist in the VPN Inventory repository.
Figure 4-10 shows how to use these operation to dispose of a VsmRegion object. The retrieveVsmRegion() operation is shown in italics to represent the two operations supplied by the CiscoVsmBrowser::VsmProviderAdminDomain interface that are listed and described in the "Retrieving VsmRegion Objects from the VPN Inventory Repository" section.
Create a CiscoVsmBrowser::VsmCoSProfile object and assign it, with a list of class-of-service (CoS) classes, to a VsmProviderAdminDomain object in the VPN Inventory repository. The VsmCoSProfile object represents a set of CoS configurations offered by a provider to its customer. Each CoS profile consists of a set of CoS classes that record information on how to configure traffic shaping and policing.
This section explains the following tasks as they apply to managing VsmCoSProfile objects:
For information regarding the object relationships of the VPN service model, see the "Class-of-Service Profile" section.
Use the following operations to create and define a CiscoVsmBrowser::VsmCoSProfile object:
Figure 4-11 shows the use of these operations. The order of execution is only significant for the newCoSProfileCreator(), addToRep(), and releaseCoSProfileCreator() operations. The setName() operation must execute prior to the addToRep() operation. The retrieveVsmProviderAdminDomain() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmProviderAdminDomain Objects from the Repository" section.
After adding a CiscoVsmBrowser::VsmCoSProfile object to the VPN Inventory repository, you may need to implement algorithms in your client code to modify the VsmCoSProfile object or simply dispose of the object when it is no longer needed.
The APIs supply the following operations to help you find a specific VsmCoSProfile object or all of them, as needed:
The findCoSProfileByName() operation returns a single VsmCoSProfile object based on the name specified in the CiscoVsmFWCreator::VsmCoSProfileCreator::setName() operation when the object was created. The CiscoVsmBrowser::VsmProviderAdminDomain::getCoSProfiles() operation returns a sequence of all VsmCoSProfile objects stored in the VPN Inventory repository; you must specify your own qualification scheme to get a specific object from the sequence. The VsmSRVC::getCoSProfile() operation returns the VsmCoSProfile object to which the given VsmSRVC object belongs.
Figure 4-12 shows how to retrieve a VsmCoSProfile object from the VPN Inventory repository. Because the repository is not modified, no addToRep() or updateRep() operations are required. Use these operations when modifying or disposing of a VsmCoSProfile object; the VsmSRVC::getCoSProfile() operation is also useful for traversing the object structure for your VSM implementation.
After adding a CiscoVsmBrowser::VsmCoSProfile object to the VPN Inventory repository, you can modify it. You can retrieve a VsmCoSProfile object from the VPN Inventory repository using the operations described in the "Retrieving VsmCoSProfile Objects from the VPN Inventory Repository" section.
Here is a list of the operations you can perform to modify a VsmCoSProfile object in the VPN Inventory repository:
Figure 4-13 shows how to use these operations to modify a VsmCoSProfile object from the VPN Inventory repository. The retrieveVsmCoSProfile() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmCoSProfile Objects from the VPN Inventory Repository" section.
There are two types of removal operations that support the cleanup portion of the object-management task for VsmCoSProfile objects. They are:
Figure 4-10 shows how to use these operation to dispose of a VsmCoSProfile object. The CiscoVpnServiceModel::VpnInvMgr::releaseCoSProfile() operation simply releases a specified CiscoVsmBrowser::VsmCoSProfile object on the server. Client software can also remove a VsmCoSProfile object from the VPN Inventory repository if no CiscoVsmBrowser::VsmSRVC objects use it to define VPN connectivity for a PE-CE pair.
You can determine whether or not there are any VsmSRVC objects that use the VsmCoSProfile object to be removed using the CiscoVsmBrowser::VsmCoSProfile::getSRVCs() operation with the following states listed in the CiscoVsmBrowser::VsmSRStateSeq input parameter: Requested, Pending, Invalid, FailedDeploy, Deployed, Broken, Functional, and Lost. This operation returns a sequence of VsmSRVC objects that belong to the specified VsmCoSProfile object; if all associated service requests are Closed, this operation returns an empty CiscoVsmBrowser::VsmSRVCSeq list.
The CiscoVpnServiceModel::VpnInvMgr::removeCoSProfileFromRep() operation implicitly calls the releaseCoSProfile() operation for the VsmCoSProfile object passed to it though the cosProfile parameter. Clients that execute this operation, therefore, need not execute the releaseCoSProfile() operation. To do so raises a RepException, because the VsmCoSProfile object, at that point, does not exist in the VPN Inventory repository.
"Overview: VPN Service Model," lists the CiscoVsmBrowser::VsmVRFDef object as a standard VSM object, but its management requirements are slightly different from other VSM objects in your client-application code. A VsmVRFDef object is created automatically when a request to add VPN service to a CE is created; thus, there is no explicit constructor or modifier for this interface.
Although the CiscoVsmSRCreator::VsmVPNConnectrivityCreator::addToRep() operation implicitly creates a VsmVRFDef object when it executes, releasing object references to the VsmVRFDef object and removing obsolete VsmVRFDef objects from the VPN Inventory repository are tasks that require management by the client application.
This section explains the following tasks as they apply to managing VsmVRFDef objects:
For information regarding the object relationships of the VPN service model, see the "VPN Routing/Forwarding Table Definition" section.
To create a CiscoVsmBrowser::VsmVRFDef object, use the instructions in the "VPN Connectivity" section, which describes how to create a CiscoVsmBrowser::VsmSRVC object. The process for creating a VsmSRVC object does not return a VsmVRFDef object, but you can use the VsmSRVC API to access the related VsmVRFDef object as described in the "Retrieving VsmVRFDef Objects from the VPN Inventory Repository" section that follows.
 |
Note The CiscoVsmBrowser::VsmVRFDef object cannot be modified. However, using the CiscoVsmSRCreator::VsmVPNServiceModifier interface you can create a new VsmSRVC object that subsumes an existing one, thus replacing the existing VsmVRFDef object. |
After adding a CiscoVsmBrowser::VsmVRFDef object to the VPN Inventory repository, you may need to implement algorithms in your client code to modify the VsmVRFDef object or simply dispose of the object when it is no longer needed.
The APIs supply the following operations to help you find a specific VsmVRFDef object or all of them, as needed:
The CiscoVsmBrowser::VsmSRVC::getVRFDef() operation returns the single VsmVRFDef object specified by the CiscoVsmSRCreator::VsmVPNConnectivityCreator::setVRFNameAndRD() operation when creating the VsmSRVC object with which the VsmVRFDef object is associated. The CiscoVsmBrowser::VsmProviderAdminDomain::getVRFDefs() operation returns a sequence of all VsmVRFDef objects stored in the VPN Inventory repository for the provider; you must specify your own qualification scheme to get a specific object from the sequence.
Figure 4-15 shows how to retrieve a VsmVRFDef object from the VPN Inventory repository. Because the repository is not modified, no addToRep() or updateRep() operations are required.
Unlike other VSM objects, only the CiscoVpnServiceModel::VpnInvMgr::releaseVRFDef() operation supports the cleanup portion of the object-management task for VsmVRFDef objects. Figure 4-16 shows how to use the CiscoVpnServiceModel::VpnInvMgr::releaseVRFDef() operation to releases a specified CiscoVsmBrowser::VsmVRFDef object on the server. Client software can remove a VsmVRFDef object from the VPN Inventory repository only by removing the CiscoVsmBrowser::VsmSRVC objects that use it to define VPN connectivity for a PE-CE pair.
You can determine whether or not there are any VsmSRVC objects that use the VsmVRFDef object to be removed using the CiscoVsmBrowser::VsmVRFDef::getSRVCs() operation with the following states listed in the CiscoVsmBrowser::VsmSRStateSeq input parameter: Requested, Pending, Invalid, FailedDeploy, Deployed, Broken, Functional, and Lost. This operation returns a sequence of VsmSRVC objects that belong to the specified VsmVRFDef object; if all associated service requests are Closed, this operation returns an empty CiscoVsmBrowser::VsmSRVCSeq list.
Create a CiscoVsmBrowser::VsmVPN object and assign it to a VsmProviderAdminDomain from the VPN Inventory repository. The VsmVPN object consists of a set of provisioning templates and policies (PRG and CERC).
This section explains the following tasks as they apply to managing VsmProviderAdminDomain objects:
For information regarding the object relationships of the VPN service model, see the "Virtual Private Network" section.
Use the following operations to create and define a CiscoVsmBrowser::VsmVPN object:
Figure 4-17 shows the use of these operations. The order of execution is only significant for the newVPNCreator(), addToRep(), and releaseVPNCreator() operations. The setName() operation must execute prior to the addToRep() operation. The retrieveVsmProviderAdminDomain() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmProviderAdminDomain Objects from the Repository" section.
|
Note The CiscoVpnServiceModel::VpnInvMgr::newVPNCreator() operation is not the same as the CiscoVpnServiceModel::VpnInvMgr::newVPNConnectivityCreator() operation, which is the constructor operation for creating a new service request. Likewise, the CiscoVpnServiceModel::VpnInvMgr::releaseVPNCreator() operation is not the same as the CiscoVpnServiceModel::VpnInvMgr::releaseVPNConnectivityCreator() operation, which is the destructor operation for a new service-request creator. |
After adding a CiscoVsmBrowser::VsmVPN object to the VPN Inventory repository, you may need to implement algorithms in your client code to modify the VsmVPN object or simply dispose of the object when it is no longer needed.
The APIs supply the following operations to help you find a specific VsmVPN object or all of them, as needed:
The findVPNByName() operation returns a single VsmVPN object based on the name specified in the CiscoVsmFWCreator::VsmVPNCreator::setName() operation when the object was created. The CiscoVpnServiceModel::VpnInvMgr::getAllVPNs() operation returns a sequence of all VsmVPN objects stored in the VPN Inventory repository; you must specify your own qualification scheme to get a specific object from the sequence. The VsmCERC::getVPN() and VsmPRG::getVPN() operations return the VsmVPN object to which the respective VsmCERC and VsmPRG objects belong.
Figure 4-18 shows how to retrieve a VsmVPN object from the VPN Inventory repository. Because the repository is not modified, no addToRep() or updateRep() operations are required. Use these operations to manage IP address pools or to modify or dispose of a VsmVPN object; the VsmCERC::getVPN() and VsmPRG::getVPN() operations are also useful for traversing the object structure for your VSM implementation.
There are two types of removal operations that support the cleanup portion of the object-management task for VsmVPN objects. They are:
The CiscoVpnServiceModel::VpnInvMgr::releaseVPN() operation simply releases a specified CiscoVsmBrowser::VsmVPN object on the server. Client software can also remove a VsmVPN object from the VPN Inventory repository if no CiscoVsmBrowser::VsmCERC or VsmPRG objects belong to it.
You can determine whether or not the VsmVPN object to be removed has any VsmCERC or VsmPRG objects using the CiscoVsmBrowser::VsmVPN::getAllCERCs() and getAllPRGs() operation. These operations, respectively, return a sequence of VsmCERC objects and a sequence of VsmPRG objects that belong to the specified VsmVPN object.
The CiscoVpnServiceModel::VpnInvMgr::removeVPNFromRep() operation implicitly calls the releaseVPN() operation for the VsmVPN object passed to it though the vpn parameter. Clients that execute this operation, therefore, need not execute the releaseVPN() operation. To do so raises a RepException, because the VsmVPN object, at that point, does not exist in the VPN Inventory repository.
Figure 4-19 shows how to use these operation to dispose of a VsmVPN object. The retrieveVsmVPN() operation is shown in italics to represent the operations supplied by the VsmProviderAdminDomain interface that are listed and described in the "Retrieving VsmVPN Objects from the VPN Inventory Repository" section.
Create a CiscoVsmBrowser::VsmPRG object and assign it to a VsmVPN from the VPN Inventory repository. The VsmPRG object groups a set of port reservation service request objects that are SRVCs containing only PE port information.
This section explains the following tasks as they apply to managing VsmPRG objects:
For information regarding the object relationships of the VPN service model, see the "Port Reservation Group" section.
Use the following operations to create and define a CiscoVsmBrowser::VsmPRG object:
Figure 4-20 shows the use of these operations. The order of execution is only significant for the newPRGCreator(), addToRep(), and releasePRGCreator() operations. The setDesc() operation must execute prior to the addToRep() operation. The retrieveVsmVPN() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmVPN Objects from the VPN Inventory Repository" section.
After adding a CiscoVsmBrowser::VsmPRG object to the VPN Inventory repository, you may need to implement algorithms in your client code to modify the VsmPRG object or simply dispose of the object when it is no longer needed.
The APIs supply the following operations to help you find a specific VsmPRG object or all of them, as needed:
The findPRGByID() operation returns a single VsmPRG object based on the unique identifier assigned to it when the object was created. The VsmSRVC::getPRG() operation returns a single VsmPRG object based on the name specified in the CiscoVsmFWCreator::VsmPRGCreator::setName() operation when the object was created. The VsmVPN::getAllPRGs() operation returns a sequence of all VsmPRG objects stored in the VPN Inventory repository; you must specify your own qualification scheme to get a specific object from the sequence.
Figure 4-21 shows how to retrieve a VsmPRG object from the VPN Inventory repository. Because the repository is not modified, no addToRep() or updateRep() operations are required.
After adding a CiscoVsmBrowser::VsmPRG object to the VPN Inventory repository, you can modify it. You can retrieve a VsmPRG object from the VPN Inventory repository using the operations described in the "Retrieving VsmPRG Objects from the VPN Inventory Repository" section.
Here is a list of the operations you can perform to modify a VsmPRG object in the VPN Inventory repository:
Figure 4-22 shows how to use these operations to modify a VsmPRG object from the VPN Inventory repository.
There are two types of removal operations that support the cleanup portion of the object-management task for VsmPRG objects. They are:
The CiscoVpnServiceModel::VpnInvMgr::releasePRG() operation simply releases a specified CiscoVsmBrowser::VsmPRG object on the server. Client software can also remove a VsmPRG object from the VPN Inventory repository if there are no outstanding VsmSRVC objects that use it to reserve ports on a provider-edge router (PE).
You can determine whether or not there are any VsmSRVC objects that use the VsmPRG object to be removed using the CiscoVsmBrowser::VsmPRG::getSRVCs() operation with the following states listed in the CiscoVsmBrowser::VsmSRStateSeq input parameter: Requested, Pending, Invalid, FailedDeploy, Deployed, Broken, Functional, and Lost. This operation returns a sequence of VsmSRVC objects that use the specified VsmPRG object; if all associated service requests are Closed, this operation returns an empty CiscoVsmBrowser::VsmSRVCSeq list.
The CiscoVpnServiceModel::VpnInvMgr::removePRGFromRep() operation implicitly calls the releasePRG() operation for the VsmPRG object passed to it though the prg parameter. Clients that execute this operation, therefore, need not execute the releasePRG() operation. To do so raises a RepException, because the VsmPRG object, at that point, does not exist in the VPN Inventory repository. Figure 4-23 shows how to use these operation to dispose of a VsmPRG object.
Create a CiscoVsmBrowser::VsmPE object and assign it to a VsmRegion object in the VPN Inventory repository. The VsmPE object represents a a provider-edge router in a specific geographic region of the provider backbone network.
This section explains the following tasks as they apply to managing VsmPE objects:
For information regarding the object relationships of the VPN service model, see the "Provider Edge Router" section.
|
Note VsmPE objects cannot be modified after adding them to the VPN Inventory repository. |
Use the following operations to create and define a CiscoVsmBrowser::VsmPE object:
Figure 4-24 shows the use of these operations. The order of execution is only significant for the newPECreator(), addToRep(), and releasePECreator() operations. The setHostName(), setNetworkName(), setDomainName(), setRouterPasswords(), setRouterInterfaces(), operations must execute prior to the addToRep() operation. The retrieveVsmRegion() operation is shown in italics to represent the two operations supplied by the CiscoVsmBrowser::VsmProviderAdminDomain interface that are listed and described in the "Retrieving VsmRegion Objects from the VPN Inventory Repository" section.
After adding a CiscoVsmBrowser::VsmPE object to the VPN Inventory repository, you may need to implement algorithms in your client code to add or remove router interfaces and passwords to the VsmPE object or simply dispose of the object when it is no longer needed.
The APIs supply the following operations to help you find a specific VsmPE object or all of them, as needed:
The findPEByID() operation returns a single VsmPE object based on the unique identifier assigned to it when the object was created. The findPEByRouterInfo() operation returns a single VsmPE object based on the host, network, and domain names, respectively, as specified by the VsmPECreator::setHostName(), setNetworkName(), and setDomainName() operations. The CiscoVsmBrowser::VsmRegion::getAllPEs() and CiscoVsmBrowser::VsmCustomer::getPEs() operations each return a sequence of all VsmPE objects stored in the VPN Inventory repository for that object; you must specify your own qualification scheme to get a specific object from the sequence. The VsmSRVCE::getPE() operation returns the VsmPE object that the given VsmSRVC object uses.
Figure 4-25 shows how to retrieve a VsmPE object from the VPN Inventory repository. Because the repository is not modified, no addToRep() or updateRep() operations are required. Use these operations to manage router interfaces and passwords or to modify or dispose of a VsmPE object; these operations are also useful for traversing the object structure for your VSM implementation.
Each CiscoVsmBrowser::VsmPE object maintains a set of router interfaces and router passwords, using the CiscoVsmBrowser::VsmRouterInterface and CiscoVsmBrowser::VsmRouterPassword custom types, respectively.
There are two sets of addition and removal operations that support the management of router interfaces and passwords for the CiscoVsmBrowser::VsmPE objects. They are:
These operations do not require an addToRep() or updateRep() operation and operate directly a specified VsmPE object in the VPN Inventory repository. Figure 4-26 shows how to use these operations to manage the use of router interfaces and passwords for a specified VsmPE object. The retrieveVsmPE() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmRegion Objects from the VPN Inventory Repository" section.
There are two types of removal operations that support the cleanup portion of the object-management task for VsmPE objects. They are:
The CiscoVpnServiceModel::VpnInvMgr::releasePE() operation simply releases a specified CiscoVsmBrowser::VsmPE object on the server. Client software can also remove a VsmPE object from the VPN Inventory repository if there are no outstanding VsmSRVC objects that use it to specify VPN connectivity between it and a VsmCE object.
You can determine whether or not there are any VsmSRVC objects that use the VsmPE object to be removed using the CiscoVsmBrowser::VsmPE::getSRVCs() operation with the following states listed in the CiscoVsmBrowser::VsmSRStateSeq input parameter: Requested, Pending, Invalid, FailedDeploy, Deployed, Broken, Functional, and Lost. This operation returns a sequence of VsmSRVC objects that use the specified VsmPE object; if all associated service requests are Closed, this operation returns an empty CiscoVsmBrowser::VsmSRVCSeq list.
The CiscoVpnServiceModel::VpnInvMgr::removePEFromRep() operation implicitly calls the releasePE() operation for the VsmPE object passed to it though the pe parameter. Clients that execute this operation, therefore, need not execute the releasePE() operation. To do so raises a RepException, because the VsmPE object, at that point, does not exist in the VPN Inventory repository.
Figure 4-27 shows how to dispose of a VsmPE object. The retrieveVsmPE() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmRegion Objects from the VPN Inventory Repository" section.
Creating a CiscoVsmBrowser::VsmCustomer object is the first algorithmic step in defining the customer side of the VSM objects required to establish VPN connectivity. This object is the rudimentary VSM element that manages the customer side of the VPN service.
This section explains the following tasks as they apply to managing VsmCustomer objects:
For information regarding the object relationships of the VPN service model, see the "VPN Customer" section.
Use the following operations to create and define a CiscoVsmBrowser::VsmCustomer object:
Figure 4-28 shows the use of these operations. The order of execution is only significant for the newCustomerCreator(), addToRep(), and releaseCustomerCreator() operations. The order of execution for the setName() and setContactInfo() operations is only significant in that they must both execute prior to the addToRep() operation.
After adding a CiscoVsmBrowser::VsmCustomer object to the VPN Inventory repository, you may need to implement algorithms in your client code to modify the VsmCustomer object or dispose of it when it is no longer needed.
Th APIs supplies the following operations to help you find a specific VsmCustomer object or all of them, as needed:
The findCustomerByName() operation returns a single VsmCustomer object based on the name specified in the CiscoVsmFWCreator::VsmCustomerCreator::setName() operation when the object was created. The getAllCustomers() operation returns a sequence of all VsmCustomer objects stored in the VPN Inventory repository; you must specify your own qualification scheme to get a specific object from the sequence. The VsmCustomerSite::getCustomer() operation returns the VsmCustomer object to which the given VsmCustomerSite object belongs.
Figure 4-29 shows how to retrieve a VsmCustomer object from the VPN Inventory repository. Because the repository is not modified, no addToRep() or updateRep() operations are required. Use these operations to modify or dispose of a VsmCustomer object; the VsmCustomerSite::getCustomer() operation is also useful for traversing the object structure of your VSM implementation.
After adding a CiscoVsmBrowser::VsmCustomer object to the VPN Inventory repository, you can perform limited modifications on it. You can retrieve a VsmCustomer object from the VPN Inventory repository using the operations described in the "Retrieving VsmCustomer Objects from the Repository" section.
Here is a list of the operations you can perform to modify a VsmCustomer objects in the VPN Inventory repository:
You cannot modify the AS number or the name of the VsmCustomer object. If you need to change either of these VsmCustomer features, you must create a new object.
Figure 4-30 shows how to use these operations to modify a VsmCustomer object from the VPN Inventory repository. The retrieveVsmCustomer() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmCustomer Objects from the Repository" section.
There are two types of removal operations that support the cleanup portion of the VSM object management task. They are:
The CiscoVpnServiceModel::VpnInvMgr::releaseCustomer() operation simply releases a specified CiscoVsmBrowser::VsmCustomer object on the server. Client software can also remove a VsmCustomer object from the VPN Inventory repository but only if no VsmCustomerSite objects belong to it.
You can determine whether or not the VsmCustomer object to be removed has any VsmCustomerSite objects using the CiscoVsmBrowser::VsmCustomer::getAllCustomerSites() operation. This operation returns a sequence of VsmCustomerSite objects that belong to the specified VsmCustomer object.
The CiscoVpnServiceModel::VpnInvMgr::removeCustomerFromRep() operation implicitly calls the releaseCustomer() operation for the VsmCustomer object passed to it though the customer parameter. Clients that execute this operation, therefore, need not execute the releaseCustomer() operation. To do so raises a RepException, because the VsmCustomer object, at that point, does not exist in the VPN Inventory repository.
Figure 4-31 shows how to dispose of a VsmCustomer object. The retrieveVsmCustomer() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmCustomer Objects from the Repository" section.
Create a CiscoVsmBrowser::VsmCustomerSite object and assign it to a VsmCustomer object in the VPN Inventory repository. The VsmCustomerSite object represents a specific customer site to which supply VPN connectivity over the provider backbone network.
This section explains the following tasks as they apply to managing VsmCustomerSite objects:
For information regarding the object relationships of the VPN service model, see the "Customer Site" section.
Use the following operations to create and define a CiscoVsmBrowser::VsmCustomerSite object:
Figure 4-32 shows the use of these operations. The order of execution is only significant for the newCustomerSiteCreator(), addToRep(), and releaseCustomerSiteCreator() operations. The order of execution for the setName() and setLocationInfo() operations is only significant in that they must both execute prior to the addToRep() operation. The retrieveVsmCustomer() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmCustomer Objects from the Repository" section.
After adding a CiscoVsmBrowser::VsmCustomerSite object to the VPN Inventory repository, you may need to implement algorithms in your client code to modify the VsmCustomerSite object or dispose of the object when it is no longer needed.
The APIs supply the following operations to help you find a specific VsmCustomerSite object or all of them, as needed:
The findCustomerSiteByName() operation returns a single VsmCustomerSite object based on the name specified in the CiscoVsmFWCreator::VsmCustomerSiteCreator::setName() operation when the object was created. The CiscoVsmBrowser::VsmCustomer::getAllCustomerSites() operation returns a sequence of all VsmCustomerSite objects stored in the VPN Inventory repository; you must specify your own qualification scheme to get a specific object from the sequence. The VsmCE::getCustomerSite() operation returns the VsmCustomerSite object to which the given VsmCE object belongs.
Figure 4-33 shows how to retrieve a VsmCustomerSite object from the VPN Inventory repository. Because the repository is not modified, no addToRep() or updateRep() operations are required. Use these operations to manage IP address pools or to modify or dispose of a VsmCustomerSite object; the VsmCE::getCustomerSite() operation is also useful for traversing the object structure for your VSM implementation.
After adding a CiscoVsmBrowser::VsmCustomerSite object to the VPN Inventory repository, you can modify it. You can retrieve a VsmCustomerSite object from the VPN Inventory repository using the operations described in the "Retrieving VsmCustomerSite Objects from the VPN Inventory Repository" section.
Here is a list of the operations you can perform to modify a VsmCustomerSite object in the VPN Inventory repository:
Figure 4-34 shows how to use these operations to modify a VsmCustomerSite object from the VPN Inventory repository. The retrieveVsmCustomerSite() operation is shown in italics to represent the two operations supplied by the CiscoVsmBrowser::VsmCustomer interface that are listed and described in the "Retrieving VsmCustomerSite Objects from the VPN Inventory Repository" section.
There are two types of removal operations that support the cleanup portion of the object-management task for VsmCustomerSite objects. They are:
The CiscoVpnServiceModel::VpnInvMgr::releaseCustomerSite() operation simply releases a specified CiscoVsmBrowser::VsmCustomerSite object on the server. Client software can also remove a VsmCustomerSite object from the VPN Inventory repository if no CiscoVsmBrowser::VsmCE objects belong to it.
You can determine whether or not the VsmCustomerSite object to be removed has any VsmCE objects using the CiscoVsmBrowser::VsmCustomerSite::getAllCEs() operation. This operation returns a sequence of VsmCE objects that belong to the specified VsmCustomerSite object.
The CiscoVpnServiceModel::VpnInvMgr::removeCustomerSiteFromRep() operation implicitly calls the releaseCustomerSite() operation for the VsmCustomerSite object passed to it though the region parameter. Clients that execute this operation, therefore, need not execute the releaseCustomerSite() operation. To do so raises a RepException, because the VsmCustomerSite object, at that point, does not exist in the VPN Inventory repository.
Figure 4-35 shows how to use these operation to dispose of a VsmCustomerSite object. The retrieveVsmCustomerSite() operation is shown in italics to represent the two operations supplied by the CiscoVsmBrowser::VsmCustomer interface that are listed and described in the "Retrieving VsmCustomerSite Objects from the VPN Inventory Repository" section.
Create a CiscoVsmBrowser::VsmCE object and assign it to a VsmCustomerSite object in the VPN Inventory repository. The VsmCE object represents a a provider-edge router in a specific geographic region of the provider backbone network.
This section explains the following tasks as they apply to managing VsmCE objects:
For information regarding the object relationships of the VPN service model, see the "Customer Edge Router" section.
Use the following operations to create and define a CiscoVsmBrowser::VsmCE object:
Figure 4-36 shows the use of these operations. The order of execution is only significant for the newCECreator(), addToRep(), and releaseCECreator() operations. The setHostName(), setNetworkName(), setDomainName(), setRouterPasswords(), setRouterInterfaces(), operations must execute prior to the addToRep() operation. The retrieveVsmCustomerSite() operation is shown in italics to represent the two operations supplied by the CiscoVsmBrowser::VsmCustomer interface that are listed and described in the "Retrieving VsmCustomerSite Objects from the VPN Inventory Repository" section.
After adding a CiscoVsmBrowser::VsmCE object to the VPN Inventory repository, you may need to implement algorithms in your client code to modify the VsmCE object, add or remove router interfaces and passwords, or simply dispose of the object when it is no longer needed.
The APIs supply the following operations to help you find a specific VsmCE object or all of them, as needed:
The findCEByID() operation returns a single VsmCE object based on the unique identifier assigned to it when the object was created. The findCEByRouterInfo() operation returns a single VsmCE object based on the host, network, and domain names, respectively, as specified by the VsmCECreator::setHostName(), setNetworkName(), and setDomainName() operations. The CiscoVsmBrowser::VsmCustomerSite::getAllCEs() operation returns a sequence of all VsmCE objects stored in the VPN Inventory repository for that object; you must specify your own qualification scheme to get a specific object from the sequence. The VsmSRVCE::getCE() operation returns the VsmCE object that the given VsmSRVC object uses.
Figure 4-37 shows how to retrieve a VsmCE object from the VPN Inventory repository. Because the repository is not modified, no addToRep() or updateRep() operations are required. Use these operations to manage router interfaces and passwords or to modify or dispose of a VsmCE object; these operations are also useful for traversing the object structure for your VSM implementation.
After adding a CiscoVsmBrowser::VsmCE object to the VPN Inventory repository, you can modify it on a limited basis. You can retrieve a VsmCE object from the VPN Inventory repository using the operations described in the "Retrieving VsmCE Objects from the VPN Inventory Repository" section.
Here is a list of the operations you can perform to modify a VsmCE object in the VPN Inventory repository:
Figure 4-38 shows how to use these operations to modify a VsmCE object from the VPN Inventory repository. The retrieveVsmCE() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmCE Objects from the VPN Inventory Repository" section.
Each CiscoVsmBrowser::VsmCE object maintains a set of router interfaces and router passwords, using the CiscoVsmBrowser::VsmRouterInterface and CiscoVsmBrowser::VsmRouterPassword custom types, respectively.
There are two sets of addition and removal operations that support the management of router interfaces and passwords for the CiscoVsmBrowser::VsmCE objects. They are:
These operations do not require an addToRep() or updateRep() operation and operate directly a specified VsmCE object in the VPN Inventory repository. Figure 4-26 shows how to use these operations to manage the use of router interfaces and passwords for a specified VsmCE object. The retrieveVsmCE() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmRegion Objects from the VPN Inventory Repository" section.
There are two types of removal operations that support the cleanup portion of the object-management task for VsmCE objects. They are:
The CiscoVpnServiceModel::VpnInvMgr::releaseCE() operation simply releases a specified CiscoVsmBrowser::VsmCE object on the server. Client software can also remove a VsmCE object from the VPN Inventory repository if there are no outstanding VsmSRVC objects that use it to specify VPN connectivity between it and a VsmCE object.
You can determine whether or not there are any VsmSRVC objects that use the VsmCE object to be removed using the CiscoVsmBrowser::VsmCE::getSRVCs() operation with the following states listed in the CiscoVsmBrowser::VsmSRStateSeq input parameter: Requested, Pending, Invalid, FailedDeploy, Deployed, Broken, Functional, and Lost. This operation returns a sequence of VsmSRVC objects that use the specified VsmCE object; if all associated service requests are Closed, this operation returns an empty CiscoVsmBrowser::VsmSRVCSeq list.
The CiscoVpnServiceModel::VpnInvMgr::removeCEFromRep() operation implicitly calls the releaseCE() operation for the VsmCE object passed to it though the ce parameter. Clients that execute this operation, therefore, need not execute the releaseCE() operation. To do so raises a RepException, because the VsmCE object, at that point, does not exist in the VPN Inventory repository.
Figure 4-40 shows how to dispose of a VsmCE object. The retrieveVsmCE() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmCE Objects from the VPN Inventory Repository" section.
Create a CiscoVsmBrowser::VsmCERC object and assign it to a VsmVPN from the VPN Inventory repository. The VsmCERC object represents the CE Routing Community, which defines the relationship between sites as either "full mesh" or "hub-and-spoke."
This section explains the following tasks as they apply to managing VsmCERC objects:
For information regarding the object relationships of the VPN service model, see the "CE Routing Community" section.
Use the following operations to create and define a CiscoVsmBrowser::VsmCERC object:
Figure 4-41 shows the use of these operations. The order of execution is only significant for the newCERCCreator(), addToRep(), and releaseCERCCreator() operations. The setDesc(), setAutoPickRTValues(), setHubRT(), setSpokeRT() operation must execute, as required, prior to the addToRep() operation. The retrieveVsmVPN() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmVPN Objects from the VPN Inventory Repository" section.
After adding a CiscoVsmBrowser::VsmCERC object to the VPN Inventory repository, you may need to implement algorithms in your client code to modify the VsmCERC object or simply dispose of the object when it is no longer needed.
The APIs supply the following operations to help you find a specific VsmCERC object or all of them, as needed:
The findCERCByID() operation returns a single VsmCERC object based on the unique identifier assigned to it when the object was created. The VsmSRVC::getCERC() operation returns a VsmCERC object based on the name specified in the CiscoVsmFWCreator::VsmCERCCreator::setName() operation when the object was created. The VsmVPN::getAllCERCs() operation returns a sequence of all VsmCERC objects stored in the VPN Inventory repository; you must specify your own qualification scheme to get a specific object from the sequence.
Figure 4-42 shows how to retrieve a VsmCERC object from the VPN Inventory repository. Because the repository is not modified, no addToRep() or updateRep() operations are required.
After adding a CiscoVsmBrowser::VsmCERC object to the VPN Inventory repository, you can modify it. You can retrieve a VsmCERC object from the VPN Inventory repository using the operations described in the "Retrieving VsmCERC Objects from the VPN Inventory Repository" section.
Here is a list of the operations you can perform to modify a VsmCERC object in the VPN Inventory repository:
Figure 4-43 shows how to use these operations to modify a VsmCERC object from the VPN Inventory repository.
There are two types of removal operations that support the cleanup portion of the object-management task for VsmCERC objects. They are:
The CiscoVpnServiceModel::VpnInvMgr::releaseCERC() operation simply releases a specified CiscoVsmBrowser::VsmCERC object on the server. Client software can also remove a VsmCERC object from the VPN Inventory repository if no VPN routing and forwarding (VRF) table definitions are associated with it.
To verify that no CiscoVsmBrowser::VsmVRFDef object is associated with the specified VsmCERC object has, execute the CiscoVsmBrowser::VsmCERC::getAllVRFDefs() operation. If the this operation returns an empty CiscoVsmBrowser::VsmVRFDefSeq list, there are no VRFs associated with this VsmCERC object, and the removeCERCFromRep() operation can execute successfully.
The CiscoVpnServiceModel::VpnInvMgr::removeCERCFromRep() operation implicitly executes the releaseCERC() operation for the VsmCERC object passed to it though the cerc parameter. Clients that execute this operation, therefore, need not execute the releaseCERC() operation. To do so raises CiscoVsmExceptions::RepException, because the VsmCERC object, at that point, does not exist in the VPN Inventory repository. Figure 4-44 shows how to use these operation to dispose of a VsmCERC object.
Verifying that there are no associated CiscoVsmBrowser::VsmVRFDef objects in the VPN Inventory repository ensures that no CiscoVsmBrowser::VsmSRVC objects in the VPN Inventory repository are associated with the VsmCERC object to be removed.
A CERC membership defines the relationship between a VRF definition and a CERC. It dictates which CERC a VRF Definition is joining and whether the CE end of the PE-CE link is joining the CERC as a hub or a spoke.
Create a CiscoVsmBrowser::VsmCERCMembership object and assign it to a VsmVPN from the VPN Inventory repository. The VsmCERCMembership object represents the CE Routing Community, which defines the relationship between sites as either "full mesh" or "hub-and-spoke."
This section explains the following tasks as they apply to managing VsmCERCMembership objects:
For information regarding the object relationships of the VPN service model, see the "CERC Membership" section.
Use the CiscoVpnServiceModel::VpnInvMgr::newCERCMembership() operation to create and define a new CiscoVsmBrowser::VsmCERCMembership object. Figure 4-45 shows how to retrieve a VsmCERC object for use as an input object to the newCERCMembership() operation.You must also supply the boolean useHubRTState parameter that specifies whether or not the VsmCERCMembership object requires a CiscoVsmBrowser::VsmVRFDef object that permits a site to join the specified CERC, cerc, as a hub site.
The CiscoVsmBrowser::VsmCERCMembership object returned by the newCERCMembership() operation is stored in the VPN Inventory repository only when it is supplied as an input parameter to either the CiscoVsmSRCreator::VsmVPNConnectivityCreator::setCERCMemberships() or CiscoVsmSRCreator::VsmVPNServiceModifier::setCERCMemberships() operation when creating or modifying a CiscoVsmBrowser::VsmSRVC object. For more information regarding the usage of VsmCERCMembership objects, see the "VPN Connectivity" section, which describe how to create a CiscoVsmBrowser::VsmSRVC object.
|
Note The CiscoVsmBrowser::VsmCERCMembership object cannot be modified. However, using the CiscoVsmSRCreator::VsmVPNServiceModifier interface you can create a new VsmSRVC object that subsumes an existing one, thus redefining the list of VsmCERCMembership objects supplied for use by a given VsmSRVC object. |
After adding a CiscoVsmBrowser::VsmCERCMembership object to the VPN Inventory repository by creating a VsmSRVC object, you can retrieve it through the interface of the VsmVRFDef object with which it is associated. You may need to implement algorithms in your client code to release memory allocated to a VsmCERCMembership object when it is no longer needed. Figure 4-46 shows how to retrieve a VsmCERCMembership object from the VPN Inventory repository.
Because VsmCERCMembership objects are not added directly to the VPN Inventory repository, there is no need to explicitly remove them from the repository, either. With the APIs, you can merely execute the only the CiscoVpnServiceModel::VpnInvMgr::releaseCERCMembership() operation to release of the VsmCERCMembership object on the server that is specified by through the cercMembership parameter. Figure 4-47 shows how to release a specified VsmCERCMembership object on the server.
While unable to directly remove a VsmCERCMembership object from the VPN Inventory repository, client software can indirectly remove a VsmCERCMembership object from the VPN Inventory repository. To remove a VsmCERCMembership object from the VPN Inventory repository, you must remove its adjoining VsmVFDef object, which may also have joined other VsmCERCMembership objects. A VsmVFDef object can only be implicitly removed from the repository be removing the VsmSRVC objects that define it.
Verifying that there are no associated CiscoVsmBrowser::VsmVRFDef objects in the VPN Inventory repository ensures that no CiscoVsmBrowser::VsmSRVC objects in the VPN Inventory repository are associated with the VsmCERCMembership object to be removed. Figure 4-47 shows how to dispose of a VsmCERCMembership object.
The CiscoVsmBrowser module defines an interface, VsmSRVC, to the service-request objects that are created and modified, respectively, by the CiscoVsmSRCreator::VsmVPNConnectivityCreator and CiscoVsmSRCreator::VsmVPNServiceModifier interfaces. For more information about managing service-request objects, see "Defining Service Requests."
"Overview: VPN Service Model," lists the CiscoVsmBrowser::VsmSRVC object as a standard VSM object, but its management requirements are very different from other VSM objects in your client-application code. A VsmSRVC object is created when a request to add VPN service to a CE is created; thus, there is no explicit constructor or modifier for this interface.
Although the CiscoVsmSRCreator::VsmVPNConnectrivityCreator::addToRep() operation implicitly creates a VsmSRVC object when it executes, releasing object references to the VsmSRVC object and removing obsolete VsmSRVC objects from the VPN Inventory repository are tasks that require management by the client application.
This section explains the following tasks as they apply to managing VsmSRVC objects:
For information regarding the object relationships of the VPN service model, see the "Service Request VPN Configuration" section.
To create a CiscoVsmBrowser::VsmSRVC object, use the instructions in the "VPN Connectivity" section, which describes how to create a CiscoVsmBrowser::VsmSRVC object. The process for creating a VsmSRVC object returns a VsmSRVC object, and you can otherwise use the VSM APIs to access the related VsmSRVC objects as described in the "Retrieving VsmSRVC Objects from the VPN Inventory Repository" section that follows.
|
Note The CiscoVsmBrowser::VsmSRVC object cannot be modified. However, using the CiscoVsmSRCreator::VsmVPNServiceModifier interface you can create a new VsmSRVC object that subsumes an existing one. |
After adding a CiscoVsmBrowser::VsmSRVC object to the VPN Inventory repository, you may need to implement algorithms in your client code to modify the VsmSRVC object or simply dispose of the object when it is no longer needed.
The APIs supply the following operations to help you find a specific VsmSRVC object or all of them, as needed:
The findSRVCByID() operation returns a single VsmSRVC object based on the unique identifier assigned to it when executing the CiscoVsmSRCreator::VsmVPNConnectivityCreator::addToRep() operation to add it to the VPN Inventory repository. The findSRVCsByPECEPair() operation returns a qualified sequence of all VsmSRVC objects that specify VPN connectivity for a given pair of VsmCE and VsmPE objects and that have one of the states listed in the srStates parameter. The getAllSRVCs() operation returns a sequence of all VsmSRVC objects stored in the VPN Inventory repository.
With the exception of the CiscoVsmBrowser::VsmConfiglet::getSRVCs() operations, which simply returns all of the VsmSRVC objects associated with the given VsmConfiglet object, each of the getSRVCs() operations returns a sequence of all VsmSRVC objects stored in the VPN Inventory repository and that have one of the states listed in the srStates parameter.
For all operations that return a sequence of VsmSRVC objects, you must specify your own qualification scheme to get a specific object from the sequence. Figure 4-48 shows how to retrieve a VsmSRVC object from the VPN Inventory repository.
To modify a CiscoVsmBrowser::VsmSRVC object, use the instructions in the "VPN Connectivity" section, which describe how to modify a CiscoVsmBrowser::VsmSRVC object. The process for modifying a VsmSRVC object returns a VsmSRVC object, and you can otherwise use the VSM APIs to access related VsmSRVC objects as described in the "Retrieving VsmSRVC Objects from the VPN Inventory Repository" section.
There are two types of removal operations that support the cleanup portion of the object-management task for VsmSRVC objects. They are:
The CiscoVpnServiceModel::VpnInvMgr::releaseSRVC() operation simply releases a specified CiscoVsmBrowser::VsmSRVC object on the server. Client software can also remove a VsmSRVC object from the VPN Inventory repository if its CiscoVsmBrowser::VsmSRState enumeration is set to Closed. To verify that the CiscoVsmBrowser::VsmSRVC object to be removed is Closed, execute the CiscoVsmBrowser::VsmSRVC::getState() operation for that VsmSRVC object.
The CiscoVpnServiceModel::VpnInvMgr::removeSRVCFromRep() operation implicitly calls the releaseSRVC() operation for the VsmSRVC object passed to it though the srvc parameter. Clients that execute this operation, therefore, need not execute the releaseSRVC() operation. To do so raises a RepException, because the VsmSRVC object, at that point, does not exist in the VPN Inventory repository.
Figure 4-49 shows how to dispose of a VsmSRVC object. The retrieveVsmSRVC() operation is shown in italics to represent the two operations supplied by the CiscoVpnServiceModel::VpnInvMgr interface that are listed and described in the "Retrieving VsmSRVC Objects from the VPN Inventory Repository" section.
The CiscoVsmBrowser module defines an interface, VsmConfiglet, that VsmSRVC objects use for provisioning the PE and CE for which VPN connectivity is specified. Each VsmSRVC object that specifies VPN connectivity for a PE-CE pair supplies one VsmConfiglet for each edge router based on the respective PE and CE information supplied when creating the VsmSRVC object. Like the VsmSRVC objects, the VsmConfiglet objects are created and modified, respectively, by the CiscoVsmSRCreator::VsmVPNConnectivityCreator and VsmVPNServiceModifier interfaces. For more information about managing service-request objects, see "Defining Service Requests."
"Overview: VPN Service Model," lists the CiscoVsmBrowser::VsmConfiglet object as a standard VSM object, but its management requirements are very different from other VSM objects in your client-application code. Two VsmConfiglet objects are created when a request to add VPN service to a CE is created; thus, there is no explicit constructor or modifier for this interface.
Although the CiscoVsmSRCreator::VsmVPNConnectrivityCreator::addToRep() operation implicitly creates the VsmConfiglet objects for its generated VsmSRVC object when it executes, releasing object references to the VsmConfiglet object and removing obsolete VsmConfiglet objects from the VPN Inventory repository are tasks that require management by the client application.
This section explains the following tasks as they apply to managing VsmConfiglet objects:
For information regarding the object relationships of the VPN service model, see the "Configlet" section.
To create a CiscoVsmBrowser::VsmConfiglet object, use the instructions in the "VPN Connectivity" section, which describes how to create a CiscoVsmBrowser::VsmSRVC object to add VPN connectivity to a CE. The process for creating a VsmSRVC object returns two VsmConfiglet objects—one for the PE and one for the CE—and you can use the VSM APIs to access them as described in the "Retrieving VsmConfiglet Objects from the VPN Inventory Repository" section that follows.
After adding a CiscoVsmBrowser::VsmConfiglet object to the VPN Inventory repository, you may need to implement algorithms in your client code to modify the VsmConfiglet object or simply dispose of the object when it is no longer needed.
The APIs supply the following operations to help you find a specific VsmConfiglet object or all of them, as needed:
The findConfigletByID() operation returns a single VsmConfiglet object based on the unique identifier assigned to it when executing the CiscoVsmSRCreator::VsmVPNConnectivityCreator::addToRep() operation to add a service request to the VPN Inventory repository.
The getCEConfiglet() and getPEConfiglet() operations simply return, respectively, the VsmCE and VsmPE objects in the VPN Inventory repository that are associated with a specific VsmSRVC object.
The getConfiglets() and getConfigletList() operations each return a sequence of all VsmConfiglet objects stored in the VPN Inventory repository that have one of the states listed in the srStates parameter. For all operations that return a sequence of VsmConfiglet objects, you must specify your own qualification scheme to get a specific object from the sequence. Figure 4-50 shows how to retrieve a VsmConfiglet object from the VPN Inventory repository.
To modify a CiscoVsmBrowser::VsmConfiglet object, use the instructions in the "Defining Service Requests," which describes how to modify a CiscoVsmBrowser::VsmSRVC object. Modifying a VsmConfiglet object is a by product of modifying a VsmSRVC object, and you can otherwise use the VSM APIs to access related VsmConfiglet objects as described in the "Retrieving VsmSRVC Objects from the VPN Inventory Repository" section.
Because VsmConfiglet objects are not added directly to the VPN Inventory repository, there is no need to explicitly remove them from the repository, either. With the APIs, you can merely execute the only the CiscoVpnServiceModel::VpnInvMgr::releaseConfiglet() operation to release of the VsmConfiglet object on the server that is specified by the configlet parameter. Figure 4-51 shows how to release a specified VsmCERCMembership object on the server.
Like the VsmCERCMembership and VsmVFDef objects, the VsmConfiglet object cannot be removed directly from the VPN Inventory repository. While unable to directly remove a VsmConfiglet object from the VPN Inventory repository, however, client software can indirectly remove a VsmConfiglet object from the VPN Inventory repository by removing all of the VsmSRVC objects that it supports.
Posted: Fri Sep 22 20:16:27 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.