| Oracle® Communications IP Service Activator Concepts Release 7.2 E47715-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications IP Service Activator Concepts Release 7.2 E47715-01 |
|
|
PDF · Mobi · ePub |
This chapter describes the features of Oracle Communications IP Service Activator that enable it to integrate with other OSS applications.
The IP Service Activator installation provides an optional Web Services component that allows IP Service Activator to integrate with Oracle Communications Order and Service Management (OSM). The IP Service Activator Web service supports the use of multiple OIM instances connected to a single instance of IP Service Activator.
For more information about web services, see IP Service Activator OSS Integration Manager Guide.
The OSS Integration Manager (OIM) enables IP Service Activator to be easily integrated with OSS applications such as order entry, service assurance, fault management, and billing, as illustrated in Figure 7-1.
The OIM consists of an open application program interface (API) that allows systems developers to access subsets of the IP Service Activator data model. Use of a Common Object Request Broker Architecture (CORBA) interface ensures secure and standardized communication with other applications, and can easily be adapted to use alternative architectures such as Tibco, Vitria, or XMP. Developers can develop scripts using any CORBA-compliant programming language (such as C++, Java, or Python), or use a command-line interface which allows user to run the commands interactively.
The OIM has been specifically designed to simplify the work of system developers wishing to integrate with IP Service Activator. To write applications to integrate with IP Service Activator, developers need:
Details of the OIM command set and syntax
Details of the objects that can be accessed and the relationships between them
The command language comprises a set of commands that provide an interface to the API. It is limited to a small set of generic commands such as create, find or modify, that operate on defined objects and their attributes. The use of generic commands means that the command set is not affected by changes to the object model, and is sufficiently flexible to support diverse uses such as integration of OSS applications, service activation or custom web development. Commands are grouped into various modules, but all commands have the same basic format, similar to UNIX or other scripting languages:
command [object_path] [parameters]
Commands that execute changes to the database and network are aggregated into transactions, which work in the same way as using transactions from the IP Service Activator client. This logical approach helps ensure straightforward scripting.
The External Object Model (EOM) is a simplified version of IP Service Activator's knowledge store. It defines all the objects that can be accessed or updated by external applications, including their attributes and the relationships between them.
Using a subset of the entire object model means that user programs can create and access data objects without needing to know the underlying complexity of the entire object model. The External Object Model is independent of the command syntax – new attributes and objects can be added without requiring new commands.
Objects in the External Object Model are divided into three major categories:
Topology: these objects represent the topology of the managed network, such as Network, Device and Interface objects.
Policy: these objects represent elements used to define policies and services that can be configured on network nodes, such as Domain, Rule and Traffic Type objects.
System: these objects represent IP Service Activator components and the event handler subscription model, such as Component, Subscription and Fault objects.
In IP Service Activator, the Policy Server performs full transaction monitoring. IP Service Activator flow-through applications can therefore reliably tracks the progress of all IP Service Activator transactions as the corresponding configuration changes are activated on the network. This allows flow-through applications, which generally use IP Service Activator through its OIM APIs, to monitor the success or failure of their IP Service Activator transactions.
The IP Service Activator object model uses the concrete activation status to indicate whether a transaction's configuration changes, corresponding to each individual concrete, were successfully activated on the network.
The concrete activation status is recorded for the concretes affected by a particular transaction. It is aggregated into the overall provisioning status for the transaction. Both are attributes of the transaction object and can be observed in the IP Service Activator client and the APIs of the OSS Integration Manager:
CORBA
OSS Java Development Library (OJDL)
For more information about OJDL, see "The OSS Java Development Library".
More information about transaction monitoring functions is provided in IP Service Activator System Administrator's Guide.
Other software applications can use the OIM API to create and modify services for particular customers. For example, external applications can:
Discover network elements, including details of interfaces, sub-interfaces and PVCs and their capabilities, or create devices for pre-provisioning.
Set up customers and sites, link sites to network elements and create VPNs and Transparent LAN Services.
Set up and apply QoS or access control policies and apply them to specific points in the network topology.
Subscribe to fault and state changes in any object.
IP Service Activator can inform external applications of events or faults that occur throughout the network it is managing. This functionality is provided by the Event Handler, an optional component that is accessible through both OIM and the IP Service Activator client.
Figure 7-2 illustrates how the Event Handler filters events.
Figure 7-2 Event Handler Subscription Model
The Event Handler enables configurable, software-driven control of event reporting. It includes the following features:
The Event Handler can report various events occurring in the managed network – the occurrence of a fault reported by IP Service Activator, the creation, deletion, linking or unlinking of an object, the change in the status of an object or the change in an attribute of an object.
Users can define the events they are interested in by setting up subscriptions, which can be viewed, added, deleted and modified through the OIM or the IP Service Activator client.
Events can be delivered using different methods (SNMP, CORBA or Netcool Probe).
User-defined filters can enable subscribers to define exactly the events of interest, for example, specific faults and fault categories.
External applications communicate with the Event Handler by means of event subscriptions, which allow users of external applications considerable control over the events reported. For example, you can set up subscriptions to report on the following:
All events and faults occurring anywhere in the system
Faults reported in IP Service Activator components
All events occurring in a specific VPN
Events occurring on all PE devices in a network
A set of specific faults relating to communication problems
The Event Handler gives subscribers considerable control over the events to be reported.
The primary point of interest can be defined. For example, an associated object in the network topology can be selected, such as a network or specific device. You can choose to report on this object only, or the object itself and all objects below it in the hierarchy. The scope can further be restricted by class of object, such as all devices, or all sites in a VPN. If you are reporting on devices and interfaces, you can choose to report only on those with a specific role. So, for example, you can set up a subscription to report on all configuration faults occurring on PE devices and their associated interfaces in VPNs associated with a specific customer.
For faults and attribute changes, you can apply filters to identify even more precisely the events to be reported. For faults, you can set up a filter to report faults in a particular category, or even by individual fault code. For attributes, you can select the individual object attribute to be monitored.
This categorization enables different types of messages to be accessed by different systems. For example, problems with provisioning may be of interest to billing systems, since requested services may have been compromised, while communication faults are more relevant to network engineers
Events can be delivered to external applications as SNMP traps, by a CORBA interface or by the Micromuse Netcool API.
Faults and clears reported from the IP Service Activator components can be delivered to other applications in the form of SNMP traps.
A basic method, ensuring compatibility with earlier releases of IP Service Activator, reports the ID, severity and description of the fault.
An upgraded method enables events other than faults to be reported, and provides more information about the event, such as the IP address and status of an affected device.
Traps can be reported in SNMP v1 or v2 format.
The CORBA delivery mechanism allows CORBA clients to register and receive events by CORBA calls. The events are sent using the same format as defined by the CosNotification standard for structured events. An event channel name is defined in the IP Service Activator user interface (or through the OIM) when setting up the subscription object. A client may connect to one specific channel or all of the event channels defined in the subscriptions.
Any type of event reported from IP Service Activator can be forwarded to Netcool/ OMNIbus, the Micromuse Service Level Manager. This means that the network manager benefits from a single point where all events are reported, prioritized and resolved. See "Fault Management" for more details of the integration.
The OSS Java Development Library (OJDL) is a toolkit that enables the development of web-based user interfaces to IP Service Activator and the integration of data from billing, fault or performance measurement software. Based on the OIM API, OJDL provides a set of Java classes that provide general access to the OIM and Java server pages ready for web deployment. An example web-based user interface is provided, which integrators can use as a basis for their own development.
These features enable Service Providers to offer self-provisioning web interfaces, allowing their customers to order, view and amend their own services without any intervention by the provider. The interface can also be optimized for web self-management or centralized workflow provisioning, for example, for call center usage.
The OJDL consists of the following components:
A toolkit: a set of Java classes and beans that may be used to integrate third-party applications or develop a Java front end to IP Service Activator.
A sample interface: an example interface that may be used for demonstration purposes or as the basis of your own development.
The elements of the OJDL Toolkit and sample application are shown in Figure 7-3.
The OJDL interfaces with IP Service Activator through the EOM. Objects in the EOM can be manipulated using pre-defined Java classes. These classes provide a generic front end to the OIM, supporting quick and easy integration by a Java developer. In addition, pre-defined Java beans simplify the development process, providing reusable collections of the OIM commands required to perform a particular task, such as logging in.
This section describes the ready-to-use integrations that come with IP Service Activator.
The ability to offer and monitor Service Level Agreements is essential to Service Providers, who risk substantial losses if network downtime occurs and agreements are violated. Real-time reporting is a valuable tool in preventing network downtime, by highlighting potential problems before they actually occur. Real-time and historical reports provide a valuable tool when selling services, enabling the Service Provider to demonstrate their ability to offer guaranteed service levels.
IP Service Activator integrates with both Concord's eHealth™ Suite and InfoVista™, enabling Service Providers to offer real-time, customer-oriented IP services with guaranteed levels of service. SLAs can be monitored through at-a-glance reports, enabling the Service Provider to identify potential problems before they occur.
Ready-to-use integration reduces management and operational costs by providing automated activation and workflow management for the delivery of IP services and SLA reporting, including Service Assurance Agent (SAA) and NetFlow configuration.
A number of range of measurement techniques are supported, enabling measurement of point-to-point performance, or performance at a specific point in the network:
Service Assurance Agent (SAA): a Cisco technology that performs point-to-point measurement based on key SLA metrics such as response time, network resources, availability, jitter, connect time and packet loss.
NetFlow: a Cisco technology that enables you to characterize and analyze an IP flow on an interface. It is often used as a metering base for other applications, including accounting/billing, network planning, and marketing.
MIB2 statistics: report on Management Information Bases (MIBs) in MIB2 format. Their variables indicate the basic state of the network – for example, load, availability, discards and broadcast rate.
Class-based QoS MIB (CB QoS MIB) statistics: provide information about the policy and class maps that are configured on a device. In IP Service Activator terms, these statistics map onto the Class-based WFQ, WRED or MQC PHB groups that have been configured through the user interface.
Both SAA and NetFlow involve configuration on the device and this is performed automatically by the IP Service Activator Device Driver.
IP Service Activator employs a basic generic architecture that supports integration with a range of third-party reporting tools. Figure 7-4 illustrates the architecture of the integrated solution for InfoVista.
The IP Service Activator integration with InfoVista offers a very scalable solution – a number of InfoVista Servers and plug-ins can be distributed throughout the network, each one polling a subset of managed devices. Service Providers can specify the type of measurement to apply and the points in the network to monitor. A range of reports is available for each measurement type, and for a range of time periods including real-time, hourly, daily and weekly.
Four components (one in IP Service Activator and three in InfoVista) enable InfoVista reporting with IP Service Activator.
InfoVista Integration module: An IP Service Activator module that includes the TopologyExporter utility and several integration files. The TopologyExporter exports the object model and converts it to an InfoVista format ready for import.
InfoVista Server: An InfoVista component that uses SNMP to poll and collect SAA and MIB-based data from devices and NetFlow data from Vista Plug-ins for NetFlow. An IP Service Activator file allocates devices to InfoVista servers.
Vista Plug-in for Netflow: An InfoVista module that collects and aggregates UDP datagrams from NetFlow-enabled devices and exports the data to an InfoVista Server. The component is required only when the NetFlow measurement is applied. An IP Service Activator file allocates devices to Vista Plug-ins for NetFlow.
Vista Provisioner: An InfoVista utility that enables users to automate a number of key tasks in the administration of an InfoVista Server.
Each InfoVista Server maintains a local object model that reflects the devices assigned to it and the measurement applied. In the InfoVista object model, a class of objects is referred to as a Vista. IP Service Activator objects such as devices, interfaces, PVCs, and SAA operations, are mapped to InfoVista Vistas. A VistaView is a library of Vistas, report templates and rules.
A service provider can customize the integration between IP Service Activator and InfoVista by modifying the integration files in IP Service Activator's InfoVista Integration module. For details, refer to the IP Service Activator Network and SLA Monitoring Guide.
Integration highlights include:
IP Service Activator's TopologyExporter utility creates the Toplogy.txt file that identifies which data to collect for the InfoVista reports. Other IP Service Activator files provide validation and structure to the integration.
The Topology.txt file identifies to the Vista Provisioner all devices in IP Service Activator that are assigned to either an InfoVista Server or a Plug-in for NetFlow collector. The Def.txt file provides the data dictionary that validates the sanity of the Topology.txt file. The report.pl file defines the folder structure to be used by InfoVista for storing reports, and ACL access to reports.
InfoVista imports Toplogy.txt and other integration files from IP Service Activator, polls the devices, and generates the necessary reports.
The object model between IP Service Activator and InfoVista is synchronized when the Topology.txt file is imported by the Vista Provisioner. The InfoVista Server polls the assigned devices for SAA and MIB-based statistics using SNMP. For NetFlow statistics, the InfoVista Server polls the Vista Plug-in for NetFlow, which collects the NetFlow statistics directly from the devices. Group reports are generated by Vista Provisioner based on configuration information provided by the Def.txt file.
Web services is an optional component of the IP Service Activator installation that allows IP Service Activator to integrate with Order and Service Management (OSM).
This solution provides a reference implementation for IP Service Activator and OSM integration. Using the reference implementation, you can develop, integrate, and deploy Order and Service Management and IP Service Activator for flow-through activation of IP-related services.
The reference implementation includes the following:
An Eclipse project that contains OSM workflows
A Solution Uptake Guide
Sample data to implement out-of-the-box workflows
Set-up scripts that perform additional system configuration required for the reference implementation to run
For information about using best practices for reference implementations, see OSS Integrated Service Provisioning Reference Implementation for Layer 3 MPLS VPN Service with Metro Ethernet Access (Doc ID 1479821.1) knowledge article on Oracle Support.
IP Service Activator's integration with Micromuse Netcool offers an integrated solution for the sending and translation of network faults, clears and events. The network manager benefits from a single point where all events are reported, prioritized and resolved. This significantly improves operational effectiveness.
Integration is by the Event Handler, which collects, filters and delivers details of faults and other events.
Monitored events are defined by subscriptions – collectors describe the scope of the subscription, while filters precisely define the type of events to be monitored. Event types include faults and attribute changes.
Multiple subscriptions can be defined, with each subscription sending events to a single Netcool/OMNIbus host machine or to distributed host machines.
Example subscriptions might monitor:
All events and faults occurring in the network
A specific customer's VPNs for provisioning faults and clears
Events occurring on all PE devices within the network
Communication faults
The Event Handler's behavior is modified by a rules file, which defines how IP Service Activator faults and events are converted into Netcool/OMNIbus events.
The converted events are forwarded as Netcool events through the NIM to the Netcool Object Server and can be viewed in an event list using the Netcool/OMNIbus Conductor, as shown in Figure 7-5.
Figure 7-5 The Netcool/OMNIbus Event List
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
