CA2212251A1 - Resolve (tm) gateway third party management platforms integration - Google Patents

Abstract

The Resolve TM suite of service management applications is designed to help service providers deliver advanced services to their customers. Resolve works with a network management platform to provide service and customer oriented views of network information

Description

CA 022l22~l lss7-07-3l CrossKeys Systems Co- ~ D~ I July 1997 Draft Version 02 P~e 2 of 2 RESOLVE TM GATEWAY
THIRD PARTY MANAGEMENT PLATFORMS INTEGRATION

This document summarizes CrossKeys' position regarding the integration of Resolve with third party management platforms, such as TeMIP, OpenView, and ISM.
The possible forms of integration are defined, and a range of solutions are presented.

1.1 Purpose The Resolve suite of service management applications is designed to help service providers deliver advanced services to their customers. Resolve works with a network management platform to provide service and customer oriented views of network information.
The first release of Resolve supports networks managed by Newbridge's 46020 MainStreet network manager. Subsequent releases will provide support for other third party management platforms. This paper describes CrossKeys' approach to adding this support.
1.2 Scope This document is concerned with integrating Resolve with third party management platforms. This integration occurs in two forms;
~ Exch~nEing Network Level Information Resolve collects availability and performance information from the third party management platform and uses it to perform a variety of service management tasks.
~ Exch~nging Service Level Information Resolve exports a service object model to the third party management platform and may generate alarms and/or trouble ticket information relating to this object model.
This document is concerned with describing the means by which these two forms of integration can be achieved.

CA 022122sl 1997-07-31 CrossKeys Systems Co. ~o~ -n July 1997 Draft Version 02 Pa~e 3 of 3 2. APPROACH
The capabilities and strengths of the third party management platforms vary. Therange of applications and customers also vary from platform to platform. Simply aiming at a lowest common denominator approach to integration will lose many of the advantages of a particular platform. The approach presented here is designed to accommodate this variation, without sacrificing platform specific features.
The proposed approach is to run a Resolve Gateway application on the management platform that will exchange information between Resolve and the platform.
The gateway will interact with the platform using the locally specified application pro~ interfaces. From a user perspective, the gateway will appear, to the extent that it is visible at all, as another platform component, con~i~tçnt in design and interf~e with all other components.
The inte~e to Resolve is specified by an object model. A base object model is presented, and a range of possible extensions to that model are then outlined.
Thus the interface can vary in complexity and sophistication depending on user/application need.
Moreover, a gateway product that requires rebuilding every time it is deployed is not a product at all, but a piece of custom development. To avoid such a scenario, and recognizing the wide variety of application domains, the design provides forsystem integrators to customize the behavior of the gateway, using a flexible scripting language, to enable local modifications to be made quickly and easily.
Section 3 describes the object model and how Resolve can receive network information from an arbitrary m~n~gement platform. Various forms of network information and levels of integration are discussed.
Section 4 how Resolve can make service level information available to an ~bi~ management platform. The types of service level information, and the means by which it can be presented, are discussed.
For the benefit of readers llnf~nnili~r with Resolve, a brief overview is given in Appendix A.

