Service Provisioning Module

Table Of Contents

service_prov_mgr.idl

Interface List

Module ServiceProvisioning

Data Structures and Types

NEInfo Structure

NEInfoSeq User Defined Type

ServiceRequest Structure

Interface ProvisionMgr

Operations

process_service_request()

service_prov_mgr.idl

---

Interface List

The service_prov_mgr.idl file contains the following interface:

ServiceProvisioning::ProvisionMgr

Module ServiceProvisioning

The ServiceProvisioning module encapsulates the ProvisionMgr interface and related data structures.

Data Structures and Types

NEInfo Structure

Structure for network element information.

Usage

struct NEInfo

{

string deviceId;

string deviceModel;

string deviceType;

CCNSC_Common::NVPairSeq overridingAttrs;

CCNSC_Common::NVPairSeq configParams;

};

Members

deviceId—fully distinguished name of the device.

deviceModel—the model of the CPE device (for example, 2421, 3660, 827v4).

deviceType—the device type (for example, AGGR, CPE, ROUTER).

overridingAttrs—overrides the values of attributes from the provision profile. For example,
{ PP_CPE_DOWNLOAD_METHOD = ftp | tftp | console:port#| http | telnet }
{ PP_CONFIG_DESTINATION = STARTUP | RUNNING }

configParams—configuration template data variable name and their values. The keywords supported for the name depend upon the actual solution on the backend side. For example, a solution with VoIPoATM may have a SignalPVC as a template data variable, however, this is not the case of a VoIPoT1 solution which is a pure Voice over IP solution.

For example, VoIPoATMoDSL, the configDAtaInfo may have the following name value pairs:
{ name = SignalPVC, value = 0/1 }
{ name = BearerPVC, value = 2/1 }
{ name = DataPVC, value = 4/1 }
{ name = FDN, value = /root:/SanJose/TestLab/20_3_1}
{ name = ManagementIP, value = 10.20.30.40}

Also, note that some IOS configuration commands take repeated multiple arguments. In this case, the value is a concatenation of all such arguments. For example:
{ name = snmp_server, value = community public R0 }

NEInfoSeq User Defined Type

User defined data type for sequence of NEInfo.

Usage

typedef sequence<NEInfo> NEInfoSeq

ServiceRequest Structure

Structure for a service request.

Usage

struct ServiceRequest

{

CCNSC_Common::OperationType opType;

string serviceReferenceId;

string serviceRequestDescription;

string operatorId;

CCNSC_Common::TechnologyType techType;

NEInfoSeq networkElements;

string customerId;

string subscriberId;

string serviceProfileId;

CCNSC_Common::StringSeq serviceFeatureList;

};

Members

opType—refer to Chapter 11, "type_def.idl," for a description of the operation type.

serviceReferenceId—service reference ID (input by the user) that need not be unique. This is for easy identification of a service request from the user's perspective. The system uses this for logging purposes only.

serviceRequestDescription—description of the service request.

operatorId—operator ID of the user requesting this service request execution.

techType—refer to Chapter 11, "type_def.idl," for a description of the technology type.

networkElements—info about the network elements that are involved in this service request.

customerId—customer ID pertaining to this service request.

subscriberId—subscriber ID pertaining to this service request.

serviceProfileId—the service profile ID to be used for this service request A service profile defines the various service parameters of a service. Refer to the profile.idl and profile_analyzer.idl files for details.

serviceFeatureList—list of service features to be handled in this service request. Depending on the service request, the device's current list of service features are updated. For example, after downloading basic provisioning, the service feature BASIC will be added to the device's service feature list and the device state will be made provisioned.

The service features are checked for any dependencies before execution of service request. These dependencies are stored in a service feature map file. The dependency are of the form ( Z -> X,Y), which means the service feature Z depends on service feature X and Y, that is, in order to add service feature Z, the device must be provisioned with service feature X and Y earlier.

Interface ProvisionMgr

The Interface ProvisionMgr encompasses the operations for service provisioning.

Operations

process_service_request()

Provisioning operations for processing a service request.

Usage

CCNSC_Common::ResultInfo process_service_request(

in CCNSC_Common::SecurityToken securityToken,

in ServiceRequest serviceRequest,

out long serviceId);

Parameters

securityToken—security token for authentication purposes.

serviceRequest—service request information (see ServiceRequest struct for details).

serviceId—service request ID returned by the server.

Returns

ResultInfo—the result of the operation (refer to Chapter 11, "type_def.idl," for information about the attributes of this structure and Chapter 8, "spm_errors.idl," for the error codes returned by this method).

Raises

No exception raised by this operation.

Description

The process_service_request method is responsible for handling the request. The service request structure passed to this method contains the operationType field which dictates the actual type of operation to be done during the handling of this service request. The operation can be either to add service, delete service, or modify service. Add_service takes a service request structure and provisions a device so as to add service features. The method returns a service ID which is a system generated unique ID to track this particular request. The service features to be added are passed in through the serviceFeatureList field of the service request. Refer to the ServiceRequest structure for the description of serviceFeatureList. The configuration parameters for the devices may be passed in the configParams field of the NEInfo struct.

Delete_service takes a service request structure and tries to unprovision a device so as to delete service features from a device that is already provisioned. This method returns a service ID which is a system generated unique ID used to track this particular request. Note that for delete service, the configuration parameters are not needed and therefore, the configParams field of the NEInfo struct should be passed empty.

Modify_service takes a service request structure and tries to modify the configuration on the device. Note, modify service is not used for adding or deleting service feature(s) on a device, rather, it is to modify the configuration parameters of a service feature that has already been added to the device through a prior add service. This method returns a service ID which is a system generated unique ID used to track this particular request. The new value for the configuration parameters for the devices may be passed in the configParams field of the NEInfo struct.

---

Note For all three types of operations, depending upon the delivery type, if it is a push method, the return result indicates whether the configuration was applied or not. If it is a pull method, the API returns after the configuration file is generated and prepared for download. The return result indicates whether the configuration generation and preparation was successful or not. However, whether the device has actually downloaded and applied the configuration or not is unknown. The OSS application must query the device or use some other method for verification purposes.

---

---

Note In the current release, the securityToken field is not used for authentication.It is a place holder.

---