DIGITAL Software Product Description ___________________________________________________________________ PRODUCT NAME: TeMIP Graphical ASCII Toolkit V2.0 for DIGITAL UNIX SPD 64.82.03 DESCRIPTION TeMIP for DIGITAL UNIX[R] is a family of software products for the man- agement of telecommunications and corporate networks, including fixed wire and mobile/cellular voice and data multi-vendor, multi-technology networks. TeMIP V3.2 provides comprehensive off-the-shelf fault and trouble management functions such as Alarm Handling, Event Logging and Trouble Ticketing for telecommunications network management. TeMIP supports the International Standards Organization (ISO) manage- ment standards ISO 10164-x and 10165-x, and the NMF ensembles. TeMIP and its features are applicable in the context of the International Telephone Union-Telecommunication Standards (ITU-T) X.73x and Telecom- munication Management Network (TMN) M.3010, M3100 Recommendations. It gives network operators a global view of their networks, and enables them to activate management functions and operations from single or multiple workstations. TeMIP is built on top of the TeMIP Framework, and fully benefits from the object oriented and truly distributed software architecture. The TeMIP for DIGITAL UNIX Graphical ASCII Toolkit V2.0 (GAT) is part of this TeMIP program and provides the TeMIP platform with access to telecommunication equipment such as switches, multiplexers or repeaters which, for historical reasons, do not support a standardized manage- ment interface, but report management information and receive control information via an interface designed for human interaction, using a character (ASCII) terminal or a printer. As such, the TeMIP Graphi- cal ASCII Toolkit extends TeMIP functionality to all network elements September 1998 AE-R5C0D-TE (NEs) that support ASCII and TL1 protocols. It also benefits from the Event Filtering and Correlation capabilities of TeMIP. Refer to the TeMIP Fault and Trouble Management Software Product Description (SPD 45.24.xx) and the TeMIP Framework SPD (54.17.xx) for more information about Distribution and Event Filtering and Correlation related fea- tures. The TeMIP Graphical ASCII Toolkit is a collection of components that enable rapid development and easy maintenance of a TeMIP GAT Access Module for a given type of equipment. The main features are: o GUI-driven codeless development toolkit with rule-based parsing o Two-way stream management o Multi-protocol support. TeMIP GAT is a windows based configuration application that facili- tates the development of a generic Access Module framework that can be adapted to the specifics of the management interfaces of a broad range of ASCII speaking network elements. The TeMIP GAT graphical user interface allows fast and easy develop- ment of Access Modules (AM) without coding. The result is a packaged AM (customized AM) that can be easily and seamlessly integrated into the TeMIP platform and as such benefits from TeMIP standard features (for example, security, distribution, low-level event filtering and correlation). It is also possible to extend and customize the toolkit. Access Modules developed using TeMIP GAT are able to: o Manage the connection with the Network Equipment o Act as an agent for ASCII devices o Support the terminal emulation and self-management capabilities of TeMIP. 2 A TeMIP GAT Access Module provides two distinct channels of communi- cation between TeMIP and the Network Element: o The Asynchronous Message Handler (AMH) is the asynchronous chan- nel for unsolicited messages o The Integrated Command Generator (ICG) is the synchronous bi-directional channel for NE control. Features Depending on the scope of the customization, Access Modules developed using TeMIP GAT will be able to: 1. Manage the connection with the NE: o Communicate with NEs using three widely used standard protocols (TCP/IP, X25, RS232) o Raise communication alarms to the TeMIP platform if the commu- nication facility fails o Detect and monitor "heartbeat" signals from an NE o Generate "keep alive" signals to maintain connections with NEs that do not support "heartbeat". o Automatically re-establish the connection with the NE when it is broken. 2. Act as an agent for ASCII devices: o Collect unsolicited ASCII messages from the NEs. Received mes- sages are parsed and used to trigger internal actions (for ex- ample, forward OSI alarms, update attribute values) o Issue "polling" messages to retrieve alarm information from NEs that cannot emit unsolicited asynchronous messages o Correlate "clear" alarm messages with the original forwarded alarms o Issue "re-synchronization" messages to re-align a TeMIP view of the element with its actual state (for NEs that support it) 3 o Log messages in a log file for optional use by off-line anal- ysis tools o Maintain attribute values in a local database. The values can be modified by operations on the entities (for example, the Set directive) or autonomously by the Access Module itself, based on messages received from the NE o Synthesize state attributes for the NEs, based on received alarms (for example, maintain an Operational State attribute based on the messages received from the NE). 3. Support terminal emulation. "Passthrough" allows an operator to open a direct session on the NE, which emulates a dumb terminal connec- tion. 4. Support the self-management capabilities of TeMIP. The AM itself is managed by TeMIP through a self-management interface, which also allows the AM to report abnormal conditions. Access Module Components After customization, a specific TeMIP GAT Access Module (Customized Access Module) will consist of the following components: o Management Model (TeMIP Interface) - the Access Module interface to the TeMIP platform. It is based on the information model of the NE being managed and makes the management information available to TeMIP applications. The toolkit includes a Q.822/Q.823 information model, or Traffic Management model, so that Access Modules produced with GAT can work with a Traffic Management application. o Communications Server (NE Interface) - the physical interface to the Network Element. All communication with the managed object passes through this interface. There is a choice of three Communications Servers, one for each of the supported protocols (TCP/IP, RS232, X25). The CS is itself a Management Module dedicated to accessing Network Equipment. The Communications Server Access Modules sup- plied with the product are all based on the same framework. This 4 framework can be customized to provide Communications Servers for additional protocols. An API is made public for this purpose. o Asynchronous Message Handler (AMH) - composed of the Asynchronous Message Parser and the Action Executor: - The Asynchronous Message Parser receives raw ASCII messages from the Communications Server (NE Interface) and breaks them down using rule based analysis. The result is an Item Set which is a set of significant recognizable codes from the message (for example, alarm severity = Critical, State = Starting Up) - The Action Executor performs pre-defined actions. The actions are selected according to the Item Set received from the parser. Typical operations are: forward an OSI alarm to the TeMIP plat- form or update an attribute value in the MIR. o Integrated Command Generator (ICG) - handles command and response dialogues with the NE. It is composed of the Dialog Manager, the Command Builder, and the Response Parser: - The Dialog Manager handles command and response dialogs with the NE. A TeMIP directive is received by the Access Module in an en- coded format. It processes the directive and passes it to the Command Builder. It also processes the resulting responses that are returned from the NE via the Response Parser. A sequence of related commands and responses is called a Dialog. - The Command Builder constructs the individual ASCII commands (in the language of the NE - MML commands) and passes them to the communication interface. - The Response Parser is a rule based parser (similar to the Asyn- chronous Message Parser) that breaks down the responses to com- mands issued to the NE and feeds them back into the Dialog Man- ager. o Local Management Information Repository (MIR) - a local Access Mod- ule data repository that stores NE management data (for example, attribute values). 5 The run-time environment for a TeMIP GAT Access Module is made up of a combination of Customized AMs and Communications Server AMs. As for all TeMIP Management Modules, they can be distributed over several TeMIP systems depending on the degree of distribution needed. Communications Server The Communications Server (CS) is a TeMIP management module that man- ages communication resources (represented by the Communication Chan- nel TeMIP global class). It offers communication services for TeMIP client applications which need to communicate using TCP, X25, or RS232 protocols. A TeMIP GAT customized AM uses the CS services. The Communications Server has the following characteristics: o It can be installed on a different system from its clients (cus- tomized AMs, Passthrough Applications, and so on) o Multiple CSs can be installed in a given environment (system) o The same CS AM is able to handle connections from more than one cus- tomized AM to any number of NEs that all use the same protocol o Each CS is specialized for a single protocol o The CS monitors the state of its Communication Channel (CC) o When activated for an NE port, raw message logging is performed by the CS for this port o When communicating with an NE or a mediator, one (or more) ports might be used. Usually the NE requires one CC (physical connection, X25+ virtual circuit or TCP socket) for asynchronous event report- ing and a different CC for commands/responses (synchronous messages). In some cases only one channel may be used for both events and com- mands/responses o Event buffering capabilities and collection management are offered at the CS level to cope with differences between the event produc- ers (NEs) rate and event consumers (management application) rate 6 o The CS is responsible for compacting raw data received from an NE into bounded messages, whenever possible, before processing it fur- ther (that is, before logging, buffering or transmitting to a con- sumer). To this effect, it has to identify: - Either Start message and End message patterns in the data re- ceived - Or only Start message patterns when the end of one message is recognized by the next coming message. o The CS can easily be managed and configured via TeMIP standard pro- cedures (that is, activation of directives on appropriate objects). Access Module Customization The syntax and semantics of the messages, commands, and responses that are exchanged between the NE and the management terminal, are called the MML (Man Machine Language) specification. MML messages are spe- cific to each type of equipment and are an equipment vendor's prop- erty. The connection between network elements and management termi- nals is either a direct line with an RS232 interface or a connection through X25+ or TCP/IP networks. The customization process includes the following steps: 1. Analyze the specific MML of the equipment to be managed 2. Define the management model for the specific equipment (that is, commands supported by the AM, messages to be mapped on to TeMIP alarms, events, and notifications) 3. Produce a specific parser and mapping table 4. Build and test the customized ASCII Access Module (run-time) ei- ther locally or by generating an Access Module kit for installa- tion on another TeMIP system 5. Finalize specific end user documentation, describing how the AM con- nects to the NE. 7 The entire customization (development of a GAT Access Module) can be done using the TeMIP GAT graphical user interface. Each of the AM com- ponents has its own customization window, which is accessed from the Main Customization Window. When all the components have been config- ured and tested, the run-time AM is generated. It is possible to im- port and re-use previous customization sources. Main Customization Window This window is the starting point for the development of a GAT Access Module. It is a graphical representation of the AM components (Com- ponent Frame). Simply clicking on a component, the user invokes the component specific editor window. From the Main Customization Window, all other options for generating the AM are available from the Menu bar (that is, Compile, Test, Generate, ...). General characteristics (Name, Version, description, ...) of the current customization are dis- played in the Detail Frame. All messages reporting the progress of the current activity (for example, edition or compilation) are displayed in the Output Frame using color-coded format. Detailed error reports are routed to a log file. All Component windows consist of a toolbar, a main editor frame, com- posed of multiple columns, and a bottom status bar. A set of optional keyboard accelerators are also available. For a detailed description of window behavior, refer to the TeMIP Graphical ASCII Toolkit Cus- tomization Manual. Management Model TeMIP architecture is based on the notion of a dynamic, extensible net- work model. In TeMIP, every manageable entity in the network (that is, NE) can be described in terms of its own unique management model de- fined in terms of: o Classes representing the entity (Class Hierarchy) o Attributes used to store and reference management information rel- ative to the entity (Attribute Partitions) 8 o Operations representing management actions (Directives) o Notifications describing unsolicited information generated by the entity (Event Partition). The Management Model Editor window allows for the development of man- agement models for entities managed via a GAT Access Module. It con- sists of up to five columns: Class Hierarchy Column - (that is, the naming tree) displays the Class Hierarchy that consists of one or more Global Classes and a framework of subordinates classes Partitions Column - displays the Attribute Partitions, the Event Par- titions, and the Directives for the selected class Detail Columns - provide the details of the Partitions or Directives selected in the Partition column. Command Builder The command builder is part of the Synchronous Channel, which is the bi-directional channel used for NE control. It is the AM component that builds individual commands in the language of the NE. The Command Builder Editor window allows for the building of individ- ual commands in the language of the NE (typically, the command def- initions are extracted from the equipment documentation). It consists of four sections: Command Column - contains a simple list of all the NE commands that are to be supported. The remaining sections of the window display the details of the selected command. 9 Command Component Column - each command consists of an ordered list of components. The component fields are "syntax guided", which sim- plifies the development of components and provides continuous guid- ance and verification of input. The actual command sent on-line con- sists of a concatenation of the command components, where the vari- ables (parameters) are replaced by values at run-time. Input Parameter List - a scroll list of all the possible input param- eters for the selected command. Output Parameter list - a scroll list of all the expected output pa- rameters for the selected command. The output parameters entered here are visible as Items in a pick-list when developing Statements in the Response Parser. Dialog Manager The Dialog Manager is part of the Synchronous Channel. It is the AM component that handles the command/response dialogs between TeMIP and the NE. The Dialog Manager Editor window is used to define the bindings be- tween the eligible directives and the NE commands, which are maintained by the Command Builder. All the new Directives, defined in the Man- agement Model, and the commands defined in the Command Builder, to- gether with their input and output parameters are visible in the Di- alog Manager editor. It consists of five main sections: Class Hierarchy Column - displays the information model Class Hier- archy. Directive Column - a list of all the Directives that are eligible for binding with NE commands. Command Column - a list of the NE commands that have been mapped onto the Directive that is currently selected in the Directive Column. 10 Input Parameter Binding List - a scroll list of all the Input Param- eters for the Command selected in the Command Column. This section is used to bind the Command Input Parameters to the Management Model at- tributes or Directive Request arguments. Output Parameters Binding List - a scroll list of all the expected Out- put Parameters for the command selected in the Command Column. Message Parser The Asynchronous Message Parser and the Response Parser have the same editor window and have the same customization possibilities. The two parsers can be combined, that is, the same parser definition can be used for both components. Message parsing is rule based. Messages from the NE, stored in the message Items, are processed according to a hi- erarchy of rules. For a detailed description of message parsing con- cepts, refer to the TeMIP Graphical ASCII Toolkit Customization Man- ual. The Asynchronous Message Parser handles asynchronous messages, typ- ically alarms and status messages, from the NE. It processes incom- ing messages and determines which Actions are to be executed. The Ac- tion List is maintained by the Action Executor component. The Response Parser handles synchronous messages. These are messages that are generated in response to commands from the Command Builder. The Response Parser editor shares information with the Command Builder so that command output parameters are visible as Items in the Response Parser. The Parser Editor window consists of four main sections: Rule Hierarchy Column - contains a graphical representation of the rule relationships and determines the order in which the rules are applied. Rule Expression Column - there may be one or more Boolean expressions that test the message. The rule only fires if all the expressions are satisfied and then all the related Statements are executed. 11 Statement List Column - statements in the Statement List are executed in turn from top to bottom if the rule fires. Each statement consists of a Guard and an Operation. Next Rule List - is a list of dependent rules that are attached to the current rule. The rule hierarchy is constructed by adding rules to this list. Action Executor The Action Executor is part of the AM Asynchronous Channel, which han- dles unsolicited messages from the Network Element. The Action Execu- tor editor is used to develop Actions which consist of a number of State- ments. The Asynchronous Message Parser processes incoming messages and determines which of the pre-defined Actions are to be executed. The Action Executor Editor window consists of three main sections: Class Hierarchy Column - contains the information model Class Hier- archy Action Column - displays a list of all the actions in the selected Class or Default Action List that is selected in the previous column Statement List Column - statements in this list are executed in turn from top to bottom when the Action is executed. Passthrough When an alarm is reported by a network element, it is critical that an operator has access to the NE. The Passthrough component provides operators with access from their local workstations to the management terminal interface of the remote NE or the Operation and Maintenance Center. The Passthrough feature allows an operator to open a direct session on the NE which emulates a dumb terminal connection to the equip- ment. 12 Passthrough is a TeMIP launched application that is invoked from the TeMIP Iconic Map. A Passthrough session interacts with an NE via a Com- munications Server. Samples To help new users to build their first TeMIP GAT Access Module, two customized AM samples are provided: o LAB_AM - a simple but realistic and complete customization exam- ple o TL1_AM - this customization example is expected to be used as a start- ing point to speed up the development of real AMs for interfacing TL1 based equipment. It provides a customized AM example for a list of messages corresponding to a fictitious NE that supports a TL1 Management Interface. Note: These sample AMs are not products and cannot be used in a pro- duction environment. Openness Extension Mechanism The Extension Mechanism allows the addition of new functions to the GUI. It also allows additional code to be included in the generated Customized AM. This is done either through initialization files con- taining information to allow the extension to be included in the rel- evant parts of the toolkit and/or run-time AM, or by using a number of hooks defined in the toolkit code and in the generated AM code. Custom Object Model Implementation It is possible to adapt standard, off-the-shelf, object model defi- nition and implementation to project specific requirements. 13 Documentation For additional information, refer to the appropriate documentation: o TeMIP Graphical ASCII Toolkit Overview o TeMIP for DIGITAL UNIX Graphical ASCII Toolkit Installation Guide o TeMIP Graphical ASCII Toolkit Customization Manual o TeMIP Graphical ASCII Toolkit Configuration and Troubleshooting Guide o TeMIP Graphical ASCII Toolkit, Advanced Customization Development Guide o TeMIP Graphical ASCII Toolkit, Advanced Customization Reference Guide HARDWARE REQUIREMENTS AlphaServer 8200 AlphaServer 8400 DEC/4600, DEC/4700 DEC/7600, DEC/7700 DEC/10600 AlphaServer 2000 AlphaServer 2100 AlphaServer 4000 AlphaServer 4100 AlphaStation 600 DEC/3500, DEC/3500S, DEC/3500X DEC/3800, DEC/3800S DEC/3900 AlphaServer 300 (Melmac) AlphaServer 400 AlphaServer 800 AlphaServer 1000, 1200 AlphaStation 200 AlphaStation 250 AlphaStation 255 14 AlphaStation 400 AlphaStation 500 DEC/2300S DEC/2500 DEC/3300, DEC/3300L, DEC/3300X, DEC/3300LX DEC/3400, DEC/3400S DEC/3600, DEC/3600S DEC/3700 TeMIP GAT V2.0 is only available on the DIGITAL UNIX platform. Disk Space Requirements: For installation: 100,000 Kbytes For use (permanent): 100,000 Kbytes Additional disk space may be required for Customized Access Modules. Run-time systems will only require sufficient disk space to load cus- tomized and CS AMs executables. Memory Requirements: For run-time systems: The minimum memory supported, due to a TeMIP Framework prerequisite, is 128 Mbytes. For development systems: The minimum memory supported, due to a TeMIP Framework prerequisite, is 256 Mbytes. However, the use of this software in conjunction with increased mem- ory improves performance. 15 SOFTWARE REQUIREMENTS For run-time systems: o DIGITAL UNIX V4.0D o TeMIP Framework V3.2 For development systems, the following software must be installed on top of the above: o Visual TeMIP Developer's Toolkit V2.0 o DEC C++ V5.7 compiler OPTIONAL SOFTWARE o DEC X.25 V3.0 for DIGITAL UNIX. YEAR 2000 READY This product is Year 2000 Ready. The testing used to confirm the Year 2000 readiness of this product included code assessment and system tests to verify transition dates. GROWTH CONSIDERATIONS The minimum hardware/software requirements for any future version of this product could be different from the requirements for the current version. DISTRIBUTION MEDIA This product is also available as part of the UNIX Consolidated Soft- ware distribution on CD-ROM. See ordering information for each Soft- ware Media reference. 16 ORDERING INFORMATION TeMIP Graphical ASCII Toolkit Development: Software License: QL-5SLA9-AA Software Media: QA-5SLAA-H8 Software Documentation: QA-5SLAA-GZ Software Product Services: QT-5SL**-** TeMIP Graphical ASCII Toolkit Run-Time: Software License: QL-5SMAM-3B Software Product Services: QT-5SM**-** * denotes a variable value. Contact your local DIGITAL office for more information. SOFTWARE LICENSING This software is furnished under the licensing provisions of Digital Equipment Corporation's Standard Terms and Conditions. For more in- formation about DIGITAL's licensing terms and policies, contact your local DIGITAL office. TeMIP Graphical ASCII Toolkit uses the FLEXlm Software License Key sys- tem. The licensed software can be used up to the limit specified in the li- cense file. The scheme used is trust based, which means that it does not use any machine-specific values or count of users to rigidly en- force license compliance. A FLEXlm key must be obtained using the request form provided with the Cover Letter, temip-license-form.txt. For use of any prior version of TeMIP, the LMF checksum is located on the Software PAK received as de- liverable upon order of the Software License. This checksum is only valid for LMF, that is for versions prior to V2.0 of TeMIP Graphical ASCII Toolkit on DIGITAL UNIX. 17 License units for TeMIP Graphical ASCII Toolkit Development are al- located on an Unlimited System Use basis. SOFTWARE PRODUCT SERVICES A variety of service options are available from DIGITAL. For more in- formation, contact your local DIGITAL office. SOFTWARE WARRANTY This software is provided by DIGITAL with a 90 day conformance war- ranty in accordance with the DIGITAL warranty terms applicable to the license purchase. The above information is valid at the time of release. Please contact your local DIGITAL office for the most up-to-date information. [R] Motif and OSF/Motif are registered trademarks of Open Software Foundation, Inc. ORACLE is a registered trademark of Oracle Corporation. Ultra is a registered trademark of Sun Microsystems, Inc. FLEXlm is a registered trademark of GLOBEtrotter Software, Inc. UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company Ltd. [TM]The DIGITAL Logo, DEC, DECnet, AlphaStation, AlphaServer, DECwindows, DIGITAL, RZ and TeMIP are trademarks of Digital Equipment Corporation. (c)1998 Digital Equipment Corporation. All Rights Reserved. 18