CA 022122sl 1997-07-31 CrossKeys Systems Corporation July 1997 Draft Version 02 Pa~e 4 of 4 3. EXCHANGING NETWORK INFORMATION
The intent of this scenario is to exploit the target management platform as a network or element management system to allow Resolve to "see" eligible service components and to receive events relating to these objects. More specifically there are two main objectives;
1. To present Resolve with a list of c~ncli(l~te service components, 2. To relay to Resolve events, and possibly performance statistics, regarding these candidate service components.
To receive information from a third party management platform requires that agreement be reached upon an interface. In keeping with the TMN approach such an interface is specified as an object model. At a high level there are two possible approaches;
1. Design a standard object model and require that third party developers must conform, 2. Design a generic object model and provide a means to integrate third party software.
Option 1 is unlikely to be viable. It is not envisaged that third party developers would wish to follow a CrossKeys-m~nd~ted object model in future development, or re-work existing applications. Option 1 will not be discussed further here.
Option 2 is more flexible and is preferred. The rest of this section discusses this option in more detail. In particular it describes increasingly more complicated,and sophisticated, implementation approaches. It is the intent that the level ofsophistication is driven by application need and that the level of sophistication may vary from installation to in~t~ tion and from platform to platform.
3.1 Universal Service Components A service component is part of a service, but it is provided by a particular ne~work capability. A service component is therefore the interface between service and network management levels. Thus the service component is chosen as the basis for the object model.
There are a number of objectives that this object model should attempt to meet;
~ The object model should capture the essential characteristics of the interface, while being sufficiently flexible that a variety of third party applications canbe integrated without significant effort.
~ Such integration work should not require re-compilation and could be performed by a Systems Integrator (SI), Platform Vendor or by CrossKeys.
~ The model should be applicable across a number of platforms. Ideally it would be specified using GDMO.

CA 022122~1 1997-07-31 CrossKeys Systems Co~ July 1997 Draft Version 02 Pa~e 5 of 5 Resolve already has the concept of a general purpose service component. It is called a Universal Service Component (USC). The interface object model should provide a means to relate a USC to a network component.
Figure lshows a service component object that will exist on the m~n~em~nt platform. It has two halves, an abstract half that is visible to Resolve and a physical half that references the object that denotes the physical network facility.
Such a service component is intçn~le~l to be applicable in a wide variety of cases.
All concrete service components are viewed as particular types of this more general service component, termed an Abstract Service Component.
The ASC object monitors the network object for changes in availability. The ASC
object is therefore acting as a form of proxy object. Changes are then reflected in the ASC (as a change in the operational state) and an event is forwarded to Resolve. Note that for every ASC object there would be exactly one network object.
To use a network object as a service component it would, at a minimllm, need to support some notion of operational availability. For objects that support such anotion in a standards compliant manner (i.e. they have an Operational State attribute modeled according to X.721) the implementation of the ASC is simple.

However, it is possible that some network objects may use some other name for operational state or identify changes in availability by some other means.
Therefore, there is a need to support a configurable mapping between the operational state of the ASC and the equivalent state in the network object. This is achieved by using a mapping language to express the relationship between the ASC and the network object.
An attempt to perform an action on the ASC is mapped into an action on the network object. This mapping is performed by embedding a flexible scripting language within the ASC. Actions on the ASC result in a script being executed.
Thus a request to receive event state changes will result in a script being executed that in turn gathers an event from the physical object and interprets it apprupliately.
For example, suppose a network object representing a multiplexor modeled operational state as an attribute called "available". Suppose further that the attribute took the values "yes" and "no", but no event was issued when the attribute was changed. It would be possible to associate with the request to receive operational state event changes from the ASC a script that polled the multiplexor object and changed the ASC's operational state attribute and issued an event change when appropliate. Thus Resolve can do availability based reporting on an object that a) does not have an operational state and b) does not issue state change events.

CA 022122~1 1997-07-31 CrossKeys Systems Co.~o ~ July 1997Draft Version 02 Pa~e 6 of 6 This mapping between object models is show in l~igure 2. An ~l,i~ network object on a management platform is mapped to an object in Resolve Service Model. The mapping is achieved via an ASC. The ASC de-couples Resolve from the management platform, ~vithout loss of functionality. This enables support for new management platforms to be added without requiring changes to Resolve which would necessitate a new release and necessary longer development times.
Note that as the ASC runs on the remote platform it must conform to the relevantplatform API. This implies that although the interface the ASC presents to Resolve is constant, the implementation of the ASC will be necessarily platform specific.
3.2 F,l~tend- ' Abstract Service Component In addition to the availability of network object, there may be additional, largely static, information that might be usefully passed to Resolve, for example the Available Bit Rate of an ATM VPC. The attributes of the ASC object can be extended to include this additional information.
There are three main options.
~ Fixed number of fixed-name attributes Add a fixed number of attributes called attribute_valuel, attribute_namel, attribute value2, ..., attribute_namen. The ASC would relate these general purpose variables to particular variables in the network object, and would use the attribute namei attribute to store a me~ningful presentation name to be used by Resolve. These attributes would be of type to accommodate a wide variety of options.
~ Variable number of fixed-name attributes Add an array of attribute/value pairs. A variation on that above, but permitting a variable number of attributes.
~ Variable number of variable-narne attributes This is the most flexible option p~. ",i~ g user-specified additions to the object model. Such additions could be performed by directly modifying the specification of the object (in GDMO, for example) or by using a platform specific tool that permits such operations. Note that this option requires that the ASC implementation and the Resolve interface be data-driven.
3.3 Abstract Service Components with Performance St~tiSt It is possible to generalize the notion of an ASC, co.~ g a number of a~bil attributes, to one capable of collecting statistical information from the NMS.
Statistical information is that information that is typically reported at a given interval (for example, every 15 mimltes). Such information is typically quite large and issuing attribute change events quickly becomes unrealistic and therefore a more considered approach is required.

CA 022122~1 1997-07-31 CrossKeys Systems CO.~Dr. -:In JUIY 1997 Draft Version 02 Pa~e 7 of 7 Performance information is traditionally presented in a flat file, usually consi~ting of ASCII data. More recently, the standards bodies have specified an approach using OSI-events and some vendors now support a native OSI interface to performance data.
3.3.1 Importing via Flat-File In many cases the statistical information can be obtained directly in a flat file and this is prefelled as it is simpler.
Performance information is presented in a native format and must be converted into the format m~int~ined by Resolve (as shown in Figure 3). The Resolve performance data attributes are based on the relevant standards (ATM Forum, Frame Relay Forum, etc), the same standards used by the equipment vendors.
Thus conversion is largely a matter of accommodating differences in presentation, rather than in content.
In some cases a vendor may omit a standard parameter, supply a useful but non-standard performance parameter, or calculate a standard parameter in a non-standard way. In this case the conversion mech~ni~m becomes more complex and a toolkit solution is required. A simple solution would provide support for mapping functions which would enable parameters to be calculated from other parameters. A more complex solution would permit the addition of user-defined performance statistics.
From the perspective of events and object models, the ASC provides a de-coupling of Resolve from the management platform. This de-coupling is also desirable for importing performance data from file and therefore the conversion is performed in two stages. The native format is first mapped to a canonical form which is then read by a Resolve statistics importer. The canonical form is an abstract performance data format then supports ~bi~ attributes on arbitrary objects.
Thus, there need only be on statistics importer and adding support for a new native format does not require changes to Resolve. The conversion to canonical form is typically a straightforward task and can be performed by an SI, platformvendor or by CrossKeys. This conversion can also be applied to binary files which are often used as a more compact format for performance data. For ASCII files a wide variety of parsing/translation tools can be used, for example yacc/lex or CrossKeys' own parsing toolkit, AMPERE.

CA 022122~1 1997-07-31 CrossKeys Systems Co- ~ c ' ~ - n July 1997 Draft Version 02 Paae 8 of 8 3.3.2 Importing via Standards-based Performance Events There may be cases where statistical information is available only via the network management system. One attractive approach would be to use Q.822, as is done in CrossKeys Traffic Management applications (AltusTM). Q.822 provides a generic framework for collecting performance information. Objects that have attributes that change over time, are called monitored objects. To collect information frommonitored objects at a certain reporting interval an object called a scanner is used (scanner objects are defined by X.738). A scanner object gathers many attribute values together and emits a Scan Report Notification that is, in essence, an optimized form of attribute value change event used when the number of attributes, and frequency of change, is high.
Using such an approach the ASC would be viewed as a specialization of a monitored object. Such specialization is the method of use suggested by Q.822.
The addition of user defined attributes would still be possible using the approach defined in section 3.2.
When information is available in the form of a Scan Report Notification it couldeither be sent directly to Resolve or converted into a flat file format before importing. The format of a Scan Report Notification is well-defined and therefore the need for a vendor-specific format conversion phase is removed.
Note that a Scan Report Notification is an event and therefore the Abstract Service Component model can be used again, as shown in Figure 4. The Resolve Statistics Collector receives Scan Report Notifications from an a~ network component, via the ASC. As the figure suggests, the fundamental mech~ni~m for relaying events remains the same.
Note that Scan Report Notification can be seen as a type of canonical form.
Performance data received from the ~bi~ network component can be in any form, and it is then mapped to canonical form (Scan Report Notification) and then relayed to a statistics collector.

3.4 Types of Universal Service Components The intent of an USC is that it be general putpose. Thus if a network object model supports a termination point object and a link object, then both would be represented in Resolve as an instance of an USC. Obtaining the operational stateof the tPrrnin~tion point object may be quite different from that of a link object.
Thus in defining the mapping it is necessary to know to what type of object the ASC is pointing. In essence, type information is required to support polymorphicbehavior of the ASC.
This type information is also of interest to Resolve. One of the value-add capabilities of Resolve is a suite of standard reports. Such reports are based on a detailed under~t~n~ling of the technology. If the service component is of type "ATM VPC" then a number of standard reports are available, for example.

CA 022122~1 1997-07-31 CrossKeys Systems Co~ ..lion July 1997 Draft Version 02 PaPe 9 of 9 With an ASC one cannot know a priori what technology it will be supporting and thus the possibility of value-added service disappears.
However, by defining some essential characteristics of, say, an SDH Add-Drop Mux (ADM) then it would be possible to pre-define some SDH ADM reports.
Such reports might require that information about X, Y, Z be available. If such information is available it would be desirable if there was some way to tell Resolve that the ASC was in fact being used as a proxy for an SDH ADM and that parameters X, Y and Z are available and that the standard reports were applicable.
One could envisage that as a number of third party applications were integrated then the possibility of developing a suite of standard reports for each technology type would increase.
Note however that the concept of type would need to be quite sophisticated. If aSDH ADM supports pararneters X, Y and Z then a suite of standard reports is possible. If a SDH ADM supports parameters U,V,W,X,Y and Z then a super-set of reports could be supported. If a SDH ADM supports parameters U, V, X and Z, but not Y, then some smaller combination of reports is possible.
Rather than develop a complex type system, the object ID (OID)I of the network component object is used as an indication of type. This OID can then be used to control both the polymorphic aspects of the mapping and as a way to identify to Resolve the capabilities of the network object and hence the extent to which pre-existing reports would be applicable.
3.5 Synchronization The ASC objects act as proxy objects for the real network objects and as such should not be directly visible to the end user. To make this possible, it would be desirable if each time a physical service component (PSC) object was created, anASC would be automatically created. Similarly for object deletion.
It is simple for a SI to write scripts that could auto-discover PSC objects and create the equivalent ASC objects. Such a script would have to be able to distinguish between different types of PSC objects so that applopl;ate mapping could be employed.
3.6 Summary The use of an Abstract Service Component enables information to be gathered from an albill~y network component object and incorporated within Resolve for the purposes of Service Management. An extended Abstract Service Component allows more complex information to be exchanged, including performance data.

An Object ID is an OSI-specified means of uniquely identifying an object class. All OSI object classes have a unique Object ID making it an excellent choice for distinguishing between classes of objects without inventing a complex type scheme.

CA 022122~1 1997-07-31 CrossKeys Systems Corporation July 1997 Draft Version 02 Pa~e 10 of 10 By mapping the network object model to the Resolve object model in two stages (i.e. first to an Abstract Service Component) the integration effort can proceed a greater rate. No changes to Resolve are necessary and, by pe~ g the ASC to be modified without recompilation, the integrator can quickly bring Resolve's service management capabilities to a new type of network object.
The same event mechanism can be used to relay performance data in the form Scan Report Notifications. Such a solution is both standards based and compatible with CrossKeys Altus products.
In situations where performance data is available in the form of a flat-file, analternative approach is adopted. Performance data is first mapped to a canonicalform. The Resolve statistics collector then reads this canonical form, instead of the native format. This permits support for new native formats to be added without requiring changes to Resolve.
The two solutions to importing performance data can be seen to be logically equivalent, differing only in the exact definition of the canonical form (ASCII text in a flat file vs Scan Report Notification). This equivalence, and the previously noted relationship to the model shown in Figure 2, means that a single, uniform architecture can be employed to solve a range of integr~tion issues.
All these mech~ni~m~ (which are essentially variations on a common solution) address a common objective; to support the integration of new information sources without requiring continual change to Resolve. By avoiding changes to Resolve the integration with other platforms is de-coupled from the Resolve release cycle, allowing faster integration. By making this integration configurable and open, it is possible for it to be performed by third parties.

CA 022122~1 1997-07-31 CrossKeys Systems Corporation July 1997 Draft Version 02 Pa~e 11 of 11 4. EXCHANGING SERVICE INFORMATION
The intent here is to make some of Resolve's service capabilities available on athird party platforrn. This is envisaged to take two forrns;
~ making Resolve's customer, service and service component objects visible on a third party platform.
~ export Resolve-detected SLA violations into the third party platform's alarms and trouble tickets facilities.
~ receive trouble tickets as a means of supporting customer-perceived outages.
The rest of this section discusses how these three objectives could be met.
4.1 Exporting the Resolve Object Model The initial implementation will export the Resolve Object Model in the form of aflat file, enabling third party platforms to incorporate this information in a variety of applications.
A more sophisticated implementation can be achieved by defining an object model on the remote platform (using GDMO, for example) and implementing a proxy-agent. Attempts to show the attributes of a service entity, for example, would result in a request being sent to Resolve to get the real attributes and then ~ll."~ g them to the platforrn.
If the proxy-agent did not cache any of the attribute values then there is no need to synchronize with Resolve with respect to Resolve-initiated attribute value changes. It will, however, be necessary to synchronize with respect to object creation/deletion. This could be done once on start-up and subsequently tracked via Resolve-generated object creation/deletion events.
4.2 Exporting SLA Violations When a SLA is violated a Quality of Service alarm is raised. Such an alarm is raised against either the service or the service component. The format of the alarrn is well known and raising it on a third party platform is comp~r~tively straighlrol ~v~d.
Note that this approach would require that the service and service component objects be known to the third party platform and therefore presupposes the existence of a solution similar to that described in section 4.1.
It would add significant value to the SLA violation alarm if it were possible toindicate the network component that had caused the violation. In cases where it is possible to identify the component, one could raise the alarm against the network component directly, or continue to raise the alarm against the service componentbut somehow include in the alarm the identity of the network component.
In both cases it is necessary to identify the network component by name. This information is stored in the ASC, and is therefore readily accessible.

CA 022122~1 1997-07-31 CrossKeys Systems C~r~ July 1997Draft Version 02 Pa~e 12 of 12 To include such information in an OSI alarm is straightforward. It could be included in the Additional Information or Additional Text fields. The latter would be simpler, but less flexible.
To raise the alarm against the network component itself is potentially more complicated. Such an object will have a GDMO (or similar) specification that describes what events it is potentially capable of generating. If this description did not include a QoS alarm, it would be necessary to augment the specification.
4.3 Exporting Trouble Tickets Exporting Trouble Tickets is similar to exporting alarms in that it requires that the objects referenced in the TT (e.g. service) be known to the remote platform. TTscan be created by executing scripts directly on the platform. These scripts can be user-defined, enabling Resolve to support a variety of creation schemes.
However, it is envisaged that the prime task of Resolve is to raise alarms indicating actual or pending SLA violations. Whether these violations should result in a TT, and how the TT is populated, is usually a local decision influenced by local policy as much by technology, and therefore Resolve would not typicallycreate TTs directly.
4.4 Importing Trouble Tickets The intent here is to allow an extern~l trouble ticketing systems to report changes in the availability of a service. When a customer reports a service outage he/she is unlikely to identify the failed service component; rather the customer would report that the service as a whole was unavailable. This could result in a trouble ticket indicating that the service is (perceived to be) unavailable. When Resolve receives a trouble ticket, it will mark the corresponding service or service component toindicate a trouble ticket is active. The outages are calculated when the troubletickets are closed.
Importing Trouble Ticket information into Resolve is performed by means of a CORBA-based importer. Thus from a remote platform perspective there are three tasks to perform.
~ Gather information about the creation/modification/deletion of Trouble Tickets, ~ Filter out TTs not relevant to Resolve, ~ Export TTs in a format understood by Resolve.
At a minimum the person creating the trouble ticket needs to know the names of all the services and service components (and by implication the names of the customers). Such information is provided in the exported Resolve object model (Section 4.1).

CA 022122~1 1997-07-31 CrossKeys Systems Co.~c '-Dn July 1997 Draft Version 02 Pa~e 13 of 13 An application would need to run on the remote platform and gather object creation/delete and attribute value change events p~J ~ining to trouble ticket objects. It is relatively strai~hlrol ~v~d to filter on the managedObjectInstance attribute of the Trouble Ticket and then use the capabilities of the Resolve Trouble Ticket importer to transmit the information to Resolve.
4.5 Summary Exporting the object model as a flat-file, while simple, will always be a desirable feature as it permits the data to be used in ~bil~dl.y ways, from sophisticated network management applications to simply incorporating the data in a spreadsheet.
A more sophisticated level of interface is provided by implementing a proxy agent on the remote management platform. This will permit the Resolve objects to be used in the same way as any other object on the management platform, including being displayed on graphical maps or referenced in trouble tickets. Users of themanagement platform would be unaware that the objects were in fact managed by Resolve.
Importing trouble ticket information back into Resolve is performed via a pre-defined CORBA interface, permitting simple gateway applications to be developed on the management platform.
Figure 5 shows the interfaces relating to the exchange of service information with a third party management platform.

CA 022122~1 1997-07-31 CrossKeys Systems Co.~c ~ July 1997Draft Version 02 Pa~e 14 of 14 5. RESOLVE-NMS TRANSPORT ISSUES
This section discusses the issue of how information can be transmitted between Resolve and another platform.
There are three main possibilities;
. Q3 As the int~rfflce between Resolve and the other platform is specified as an object model, a natural choice would be to use Q3. However, not all platforms provide the same level of support and therefore such a solution is less attractive as a multi-platform solution was desired.
~ CORBA
A CORBA interface is more widely supported by the various platforms and could be used to provide the interface between Resolve and the third party platform ~ Proprietary It would be possible to design a proprietary interconnection mech~ni~m However, this option would only begin to be attractive if both of the options above were not viable.
CORBA offers the greatest chance of providing a uniform transport mech~ni~m across a range of platforms and is therefore discussed in greater depth.
5.1 CORBA
The CORBA interface can itself be broken down into the three possibilities shownin Figure 6.
Option 1 takes the existing Resolve API and makes it available in the remote management platform. This would involve recasting the existing API using IDL, but would otherwise be relatively straightforward. An adapter would run on the remote management platform that would convert to/from the Resolve API to the local interfaces. This would permit more complex applications to be developed onthe remote platform. The internal Resolve API offers a low-level interface whichwill increase the complexity of remote application development.
Option 2 takes the opposite approach to option 1 and makes some of the platform's API visible to Resolve. An adapter would run on Resolve that convertsbetween the platform API and the Resolve API. The major limitation of this approach is that it is platform dependent and Resolve would have to separately m~int~in interfaces to each type of platform.
Option 3 requires the specification of an intermediate representation. A Resolverequest is converted into intermediate form, relaying across the interface and then converted into the platform specific form. Similarly for platform-initiated communication. Adapters would be required on both Resolve and management platform.

CA 022122~1 1997-07-31 CrossKeys Systems Cor~,o. ' -~1 July 1997 Draft Version 02 Pa~!e lS of 15 For all of these possible interfaces, where it is required to define the structure of an object or an event it is desirable that GDMO be used, which in turn is compiled into IDL. Such an interface would provide a higher level interface to Resolve that can be exten-led to support a wider range of applications to execute on the third party management platform.
5.2 Summary CORBA will be used as the transport mechanism between Resolve and a third party management platform. A common intermediate representation will be used to exchange information (option 3) as this provides a high level interface that will be consistent across all management platforms. Adding support for a new m~n~gement platform requires only that the platform specific component be re-written, enabling a new management platform to be added without a change to Resolve that would require a new release and unnecessarily delay integration.
Moreover, this interface can grow in scope making more Resolve functionality available, permilting more sophisticated applications to be developed on the third party management platform.

CA 022122~1 1997-07-31 CrossKeys Systems Co. ~c _ -~l July 1997 Draft Version 02 Pa~e 16 of 16 Appendix A - RESOLVE ARCHITECTURE OVERVIEW
CrossKeys' Resolve addresses three primary areas of the Service Management level of the TMN model: Performance Management, Configuration Management, and Fault Management. The applications in these areas are designed to be integrated and work together in configurable combinations through the use of common core components.
Figure A-1 shows the Resolve Core Object Model. A customer has one or more services and one or more contract with the service provider. A contract includes a definition of the specified quality of service (as captured in a Service Level Agreement). A service profile defines a certain quality of service for a range of services. For example, a "Gold" service profile may specify 99.995% availabilitywhereas a "Silver" service profile may specify 99.9% availability.
Each SeNice is supported by one of more Service Components. A service component could be a physical piece of equipment such as a termin~ti~n point a logical entity such as an end-to-end path or an albi~ external system such as a customer support desk. All service components support the notion of availability, and most support the production of performance measures.
This object model is m:~int~ined in the Service Management Information Base (SMIB). The SMIB is an operational data store. In addition to customer, contractand service information it contains current, volatile data (such as path states, and events), which may be used in real-time reports.
Resolve also m~int~in~ two other major information bases, the Historical Information Base (HIB) and the Summarized Information Base (SIB).
The HIB contains detailed, time-varying data (such as path statistics, and old state and event data). This data is held in the HIB for a short period of time (typically 60 days). This data can be used to produce detailed reports.
The SIB contains summarized information, based on the data in the HIB. Data in the SIB may be up to 180 days old. Most relevant reports will be run against theSIB, as its information is the most meaningful. The SIB information may be used to identify trends and p~ttçrns in usage and availability.
The logical architectllre shown in figure A-2 illustrates how these various components fit together. Availability and performance data is capture from a number of information sources (figure A-2 shows some examples) and is used to update the SMIB and the HIB. Periodically the HIB is sllrnm~ri7~d to produce one or more SIBs. Users can then define and produce reports, as well as configure existing and new services.

CA 022122~1 1997-07-31 CrossKeys Systems Co- ~,u- ~ ~~ July 1997 Draft Version 02 Pa~e 17 of 17 ~ADM Add-Drop Multiplexor ~API Application Progr~mming Interface ~ASC Universal Service Component ~ATM Asynchronous Transfer Mode ~CORBA Common Object Request Broker Architecture ~GDMO Guidelines for the Definition of Managed Objects ~IDL Interface Definition Language ~OID Object Identifier ~SDH Synchronous Digital Hierarchy ~SI Systems Integrator ~SLA Service Level Agreement ~TMN Telecommunication Management Network ~TT Trouble Ticket ~USC Universal Service Component

Claims (2)

THE EMBODIMENTS OF THE INVENTION IN WHICH AN EXCLUSIVE
PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:

1. A system for integrating service management with third party management platforms comprising:
means for collecting availability and performance information from said third party management platform; and means for exporting a service object model to said third party management platform.

2 A method of integrating service management with third party management platforms comprising:
collecting availability and performance information from said third party management platform;
utilizing said information to perform service management tasks;
exporting a service object model to said third party management platform;
and generating information relating to said object model, exporting a service object model to said third party management platform.