(Message inbox:10063) Return-Path: hks Return-Path: Received: from nic.nordu.net by funet.fi with SMTP (PP) id <14328-0@funet.fi>; Wed, 4 Mar 1992 20:12:44 +0200 Received: from sun2.nsfnet-relay.ac.uk by nic.nordu.net (5.61-bind 1.5+ida/6.0) id AA14112; Wed, 4 Mar 92 19:08:54 +0100 Received: from castle.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <17844-1@sun2.nsfnet-relay.ac.uk>; Tue, 3 Mar 1992 18:31:56 +0000 From: H Evans Subject: NMS Form To: netf-netman@nic.nordu.net Cc: george@castle.edinburgh.ac.uk Date: Tue, 3 Mar 92 9:58:21 GMT Message-Id: <9203030958.aa03269@castle.ed.ac.uk> Dear Sir, Please find attached our response to your NMS evaluation form. If anyone requires any more information about the Seel Nemisys product, please contact Hugh Evans or Bob Coombe at Seel. Our phone number (from Norway) is 09544 506 411503 or we can be contacted via email at Seel@uk.ed. Yours Sincerely Hugh Evans DRAFT V0.4 Network Management System evaluation form NORDUNET Engineering and Technical Forum Network Management working group Editor & Chair: Harri Salminen 1991-11-04 This form can be used in two ways. First it can be used while evaluating different network management systems as an evaluation form or checklist of all questions that should at least be checked on the product. Secondly it can be used to define local requirements for a network management system by setting different priorities for different items in the form and them comparing it to the results of different evaluations that have could already have been done by somebody else. For example following priorities might be used: 0 Don't want it 1 No use for it 2 Don't care if it doesn't cost extra 3 Nice to have but not worth much extra cost 4 Would definitely like to have at least in the future 5 Usefull and worth paying extra to get it now if necessary 6 Necessary to have one way or other 7 Absolutely necessary. No deal otherwise. The requirements could be also verbal specifications or additional questions to the form. If they seem to be of general interest we are willing to intergrate in the future versions of the evaluation form. The completed forms you wish to share with you colleagues should be sent to netf-man@nic.nordu.net which is the mailing list for the netf-netman wg. (should we have separate mailing list for evaluation or collection?). An anonymous ftp archive for the results will be kept in nic.nordu.net directory net/net-man/results and possibly some comparison report could be written if there's enough results and interest. Otherwise the forms could be just processed locally for individual comparison needs. In general most of the questions can be answered with simple Yes/No/NA and more detailed verbal descriptions can be written as well in following linesafter the simple answer. On some questions theres suggested alternatives for the simple answer enclosed in square brackets [Yes|No|Maybe] that should be used.. On some questions a rating on scale from 0 (not available) to 10 (Excellent) should be given and of course a verbal explanation can be added The simple answers should be the first word after the question to facilitate automated statistics and table generation. Additional lines can be used as many as necessary since the question numbers are used as the separators and explanatory comments are enclosed in square brackets. In case there is 'n' or '____' or 'other' questions it means that you can add more alternatives by copying the question. You can also add subquestions or hierachy levels if seen necessary. In case answer is missing from some question it's assumed to mean that the feature in question is missing from that product. Please send your comments directly to the editor at or the netf-netman@nic.nordu.net mailing list to which you can subscribe by sending mail to netf-netman-request@nic.nordu.net. 0. Product indentification 0.1 Name of the product: NemiSys 0.2 Version of the product: 5.0 0.3 Manufacturer of the product: Seel Ltd. 0.3.1 Postall address: 3 Young Square, Livingston, EH54 9BJ, U.K. 0.3.2 International phone number: 44 506 411503 0.3.3 International fax number: 44 506 417016 0.3.4 Internet address (optional): 0.3.5 Contact person(s): R. Combe 0.4 International availability: Yes 0.4.n Representative: Seel Ltd. 0.4.n.1 Postall address: As Above 0.4.n.2 International phone number: " 0.4.n.3 International fax number: " 0.4.n.4 Internet address (optional): 0.4.n.5 Contact person(s): " 0.5 Evaluator: N/A 0.5.1 Postal address: 0.5.2 International phone number: 0.5.3 International fax number: 0.5.4 Electronic mail address: [optional, preferably as seen from the Internet e.g. netf-netman@nic.nordu.net] 0.5.5 Contact person(s): 0.5.6 Evaluation period (yyyymmdd-yyyymmdd): 0.5.7 Description on the evaluation environment: 0.6 Remarks 1 Overview (free form general description of the product): 2. Management protocol support This section is used to evaluate the support for management procols that are used between the Network Management System and the entities to be managed. Information about customization possibilities for supporting special customer needs should also be included. 2.1 SNMP support [Yes/Optional/Coming/No]?: yes 2.1.1 SNMP MIB II support [Yes/No]: yes 2.1.2 List of vendor supplied MIBs: Mib-I, Mib-II 2.1.3 Is there support for loading of customer supplied MIBs?: yes 2.1.3 What are the supported input methods and formats?: standard mib text 2.1.4 Are all MIB variables of same type equal?: yes [E.g. can some customer supplied variables used instead of default ones in all applications] 2.1.5 General comments: 2.2 CMIP support [Yes|Optional|Coming|No]: coming 2.2.1 Versions supported: N/A 2.2.2 List of vendor supplied MIBs: N/A 2.2.3 What are the supported input methods and formats?: N/A 2.2.4 Are all MIB variables of same type equal?: N/A 2.2.5 Supported transport and network layers [TP4/CLNS|TP0/CONS]?: N/A 2.2.6 General comments: 2.3 IEEE 802.1 support [Yes/Optional/Coming/No]?: no 2.4 FDDI SMT support [Yes/Optional/Coming/No]?: no 2.5 Type of support for custom programmed protocol modules? Script Language [None/RPC/IPC/Programming Library/Specific Language/Development kit/Other] [This support should in principle enable the customer to interface the NMS with any kind of entity that can be managed using computers ranging from weather monitors to Nuclear Power plants although in most cases it will be needed to support special network devices or applications that only respond to some console language or special protocol.] 2.1 Seel 'Pac' Network Processors support [Yes/Optional/Coming/No]?: yes 2.2 Stratacom support [Yes/Optional/Coming/No]?: coming 2.3 Netview support [Yes/Optional/Coming/No]?: coming [A numbered entry for each other protocol supported should be made. E.g. DEC EMA, IBM Netview, Vitalink NMS, Megapak, Stratacom, Timeplex, ATT Accumaster etc. If relevant, subentries like under point 2.2 could be added.] 3. Features supported by the network management system This section describes the features supported by the network management system. In case of a system that is specific to a certain area only (e.g. trouble ticket system or report generator) the other areas can be marked as N/A. 3.1 Configuration management: yes 3.1.1 Graphical representation: yes 3.1.1.1 General description of the user interface: mousedriven [Is it modeless, multimode, multimenu, mousedriven, assemblyprogrammed, easy to learn even for non CS experts, needing source code/dissassembler and manyears of study, Is configuration integrated to the fault or other management user interfaces or does it need to be invoked separately possibly after running down the NMS?] 3.1.1.2 Hierarchical logical maps: yes 3.1.1.3 Different parallel views: yes 3.1.1.4 Different personal views: no 3.1.1.5 Support for B/W display: yes 3.1.1.6 Configurable color schemes: yes 3.1.1.7 Userdefinable icons: yes 3.1.1.8 Supported external graphics file input formats: yes [Does it support GIF, TIFF, HP-GL, Postscript or other files to be loaded as backgrounds or icons. What about color graphics support? E.G. Maps or digitized images] 3.1.1.8.1 Can graphics input be done automatically from scripts or only interactively?: interactively 3.1.1.9 Output file formats supported: postscript display dumps [See 3.1.1.8. This is especially usefull as PR-material or technical documentation so it should be of high quality and consistent with the displayed view. Preferred format would be scalable color postscript with possible menus removed but even raster display dumps could do]. 3.1.1.10 Functionality of interactive drawing tools [0-10,remarks]: 3.1.1.10.1 Supported object types: bitmaps [These could be vectors, pixels, fonts or compound objects built from them] 3.1.1.10.2 Support for custom object libraries: no 3.1.1.10.3 Support for inheritance: yes [Can properties be derived from main class of objects? Is it possible to make a global or local changes to a particular property of an object class?] 3.1.1.10.4 Support for multiple fonts: yes 3.1.1.10.5 Support for national character sets or custom defined fonts: yes [In many countries there's a need to be able to write textual descriptions in national character sets. E.g. ISO 8859-1. If there's a documented font format for custom fonts or font editor it should be mentioned] 3.1.1.10.6 Support for various font sizes: yes 3.1.1.10.7 Support for different text orientations: no [E.g. sometimes it could be usefull to fit the labels in vertical or diagonal orientation instead of normal horizontal one] 3.1.2 Parameter configuration: 3.1.2.1 SNMP write access support: yes 3.1.2.2 Interactive console access support: yes [This support is used for speedy access to a console of a particular device so the user should need to find and type commands and addresses but just invoke right connection with right parameters with a click of a mouse.] 3.1.2.2.1 Telnet to selected object: yes 3.1.2.3.2 Dialup via phonebook to selected object: yes [This is needed for example to access a remote console using a dialup modem to check the equipment on the remote end of a line that is down.] 3.1.2.2.3 DEC MOP via node table: no 3.1.2.2.4 X.25 PAD via X.121 table: yes 3.1.2.2.5 VT via X.500 or table: no 3.1.2.2.6 Other [possibly user defined?]: 3.1.3 Shared configuration support with locking and/or syncronisation: no 3.1.4 Emergency configuration possible from a VT100 terminal?: yes 3.1.5 Other comments: 3.2 Fault management: [ Describe all available fault detection methods like SNMP Poll, SNMP Trap, ICMP ECHO, etc] SNMP Poll, SNMP Trap, ICMP ECHO, X25 Poll, NOVELL Poll. 3.2.1 Indications [text|color|shape|audio|other]: text, colour, audio. [Can the different indications be defined by the user or are they fixed inside the code?] 3.2.1.1 OK state: user defined 3.2.1.2 Unknown state: user defined 3.2.1.3 Alarm threshold exceeded: user defined [How alarm tresholds can be defined?] 3.2.1.4 Acknowledged but not fixed: not at present [Someone has acknowledged it and possibly left an open trouble ticket. It's usefull to quickly know in multioperator environment that someone has started to take care of the problem] 3.2.1.5 Dynamic performance indication by scaling colors/sizes [This could mean the color changing to an intense red under heavy load or becoming bigger in size] 3.2.1.6 Not currently operational or monitored: yes [The object is displayed currently only for documentational purposes] 3.2.1.7 Other: 3.2.1.8 Configurable audio indicators: no [Is there support for configuring different alert sounds for different indications or even playback of digital sound files. Is at least support for turning audio indication on and off by each operator possible?] 3.2.1.9 Other configurable output methods: no [This could include invoking a custom program with the parameters of the alarm that could for example be used to command slide projectors with floor plans or send a message to a beeper or voice synthetizer. It could also be used to start some standard corrective action.] 3.2.2 Handling of faults: 3.2.2.1 Acknowledgement of alarms needed: no [Does an indication of the alarm stay untill one of the operators acknowledges it or does it just come and go if there's short and possibly repetitive alarms ringing the bell and disappearing?] 3.2.2.2 Trouble ticket support: not at present [What kind of data the trouble ticket can contain? Can it be customised to conform to some local standards? Is there participation in IETF trouble ticketing work?] 3.2.2.3 Trouble log searching possibilities: yes [Page by page browsing, indexing, string search, regular expression search, condensed reports, output to a sequential text file for browsing with external tools] 3.2.2.4 Trouble ticket distribution methods: N/A [Are all other operators notified of the trouble ticket if they haven't filtered that alarm off so that they don't start parallel actions? Can the trouble tickets be forwarded using external mail or fax systems?] 3.2.2.4 Support for filtering of specified alarms: yes [can a particular operator easily filter out alarm sources that aren't relevant to him at the moment? Can the filters be saved for later use? Can an operator filter out a whole display or class of objects?] 3.2.2.5 Support for automatic filtering of non-causal alarms?: no [Can the system filter out alarms that have been caused by a failing object blocking the monitoring path beoynd that object? Is the possible state machine, expert system or AI logic doing this customizable by the user?] 3.2.3 Efficiency and responsiveness: [How well does the system perform with large configurations?] very well 3.2.3.1 How many simultaneous processes the system needs? few central [Does the system have just few central processes for polling and alarm dispatching or does it need separate processes for each polled object?] 3.2.3.2 How much working memory an average monitored object needs? [bytes]: 200 3.2.3.3 Does each operator need to poll separately from his workstation or can a central server do it once for all operators? central 3.2.3.4 Can some objects or displays be polled only on demand? yes [For example a NOC could have the configuration of a neighboring networks that need to be polled only occasionally in case of suspected problems or unmanned primary NOC] 3.2.3.6 Individually customisable polling intervals: no [Can you have different default polling intervals for different objects, object classes or displays? For objects that are behind slower paths there could be necessary to have longer polling intervals than for some local object.] 3.2.4 Distribution support [Yes/No]: yes [This applies only if the system supports multiple remote operators. If not answered the system is taken to be a single user centralized system with no support for shared network management necessary in most large or loosely organised environments without a single dedicated network manager doing everything. If the product is not distributed it's often necessary to keep multiple up to date copies of the same software in many different workstations just in case they are needed] 3.2.4.1 Central system with multiple X-windows workstations [Y/N]: y [The parallel operators can have just a simple X-windows terminal or any type of, possibly color, X-windows workstation] 3.2.4.2 Central system with workstations having local files: no [The operators can run a copy of the NMS monitoring software on their local workstation possibly with some local or personal information but the main server is still doing common tasks. This might decrease the network traffic and load to the central server although it might also cause synchronisation and updating problems for the users.] 3.2.4.3 Distributed co-operating servers [A set of parallel servers working independently on different parts of the management domain sharing information only when necessary. Possible automatic load sharing of tasks among a group of workstations or servers.] 3.2.4.4 Sharing of information between management domains: yes [There could be a protocol or proxy agents that permit users from other management domain to monitor a specified part of the local management domain without the need for giving them direct poll access to the monitored objects which might cause unnecessary load on them. If answer to 3.2.4.1 is yes then it should be possible to give remote access to some friendly operators at other domains.] 3.2.5 Is there a programming interface to add custom fault detection methods? yes [E.G. is there a set of library calls, IPC protocols, commands, development kit for proxy agents or other means of monitoring a device without standard management interfaces to the management system?] 3.2.6 Integration of external test tools and analyzers: yes [Currently just support for invoking separate programs in another window with information from a selected object as parameters would be enough. There might be some proprietary protocol support for remote protocol analysers untill standards for them are developed in IETF or elsewhere] 3.2.7 Ease of access to contact information (0-10): N/A 3.2.8 Other comments: N/A 3.3 Performance management: yes 3.3.1 Method of report definition: will be based on Ingres in near future [Please describe how reports can be generated from the performance data collected by the NMS. Can the reports be created by just selecting a set of variables, scales and representations with mouse? Does it require vading through myriads of panels and menus and still doesn't produce what you wanted? Or does it require you to write your own SQL or other programs to process the raw data and display it with external tools in which case there's not much much support for performance management included] 3.3.2 Automation of regular reports: available with Ingres option [This should at least include standard formats and right dates in a graph. Preferably such report generation should be possible to start with a timer (cron) and output directed to a uniquely named postscript or text file in a statistics archival directory.] 3.3.3 Trend graphs on any variable combination over time: yes (autoscaling) [Does it support autoscaling, logarithmic scales or two independent scales in the same graph?] 3.3.4 Relative distributions between variables: yes (bar chart) [This could for example be pie graphs or bar charts describing a protocol or load distribution] 3.3.5 Statistical analysis on time series: no [What kind of manipulation of the data is supported? Ratios between variables, vertical or horisontal averages? Regression analysis?] 3.3.6 Annotation of graphs with text and graphics: no 3.3.7 Output in numerical form to a file for postprocessing: yes 3.3.8 User customisable filters or programming interface: yes 3.3.9 Plotting output in color postscript: no 3.3.10 Plotting output in b/w postscript: yes 3.3.11 Plotting output in some other form: no 3.3.12 How performance data is stored if at all? dynamic and flat file [Do the performance management functions support only real time performance monitoring or does it collect the polled information in raw or filtered form in a common database or log files. Is there support for compression, filtering and expiration of unnecessary information? How compact the storage format is?] 3.3.13 Support for IETF recommendations?: N/A [still in draft state though, so it can't really be fully supported yet] 3.3.14 Other comments: 3.4 Accounting management: 3.4.1 Billing contact information database:will be available with Ingres 3.4.2 Reliable collection and storage of accounting information: yes 3.4.3 Individually customisable reports and bills: will be available with Ingres 3.4.5 Easy interfacing to external accounting systems: 3.4.6 Billing summaries by user groups: 3.4.7 Other comments: 3.5 Security management: 3.5.1 Individual user authentication: 3.5.2 Authentication method(s) used: password [E.g. user/password, address screening, challenge/response, Kerberos... Is it possible to add new methods by custom programming or using Common Authentication Technology interface being standardised by IETF?] 3.5.3 Multiple access levels (Configuration/Operation/Monitor): yes 3.5.4 Different groups displays available to different users: yes 3.5.5 Possibility of encrypting files: no 3.5.6 Other comments: 3.6 General: [overall opinion if any] 3.6.1 How many different database(s) are used [none|one|n|many]: 2 [A database is a place where information used, collected or produced by the Network Management System is stored. There may be single or multiple different types of databases for different kinds of information like configuration, topology, contacts or statistics. In case there's multiple types of databases they should be described separately. If description is missing for particular information category it is expected to be in the form of ASCII text files.] 3.6.1.n Database description: central in core database for general management and monitoring operations + Ingres database for statistics and Trouble Ticketing. [Describe what the database is used for, just configuration or statistics information or for generally all information. E.g. Contact db, topology db, contact db, statistics db or general db] 3.6.1.1 Database type [single user|centralised|master/slave|multimaster]: In Core - Centralised Ingres - Centralised [Does the database support multiple concurrent users reading or writing in different workstations with apropriate record locking mechanisms? Is there a central database machine common for the whole NOC or does every workstation need to have automatically maintained slave copies or even separate master copies of the database?] 3.6.1.2 Database model [text,table,relational,object-oriented,other]: In Core - table Ingres - relational [It can be simply a collection of text files, indexed tables (dbm), SQL database, object oriented database, X.500 directory or something else.] 3.6.1.3 Database management tools [0-10,comments]: 3.6.1.4 External database interface [SQL,C library,other]: In Core - C library Ingres - SQL 3.6.1.5 Database product needed if not included: In Core - included Ingres - Ingres 3.6.1.6 Support for aging of old information: In Core - no Ingres - yes [If the database is used to collect for example statistical information the old information needs to be aged out after some period of time during which reports and analyses of the collected data has been made. Is the aged out information just deleted or exported to external files that can be archived] 3.6.1.7 Support for sharing database information with other NOCs: [Is it possible to share part of the database with another NOC using some common inter NMS protocol or files? In many cases several management domains overlap and the NOCs having secondary responsibility for a managed object should be able to easily have up to date information from the master database] 3.6.2 Quality of on-line help system [0-10,comments]: [Is it just obfuscated C source code without comments or context sensitive multimedia help system with AI features?] 3.6.3 Quality of printed manuals [0-10,comments]: [Are they non existent, easily updated and consistent set of folders with good examples etc. or just pretty looking leather bound volumes without any real detail or update possibilities?] 3.6.4 Overall ease of use [0-10,comments]: 3.6.5 Distribution restrictions: [Is the software freely distributable or licensed for certain organisation, site, central server or even single workstation?] 3.6.6 Price range: P.O.A. [If separately priced modules or options are available they should be listed separately. The denominations should preferably converted to ECUs. For other currencies the ISO standard codes should be used. Is there special discount policies e.g for non-commercial or academic users?] 3.6.7 Support policies: P.O.A. [The cost of standard maintenance contract should be included in the local currency or as a percentage of the purchase price. Since these may vary from country to country they should be taken just as an indication. Main issue is the availability of after sales support. If developers can be contacted via email it's a big bonus and should be mentioned.] mail address seel@uk.ed 3.6.8 Supported platforms: Sparcstation2 (standard config) 1/4" tape drive SunOS 4.1.1 X Windows X11.R4 OSF Motif 1.1 + SunNet X.25 Ver 7.0 [Minimum recommended hardware and software configuration should be described. E.g. SparcStation,32MB memory,600MB disk,8-bit GX color,sunos4.1.1,X.windowsR5 or IBM PC, 4.77Mhz, 128KB,2x320KB floppy, MGA, serial port] 3.6.9 Is the implementation derived from some other implementation(s)? no [E.g. it could be based on Nysernet, ISODE or SunNetmanager packages. If licences or documentation from base packages isn't included it should be mentioned here]. 3.6.10 Availability of source code no [Many users would like to have the ability fix problems or customize the software for our specific needs. The need depends on the quality of the product and it's support, it's programming interfaces and level of documentation. Some users might also be interested of a close co-operation in the development of the product.] 3.6.11 Other comments: [Additional points can be added if necessary] [After filling this in please share it with us by sending it to netf-netman@nic.nordu.net adn we'll put it into our collection]