TNMS Ted

Information
TNMS Core/CDM 8.5 Technical Description (TED)

A42022-L5938-G51-1-7618
Technical Description (TED)
Information TNMS Core/CDM 8.5
Important Notice on Product Safety

Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the circuit parts may also have elevated operating temperatures. Systems with forced ventilation have rotating items. Non-observance of these conditions and the safety instructions can result in personal injury or in property damage. The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to comply with the applicable safety standards. Mount the systems in areas with restricted access only. Only trained and qualified personnel may install, operate, and maintain the systems.
The same text in German: Wichtiger Hinweis zur Produktsicherheit In elektrischen Anlagen stehen zwangslufig bestimmte Schaltungsteile der Gerte unter Spannung. Einige Teile knnen auch eine hohe Betriebstemperatur aufweisen. Anlagen mit Zwangsbelftung haben drehende Teile. Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Krperverletzungen und Sachschden fhren. Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen. Die Anlagen drfen nur in Betriebssttten mit beschrnktem Zutritt aufgebaut werden. Die Anlagen drfen nur durch geschultes und qualifiziertes Personal installiert, betrieben und gewartet werden.
Trademarks: All designations used in this document can be trademarks, the use of which by third parties for their own purposes could violate the rights of their owners.
Copyright (C) Siemens AG 2003.

Issued by the Information and Communication Networks Group Hofmannstrae 51 D-81359 Mnchen Technical modifications possible. Technical specifications and features are binding only insofar as they are specifically and expressly agreed upon in a written contract.
A42022-L5938-G51-1-7618
This document consists of a total of 82 pages. All pages are issue 1.
Contents
1 1.1 1.2 1.3 2 2.1 2.1.1 2.1.2 2.1.3 2.1.3.1 2.1.3.2 2.1.3.3 2.1.3.4 2.1.3.5 2.1.3.6 2.2 3 3.1 3.2 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.4 3.5 3.6 3.7 3.8 4 4.1 4.2 4.3 5 5.1 5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.3 5.3.1 Introductory Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Available Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Symbols Used in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Communication Networks (DCN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples of Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WDM Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multi-NE Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resilient Packet Ring (RPR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SDH Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PDH Access Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core/CDM NetServer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core/CDM Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core/CDM Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core/CDM SysAdmin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Scalability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . External Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Licensed Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NE Upgrade Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Migration/Upgrade from TNMS Core V8.0 . . . . . . . . . . . . . . . . . . . . . . . . . Functional Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Features of TNMS Core/CDM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core/CDM Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core/CDM NetServer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core/CDM SysAdmin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Core/CDM Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Log Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Log Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 7 8
10 11 11 14 15 15 16 17 19 20 21 22 23 23 24 25 26 26 27 27 28 29 30 30 31 33 33 33 33 34 34 35 35 35 36 36 36 37
A42022-L5938-G51-1-7618
5.3.2 5.4 6 6.1 6.1.1 6.1.2 6.1.3 6.2 6.2.1 6.3 6.4 7 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.8.1 7.8.2 7.8.3 7.9 7.10 7.10.1 7.10.2 8 8.1 8.1.1 8.1.2 8.2 8.2.1 8.3 9 10 10.1 10.2 10.3 10.3.1 10.3.2 10.3.3 10.3.4 10.4 10.5
Log Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 RPR Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Client Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Network Topology Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Path Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Subscriber Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Performance Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Performance Log Export Tool (PLET) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 SysAdmin Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 TNMS Core/CDM Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Alarm Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Cost Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Date / Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 License Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 NE Inscription Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Account Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Container Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Northbound Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 DCN Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 NetServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 DCN Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Optional Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Northbound Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 TCOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 SNMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Southbound Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 TCOM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Multi Server CDM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Multi Server CDM: Hierarchical Distributed Network Management . . . . . . . 58 Multi Server CDM: System Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 MS CDM Netserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 MS CDM Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 MS CDM Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 MS CDM SysAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A42022-L5938-G51-1-7618
10.6 10.7 11 11.1 12 12.1 12.2 12.2.1 12.2.2 12.2.3 12.2.4 12.3 12.3.1 12.3.2 13 13.1 13.2 13.2.1 13.2.2 13.3 13.4 14 14.1 14.2 14.3 14.3.1 14.3.1.1 14.3.2 14.3.3 14.3.4 14.4 14.5 14.6 14.7 14.7.1 14.7.2 14.8 14.8.1 14.8.2 15
External Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 System Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Multi Server CDM: Installation Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Licensed Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Multi Server CDM: Functional Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . Main Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MS CDM Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MS CDM Netserver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MS CDM SysAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MS CDM Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Log Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Log Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Log Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multi Server CDM: Client Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Task Order Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Topology Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subscriber and Service Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multi Server CDM: SysAdmin Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . TNMS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alarm Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Database Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backup/Restore in a Distributed TNMS Environment . . . . . . . . . . . . . . . . . Details of Backup/Restore in Multi Server CDM . . . . . . . . . . . . . . . . . . . . . Data Import/Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Log Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Date / Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . License Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SN Inscription Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Account Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DCN Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NetServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DCN Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 69 69 69 70 70 70 71 71 71 72 72 72 72 73 73 74 75 75 75 76 76 76 77 77 77 77 78 78 78 78 78 79 79 79
Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A42022-L5938-G51-1-7618
A42022-L5938-G51-1-7618
1 Introductory Notes
1.1 Available Documentation
All TNMS Core/CDM manuals are available on CD-ROM, and can be ordered in English. Manual Type CD-ROM (contains TED, IMN and OGL) Table 1.1 Order Number A42022-L5938-G10-*-76K5
TNMS Core/CDM Documentation on CD-ROM
Technical Description (TED) The Technical Description provides an overview of the applications, features, system architecture and functions of TNMS Core/CDM including the descriptions for the optional Multi Server CDM software. Installation Manual (IMN) The Installation Manual contains instructions on installing the TNMS Core/CDM software including the installation descriptions for the optional Multi Server CDM software. Operator Guidelines (OGL) The Operator Guidelines contain a general description of the TNMS Core/CDM Client and TNMS Core/CDM SysAdmin user interfaces including the descriptions for the optional Multi Server CDM softwareas well as the necessary background information.
You may also consult the online help which is provided with the TNMS Core/CDM software. It provides comprehensive instructions on the functions offered by the Client and SysAdmin user interfaces. The Contents, Index and Search tabs enable the online help to be searched through quickly and conveniently. Individual help topics can be printed, and context-sensitive help texts called up directly from the user interface. The complete online help for TNMS Core/CDM and the individual instruction manuals are also provided as *.pdf files under the Help menu. These files can be viewed and printed using Adobe Acrobat Reader.
1.2
Symbols Used in This Manual

The following symbols are used in this manual:
i
!
Table 1.2 Symbols
Additional information Warnings
A42022-L5938-G51-1-7618
1.3
Feedback
We aim to provide you with documentation which is easy to understand and userfriendly. Your practical experience with the TNMS documentation/online help is very important to us in achieving this objective. We are particularly interested in your opinion on the following issues: Where is too much/not enough detail provided? Where do you nd these instructions difcult to understand? Where would additional graphics be useful to improve understanding? What improvements could be made to the basic layout of the TNMS Core/CDM documentation? Please enter your comments, suggestions and corrections in the questionnaire on the following page. If necessary, this questionnaire can also be photocopied or printed out from your documentation CD. So that we can contact you and discuss your comments at greater length if necessary, do not forget to enter your contact details. Thank you in advance for your support!
A42022-L5938-G51-1-7618
Questionnaire
Completed questionnaires can be returned: by fax: +49 89 722 57315 or by post: SIEMENS AKTIENGESELLSCHAFT Information and Communication Networks Group ICN CP E PD D Hofmannstrasse 51 D-81359 Mnchen Company/Name:
Address:
Department:
Telephone: Fax:
Date:
Signed:
I am using this documentation (...) (...) (...) (...) (...) (...) As service documentation As an installation/commissioning guide As a general introduction For reference purposes As training material _______________________________
My duties include (...) (...) (...) (...) (...) (...) Commissioning Operation Maintenance Sales Training activities _______________________________
Page
Remarks
A42022-L5938-G51-1-7618
2 Network Overview
The telecommunication network management system TNMS Core/CDM is an integrated solution designed for large, medium and small networks. It supports network elements with WDM, OTH, SDH, PDH, Ethernet and Data interfaces and can be used to manage networks at the access, edge, metro, core and backbone level.
TNMS Core/CDM Integrated element manager (EM): LCTs, TNMS-SX, EM-OS, MSN manager, NetViewer NME
Management interface ELI TNMS-SX EMOS-SLI EM-OS MSN
Type of network element
SXA, SXD
SLxx, SMAxx, etc. MSN, SURPASS hiT7070 Node SURPASS hiT7070 Lambda FMX, CMX
QD2SISA SMA1/4, SMA4/1, SMA1K, SMA1K-CP, SMA16, SMA16/4, SL16, SLR16, SL64, Infinity MTS, Infinity WL, Infinity WLS, OCU, WTTR, SURPASS hiT 7050 / 7070 / 7540 / 7550 ULAF+, SSU-2000e, Summit48si, Waveline EL2, Waveline MN, FSP2000, FSP3000 Radio NEs
DCN
QB3M
SNMP
TCOI
NetViewer NME
TCOI TCOI; optional
Silvx
SN16000 other vendors EMSs e.g. NEs supported via TIF
UNO+ (logical interface)
Fig. 2.1
General Structure of a TNMS Core/CDM Network
10
A42022-L5938-G51-1-7618
Fig. 2.1 shows the general structure of a transmission network managed by TNMS Core/CDM. The network elements (NE) provide various management interfaces. This means that they can be connected via the DCN to the management system in several ways. Element management functions are executed via the element managers (LCTs, TNMSSX, MSN manager, EM-OS, NetViewer NME) provided by the TNMS Core/CDM system. For network elements managed via EM-OS, network management is restricted to fault management (alarm mapping). These network elements are displayed as universal objects in the TNMS Core/CDM network plan.
2.1
Network Architecture
TNMS Core/CDM can be used universally in all kinds of transport networks. The seamless integration of WDM, SDH, PDH, Radio and Data equipment significantly broadens the range of possible application scenarios. This manual offers just a few examples.
2.1.1
Network Elements
TNMS Core/CDM supports line, star, ring and mesh networks comprising the network elements listed in Table 2.1. The table only consists network elements supported with TNMS Core/CDM 8.5. Further NE types or NE versions can be added with software upgrade packages.
A42022-L5938-G51-1-7618
11
Information TNMS Core/CDM 8.5 Device FSP500 FSP2000 FSP3000 Infinity WL Infinity WLS Infinity MTS 3.3 5.4, 5.6 2.3, 3.0, 3.1 2.1, 2.2, 2.3, 2.35 1.0, 2.0, 2.05 1.1E, 1.1 ANSI, 2.03 WLS 1.0: via TIF only 1.1.ANSI: Not compatible with SDH devices, can only be operated with SONET equipment. Only the subtypes OTT8, OTT16 and OLR are supported. Version Note as icon only
NE class WDM
Infinity MTS 1c OCU OSN WTT SURPASS hiT 7540 SURPASS hiT 7550 Waveline EL2 WDM Table 2.1 Waveline MN
1.0 1.0E, 1.2.5, 2.0, 2.1.5, 2.2, 2.6 2.15 1.5, 2.65 2.05 2.0 3.1 EM only
List of Supported Network Elements
12
A42022-L5938-G51-1-7618
NE class SDH SL16 SL64 SLR16 SMA1/4 SMA 4/1 SMA1K
Device
Version 2.35, 2.4.1, 2.5 2.6 3.25, 3.27, 3.3 2.2 2.2, 2.2R, 2.3, 2.3R 4.2, 4.3, 4.35 3.2, 3.3 3.2, 3.3 4.1 4.2, 4.3, 4.35 6.0, 6.2
Note
SMA1K-CP SMA16 SMA16/4 SN16000
TCOI required toleration of broadleaf for 6.2
SURPASS hiT 7070 SURPASS hiT 7050 SXA SXD SXC WTTR PDH ASA32 CC64kr FMX II (MXS19 and CMXS subrack) LTCOH-LT, LTCOH-NT LTO-LT, LTO-NT ULAF+ Other SSU-2000E Summit48si Table 2.1
1.1 1.1 2.50, 3.10, 3.20 1.30, 2.10, 2.15 1.42.6 2.0 SUE TCOI required
2, 3 LTC(LT), LTC(NT)
3.1 1.0 6.2.2
A42022-L5938-G51-1-7618
13
NE class SDH Radio SPS 155 SRA 1
Device
Version 1.5/2.3 1.13.x/2.13, 1.14.x/2.14 series 3: 3.3.x, 3.4.x, 3.5.x, 3.6.x series 4: 4.1.x
Note as icon only TCOI required as icon only TCOI required TCOI required
TCOI required TCOI required as icon only TCOI required TCOI required
SRA 1S SRT 1 SRT 1C
1.11.x/2.11.x 1.14.x/2.14.x 1.5/2.3 1.15.x/2.15.x 1.16.x/2.16.x 1.18.x 1.2.2/2.1 3.0.x, 3.1.x 4.0.x, 4.1.x 1.3.x/2.1, 1.4.x/2.2, 1.3.xF/2.1F; 1.4.xF/2.2F; 1.3.xS2.1S; 1.4.xS/2.2S 1.0
SRT 1S SPS E SRT 1F PDH Radio SRA L
as icon only TCOI required TCOI required TCOI required TCOI required
Multi NE devices
MSN SURPASS hiT 7070 Node SURPASS hiT 7070 Lambda
1.0
Table 2.1
2.1.2
Data Communication Networks (DCN)

Data communication networks play an important role in managed transmission networks. DCN faults therefore have a considerable effect on the functionality of the network as a whole. The transmission rate of each DCN also influences the general network performance. Settings for the various DCN interfaces to the network elements (e.g. addresses) are made in TNMS Core/CDM SysAdmin. For more information, see Section 7.10. Each type of DCN is assigned to a specific type of network element, an important consideration during DCN planning (see Fig. 2.2 below).
14
A42022-L5938-G51-1-7618
TNMS Core/CDM
Ethernet
SISAGKE QD2 FMX SMA
SMA
STM-1 ring
SMA
SMA QB3-DCN (routed via DCC channels) CMX QD2-DCN routed via 64-kbit/s payload channel
FMX
Fig. 2.2
Data Connections via Different DCNs (Example)
2.1.3 2.1.3.1
Examples of Networks WDM Networks

TNMS Core/CDM offers comprehensive support for new-generation WDM systems such as Waveline/FSP for metropolitan networks, SURPASS hiT 7550 for long-haul applications and Infinity WL/WLS. These systems are used in ultra-high capacity (UHC) networks as well as in metropolitan networks. Fig. 2.3 shows a simple example of a UHC network. The 10 Gbit/s connections represent interfaces to a lower transport layer (comprising SDH systems, for example).
A42022-L5938-G51-1-7618
15
TNMS Core/CDM
DCN
n x 10 Gbit/s
n x 10 Gbit/s
SURPASS hiT 7550
SURPASS hiT 7550
SURPASS hiT 7550
SURPASS hiT 7550 Backbone network Regional/Metro network SL64 SL64
n x 10 Gbit/s
SURPASS hiT 7550
Waveline / FSP
Waveline / FSP
Managed network
Waveline / FSP
Fig. 2.3
WDM Network
2.1.3.2
Data Networks
There are several types of data network. One of these, the Storage Area Network (SAN), is shown in the following figure. Storage Area Networks consist of storage devices (e.g. RAID arrays, storage applications, and tape storage) connected on a separate network from the LAN. In other words, a dedicated storage network is inserted between the network servers and various storage subsystems. This network operates at gigabit speed via fiber optic cabling, enabling long-distance communication between nodes. Because SANs run on an
16
A42022-L5938-G51-1-7618
entirely separate network from that of the corporate LAN, a lot of bandwidth is freed up on the LAN, thus minimizing the risk of bottlenecks.
TNMS Core/CDM
Server
DCN ESCON / FICON Gigabit Ethernet
Waveline / FSP
Waveline / FSP
Metro DWDM
Waveline / FSP
Waveline / FSP
Managed network ESCON / FICON
Main Frame
Fig. 2.4
Data Network All standard optical fiber connections such as ESCON, FICON and Fiber Channel are supported by TNMS Core/CDM.
2.1.3.3
Multi-NE Devices
For high capacity transport networks the ring topology with its self-protecting capability can be advantageously used. OADM rings providing several transparent wavelengths, which in turn enable the creation of a virtual meshed network where services are transported between arbitrary nodes. A Multi-NE device contains several NEs which enable implementation of high bandwidth line interfaces and various tributary interfaces (see Section 6.1.1 for details).
A42022-L5938-G51-1-7618
17
TNMS Core/CDM
DCN
Managed network Multi-NE device Multi-NE device
optical ring
Multi-NE device Multi-NE device
Multi-NE device
Fig. 2.5
Multi-NE Devices within an optical ring Two main kinds of services can be run using Multi-NE devices: Services provided by SDH equipment (SDH, SONET, Ethernet services). The protection of these services is provided by SDH equipment. Other services (data, video, clear channels), typically protected by Waveline/FSP protection facilities. Building Multi-NE devices simplify the handling within the network layer of TNMS Core/CDM. As a Multi-NE device is handled similar to a single NE, the network map and several lists are more clearly arranged (Note: e.g. a SURPASS hiT 7070 Node can contain up to 65 network elements). Multi-NE devices are controlled by a special multi-NE manager which offer two sights: the Functional View (presents the NE structure) and the Rack View (presents the physical arrangement). There are three types of Multi-NE devices: the Multi Service Node (MSN), SURPASS hiT 7070 Node and SURPASS hiT 7070 Lambda. From the functional point of view, they are very similar. Nevertheless, the combination of the used network element types is different. For more information about MSN, SURPASS hiT 7070 Node and SURPASS hiT Lambda see Section 6.1.1.
18
A42022-L5938-G51-1-7618
2.1.3.4
Resilient Packet Ring (RPR)

Basics Resilient Packet Ring (RPR) is a network topology being developed as a new standard for fiber optic rings. Fiber optic rings are widely deployed in both Metropolitan Area Networks (MAN) and Wide Area Networks (WANs). A special RPR access protocol and Ethernet interfaces enables high-speed data transmission. RPR is an emerging network architecture and technology designed to meet the requirements of a packet-based MAN like guaranteed service quality and bandwidth management within service level agreements. Architecture An RPR consists of packet-switching nodes connecting to adjacent nodes over a single fiber pair. SDH paths constitute the links between the RPR nodes. These are VC-4 paths or VC-4-4v paths as well in each direction. SDH network elements provide the physical connections. The RPR nodes (RN) are fit into the tributary slots of the SDH equipment. RPR operates by sending in both (clockwise and counter clockwise) directions data frames and control frames (the latter for handle tasks such as topology discovery, protection switching and congestion control).
Resilient Packet Ring (RPR) SURPASS hiT 70.. SURPASS hiT 70..
RPR node counter-clockwise
VLAN for a CUG with three access points
SURPASS hiT 70..
SURPASS hiT 70..
clockwise
Fig. 2.6
Resilient Packet Ring (RPR) Using a RPR Within a RPR broadcast domains are defined by Closed User Group (CUG) and Virtual LAN (VLAN) together. In any case no frame may cross the broadcast domain boundary. Usually a CUG is composed of different locations of the same enterprise e.g. a company consisting of headquarter and some subsidiaries. The RPR can be seen as a set of virtual switches. Each layer of the switch represents one CUG and all layers are strictly separated. For convenient handling of RPR services, the RPR Manager is used, for details see section 5.4.
A42022-L5938-G51-1-7618
19
2.1.3.5
SDH Networks
TNMS Core/CDM is capable to manage various SDH NEs offering services from 2 Mbit/s up to STM-64. Both line and ring structures including BSHR and MSP are supported, depending on the NE version. The combination of full element management functionality and extensive network layer capabilities provides comprehensive support for network operator tasks such as end-to-end service and path provisioning (see Chapter 6). Additional operations such as supervision, monitoring, maintenance and provisioning of the SDH network can be completed without the need for auxiliary TMN equipment. TNMS Core/CDM
DCN
STM-64 SL64 SL64 SMA16 SL64
SLD16 SLD16 STM-16
SXA
SLD16
SLD16 MSP SMA4 SMA1K SMA4 STM-4 SMA4
SMA1 SMA1K
SMA4
Managed network
Fig. 2.7
SDH Network
20
A42022-L5938-G51-1-7618
2.1.3.6
PDH Access Networks

TNMS Core/CDM supports n x 64-Kbit PDH access services using tributary cards of FMX/CMX NEs. End-to-end management for PDH equipment is implemented via TNMS Core/CDM at the network management layer (NML). Other tributary cards such as ISDN and 64-Kbit sub-bitrate cards are configured via the LCT application and implemented at the element management layer (EML). Administration of these services is therefore performed directly via the element managers. For the purposes of fault management, however, all alarms are written to a global alarm log maintained in TNMS Core/CDM. Fig. 2.8 shows a typical application scenario with FMX/CMX in interaction with a SDH network.
TNMS Core/CDM
DCN
SMA
SMA
STM-4
SMA SMA
SMA
CMX CMX FMX Managed network
CMX
FMX
Fig. 2.8
PDH Access Network
A42022-L5938-G51-1-7618
21
2.2
Network Protection
Protection mechanisms are used to ensure the continued availability of a service even if a connection or part of a connection fails. Services can be protected using either path protection (for the transmission path) or trail protection (for the physical network elements and lines). Various network structures are supported such as meshed networks, line structures, and rings. A path comprises a sequence of port connections and cross connections. Both path ends may have either one or two endpoints. The path endpoints may lie on the same or on different network element layers. The route and endpoints can be modified by the operator. A trail comprises a defined number of connections between termination points on the same network layer. Connections in adjacent transmission layers have a client/server relationship. The individual trails are known as client trails, and if located on adjacent transmission layers, they can be linked to create a server trail. Path Protection Path protection is configured in TNMS Core/CDM using a series of dedicated windows which create a standby path for every working path selected. The option for sub-network connection protection (SNCP) provides protection at every transmission level and can therefore be used to protect either an entire path or parts of a path across a network. Trail Protection Trail protection is performed on the network management layer. The possibilities include multiplex section protection (MSP), a bi-directional self-healing ring (BSHR) or optical protection. Multiplex section protection (1+1) is used on lines to protect point-to-point connections between network elements with multiplex capability. The individual service is not protected, rather the whole multiplex section between two adjacent nodes with multiplex functionality. MSP is provided on the network management layer (NML). A two or four-fiber bi-directional self-healing ring (BSHR-2/4) is a special multiplex section protection mechanism used within rings. As is the case with MSP, it protects the whole multiplex section between two adjacent ring nodes, called a span. BSHR is also provided on the network layer. 1+1 Optical Protection TNMS Core/CDM supports 1+1 optical protection against failures on the optical channel layer independent of the optical channel client (with NEs SURPASS hiT 7540 or Waveline/FSP), on the optical multiplex section layer (with NE Waveline/FSP).
22
A42022-L5938-G51-1-7618
3 System Overview
3.1 System Architecture
TNMS Core/CDM is a scalable multi-user system with a client/server architecture comprising several industry standard PCs with the Windows 2000 operating system and various software applications. External devices such as printers, tape units and remote clients can also be connected but are not dealt with here.
TNMS Core/CDM Client SysAdmin
TNMS Core/CDM Client SysAdmin
TNMS Core/CDM Server SysAdmin
Client PCs
Server PC
TNMS Core/CDM NetServer
NetServer PCs
NE containers
NE containers NE containers Large network
Fig. 3.1
System Architecture The TNMS Core/CDM software comprises the Client, SysAdmin, Server and NetServer applications. Client and SysAdmin are installed on a client PC. To support distributed operation of the network, up to 25 Client and 10 SysAdmin installations can be managed simultaneously. Concurrent access to network resources is regulated by the server PC so that only one operator at a time is granted write access to a network element. The Server software is installed on a server PC. A second SysAdmin installation on the server PC together with an additional monitor is also recommended as this enables
A42022-L5938-G51-1-7618
23
administration of the TNMS Core/CDM system to continue even if the data flow between the client and server PC is interrupted. If the installation of TCOA is required, additional 3rd-party software must be installed on the server PC. The NetServer software is installed on a netserver PC. Depending on the number of network elements, the number of netserver PCs that can be managed simultaneously, is scalable.
3.2
Hardware Components
The table below provides an overview of recommended hardware requirements for TNMS Core/CDM installations. However other configurations are possible, depending on the network size. Planning for hardware, software and licences should be undertaken on a project-specific basis. Server CPU: Xeon TX300, 2.66 GHz Multiprocessor operation supported. Memory: 1 GB bzw. 2 GB *) Hard Disk: 2 x 36 GB Floppy Disk: 1.44 MB CD-ROM drive Ethernet card RAID controller NetServer CPU: P4, 2.4 GHz Multiprocessor operation supported. Memory: 2 x 512 MB Hard Disk: 40 GB Floppy Disk: 1.44 MB CD-ROM drive Ethernet card, 2x Client CPU: P4, 2.4 GHz Multiprocessor operation supported. Memory: 512 MB Hard Disk: 40 GB Floppy Disk: 1.44 MB CD-ROM drive Ethernet card PC I/O, optional Color monitor 21 Operating system: Windows 2000 Professional
DAT streamer for backup Color monitor 17 Operating system: Windows 2000 Server *) Enhanced Hardware Tab. 3.1 Color monitor 17 Operating system: Windows 2000 Professional
TNMS Hardware Requirements for Server, NetServer and Client
24
A42022-L5938-G51-1-7618
3.3
Software Components
Fig. 3.2 shows the TNMS Core/CDM software architecture.
TNMS Core/CDM Client components Element manager Element manager
TNMS Core/CDM SysAdmin components Import / Export files (XML)
Export files (TSF)
TNMS Core/CDM Client Frame Network management user interface
TNMS Core/CDM SysAdmin Frame System administration user interface
TNMS Core/CDM Server components
SNMP proxy
TNMS RegDB
TCOA proxy TNMS NmlDB
TNMS Core/CDM Server
TNMS LogDB
TNMS Core/CDM NetServer Frame
TNMS EmlDB
EML package NE controller
EML package NE controller TNMS Core/CDM NetServer components
DCN interfaces NE NE
Fig. 3.2
Software Components (overview)
A42022-L5938-G51-1-7618
25
3.3.1

TNMS Core/CDM NetServer operates as a mediation device for the DCNs connected to it. It processes large volumes of data imported from the DCN and relays this information to the TNMS Core/CDM Server in compressed form. The NetServer supports all NEspecific functions, except for the element managers included with TNMS Core/CDM Client. The main parts of the NetServer are the NetServer frame component, the EML packages and the TNMS Core/CDM EmlDB. NetServer Frame Component The NetServer frame is essentially a proxy for the TNMS Core/CDM Server. It facilitates the management of EML packages as well as remote communication between TNMS Core/CDM Server components and TNMS Core/CDM NetServer components. EML Packages A EML package is an installation package, which contain all relevant components (e.g. the NE controller) needed to run a family of NEs within TNMS Core/CDM. The combination of EML packages required for a given TNMS Core/CDM system depends on the NE types that TNMS Core/CDM system configuration is required to support. NE Controllers The main task of an NE controller is to convert NE-specific management interfaces to a simple internal TNMS Core/CDM element management interface. In this way, network layer management in the TNMS Core/CDM Server only receives the necessary information from the element management layer. A corresponding NE controller must be registered in the system for every NE type to be managed by TNMS Core/CDM. Each NE controller class can support different NE types, but each NE can only be controlled by one type of NE controller. TNMS Core/CDM NetServer Database The NetServer also includes a TNMS Core/CDM NetServer database (TNMS Core/CDM EmlDB) where relevant network element data is temporarily stored.
3.3.2

TNMS Core/CDM Server is the central component of TNMS Core/CDM and controls the following FCAPS (Fault, Configuration, Accounting, Performance, Security) functions for the network management layer and element management layer: Fault Management Conguration Management Performance Management Security Management Data relating to these processes is written to various databases. The config database (also known as the TNMS Core/CDM registry) stores general data, the Server database stores network management data and the log database stores log and list data. More information on TNMS Core/CDM databases is provided in Section 3.4. As well as coordinating DCN management functions such as the administration of network element addresses, DCN channels and NetServers, the TNMS Core/CDM
26
A42022-L5938-G51-1-7618
Server also support interfaces to higher-ranking network management systems (see Section 3.7), to TNMS Core/CDM NetServers and to TNMS Core/CDM Clients. Up to 25 Client, 10 SysAdmin and 10 NetServer installations can be connected to the TNMS Core/CDM Server at the same time.
3.3.3
TNMS Core/CDM Client

The TNMS Core/CDM Client is responsible for the following functional layers: Network Management User Interface The TNMS Core/CDM Client user interface provides the operator with several network views which contain graphical and textual information about current alarms, states and resources. Depending on the operators user class, the Client user interface also includes various wizards and dialogs which simplify system operation. The main GUI contains the network map window, several list and log windows (alarm list, alarm log, network event log, system message log, etc.) and specific dialog windows associated to the functionality of the client. Element Manager / Network Manager Application Interfaces A corresponding element manager can be started for each network element with a simple double-click (e.g. on the network element symbol within the network plan). The TNMS Core/CDM Client starts the corresponding process and provides the interface of the associated NE controller to the element manager. Element manager applications provide full access to all NE data and also enable the configuration and control of NE behavior. In this way, depending on the actual NE type, performance values and alarms can be requested, and the backup and restore of configuration and other data initiated. Network Management Data Export Data export is provided in the TNMS Core/CDM Client to export data for external evaluation. This enables the operator to export the content of each list and log to a file. This information is written to tab separated format (*.tsf) files. Several tools and standard applications (e. g. MS Access or MS Excel) can read these files. Detailed functional information on TNMS Core/CDM Client is provided in Chapter 6.
i
3.3.4
Detailed operating information on TNMS Core/CDM Client is provided in the Operator Guidelines (OGL) and in the online help.
TNMS Core/CDM SysAdmin

TNMS Core/CDM SysAdmin provides administration functions for all TNMS Core/CDM components in the component tree, as well as various monitoring (e.g. client monitoring, DCN monitoring) and log (e.g. notification log, system message log) windows which can be opened in the main window. TNMS Core/CDM Import / Export Interface TNMS Core/CDM SysAdmin supports an interface which allows the import (unscheduled) and export (scheduled and unscheduled) of data using XML.
A42022-L5938-G51-1-7618
27
Detailed functional information on SysAdmin is provided in Chapter 7.
i 3.4
Detailed operating information on SysAdmin is provided in the Operator Guidelines (OGL) and in the online help.
Databases
TNMS Core/CDM uses the following databases: TNMS Core/CDM Registry Database (TNMS Core/CDM RegDB) TNMS Core/CDM Network Management Layer Database (TNMS Core/CDM NmlDB) TNMS Core/CDM Logs and Lists Database (TNMS Core/CDM LogDB) TNMS Core/CDM Element Management Layer Database (TNMS Core/CDM EmlDB) The TNMS Core/CDM RegDB stores general TNMS Core/CDM configuration data such as: Security policies User group denitions User account data Properties of TNMS Core/CDM components Properties of DCN objects Background bitmaps to be used for network maps The TNMS Core/CDM RegDB is managed by the TNMS Core/CDM Server and is opened as soon as the Server is loaded. The TNMS Core/CDM RegDB can be backed up, restored, replicated and migrated. The TNMS Core/CDM NmlDB permanently stores the following objects: Subscribers Services Paths Port connections NE links NE containers PM log denitions NEs Ports Termination points Cross connections Protection groups PMPs used in PM logs Alarms The TNMS Core/CDM NmlDB is managed by the TNMS Core/CDM Server and is opened when the Server is started. The TNMS Core/CDM NmlDB can be backed up, restored, replicated and migrated. The TNMS Core/CDM LogDB stores the following tables: Current alarm list Alarm log Network event log Security event log System message log
28
A42022-L5938-G51-1-7618
PM logs User-dened object types User-dened probable causes
The TNMS Core/CDM LogDB is managed by the TNMS Core/CDM Server and is opened when the Server is started. The TNMS Core/CDM LogDB can be backed up, restored, replicated and migrated. More information on log management is provided in Section 5.3. The TNMS Core/CDM EmlDB is used as a file cache by some NE controllers that cannot store the complete NE data. The TNMS Core/CDM EmlDB cannot be backed up or migrated.
3.5
System Scalability
The TNMS Core/CDM system architecture supports scalable configurations. This means that different groups of components can be installed on the same machine or on different machines. Components of the same group must always run on the same machine. Examples are: Medium System TNMS Core/CDM Server components and TNMS Core/CDM NetServer components run on one PC, TNMS Core/CDM Client components run on separate PCs. TNMS Client TNMS SysAdmin TNMS Server TNMS NetServer TNMS SysAdmin
TNMS Client TNMS SysAdmin
TNMS Client TNMS SysAdmin Fig. 3.3 TNMS Core/CDM Medium System
Large System There is one TNMS Core/CDM Server associated to a number of TNMS Core/CDM NetServers running on separate PCs. TNMS Core/CDM Clients also run on separate PCs.
A42022-L5938-G51-1-7618
29
TNMS NetServer
TNMS Server TNMS SysAdmin
TNMS NetServer
TNMS NetServer
Fig. 3.4
TNMS Core/CDM Large System
i 3.6
The required hardware configuration should be planned individually for each transport network.
Operating System
All TNMS Core/CDM components require the Windows 2000 operating system. For TNMS Core/CDM Client, TNMS Core/CDM SysAdmin and TNMS Core/CDM NetServer Windows 2000 Professional is recommended. The TNMS Core/CDM Server should run on Windows 2000 Server.
3.7
External Interfaces
TNMS Core/CDM supports the following external interfaces: Name Qx Used by NE controller Umbrella Systems Other vendor management systems Attributes External Description Q interfaces. Proprietary NE interfaces such as QD2, QST, Q3, etc.
SNMP TCOI
Open SNMP TMF CORBA TMF CORBA interface. This interface is compliant with the TMF CORBA specification. The interface provides access to the NEs, subnetworks and subnetwork connections managed by a TNMS Core/CDM Server. OLE-DB interface. This interface is a standard Microsoft database interface for accessing tabular data. Active read-only access is enabled for lists and logs.
OLE-DB
Tools for Open OLEexternal DB DCOM data evaluation
Tab. 3.2
External Interfaces of TNMS Core/CDM
30
A42022-L5938-G51-1-7618
Name TSF
Used by Customers
Attributes Open TSF
Description TSF list export interface. Interface for exporting the contents of lists and logs an *.tsf file. XML list import/export interface. Interface for importing/exporting the contents of lists and logs an *.xml file.
XML
Customers
Open XML
Tab. 3.2
External Interfaces of TNMS Core/CDM
3.8
System Availability
The intensive data security and system availability demands of TNMS Core/CDM require an advanced security concept. The following options are provided: Mirror disks Warm standby TNMS Core/CDM Server Standby TNMS Core/CDM NetServer Database recovery (see Section 7.4) Database backup (see Section 7.4) Mirror disk If the TNMS Core/CDM Server PC is provided with a RAID system, all data is also stored on an additional mirror disk which are monitored by a SCSI RAID controller. The SCSI RAID controller ensures automatic data synchronization between the active hard disk and the mirror disk, so if the active hard disk develop a fault, a mirror disk takes over and the system is not affected. The faulty disk can be replaced by a new disk of the same type without shutting down the Server. The RAID controller then copies the data from the active hard disk to the newly installed hard disk. Warm standby TNMS Core/CDM Server This option can be used if the TNMS Core/CDM Server is no longer available, e.g. due to a fire or complete hardware failure. The standby server is a second server machine with exactly the same hardware and software configuration as the active server. The operator registers the standby server at the active TNMS Core/CDM Server and activates database replication mechanisms. Should a failure occur, the operator simply switches manually to the standby server and starts the TNMS Core/CDM Server process as normal on the standby system. The standby TNMS Core/CDM Server also supports the following features: Conguration ID counters on the network management layer (NML) and NEC proxy layer: The conguration ID counters on the NEC proxy layer each record changes to a particular object class, e.g. ports, cross connections, alarms, termination points, etc. After switchover to the standby server, these changes are synchronized only with those NEs which have different counter values. This enables accelerated startup of the standby system. Automatic synchronization of the NML with the NECs: If changes have been recorded to object classes, TNMS Core/CDM automatically
A42022-L5938-G51-1-7618
31
initiates resynchronization of the NML with the NECs. Manual synchronization by the operator is no longer necessary. Access to additional standby server information: The operator can log onto the standby server via SysAdmin and obtain information about the status of the data replication process (see the section on Data Replication) as well as the name of the corresponding active server. This ensures greater transparency during switchover to the standby server. The user can also manually validate or cancel database replication at any time.
In order to make the most of these features, a reliable link must be provided to the remote server. So that the database can be updated without interruption, this link should have a transfer rate of > 2 Mbps as well as low signal latency. Standby TNMS Core/CDM NetServer This option can be used if the TNMS Core/CDM NetServer is no longer available, e.g. due to a fire or complete hardware failure. The standby NetServer is a second machine with exactly the same hardware and software configuration as the active NetServer. Activating a standby NetServer requires full DCN access at the standby site.
32
A42022-L5938-G51-1-7618
4 Installation Notes
The TNMS Core/CDM software includes a number of applications and feature components. It is supplied on CD-ROMs which includes a convenient master installation program for installing the TNMS Core/CDM software components on the users hard disk, modifying an existing installation by adding or removing selected components or subcomponents, removing the TNMS Core/CDM software completely from the users hard disk.
i 4.1
Full commissioning and startup details can be found in the Installation Manual (IMN).
Licensed Software
In order to install the TNMS Core/CDM software, the corresponding licenses are required. Depending on functionality, the TNMS Core/CDM software is divided into several software packages, which are provided on separate CD-ROMs with individual licenses.
Various software products referred to in this manual have been licensed by Siemens AG and are provided together with the TNMS Core/CDM software. Any questions concerning these products should therefore be directed to Siemens AG rather than to the original manufacturer. Questions regarding software products such as virus scanners, which may run with TNMS Core/CDM software, but which are not provided, sold or purchased by Siemens AG, should be addressed directly to the manufacturer in question.
4.2
NE Upgrade Packages
The TNMS Core/CDM software supports subsequent integration of new network elements or new network element versions. The software components for managing a new network element or a new network element version are provided with a TNMS Core/CDM upgrade installation package. Using this package, a TNMS Core/CDM system can be upgraded with the element management components required for the new network element/network element version. It is not necessary, however, to install a new version of the TNMS Core/CDM package.
4.3
Migration/Upgrade from TNMS Core V8.0

TNMS Core/CDM supports the migration of databases when upgrading from TNMS Core V8.0 to TNMS Core/CDM V8.5 UP1.
A42022-L5938-G51-1-7618
33
5 Functional Overview
TNMS Core/CDM provides all the major network management functions defined in the ITU-T standard M.3010 Principles for a Telecommunications Management Network. Fault, configuration and performance management are supported on the element management layer, with configuration management and fault management also provided on the network management layer. Additional configuration, fault and performance management features are available on the service management layer, and various security management features are also implemented.
5.1
Features of TNMS Core/CDM

The main features of TNMS Core/CDM are summarized below: Integrated management for network elements with WDM, OTH, SDH, PDH, Ethernet and data interfaces Management on the network layer, network element layer, and service layer Fault, conguration, performance and security management End-to-end connection management for services with WDM, OTH, SDH, PDH, Ethernet and data interfaces Support of SNCP Support of VC4, VC3 and VC12 concatenation Support of Multi-NE Devices (e.g. MSN, SURPASS hiT 7070 Node) Support of Multi-Layer Switching (e.g. for SURPASS hiT 70..) Support of sub-equipped cards (e.g. for SURPASS hiT 70..) Support of Auto-link Detection (e.g. for SURPASS hiT 70..) Support of Radio NEs (via NetViewer) RPR Manager for convenient handling of RPR services Logical domain concept TMF CORBA Interface to umbrella TMN SNMP interface to umbrella TMN (alarm and status management) Import (unscheduled) and export (scheduled/unscheduled) for conguration data and logs External alarming (summary of network statistics) via e-mail/SMS Visual network representation, intuitive operator guidance, detailed and contextsensitive online help Scalable system architecture, high system availability Multi-user capability (up to 25 clients can be connected to the server) Remote control via public networks Dedicated conguration windows for automatic and manual routing Operating capacity overview for port connections Support of NE container concept Straightforward installation/upgrading of network elements Software updates without data loss/trafc interruption Subscriber management Enhanced security management Support of multiple management interfaces to the NEs Support of additional NE types or versions in upgrade packages Standby system These functions are available via the Client and SysAdmin interfaces. For more information, see Chapter 6 and Chapter 7.
34
A42022-L5938-G51-1-7618
5.2
5.2.1
Basic Operation
Starting TNMS Core/CDM Server TNMS Core/CDM Server can be either be started automatically or manually by the administrator. Once it has been started, TNMS Core/CDM Server is linked to all active TNMS Core/CDM NetServers. Stopping TNMS Core/CDM Server TNMS Core/CDM Server can be stopped by the administrator. When the Server is stopped, all connected client PCs are notified and any further login attempts rejected. Once all clients have been disconnected from the TNMS Core/CDM Server, the NetServers are also shut down and the TNMS Core/CDM databases closed. The TNMS Core/CDM Server can also be stopped independently of the NetServers, for example if maintenance work is required. Concurrent Access Concurrent access to multiple TNMS Core/CDM Clients is managed by the TNMS Core/CDM Server as follows: Network conguration, creation of port connections and alterations to icons in the network editor are only permitted for one TNMS Core/CDM Client at a time. Subscriber information can only be changed by one operator at a time. If selected for service management in the service mode, a network element is not available to other operators. Up to 25 client installations can be operated simultaneously. Distribution of Date / Time TNMS Core/CDM provides a manual date and time synchronization function for all managed TNMS Core/CDM components and for NEs which support this function. The TNMS Core/CDM Server distributes the current TNMS Core/CDM Server time in GMT to every available NE controller. The date and time are also distributed to all active NetServers and connected client PCs, with the exception of NetServer or Client installations running on the TNMS Core/CDM Server machine. For the NE types MTS, WLS, OCU, SURPASS hiT 75... and SURPASS hiT 70... the network element clock is set automatically in regular intervals to avoid that the network element time will get inaccurate.
5.2.2

Activating/Deactivating TNMS Core/CDM NetServer A TNMS Core/CDM NetServer and each DCN object managed by the NetServer can have the activation state activated or deactivated. If a TNMS Core/CDM Server is started, connections will be established for all activated NetServers.
A42022-L5938-G51-1-7618
35
5.2.3
TNMS Core/CDM SysAdmin

Starting TNMS Core/CDM SysAdmin To access the TNMS Core/CDM system, you must first log onto the SysAdmin software. Once you have logged on, you can start the TNMS Core/CDM Server using the icon provided in the toolbar. Once the Server is started, you can also access the TNMS Core/CDM Client software. More information on TNMS Core/CDM SysAdmin is provided in Chapter 7.
5.2.4
TNMS Core/CDM Client

Starting a TNMS Core/CDM Client Once the TNMS Core/CDM Client has been started, the operator can enter the login data. Functions authorized by the operators user class can now be accessed (see Section 7.8.2). The Client contacts the Server and requests alarm information, port and connection data, and the data required for mapping the network. If complete data is not available for certain network elements, these are shown as unavailable on the user interface by a box containing two question marks. The first time the Client is started, only the notifications log is opened. In subsequent sessions, log windows which were opened when previous sessions were shut down are also opened. The entries from previous sessions are then displayed. If the TNMS Core/CDM Server is not available, an error message is displayed. Starting Element Manager Applications The element manager applications are started via TNMS Core/CDM Client. A data connection is established to the relevant NE which allows the user to execute required functions directly at the NE. The user interface is the same as for operations with the LCT. Administrating NE Write Access TNMS Core/CDM only administers write access to managed network elements which support this feature. Write access to a given network element or set of network elements can be requested, enforced or released. In this way the TNMS Core/CDM operator also has control over external LCT write access. Terminating a TNMS Core/CDM Client Session A TNMS Core/CDM Client session is terminated when the user logs off. All windows are closed and access is only provided to the login function.
5.3
Log Management
In TNMS Core/CDM, specific operator activities as well as random actions and events are stored in log files on the TNMS Core/CDM Server. The log contents can be printed out, saved to a file or evaluated via a standard OLEDB/ADO interface.
36
A42022-L5938-G51-1-7618
The Performance Log Export Tool (PLET) exports performance logs, alarm logs, network event logs and system message logs to different applications and systems (for details see Section 6.2.1).
5.3.1
Log Classes
In TNMS Core/CDM, each log is assigned one of the following classes: Permanent Custom Non-persistent Permanent logs are fixed, global logs administered by the TNMS Core/CDM system. The operator can, however, specify certain attributes such as the type of event to be included, maximum log size, etc. Custom logs are created and administered entirely by the operator. Operators can create or delete custom logs according to their individual access rights. Attributes such as log capacity and scope can be defined as required, and logs of this type can also started or stopped at any time. Non-persistent logs are maintained by the TNMS Core/CDM Client and TNMS Core/CDM SysAdmin and only exist for the duration of a client session. The log content is deleted when the client session is terminated.
5.3.2
Log Types
The following log types are possible in TNMS Core/CDM: Log Type TNMS Core/CDM Client X X X X X X X X X TNMS Core/CDM SysAdmin Log Class
Alarm log System message log Network event log Security event log Performance log Notifications log Operator input log Table 5.1 Log Types
Permanent log Permanent log Permanent log Permanent log Custom log Non-persistent log Non-persistent log
The alarm log contains a chronological list of alarms which have occurred. Toggling alarms, i.e. identical alarms which are triggered repeatedly, are entered once only if the toggling filter with a proper time setting is switched on. The system message log contains a chronological list of relevant administrative events. Critical events are indicated at the user interface. The network event log documents configuration changes to the network management layer. It includes actions initiated or triggered directly by the network or individual network components.
A42022-L5938-G51-1-7618
37
The security event log documents relevant security events in TNMS Core/CDM. It provides information such as the event type, event severity and the object affected. The performance log documents the performance records for the measurement points defined by the operator. As there may be several network elements each with a number of measurement points, special algorithms regulate data collection and ensure that each value is only requested once. These mechanisms prevent the unnecessarily high network loads which can occur when numerous data requests are sent simultaneously. The notifications log only documents events which are relevant for the current Client session, for example communication errors. An individual operator input log can be created for each operator. Information relevant to the operator, such as executed actions, is collected from the permanent logs and presented in a report window. The operator input log is a snapshot, and is therefore not updated automatically.
5.4
RPR Manager
Introduction The RPR Manager provides functions to handle the RPR layer of a network managed by TNMS Core/CDM as indicated in Fig. 5.1. Resilient Packet Rings (RPRs) are build up of SMA16 4.3/4.35 or SURPASS hiT 7070 1.0 network elements (it is not possible to have a mixture of different NE types on the same ring).
- Packet switched traffic - Bandwidth scalability - dynamic RPR layer Focus of RPR Manager
- Provides trails between RPR nodes, - Alarms - PM data
- Configuration requests
SDH + ethernet end-to-end - Circuit switched traffic - TDM traffic - Low flexibility - static Focus of TNMS Core/CDM
Fig. 5.1
Interworking between RPR Manager and TNMS Core/CDM
The RPR Manager can be launched from the TNMS Core/CDM Client; it works closely with TNMS Core/CDM: TNMS Core/CDM is responsible for the NEs containing the RPR
38
A42022-L5938-G51-1-7618
nodes and the trails between the nodes, i.e. it provides the infrastructure for the RPR Manager. The RPR Manager creates the services running on the RPR layer. To activate the services, the RPR Manager sends requests to TNMS Core/CDM that performs the requested actions in the NEs. Alarms from the NEs are received by TNMS Core/CDM and forwarded to the RPR Manager. PM logs are created in TNMS Core/CDM by request of the RPR Manager. TNMS Core/CDM performs the PM data collection and logs the data. With the RPR Manager the operator has the possibility to display the PM log and the PM records in the log. Data Synchronisation between RPR Manager and TNMS Core/CDM The two main principles of database management for RPR Manager are: The RPR Manager database contains only the data that is specic to the application. There is no duplication of data already available in TNMS. The user explicitly requests all data synchronisation concerning conguration changes. On the other hand the application automatically processes alarms (spontaneous events) that affect the RPR infrastructure as well as operational state changes in the SDH paths that support the rings. The application also monitors configuration changes in the underlying infrastructure and raises an appropriate alarm. When synchronizing the data TNMS is considered to be the master source for all SDH and subscriber information while RPR Manager is the master of all RPR related data. Whenever a discrepancy between the data models is detected at synchronization an error message will be shown to the user. The synchronisation process is done separately for each ring or for all rings. Ring Discovery The RPR Manager can discover the existence of any RPRs from the data reported by TNMS. Alarm and Operational State Monitoring In order to allow the real time monitoring of the state of RPR services, the application processes alarms, operational state changes notifications and changes in the configuration of the underlying infrastructure that affect the rings. All relevant notifications are logged and shown to the user. When the application detects that aconnection to a TNMS domain has been established it will automatically check the operational state and the alarms of all rings that are in that domain. In addition, when a connection to a domain is lost that shall be reported to the user. Licensing The RPR Manager server can only run if a valid license has been entered. The license key enables all functionality of the RPR Manager. Login Account The RPR Manager client is started from the TNMS Client GUI. The operator will inherit all access rights from TNMS Core/CDM concerning user class and set of objects. RPR Manager distinguishes between the following user classes: Supervision, Maintenance,
A42022-L5938-G51-1-7618
39
Operation, Conguration, Administration.
Access rights to a RPR The visibility of the NEs of an RPR in defined by the user class, user group and the NE containers of the NEs. The user class of the operator applies to all visible NEs. When one NE of an ring is visible to the operator in TNMS, the whole ring is visible in RPR Manager and the access rights defined by the user class of the operator applies to the whole ring.
40
A42022-L5938-G51-1-7618
6 Client Functions
6.1 Conguration Management
Configuration management is an umbrella term for the tasks involved in the organization and modification of the network plan, the creation and modification of services, and the administration of subscribers to these services.
6.1.1
Network Topology Management

Network topology management is concerned with the process of preparing and enabling TNMS Core/CDM for network management operation. This includes in particular the following: Providing information necessary for communication between network components, e.g. NE addresses, Conguring the NE container topology structure, Providing information about the physical network topology, i.e. the NEs and the port connections between these NEs, Handling RPR rings and MSNs. The following objects are managed by TNMS Core/CDM and represented on the network map by various graphical symbols such as icons, lines, etc. Network Element (NE) This object represents a physical network element. Two types of network element object are provided in TNMS Core/CDM. A real NE object represents those NEs that can be managed directly via an NE controller in the NetServer and that are therefore also managed entirely by TNMS Core/CDM. An UNO NE object is used to represent those NEs that are not managed entirely by TNMS Core/CDM because: alarms for the NE in question are not forwarded to TNMS Core/CDM directly but via another NE, alarms for the NE in question are not forwarded to TNMS Core/CDM directly but via an EMOS management system using a serial interface, the NE is managed via a generic SNMP controller, the NE is not managed at all. In this case the UNO only provides a symbolic representation of the unmanaged NE. Network elements form the basis of the network topology. Each individual NE is both clearly identifiable and can also be combined with other NEs to form network structures known as NE containers. Invoking the LCT of an individual network element, the TNMS operator can execute functions on element management layer. In case of configuration management for example it is possible to use the Script Configuration Function of the LCT to configure several NEs in a comfortable way (only for NEs which support this function, e. g. for SURPASS hiT 7070). Protection Group and MS Protection A protection group is an object that represents MSP or BSHR functionality in the NEs. The MS protection object represents an interworking relation between dedicated protec-
A42022-L5938-G51-1-7618
41
tion groups in different NEs (e.g. between two MSP protection groups that belong together). NE Container This object represents a container where NEs/UNOs/MSNs are grouped together and illustrated by icons. In addition to these NEs, every NE container can also contain one ore more other NE subcontainers. Port Connection This object represents physical connections (e.g. fibers) that are possible between NEs/UNOs/Multi-NE devices and also inside the Multi-NE devices. A prerequisite for port connections is that the ports at both ends either support the same transmission layer, or have a dedicated transmission layer at one end (e.g. STM-16) and a generic port belonging to the generic trail layer at the other: Port connections can be congured between real NE ports, UNO ports and between a mixture of both. Port connections can connect NEs and UNOs in different NE containers. In the case of NEs, connections are also possible between different NE types. Port connections can be created for a wide range of technologies such as pure optical networks, SDH, PDH, Ethernet, ESCON, FICON, Fiber Channel, etc. Unidirectional and bidirectional port connections are possible. Port connections can be congured between ports with MSP or BSHR functionality. It is also possible to connect two ports within the same NE, e.g for test purposes. Unlike internal port connections within TNMS Core/CDM and port connections within an Multi-NE devices, external port connections are always created explicitly by the TNMS Core/CDM operator. Server Path This object represents an explicitly/implizitly created server path that provides infrastructure for lower order paths. Remote Inventory In order to determine the requirements when updating or upgrading network components, or extending the network, the operator must have sufficient information about the installed base. For this purpose, TNMS Core/CDM provides a remote inventory (RI) which stores inventory files. These files contain information about the hardware and software installed on each individual NE. Multi Service Node (MSN) An MSN is basically a cluster of individual network elements that is displayed as a single network element on the TNMS Core/CDM GUI. In this way, the TNMS Core/CDM operator can conveniently manage several NEs at once using a single NE cluster. Fault management is also provided for MSNs via an alarm list. Performance management is supported in accordance with the functionality of the MSN component NEs. The following diagram shows a typical MSN configuration:
42
A42022-L5938-G51-1-7618
Optical line IF
Waveline MN / FSP3000
Optical line IF
SL64
SMA16
SURPASS hiT7540c
Tributary IF: PDH, SDH, SONET, Data Fig. 6.1 Example of a Multi Service Node (MSN)
SURPASS hiT 7070 Node The SURPASS hiT 7070 Node offers functions very similar to the MSN. Nevertheless, the combination of the used network element types is different. It contains the following NEs: 1 FSP3000, 1 to 8 SURPASS hiT 7070, 0 to 64 SURPASS hiT 7050, 0 to 8 SLD16, 0 to 2 SURPASS hiT 7540c, An example of a node is shown in Fig. 6.2.
Optical line IF FSP3000
Optical line IF SLD16
SURPASS hiT7070
SURPASS hiT7070
SURPASS hiT7540c
SURPASS hiT7050
Tributary IF: PDH, SDH, SONET, Data Fig. 6.2 Example of a SURPASS hiT 7070 Node
A42022-L5938-G51-1-7618
43
SURPASS hiT 7070 Node Lambda The SURPASS hiT 7070 Lambda offers functions very similar to the SURPASS hiT 7070 Node. It contains the following NEs: 0 or 1 FSP3000, 1 SURPASS hiT 7070, 0 or 1 SLD16. An example of a node is shown in Fig. 6.2.
Optical line IF FSP3000
Optical line IF SLD16
SURPASS hiT7070
Tributary IF: PDH, SDH, SONET, Data
Fig. 6.3
Example of a SURPASS hiT 7070 Lambda
Network Augmentation Network augmentation refers specifically to the dynamic aspects of network restructuring. This includes migration from one protection mechanism to another, the insertion and removal of traffic-carrying network elements, the re-routing of paths, the extension of managed networks and the merging of fragmented managed networks. TNMS Core/CDM provides the following options for network augmentation: Re-routing paths: This can be implemented either directly where trafc interruption is permitted, or using SNCP mechanisms. Inserting and removing network elements: NEs can be inserted or removed by modifying port connections, even if these are used by services. Auto-link Detection With Auto-link Detection it is possible to detect physical connected ports (i.e. port connections) not yet known by TNMS Core/CDM. To enable this, each NE sends automatically a unique trace to other NEs. TNMS Core/CDM may request traces received and traces sent from/to the NEs and evaluate them by comparison to suggest automatically port connections on the operators decision. As a result TNMS Core/CDM knows all about existing port connections of all managed NEs that support auto link detection (e. g. SURPASS hiT 7070/7050/7540). Typically auto-link detection will occur in augmentation scenarios where a telecommunication provider extends or reorganises its network and adds such NEs.
44
A42022-L5938-G51-1-7618
6.1.2
Path Management
Path management includes the creation, maintenance and supervision of paths. Once the relevant network elements have been selected, paths (also known as end-to-end connections) can be established quickly and conveniently in TNMS Core/CDM Client using dedicated configuration windows. These guide the user step-by-step through connection setup. Once they have been configured, paths are then assigned to a subscriber. As a large number of ports and termination points (TPs) are administered as part of path management, it can be quite difficult to maintain an adequate overview of all configured paths. For this reason, a special hierarchy tree which only displays the TPs of the current level is implemented. Ports which are shared by two different modules are also only displayed once in the tree. In addition, special icons are implemented to enable clearer distinction between the various operational states and port connection types. TNMS Core/CDM also enables either a complete list of TPs to be displayed, or just those TPs of a particular layer. Paths can be created either automatically or manually. A combination of the automatic and manual routing mechanisms is also possible. This feature is known as hybrid routing. With automatic routing, only the endpoints must be selected. The least expensive available connections are then searched for across all network elements between these endpoints. With manual routing, the operator must configure the path step-by-step via the appropriate network elements from one endpoint to the other endpoint. Hybrid routing combines the automation and easy handling of the automatic router with the flexibility of the manual router. With hybrid routing, you can simply switch as required between automatic and manual routing during the path creation process. Paths can be configured with additional SNC protection during or after the routing process. TNMS Core/CDM supports multiple cable conduits. This function enables maximum network traffic availability because the cables for the working path and the standby (protection) path are not located in the same cable conduits. This is particularly important in the case of automatic routing. Supported Types of path Unidirectional, bidirectional and broadcast path (consisting of several unidirectional paths) can be created. The paths which TNMS Core/CDM can administer are classified according to the source and destination port, the transmission direction and type of TP, the bitrate, and the type of user data which can be transmitted (WDM, OTH, SDH, PDH, Ethernet or data). Optical server paths are also supported thus enabling enhanced handling for optical network elements and concatenated SDH path. This feature facilitates the creation of optical lines (e.g. Infinity SURPASS hiT 7550) and the routing of paths (e.g. SDH) over optical network elements. For Ethernet services scalability is supported by the use of the Generic Framing Procedure (GFP) functionality in the NEs. The bandwidth can be defined during path creation and is scalable in fix steps of 1Mbit/s. Paths are also classified according to whether both endpoints are located within the administered network (closed path), or whether one endpoint or both endpoints is/are located outside the network (half-open path or open path).
A42022-L5938-G51-1-7618
45
Path Bundle Routing A path bundle is a collection of paths used to concentrate identical operations on multiple paths into one bulk operation. For fast creation of identical paths, the provisioning of NEs often requires the configuration of path bundles, e.g. for several VC 12 paths or other using the same NEs (though bundles on layers with variable bandwidths (GFP) are not supported). Via path bundles the routing of multiple paths can be done more effectively and thus saves operation efforts. The function allows the creation and modification of path bundles, thus allows the handling of one or more path(s) belonging to a path bundle. Paths bundles need not to be created in one step and no new connection type or object type is required. Thus it can save a lot of operation efforts. On the other hand, it is the operators responsibility to select all paths belonging to a bundle for an effort-saving bulk operation. Trail-oriented Server Model In TNMS Core/CDM, a trail-oriented server model has been implemented to enable the exact definition of paths and server paths for individual network layers. This model also incorporates ports and TPs which are located on more than one transport layer. Multiple networks, and networks which are partitioned into different subnetworks or include a variety of transport technologies can now be managed via a single user interface. Enhanced service creation, manual and automatic routing are also supported. Loopback functions The loopback functions are used for physical verification of the routed paths, usually for test purposes as they are service-affecting. Two types of loopbacks are supported in TNMS Core/CDM: Port Loopback The port loopback can be done in the interface cards of the NEs (for Ethernet and PDH) by setting a special switch. Internal (inwards) and external (outwards) loopbacks with different modes are possible. Port loopback is supported by SURPASS hiT 70.., SMA4 4.x and SMA16 4.x. Matrix Loopback The matrix loopback can be done in the switching matrix of the NEs: In this case a unidirectional cross-connection is created from the source to the sink sides of the same TP to loop back the traffic (for all supported path transmission levels - as far as unidirectional CCs are supported by the NE type). Status Management for Paths paths are assigned to three different state types: Operational State It indicates whether sufficient resources are currently available to enable access to the service or path. Administrative State It indicates whether this service or path has been locked or unlocked by the administrator. Locked means that the resource is not used by the autorouter mechanism. Required Creation State (RCS) It expresses the desired state of the path, which is set by the user. Actual Creation State (ACS) It indicates whether this service or path has been locked or unlocked by the administrator.
46
A42022-L5938-G51-1-7618
The operational, administrative and creation states are shown in the Path Properties window and are also indicated by icons in the service tree. Showing Services and Paths The user interface offers various service (container for paths) and path views. The Subscribers and Services tree view in the client for example contains a complete overview of all services and paths assigned to particular subscribers. If a path is selected in this view, it can be highlighted in the network plan. TNMS Core/CDM also provides a list of all paths together with relevant attributes. This list can be filtered according to the given attributes, and also printed out or saved to a file for further processing. The details of a path can be displayed or modified both in the Path Properties window. RPR Services RPR services are handled by the RPR Manager. For principles of RPR see 2.1.3.4, for details of RPR Manager see 5.4. Path Analyser With the path analyser it is possible to check wether a cross connection matches the actual situation within the network and to set the actual creation state accordingly. This enables the operator to see, if the creation has not been successfully. There are three modes for the path analyser: automatic, manual and disabled.
6.1.3
Subscriber Management
Each new service must be assigned to a subscriber. The subscriber name can be added to a subscriber list in TNMS Core/CDM Client, together with other relevant contact data. This list can then be printed out or saved to a file for further processing. TNMS Core/CDM provides a built-in subscriber account with the name "Default subscriber". If a service is not assigned to a specific subscriber during subscriber creation, it is automatically assigned to the default subscriber.
6.2
Performance Management
Transmission quality can be monitored by PMP (performance measurement point). for any any path. Furthermore any PMP of any NE may be monitored. The performance data collected is stored on the TNMS Core/CDM Server machine in user-defined performance logs (see Section 5.3 for details). A new performance log can be created at any time, however in order to modify or delete an existing performance log, the log in question must be locked first. As the number of supported network elements increases, so too does the number of performance counters which are supported by TNMS Core/CDM. The performance parameters to be collected at the PMP can be selected individually. This minimizes the amount of data requested from a PMP when a performance log is created. Examples for performance parameters are Background Block Error and Errored Seconds (SDH), Minimum Power Level and Maximum Signal to Noise Ratio (Optical) or MultiBroadcastFrames Rx and UnicastThrougput Rx (Ethernet). A measurement and an update interval is configured for each performance measurement log. The measurement interval which determines how often data is collected can
A42022-L5938-G51-1-7618
47
be set to either every 15 minutes or every 24 hours. The update interval which determines when data is actually written to the performance data log is freely configurable. However, in order to minimize the DCN load, the update interval is always determined by the PMPs attributes. The data is evaluated in accordance with ITU-T recommendations concerning error performance (G.821 and G.826). Transmission quality can also be monitored using element managers. Via the element managers further settings can be done concerning performance management (e. g. adjusting the threshold values). For network elements managed by EM-OS, performance management is possible via the EM-OS element manager. For network elements managed by TNMS-SX, performance management is possible both via TNMS Core/CDM or directly via the TNMS-SX element manager. TNMS Core/CDM also supports Tandem Connection Monitoring (TCM). TCM is an attribute that can be set for a regular performance log. A tandem connection consists of a start PMP and an end PMP. During TCM, data for both PMPs is compared and any differences are written in the log.
6.2.1
Performance Log Export Tool (PLET)

The Performance Log Export Tool (PLET) can be run on a Windows 2000 platform either together with TNMS Core/CDM or separately. PLET is not an integral part of TNMS Core/CDM and has therefore to be installed separately. Using PLET, logs can be exported automatically so that the data they contain can be imported and used in different applications and systems. PLET is installed on the TNMS Client machine. It is possible to install PLET on more than one Client machine (i.e. it is possible to use PLET in parallel).
6.3
Fault Management
Fault management in TNMS Core/CDM comprises the following alarm handling functions: Alarm list Alarm log Display of alarm summary Display of alarm state Display of alarm severity Audible alarm External alarm output Alarm messenger for alarm summary forwarding via email/SMS All alarms are administered in the TNMS Core/CDM Server and recorded in an alarm list and an alarm log. The alarm list is accessed via the TNMS Core/CDM Client. A global alarm list contains all alarms currently raised for all NEs in the network, with the exception of alarms which have been suppressed. An individual list of current alarms can also be generated for each NE. Once an alarm has been cleared it is deleted from the alarm list. The alarm log, by contrast, is a permanent record containing all network element layer alarms, both raised and cleared. It provides a complete alarm history for the supervised network. The size of this log can be configured as required for up to one million entries.
48
A42022-L5938-G51-1-7618
The alarm log and alarm lists can also be filtered and sorted in accordance with specific criteria. If alarm notifications are received by the TNMS Core/CDM Server or TNMS Core/CDM Client, the following actions are performed. For each alarm notification received by the TNMS Core/CDM Server: the notication is forwarded to all connected TNMS Core/CDM Clients, the list of current alarms is updated, automatic correlation to services is performed, the notication is stored in the alarm log. For each alarm notification received by the TNMS Core/CDM Client: the alarm is updated, the alarm log is updated, the alarm supervision of NE icons and NE container icons is updated, the current alarm statistics for NEs and NE containers are updated, the operational state for services/paths is updated. TNMS Core/CDM supports alarm suppression and modification of alarm suppression for certain objects. This can be implemented: for all alarms relating to unused TPs for a selected NE, for secondary alarms of service endpoints, for secondary alarms of a service, for all alarms of a service, when creating/deleting cross-connections. Transient alarms where the operator is not required to take any action are suppressed in TNMS Core/CDM. These alarms may occur as a result of structuring/unstructuring of ports, for example, or due to differing CC creation/deletion times for the NEs used by the path. As far as possible such alarms will already be suppressed in the NEs in order to decrease DCN load. The main benefits of improved alarm suppression are: Transient alarms where operator action is not required are not stored in the alarm logs or displayed in the alarm list. Delays in the clearance of events for transient alarms are restricted due to the alarm toggle filter. The DCN load is decreased. The operator can localize the network element where the alarm was raised by referring to the alarm list. The NE is then highlighted in the network plan and the DCN tree. Specific symbols are used to illustrate the current access state and the highest alarm severity. These can be displayed for both the network as a whole as well as for individual network elements. This allows the user to quickly assess the importance of the alarm concerned. The alarms at the ports determine the color of the port connection line on the network plan. The user can also refresh the alarm information either for an individual network element, for all NEs in an NE container or for all NEs in a DCN. For further fault localization, the user can also call up the appropriate element manager. The element manager EM-OS, for example, provides an alarm list which can be displayed by TNMS Core/CDM. Additional functions must be performed via the element manager itself. This is simplified by screen-level integration of the EM-OS GUI. The alarm statistics window enables the operator to handle alarms conveniently. The alarm summary windows shows:
A42022-L5938-G51-1-7618
49
The number of current alarm per severity, alarms separated for unacknowledged and acknowledged state, summary counters per severity, summary counters per management state, summary counter of total alarms.
The window presents the alarm statistics in a matrix view and is updated automatically. Raised alarms can also be correlated to the corresponding paths. The operator can choose the settings Off, Normal or Extended. With normal correlation (default setting), alarms are only correlated to the endpoints of the affected path so that the operational state of the path can be determined quickly. With extended correlation, alarms are correlated to all TPs/ports of the affected path. Complete manual alarm correlation is also supported for complex paths so that all termination points, ports and modules in the current path are also included. TNMS Core/CDM provides a summary of network statistics for selected NEs. These can be forwarded via email/SMS in order to provide the operator with an overview of the current network state. The information provided by these statistics can include, for example, the number of enabled/disabled paths, PCs and faulty DCN objects. The operator can configure various settings for this function, including a notification interval and a severity threshold for the notified alarms. Alarms are forwarded using the standard SMTP protocol and implement a fixed message format which also meets the requirements for SMS (max. 142 characters, no attachments).
6.4
Security Management
Security management functions can be used to restrict access either to the TNMS Core/CDM user interface or to individual network elements. Access to the TNMS Core/CDM user interface is regulated by a user ID and a password which is initially configured in the security settings provided by the SysAdmin application (see Chapter 7). If required, the password can subsequently be changed directly in the Client application. For NEs that do not have security mechanisms, access can be restricted via the NE write access options (see Section 5.2.4). The access rights defined for users based on their user class can be further restricted to particular NE containers (domains) for which the user is responsible. In this way, the visibility of objects is also avoided, i.e. only those objects belonging to those NE containers or sub-NE containers for which the user has access permissions are displayed. More information on user permissions and object visibility is provided in Section 7.8.3. Antivirus and Firewall Software To prevent computer viruses from damaging the TNMS Core/CDM system, and to prevent infiltration and sabotage of the system by third parties, professional antivirus and firewall software should be installed. Firewall and antivirus software can be installed on all TNMS Core/CDM machines. Separate firewall servers can also be configured if required. These servers then control and monitor access to the TNMS Core/CDM Server and the TNMS Core/CDM NetServer. This solution is more expensive but is worthwhile as it offers greatly improved security.
50
A42022-L5938-G51-1-7618
7 SysAdmin Functions
The TNMS Core/CDM Server and NetServer do not have a user interface. Configuration and administration of the Server and NetServer components is implemented using the TNMS Core/CDM SysAdmin application. This application can be accessed by users who have been assigned administration rights or configuration rights. For security reasons, system administration features are not available in the TNMS Core/CDM Client application. It is possible, however, to run the TNMS Core/CDM SysAdmin and TNMS Core/CDM Client software on the same PC. Concepts Data Security: The TNMS Core/CDM Server and TNMS Core/CDM SysAdmin software ensures that all user management data (accounts, passwords, groups etc.) are transferred and stored encrypted between both recipients and secure data will only be stored on the TNMS Core/CDM Server side. Notifications: All running Clients including TNMS Core/CDM SysAdmin will be notified if errors, relevant to the TNMS Core/CDM System, occur. It will be evaluated by the TNMS Core/CDM Server which information has to be sent to a Client. Remote Access: In order to enable remote control of the TNMS Core/CDM via public telecom network it is necessary to configure the Windows 2000 Remote Access Services on Server and Client and to add appropriate entries in the Dial-Up Networking Service on the Client workstation. DCN Management: A central address administration called "DCN Management" combines the administration of subnetwork addresses as well as the administration of DCN channels and NetServers in a similar manner. Concurrent User Access: Concurrent access from different TNMS Core/CDM SysAdmin application instances to properties of a component of the TNMS Core/CDM SysAdmin's component tree is handled by a corresponding locking mechanism. The SysAdmin functions are available via the main menu, the toolbar and the SysAdmin component tree window. For details refer to the Operator Guidelines OGL and the TNMS Core/CDM Online Help.
7.1

The TNMS Core/CDM Server option in the SysAdmin menu tree provides an overview of the TNMS Core/CDM Server data (Properties and Component Info).
7.2
Alarm Settings
SysAdmin supports the following alarm handling features: Alarm messenger for alarm summary (network statistic) forwarding via email/SMS. Color Settings for alarm severity colors. General Settings for alarm objects (Toggle Filter, Default Severity, Alarm Overview). Probable Causes (user dened settings). User Dened Object Types (user defined settings).
A42022-L5938-G51-1-7618
51
The alarm severity can be both displayed and configured for user-defined probable causes. In order to configure the alarm severity, the operator must define a severity profile. This is stored in the TNMS Core/CDM database.
7.3
Cost Factors
Three cost factor levels can be can be configured in SysAdmin. If these are assigned to the port connections, the automatic router can select the least expensive route first.
7.4
Database
SysAdmin provides a comprehensive range of database functions. These functions are only available to system administrators, and include database analysis to ensure data consistency and integrity, backup and recovery utilities for data restoration in the case of system failure, and options for importing/exporting network configuration data. TNMS Core/CDM system data is distributed across a number of databases (see Chapter 3 for details). Backup TNMS Core/CDM provides a backup facility which enables the administrator to maintain several backup sets for the TNMS Core/CDM Server database, TNMS Core/CDM Config database and TNMS Core/CDM Log database for later restoration. Utilization of an own backup server is supported. The operator can either implement the backup manually, or can configure a scheduled backup to be saved to a particular directory at a particular time. During the backup procedure, an analysis function checks the referential integrity and data consistency of each backup set. A browse function is also provided so that the administrator can obtain an overview of existing backup sets. As part of a manual or scheduled backup operation, backup sets in the dedicated directory can be copied by the operator to a SCSI DAT streamer using the Windows 2000 backup utility. This can be completed once a day, preferably at a time of low system and user activity. Creating backup sets, configuring scheduling of backup sets and analyzing a database is possible regardless of whether the server is started or stopped. Restore Stopping the TNMS Core/CDM Server activates a restore option which the operator can use to restore a previously-created backup set from the dedicated backup directory. This operation can only be completed offline and is used to support system migration, for example. To prevent inconsistent configuration data, the option for NetServer deactivation should also be selected. Once the restore operation has been completed, the TNMS Core/CDM Server and TNMS Core/CDM NetServer have to be restarted. Restarting the TNMS Core/CDM Server opens the restored databases and restores the backed-up configuration. Data Replication To minimize the loss of data after a system component has broken down, the TNMS Core/CDM system provides an internal database recovery mechanism for all TNMS Core/CDM databases. This mechanism automatically implements an internal backup at regular intervals using a previously-created backup copy of the database. The database
52
A42022-L5938-G51-1-7618
itself is not affected and normal system functionality is still available while database recovery is in progress. Should a software failure occur, the system uses these database backups to restart the system. TNMS Core/CDM also provides an incremental data replication function which continuously replicates the databases of the active server system to the standby system. Should the active server fail, the operator can then switch to the standby system. However, open transactions and queued jobs are lost. Data Import/Export TNMS Core/CDM supports a variety of convenient options for importing/exporting using XML. Service layer information, configuration data, alarm logs, network event logs, system message logs and performance logs can be exported. Scheduled and unscheduled export is possible. When using scheduled export, time, cycles and destination can be defined. In any case, defining the objects to be exported is possible . The XML files can be viewed with the Internet Explorer. Automatic access to logfile data is also available via the OLE-DB interface (objectlinking and embedding database) for active data objects. This interface can also be used to export data for processing by external tools (e. g. with the Performance Log Export Tool, a scheduled export of log data is possible). Log Configuration Several different log types are maintained by the system. The space available on the hard disk for TNMS Core/CDM log data can be set using this option. The system message log can then be configured to include a specific level of entries, for example, and the network event log configured to include particular types of network event. Display facilities are also provided for the security event log and operator input log (here, configuration is also possible) in the main SysAdmin menu. For more information on log management and log types, see Chapter 5.
7.5
Date / Time
The system date and time configured for the TNMS Core/CDM Server can be viewed and adjusted as required. The Server date and time can also be set to the date and time of the PC where SysAdmin is installed.
7.6
License Manager
Licenses are mandatory if you wish to install and operate the TNMS Core/CDM system. The following types of licenses exist: Basic license, NE licenses, Feature licenses. A list of the available licenses can be viewed, and also imported and exported as *.xml files. Number and kind of licenses have to be planned individually for each customer. The license keys are delivered as XML files and can be imported conveniently in TNMS Core/CDM. TNMS Core/CDM supports download of license key files to a network element via LCT/Element Manager (e.g. for SURPASS hiT 70..).
A42022-L5938-G51-1-7618
53
7.7
NE Inscription Settings
The network element inscription labels shown in the Network View in TNMS Core/CDM Client can be adjusted here. The ID name of the network element appears by default, however other information such as the NE name, NE type, location, or user-defined texts entered in the network element property pages can also be included as required.
7.8
Security
Special security features are provided by SysAdmin to regulate access to the TNMS Core/CDM interface. An authorized user must have an account with a valid user ID and password.
7.8.1
Account Policy
Global account settings which apply for all user accounts are set under Account Policy. These include specific password restrictions and options for account lockout if an incorrect password is entered.
7.8.2
User Management
Under User Management, existing user configurations can be changed and new users set up by the administrator. The level of user access is determined by the user class, user properties, and password restrictions set by the administrator for the user in question. The user class is of particular significance as it determines the range of functions which a user is permitted to perform: Supervision: the user can execute supervision functions and start element manager applications with read-only access. Maintenance: the user can execute supervision functions and start element manager applications with read-only access. The user can also acknowledge alarms and congure performance logs to monitor system performance. Operation: the user can perform maintenance functions and create, modify or delete services. Conguration: the user can perform operation functions and conguration management functions. Administration: the user can perform conguration functions and all administration management functions. In other words, the user has unrestricted access. If required, the administrator can also assign a user to one or more user groups. The access rights defined by the individual user classes remain valid, except where the user is assigned to the TNMS Core/CDM Superuser group. A user group can be authorized to access one or more NE containers each of which may represent a network domain. However, each individual NE container can only be assigned one user or user group. The users access rights are limited to the NE container assigned and the NEs which this container comprises.
54
A42022-L5938-G51-1-7618
7.8.3
Container Access
Users Responsibility for an NE Container Access rights to containers is regulated on a per-user basis. This means that users do not have access to objects included in NE containers for which they do not have access permissions. Specific NE container access levels are defined as follows: Responsible: The user is responsible for this NE container. An NE container of this type is visible for the user concerned. Child responsible: The user is only responsible for a child NE container within this NE container, and not for this NE container as a whole. An NE container of this type is visible for the concerned user. Not responsible: The user is not responsible either for this NE container, child NE containers contained therein, or for the parent container of the NE container in question. An NE container of this type is not visible for the user concerned. The container visibility can also be set to non-restricted. In this case all objects are visible independent of the NE container visibility. Object Visibility Related to an NE Container Restricted access rights to NE containers may result in restricted visibility of the following objects: Network objects, e.g. a path or a port connection Object lists, e.g. list of port connections, list of TPs, list of services, list of protection groups Logs, e.g. network event log, system message log, performance log, alarm log Alarms, i.e. the alarm log, current alarm list, and service/port connection-related alarm list The security event log, operator input log and list of DCN objects are, however, visible at all times. An object is also generally visible if at least one part of the object lies in an NE container for which the user is responsible.
7.9
Northbound Interfaces
Optional northbound interfaces can be used to connect the TNMS Core/CDM system with an umbrella network management system. TNMS Core/CDM supports two types of northbound interfaces: TCOA and SNMP. For details see Section 8.1.
7.10
DCN Management
DCN management comprises the definition and administration of NetServers, DCN channels and network elements. These DCN objects are displayed in a hierarchical tree and can be added, deleted and modified as required. They can also be moved to another parent element, e.g. network elements can be moved from one NetServer to another NetServer. The current connection state is also displayed for each DCN object.
A42022-L5938-G51-1-7618
55
Some network element types may group or address further network elements. These network element types are known as node NEs. The following node NE types can perform this function: SISA network node (for PDH network elements), Multi-NE Devices.
7.10.1
NetServer
This object handles the connection to one or more different network elements, is the direct source for all NE data to be uploaded by the TNMS Core/CDM Server, loads the NE data required by the TNMS Core/CDM Server to the NetServer memory and maintains data consistency while NetServer is connected to the NE, acts as an mediation device by standardizing the data transferred from the different NE interfaces to the TNMS Core/CDM Server and vice versa.
7.10.2
DCN Channels
The DCN channels connect the network elements directly or via an external element manager to the TNMS Core/CDM NetServer (see Fig. 2.1). The DCN channels are used by the operator to group NEs of the same DCN channel type. TNMS Core/CDM supports the following DCN technologies: DCN Interface ELI EMOS-SLI MSN QB3M Physical Interface Ethernet (TCP/IP) RS232 Protocol ELI SLI Network Elements/ Element Managers SXA, SXD EMOS NEs, e.g. SLxx, SMAxx, etc. NEs supported by MSN SDH e.g. SMA1/4, SMA4/1 SDH e.g. SL16 WDM e.g. SURPASS hiT 7540 / 7550 PDH (e.g. FMX, CMX) with connection node type SISAGKE only Generic SNMP, ULAF+, and e. g. Waveline EL, FSP2000, FSP3000 Universal objects e. g. SXC e.g. SN16000, NetViewer NME / Radio NEs
depends on type of NEs within MSN Ethernet (OSI) QD2 QST Q3
QD2-SISA
Ethernet (TCP/IP)
SISA
SNMP
Ethernet (TCP/IP)
SNMP
UNO+ TCOM (G7 V2.0.0) TCOM (TMF 814 V2.1) Table 7.1
None Ethernet (TCP/IP) Ethernet (TCP/IP)
None TCOI TCOI
DCN Interfaces
56
A42022-L5938-G51-1-7618
8 Optional Software Components

8.1
8.1.1
Northbound Interfaces
TCOA
TCOA (TMF CORBA Agent) is an optional module which implements the TMF CORBA Interface (TCOI), a standardized, multi-technology interface for the management of multi-vendor transport networks. TCOA enables the TNMS Core/CDM Server to connect to third-party TMF CORBA Managers (TCOM) and should be installed if TNMS Core/CDM is to be connected to an umbrella network management system. WDM and SDH network elements are supported, however support is not available for PDH NEs or SISA-V DCN components.
8.1.2
SNMP
The SNMP proxy component provides an SNMP-based interface to the network layer of the TNMS Core/CDM system and enables access to the TNMS Core/CDM management information base (MIB). It facilitates the integration of TNMS Core/CDM with umbrella fault management systems which supports the SNMP protocol and which recognizes the TNMS Core/CDM MIB can read object properties and receive traps from the TNMS Core/CDM element management layer and network management layer. The SNMP proxy is a read only interface. Once it has been configured under SysAdmin, it can be activated or deactivated as required.
8.2
8.2.1
Southbound Interfaces
TCOM
TCOM (TMF CORBA Manager) is an optional southbound interface connecting network elements or other vendors element management systems (EMSs, e. g. NetViewer) and NEs managed by them. Two types of the TMF CORBA interface (TCOI) are realized by TCOM, the TMF814 and Go7.
8.3
Multi Server CDM

For information on the optional Multi Server CDM software please refer to the following chapters.
A42022-L5938-G51-1-7618
57
9 Multi Server CDM: Hierarchical Distributed Network Management

i
Multi Server CDM is available only on customers request. Multi Server CDM (Cross Domain Manager) is used as a superior management system for access, edge, metro, core and backbone networks. The main applications which cannot be covered by one single TNMS Core system are: managing very large networks (high number of network elements) managing networks which are devided into several independent physical domains for regionalization purposes. Fig. 9.1 shows the general structure of a transmission network managed by Multi Server CDM. The subnetworks are connected to Multi Server CDM via the DCN management interfaces.
Multi Server CDM Integrated Subnetwork Manager (TNMS Core/CDM)
Management interface Subnetwork TNMS Core/CDM 1 Subnetwork 1
DCN
Subnetwork TNMS Core/CDM n Subnetwork n Fig. 9.1 General Structure of a Multi Server CDM Network Subnetwork functions are executed via the subnetwork managers provided by the Multi Server CDM system. Subnetworking is supported by the ability of cascading TNMS Core/CDM Servers. The managed networks of several TNMS Core Servers (Domain Managers) are exported by the northbound interfaces (SNIF+) and used by the subnetwork controllers to map the subnetwork information into a MS CDM Server (Cross Domain Manager) southbound
58
A42022-L5938-G51-1-7618
interface. This is used to manage multiple subnetworks in a MS CDM Server. Subnetwork boundaries are always domain boundaries. Subnetwork Handling In the Multi Server CDM DCN components tree and in the network plan each network managed by one single TNMS Core system is displayed as a subnetwork. Global Data Lists With Multi Server CDM, lists with global data of all subnetworks (paths, subscribers, alarms, NEs) give the operator an overview of the whole network. The lists can be filtered in several ways to get a better clearness in case of huge amount of data. Security Management The TNMS security concepts are applied for a distributed environment. For this, a special user class "Multi Server CDM" must be administered in the TNMS Core. The security of the IP connection and the network of a distributed TNMS environment must be provided by the customer by measures like exclusive networks, firewalls etc.
A42022-L5938-G51-1-7618
59
10 Multi Server CDM: System Overview

i 10.1
Multi Server CDM is available only on customers request.
System Architecture
Multi Server CDM is a scalable multi-user system with a client/server architecture comprising several industry standard PCs with the Windows 2000 operating system and various software applications. External devices such as printers, tape units and remote clients can also be connected but are not dealt with here.
MS CDM Client MS CDM SysAdmin
MS CDM Client MS CDM SysAdmin
Client PCs
MS CDM Server MSCDM SysAdmin MS CDM NetServer
Server PC
TNMS Core/CDM
TNMS Core/CDM n
Fig. 10.1
Multi Server CDM Large System
The Multi Server CDM software comprises the Client, SysAdmin, Server and NetServer applications. Client and SysAdmin are installed on a client PC. To support distributed operation of the network, up to 25 Client and 10 SysAdmin installations can be managed simultaneously. Concurrent access to network resources is regulated by the server PC so that only one operator at a time is granted write access to a subnetwork. The Server software is installed on a server PC. A SysAdmin installation on the server PC together with an additional monitor is also recommended as this enables administration of the Multi Server CDM system to continue even if the data flow between the client and server PC is interrupted. The NetServer software is usually also installed on the server PC.
60
A42022-L5938-G51-1-7618
10.2
Hardware Components
The hardware for the Multi Server CDM is the same as for TNMS Core/CDM. Please see chapter 3.2.
A42022-L5938-G51-1-7618
61
10.3
Software Components
Fig. 10.2 shows the Multi Server CDM software architecture.
MS CDM Client components Element manager Element manager
MS CDM SysAdmin components Import / Export files (XML)
Export files (TSF)
MS CDM Client Frame Network management user interface
MS CDM SysAdmin Frame System administration user interface
MS CDM Server components
TNMS RegDB
TNMS NmlDB
MS CDM Server
TNMS LogDB
MS CDM NetServer Frame
TNMS EmlDB
EML package SN controller
EML package SN controller MS CDM NetServer components
DCN interfaces Subnetwork 1 Subnetwork n
Fig. 10.2
Software Components (simplified overview)
62
A42022-L5938-G51-1-7618
10.3.1
MS CDM Netserver
MS CDM Netserver operates as a mediation device for the DCNs connected to it. It processes large volumes of data imported from the DCN and relays this information to the MS CDM Server in compressed form. The NetServer supports all SN-specific functions, except for the subnetwork managers included with MS CDM Client. The main parts of the NetServer are the NetServer frame component, the EML packages and the TNMS EmlDB. NetServer Frame Component The NetServer frame is essentially a proxy for the TNMS Server. It facilitates the management of EML packages as well as remote communication between TNMS Server components and TNMS NetServer components. EML Packages A EML package is an installation package, which contain all relevant components (e.g. the SN controller) needed to run a subnetwork within Multi Server CDM. SN Controllers The main task of an SN controller is to convert SN-specific management interfaces to a simple internal Multi Server CDM subnetwork management interface. In this way, network layer management in the MS CDM Server only receives the necessary information from the subnetwork management layer. MS CDM Netserver Database The NetServer also includes a MS CDM Netserver database (TNMS EmlDB) where relevant subnetwork data is temporarily stored.
10.3.2
MS CDM Server
MS CDM Server is the central component of Multi Server CDM and controls the following management functions for the network management layer and subnetwork management layer: Fault Management Conguration Management Security Management Data relating to these processes is written to various databases. The config database (also known as the Multi Server CDM registry) stores general data, the server database stores network management data and the log database stores log and list data. More information on Multi Server CDM databases is provided in Section 10.4. As well as coordinating DCN management functions such as the administration of subnetwork addresses, DCN channels and NetServers, the MS CDM Server also supports interfaces to MS CDM Netservers and to MS CDM Clients. Up to 25 Client, 10 SysAdmin and 10 NetServer installations can be connected to the MS CDM Server at the same time.
A42022-L5938-G51-1-7618
63
10.3.3
MS CDM Client
The MS CDM Client is responsible for the following functional layers: Network Management User Interface: The MS CDM Client user interface provides the operator with several network views which contain graphical and textual information about current alarms, states and resources. The main GUI contains the network map window, several list and log windows (alarm list, network event log, system message log, etc.) and specific dialog windows associated to the functionality of the Client. Subnetwork Manager / Network Manager Application Interface: A corresponding subnetwork manager can be started for each subnetwork with a simple double-click (e.g. on the subnetwork symbol within the network plan). The MS CDM Client starts the corresponding process and provides the interface of the associated SN controller to the subnetwork manager. Subnetwork manager applications provide full access to all SN data and also enable the configuration and control of SN behavior. In this way, depending on the actual SN type, performance values and alarms can be requested, and the backup and restore of configuration and other data initiated. Network Management Data Export: Data export is provided in the MS CDM Client to export data for external evaluation. This enables the operator to export the content of each list and log to a file. This information is written to tab separated format (*.tsf) files. Several tools and standard applications (e. g. MS Access or MS Excel) can read these files. Note: Detailed functional information on MS CDM Client is provided in Chapter 6.
i
10.3.4
Detailed operating information on MS CDM Client is provided in the Operator Guidelines (OGL) and in the online help.
MS CDM SysAdmin
MS CDM SysAdmin provides administration functions for all Multi Server CDM components in the component tree, as well as various monitoring (e.g. client monitoring, DCN monitoring) and log (e.g. notification log, system message log) windows which can be opened in the main window. TNMS Import / Export Interface MS CDM SysAdmin supports an interface which allows the import (unscheduled) and export (scheduled and unscheduled) of data using XML. Note: Detailed functional information on SysAdmin is provided in Chapter 7.
Detailed operating information on SysAdmin is provided in the Operator Guidelines (OGL) and in the online help.
64
A42022-L5938-G51-1-7618
10.4
Databases
Multi Server CDM uses the following databases: TNMS Registry Database (TNMS RegDB) TNMS Network Management Layer Database (TNMS NmlDB) TNMS Logs and Lists Database (TNMS LogDB) TNMS Element Management Layer Database (TNMS EmlDB) The TNMS RegDB stores general Multi Server CDM configuration data such as: Security policies User group denitions User account data Properties of TNMS components Properties of DCN objects Background bitmaps to be used for network maps The TNMS RegDB is managed by the MS CDM Server and is opened as soon as the Server is loaded. The TNMS RegDB can be backed up, restored, replicated and migrated. The TNMS NmlDB permanently stores the following objects: Subscribers Subnetworks The TNMS NmlDB is managed by the MS CDM Server and is opened when the Server is started. The TNMS NmlDB can be backed up, restored, replicated and migrated. The TNMS LogDB stores the following tables: Current alarm list (empty) Network event log Security event log System message log User-dened object types (empty) User-dened probable causes (empty) Task orders Global NE list The TNMS LogDB is managed by the MS CDM Server and is opened when the Server is started. The TNMS LogDB can be backed up, restored, replicated and migrated. More information on log management is provided in Section 5.3. The TNMS EmlDB is used as a file cache by some SN controllers that cannot store the complete SN data. The TNMS EmlDB cannot be backed up or migrated.
10.5
Operating System
All TNMS components require the Windows 2000 operating system. For MS CDM Client, MS CDM SysAdmin and MS CDM Netserver Windows 2000 Professional is recommended. The MS CDM Server should run on Windows 2000 Server.
A42022-L5938-G51-1-7618
65
10.6
External Interfaces
Multi Server CDM supports the following external interfaces: Name SNIF+ Used by TNMS Core Server Attributes Internal DCOM Description SNIF+ interface. Exposes a subnetwork view of the network managed by a TNMS Core server. OLE-DB interface. This interface is a standard Microsoft database interface for accessing tabular data. Active read-only access is enabled for lists and logs. TSF list export interface. Interface for exporting the contents of lists and logs an *.tsf file.
OLE-DB
Open OLETools for DB DCOM external data evaluation Customers Open TSF
TSF
Tab. 10.1
External Interfaces of Multi Server CDM
10.7
System Availability
The standby concept is based on the principles defined for TNMS Core and extended to cover the Multi Server CDM System. Protection is provided against outages of separate servers, such as protection to cover disaster conditions by switch over to a standby control centre. The standby concept is based on data replication, to update the databases on the standby systems. In case of a failure on the main system, the operator must initiate the switch to the standby system manually. The remote standby in a hierarchical Multi Server CDM system covers several scenarios which are possible depending on the component that fails (here, only principles are described): NetServer failure in a TNMS Core system: The failed NetServer can be manually replaced by a cold standby NetServer. There is no additional effort required on the Multi Server CDM system. Server failure in a TNMS Core system: The operator must "start" the TNMS Server on the TNMS Core standby Server machine. The TNMS starts with the replicated database and connects to the running NetServers. NetServer Failure in a Multi Server CDM system: Analogous behaviour as for NetServer failure in a TNMS Core system. The failed CDM NetServer can be manually replaced by a cold standby NetServer. There is no additional effort required on the TNMS Core system. Server failure in a Multi Server CDM system: Analogous behaviour as for Server failure in a TNMS Core system. The operator must "start" the TNMS Server on the TNMS standby CDM Server machine. The TNMS starts with the replicated database and connects to the running CDM NetServers. Next to the remote standby, local standby is supported optionally. For this, a single high end server with high performance and reliability as scalable multi-processor architec-
66
A42022-L5938-G51-1-7618
ture, hot swap facilities for disks, power supplies, fans, etc. and support of RAID is required.
A42022-L5938-G51-1-7618
67
11 Multi Server CDM: Installation Notes

i
Multi Server CDM is available only on customers request. The Multi Server CDM software includes a number of applications and feature components. It is supplied on CD-ROM which includes a convenient master installation program for installing the Multi Server CDM software components on the users hard disk, modifying an existing installation by adding or removing selected components or subcomponents, removing the Multi Server CDM software completely from the users hard disk.
i 11.1
Full commissioning and startup details can be found in the Installation Manual (IMN).
Licensed Software
In order to install the Multi Server CDM software, the corresponding licenses are required. Depending on functionality, the TNMS software is divided into several software packages, which are provided on separate CD-ROMs with individual licenses.
Various software products referred to in this manual have been licensed by Siemens AG and are provided together with the Multi Server CDM software. Any questions concerning these products should therefore be directed to Siemens AG rather than to the original manufacturer. Questions regarding software products such as virus scanners, which may run with Multi Server CDM software, but which are not provided, sold or purchased by Siemens AG, should be addressed directly to the manufacturer in question.
68
A42022-L5938-G51-1-7618
12 Multi Server CDM: Functional Overview

i 12.1
Multi Server CDM is available only on customers' request.
Main Features
The main features of Multi Server CDM are summarized below: Hierarchical distributed network management for networks with WDM, OTH, SDH, PDH, Ethernet and data interfaces Fault, conguration and security management Import (unscheduled) / export (scheduled and unscheduled) for conguration data and logs Visual network representation, intuitive operator guidance, detailed and contextsensitive online help Scalable system architecture Multi-user capability (up to 25 clients can be connected to the server) High system availability Remote control via public networks Software updates without data loss/trafc interruption Subscriber management Enhanced security management Standby system These functions are available via the Client and SysAdmin interfaces. For more information, see Chapter 6 and Chapter 7.
12.2
12.2.1
Basic Operation
MS CDM Server
Starting MS CDM Server MS CDM Server can be either be started automatically or manually by the administrator. Once it has been started, MS CDM Server is linked to all active MS CDM Netservers. Stopping MS CDM Server MS CDM Server can be stopped by the administrator. When the server is stopped, all connected client PCs are notified and any further login attempts rejected. Once all clients have been disconnected from the MS CDM Server, the NetServers are also shut down and the Multi Server CDM databases closed. The MS CDM Server can also be stopped independently of the NetServers, for example if maintenance work is required. Concurrent Access Concurrent access to multiple MS CDM Clients is managed by the MS CDM Server as follows: Network conguration and alterations to icons in the network editor are only permitted for one MS CDM Client at a time. Subscriber information can only be changed by one operator at a time. Up to 25 client installations can be operated simultaneously.
A42022-L5938-G51-1-7618
69
Distribution of Date / Time Multi Server CDM provides a manual date and time synchronization function for all managed Multi Server CDM components. The date and time are also distributed to all active NetServers and connected client PCs, with the exception of NetServer or Client installations running on the MS CDM Server machine.
12.2.2
MS CDM Netserver
Activating/Deactivating MS CDM Netserver A MS CDM Netserver and each DCN object managed by the NetServer can have the activation state activated or deactivated. If a MS CDM Server is started, connections will be established for all activated NetServers.
12.2.3
MS CDM SysAdmin
Starting MS CDM SysAdmin To access the Multi Server CDM system, you must first log onto the SysAdmin software. Once you have logged on, you can start the MS CDM Server using the icon provided in the toolbar. Once the server is started, you can also access the TNMS Client software. More information on TNMS SysAdmin is provided in Chapter 7.
12.2.4
MS CDM Client
Starting a MS CDM Client Once the MS CDM Client has been started, the operator can enter the login data. Functions authorized by the operators user class can now be accessed (see Section 7.8.2). The Client contacts the Server and requests alarm the data required for mapping the network. If complete data is not available for certain subnetworks, these are shown as unavailable on the user interface by a box containing two question marks. The first time the Client is started, only the notifications log is opened. In subsequent sessions, log windows which were opened when previous sessions were shut down are also opened. The entries from previous sessions are then displayed. If the MS CDM Server is not available, an error message is displayed. Starting Subnetwork Manager Applications The subnetwork manager applications are started via MS CDM Client. A data connection is established to the relevant SN which allows the user to execute required functions directly at the SN. Terminating a MS CDM Client Session A MS CDM Client session is terminated when the user logs off. All windows are closed and access is only provided to the login function.
70
A42022-L5938-G51-1-7618
12.3
Log Management
In Multi Server CDM, specific operator activities as well as random actions and events are stored in log files on the MS CDM Server. The log contents can be printed out, saved to a file or evaluated via a standard OLEDB/ADO interface.
12.3.1
Log Classes
In Multi Server CDM, each log is assigned one of the following classes: Permanent Non-persistent Permanent logs are fixed, global logs administered by the Multi Server CDM system. The operator can, however, specify certain attributes such as the type of event to be included, maximum log size, etc. Non-persistent logs are maintained by the MS CDM Client and MS CDM SysAdmin and only exist for the duration of a client session. The log content is deleted when the client session is terminated.
12.3.2
Log Types
The following log types are possible in Multi Server CDM: Log Type Multi Server CDM Client X X X X X X Multi Server CDM SysAdmin X Log Class
System message log Network event log Security event log Notifications log Operator input log Table 12.1 Log Types
Permanent log Permanent log Permanent log Non-persistent log Non-persistent log
The system message log contains a chronological list of relevant administrative events. Critical events are indicated at the user interface. The network event log documents configuration changes to the network management layer. It includes actions initiated or triggered directly by the network or individual network components. The security event log documents relevant security events in Multi Server CDM. It provides information such as the event type, event severity and the object affected. The notifications log only documents events which are relevant for the current Client session, for example communication errors. An individual operator input log can be created for each operator. Information relevant to the operator, such as executed actions, is collected from the permanent logs and presented in a report window. The operator input log is a snapshot, and is therefore not updated automatically.
A42022-L5938-G51-1-7618
71
13 Multi Server CDM: Client Functions

i 13.1
Multi Server CDM is available only on customers' request.
Task Order Management

With the task order management Multi Server CDM is able to execute functions affecting several TNMS Core systems. Task Order Modelling The task order entry interface enables e. g. the MS CDM Server to request specific services from the TNMS Core Servers. Task orders are used for operations, which may require human interaction for execution (e.g. manual routing). Operations The tasks are described by their attributes. The life cycle of a task order is modelled by its states. Only generic task orders are possible. Notifications Each observer (e.g. Multi Server CDM) is notified about progress related to the execution of a task order. If related to an explicit request the notification can be mapped to this request. Task orders that have reached final state are retained for some time. Garbage collection will remove task orders exceeding a certain number to be chosen for each type of task by the administrator. Based on this and considering the timestamp of their final transition, the eldest task orders will be removed at an unspecified point of time. Explicit Requests Information about existing task orders may be requested. The information returned will depend on the type of task order and will usually not comprise details about the subnetwork or network layer objects that the task order is referring to. This capability is implicitly used by the software, a user does not have to (and cannot) issue explicit requests. Task Order Entry Interface The Multi Server CDM SNIF+ interface comprises the task-order entry interface.
13.2
Conguration Management
Configuration management is an umbrella term for the tasks involved in the organization and modification of subnetworks and subscribers.
13.2.1
Network Topology Management

Network topology management is concerned with the process of preparing and enabling Multi Server CDM for network management operation (e. g. creating subnetworks).
72
A42022-L5938-G51-1-7618
Subnetworks represents physical subnetworks that can be managed directly via an SN controller in the NetServer and are therefore also managed entirely by Multi Server CDM.
13.2.2
Subscriber and Service Management

Creating a subscriber within Multi Server CDM Multi Server CDM provides a built-in subscriber account with the name "Default subscriber". A new subscriber name can be added to a subscriber list in MS CDM Client, together with other relevant contact data. This list can then be printed out or saved to a file for further processing. Subscriber Management within distributed TNMS environment In large networks with one Multi Server CDM system and several TNMS Core systems it is necessary to synchronize the subscriber data for all TNMS Core systems. The subscriber data are stored persistently in the Multi Server CDM system and in all TNMS Core systems. These data are synchronised when connecting to the Multi Server CDM and every time the user changes data. Global NE List and Global Path List In Multi Server CDM, a list for all NEs and a list for all paths in all subnetworks is available. The data of the global NE list are stored persistently in the Multi Server CDM system. These data are synchronised when connecting to the Multi Server CDM and every time the user changes data. The data for the global path list are retrieved from the TNMS Core systems on user demand. The operator has to enter a scope indicating which data to be displayed. The path data are not stored persistently in the Multi Server CDM system. The normal TNMS backup, restore, replication mechanisms are applied.
13.3
Fault Management
Operational States and Alarm Overview In order to provide an overview of the operational states of all paths managed in a TNMS Core and all raised alarms for each TNMS Core the Path Operational State and Alarm State Overview window is provided with Multi Server CDM. The window contains three folders with a graphical Overview, a Alarm States list and a Path States list. The graphical overview contains three bar diagrams which displays a statistic about All Alarms, Unacknowledged Alarms and Paths for all managed subnetworks. Furthermore a table is shown, containing the sum of unacknowledged/acknowledged and the total number of alarms per severity and the number of disabled/enabled paths and the total number of paths. By default the statistic gives an overview of all managed subnetworks. It can be filtered for each subnetwork.
A42022-L5938-G51-1-7618
73
Within the Alarm States list and the Path States list further detailed informations are given concerning all subnetworks. The Alarm States list and the Path States list can be opened several times with different filter settings (at least 5 times per client). The window is updated automatically. Global Alarm List In addition, a list of all alarms in all subnetworks is available. The data for the global alarm list are retrieved from the TNMS Core systems on user demand. The operator has to enter a time range indicating which data to be displayed. The alarm data are not stored persistently in the Multi Server CDM system. The normal TNMS backup, restore, replication mechanisms are applied.
13.4
Security Management
Security management functions can be used to restrict access to the Multi Server CDM user interface. The access is regulated by a user ID and a password which is initially configured in the security settings provided by the SysAdmin application (see Chapter 7). If required, the password can subsequently be changed directly in the Client application. For the access from Multi Server CDM to the TNMS Core systems, the Multi Server CDM first must logon at each of the TNMS Core systems. For this reason a special user account in the TNMS Core systems must be administered. The access rights for a user account on TNMS Core and on Multi Server CDM may be different (e.g. it is possible that a user has operation rights on Multi Server CDM and administration rights on TNMS Core). Antivirus and Firewall Software To prevent computer viruses from damaging the Multi Server CDM system, and to prevent infiltration and sabotage of the system by third parties, professional antivirus and firewall software should be installed. Firewall and antivirus software can be installed on all Multi Server CDM machines. Separate firewall servers can also be configured if required. These servers then control and monitor access to the MS CDM Server and the MS CDM Netserver. This solution is more expensive but is worthwhile as it offers greatly improved security.
74
A42022-L5938-G51-1-7618
14 Multi Server CDM: SysAdmin Functions

i
Multi Server CDM is available only on customers request. The TNMS Server and NetServer do not have a user interface. Configuration and administration of the Server and NetServer components is implemented using the TNMS SysAdmin application. This application can only be accessed by users who have been assigned administration rights. For security reasons, system administration features are not available in the TNMS Client application. It is possible, however, to run the TNMS SysAdmin and TNMS Client software on the same PC. Concepts Data Security: The MS CDM Server and MS CDM SysAdmin software ensures that all user management data (accounts, passwords, groups etc.) are transferred and stored encrypted between both recipients and secure data will only be stored on the MS CDM Server side. Notifications: All running Clients including MS CDM SysAdmin will be notified if errors, relevant to the Multi Server CDM System, occur. It will be evaluated by the MS CDM Server which information has to be sent to a Client. Remote Access: In order to enable remote control of the Multi Server CDM via public telecom network it is necessary to configure the Windows 2000 Remote Access Services on Server and Client and to add appropriate entries in the Dial-Up Networking Service on the Client workstation. DCN Management: A central address administration called "DCN Management" combines the administration of subnetwork addresses as well as the administration of DCN channels and NetServers in a similar manner. Concurrent User Access: Concurrent access from different MS CDM SysAdmin application instances to properties of a component of the MS CDM SysAdmin's component tree is handled by a corresponding locking mechanism. The SysAdmin functions are available via the main menu, the toolbar and the SysAdmin component tree window. For details refer to the Operator Guidelines OGL and the Multi Server CDM Online Help.
14.1
TNMS Server
The TNMS Server option in the SysAdmin menu tree provides an overview of the MS CDM Server data (Properties and Component Info).
14.2
Alarm Settings
SysAdmin supports the following alarm handling features: Alarm messenger for alarm summary (network statistic) forwarding via email/SMS. Color Settings for alarm severity colors. General Settings for alarm objects (Toggle Filter, Default Severity, Alarm Overview).
A42022-L5938-G51-1-7618
75
14.3
Database Administration
SysAdmin provides a comprehensive range of database functions. These functions are only available to system administrators, and include database analysis to ensure data consistency and integrity, backup and recovery utilities for data restoration in the case of system failure, and options for importing/exporting network configuration data. Multi Server CDM system data is distributed across a number of databases (see Chapter 3 for details).
14.3.1
Backup/Restore in a Distributed TNMS Environment

In a distributed TNMS environment the data of each TNMS Core and the Multi Server CDM are backed up separately. The TNMS Core/CDM Backup Server component is installed on the target machine and receives and delivers all backup-sets and matching meta-data. TNMS Core/CDM Backup Sets Backup-sets represent a snapshot of TNMS Core/CDM databases. It is possible to restore backup-sets on a different machine than where it was created. This is done, e.g. in case of a stand-by or when a new installed system replaces a previous system. TNMS Core/CDM Backup Server The TNMS Core/CDM Backup Server encapsulates backup and restore functionality like collecting and delivering the backup databases and matching meta-data. The TNMS Core/CDM Backup Server avoids Windows security problems that occur by simple file copies. Furthermore, the TNMS Core/CDM Backup Server relieves the TNMS Core/CDM Server from performance intensive tasks like analyzing and migrating backup databases.
14.3.1.1
Details of Backup/Restore in Multi Server CDM

Backup Multi Server CDM provides a backup facility which enables the administrator to maintain several backup sets for the MS CDM Server database, Multi Server CDM Config database and Multi Server CDM Log database for later restoration. Utilization of an own backup server is supported. The operator can either implement the backup manually, or can configure a scheduled backup to be saved to a particular directory at a particular time. During the backup procedure, an analysis function checks the referential integrity and data consistency of each backup set. A browse function is also provided so that the administrator can obtain an overview of existing backup sets. As part of a manual or scheduled backup operation, backup sets in the dedicated directory can be copied by the operator to a SCSI DAT streamer using the Windows 2000 backup utility. This can be completed once a day, preferably at a time of low system and user activity. Creating backup sets, configuring scheduling of backup sets and analyzing a database is possible regardless of whether the server is started or stopped.
76
A42022-L5938-G51-1-7618
Restore Stopping the MS CDM Server activates a restore option which the operator can use to restore a previously-created backup set from the dedicated backup directory. This operation can only be completed offline and is used to support system migration, for example. To prevent inconsistent configuration data, the option for NetServer deactivation should also be selected. Once the restore operation has been completed, the MS CDM Server and MS CDM Netserver have to be restarted. Restarting the MS CDM Server opens the restored databases and restores the backed-up configuration.
14.3.2
Data Import/Export
TNMS Core supports a variety of convenient options for importing/exporting using XML. Configuration data and logs can be exported. Scheduled and unscheduled export is possible. When using scheduled export, time, cycles and destination can be defined. In any case, defining the objects to be exported is possible. The XML files can be viewed with the Internet Explorer. Automatic access to logfile data is also available via the OLE-DB interface (objectlinking and embedding database) for active data objects. This interface can also be used to export data for processing by external tools.
14.3.3
Data Replication
To minimize the loss of data after a system component has broken down, the Multi Server CDM system provides an internal database recovery mechanism for all Multi Server CDM databases. This mechanism automatically implements an internal backup at regular intervals using a previously-created backup copy of the database. The database itself is not affected and normal system functionality is still available while database recovery is in progress. Should a software failure occur, the system uses these database backups to restart the system. Multi Server CDM also provides an incremental data replication function which continuously replicates the databases of the active server system to the standby system. Should the active server fail, the operator can then switch to the standby system. However, open transactions and queued jobs are lost.
14.3.4
Log Configuration
Several different log types are maintained by the system. The space available on the hard disk for Multi Server CDM log data can be set using this option. The system message log can then be configured to include a specific level of entries, for example, and the network event log configured to include particular types of network event. Display facilities are also provided for the security event log and operator input log (here, configuration is also possible) in the main SysAdmin menu. For more information on log management and log types, see Chapter 5.
14.4
Date / Time
The system date and time configured for the MS CDM Server can be viewed and adjusted as required. The Server date and time can also be set to the date and time of the PC where SysAdmin is installed.
A42022-L5938-G51-1-7618
77
14.5
License Manager
Licenses are mandatory if you wish to install and operate the Multi Server CDM system. The following types of licenses exist: Basic license, SN licenses, Feature licenses. A list of the available licenses can be viewed, and also imported and exported as *.xml files. Number and kind of licenses have to be planned individually for each customer. The license keys are delivered as XML files and can be imported conveniently in TNMS.
14.6
SN Inscription Settings
The subnetwork inscription labels shown in the Network View in TNMS Client can be adjusted here. The ID name of the subnetwork appears by default, however other information such as the SN name, SN type, location, or user-defined texts entered in the subnetwork property pages can also be included as required.
14.7
Security
Special security features are provided by SysAdmin to regulate access to the Multi Server CDM interface. An authorized user must have an account with a valid user ID and password.
14.7.1
Account Policy
Global account settings which apply for all user accounts are set under Account Policy. These include specific password restrictions and options for account lockout if an incorrect password is entered.
14.7.2
User Management
Under User Management, existing user configurations can be changed and new users set up by the administrator. The level of user access is determined by the user class, user properties, and password restrictions set by the administrator for the user in question. The user class is of particular significance as it determines the range of functions which a user is permitted to perform: Supervision: The user can execute supervision functions but cannot congure or start subnetwork applications. Maintenance: The user can execute supervision functions and start subnetwork manager applications to access specic data on SNs. Operation: The user can perform maintenance functions. Conguration: The user can perform operation functions and conguration management functions. Administration: The user can perform conguration functions and all administration management functions. In other words, the user has unrestricted access. Multi Server CDM: For TNMS Core only. Necessary for login from Multi Server CDM to TNMS Core.
78
A42022-L5938-G51-1-7618
If required, the administrator can also assign a user to one or more user groups. The access rights defined by the individual user classes remain valid, except where the user is assigned to the TNMS Superuser group. A user group can be authorized to access one or more SN containers each of which may represent a network domain. However, each individual SN container can only be assigned one user or user group. The users access rights are limited to the SN container assigned and the SNs which this container comprises.
14.8
DCN Management
DCN management comprises the definition and administration of NetServers, DCN channels and subnetworks. These DCN objects are displayed in a hierarchical tree and can be added, deleted and modified as required. The current connection state is also displayed for each DCN object.
14.8.1
NetServer
This object handles the connection to one or more different subnetworks, is the direct source for all SN data to be uploaded by the MS CDM Server, loads the SN data required by the MS CDM Server to the NetServer memory and maintains data consistency while NetServer is connected to the SN, acts as an mediation device by standardizing the data transferred from the different SN interfaces to the MS CDM Server and vice versa.
14.8.2
DCN Channels
Subnetworks are connected via a DCN channel to the MS CDM Netserver (see Fig. 2.1). DCN channels are used by the operator to group SNs of the same DCN channel type. Multi Server CDM supports the following DCN types: DCN Interface Subnetwork Physical Interface Ethernet (TCP/IP) Protocol DCOM Subnetwork Subnetwork
Table 14.1 DCN Interfaces
A42022-L5938-G51-1-7618
79
80
A42022-L5938-G51-1-7618
15 Abbreviations
BSHR CC CDM CORBA CUG DAT DCC DCN DCN EM EML EmlDB EM-OS ESCON FCAPS FICON GMT GUI ID IMN ITU-T LAN LCT LogDB MAN MIB MS CDM MS MSN MSP NE NEC NML NmlDB OADM OGL Bidirectional Self Healing Ring Cross Connection Cross Domain Manager Common Object Request Broker Architecture Closed User Group Digital Audio Tape Data Communication Channel Data Communication Network Data Communications Network Element Manager Element Management Layer
, ,
Element Management Layer Database Element Manager Operations System Enterprise System Connection
Fault, Configuration, Accounting, Performance, Security Fiber Connection Greenwich Mean Time Graphical User Interface Installation Manual Telecommunication Standardization Sector of International Telecommunications Union Local Area Network Local Craft Terminal Logs and Lists Database
, ,
Identification (Service Status)
Metropolitan Area Network Management Information Base Multi Server Cross Domain Manager Microsoft Multi Service Node Multiplex Section Protection Network Element Network Element Controller Network Management Layer Network Management Layer Database Optical Add-Drop Multiplexer Operator Guidelines
OLEDB/ADO Object Linking and Embedding Database / Active X Data Objects
A42022-L5938-G51-1-7618
81
OLEDB/ADO Object Linking and Embedding Database Active X Data Objects OSI OTH PC PDH PLET PM PMP RAID RegDB RN RPR SAN SCSI SDH SMS SN SNCP SNIF+ SNMP SONET TCM TCOA TCOI TCOM TED TIF TMF TMN TNMS TP TSF UHC UNO VC VLAN WAN WDM XML Open Systems Interconnection (G.784) Optical Transport Hierarchy Personal Computer
, ,
Plesiochronous Digital Hierarchy Performance Log Export Tool Performance Management Performance Measurement Point
Redundancy Array of Independent Disks Registry Database RPR Node Resilient Packet Ring Storage Area Network Small Computer System Interface Synchronous Digital Hierarchy Short Message System Subnetwork Subnetwork Connection Protection Service Network Interface + Simple Network Management Protocol Synchronous Optical Network Tandem Connection Monitoring TMF CORBA Agent TMF CORBA Interface TMF CORBA Manager Technical Description Telemetry Interface Telecommunication Management Forum
Telecommunication Management Network Telecommunication Network Management System Termination Point Tab Separated Format Ultra-High Capacity Universal Object Virtual Container Virtual LAN Wide Area Networks Wavelength Division Multiplexing Extended Markup Language
,,
82
A42022-L5938-G51-1-7618

TNMS Ted

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TNMS Ted

Uploaded by

Copyright:

Available Formats

Information

TNMS Core/CDM 8.5 Technical Description (TED)

Technical Description (TED)

Information TNMS Core/CDM 8.5

Important Notice on Product Safety

Copyright (C) Siemens AG 2003.

Information TNMS Core/CDM 8.5

Technical Description (TED)

This document consists of a total of 82 pages. All pages are issue 1.

Technical Description (TED)

Information TNMS Core/CDM 8.5

Information TNMS Core/CDM 8.5

Technical Description (TED)

Technical Description (TED)

Information TNMS Core/CDM 8.5

Information TNMS Core/CDM 8.5

Technical Description (TED)

TNMS Core/CDM Documentation on CD-ROM

Symbols Used in This Manual

Additional information Warnings

Technical Description (TED)

Information TNMS Core/CDM 8.5

Information TNMS Core/CDM 8.5

Technical Description (TED)

Technical Description (TED)

Information TNMS Core/CDM 8.5

Management interface ELI TNMS-SX EMOS-SLI EM-OS MSN

Type of network element

TCOI TCOI; optional

SN16000 other vendors EMSs e.g. NEs supported via TIF

UNO+ (logical interface)

General Structure of a TNMS Core/CDM Network

Information TNMS Core/CDM 8.5

Technical Description (TED)

Technical Description (TED)

List of Supported Network Elements

Information TNMS Core/CDM 8.5

Technical Description (TED)

NE class SDH SL16 SL64 SLR16 SMA1/4 SMA 4/1 SMA1K

SMA1K-CP SMA16 SMA16/4 SN16000

TCOI required toleration of broadleaf for 6.2

3.1 1.0 6.2.2

List of Supported Network Elements

Technical Description (TED)

Information TNMS Core/CDM 8.5

NE class SDH Radio SPS 155 SRA 1

SRA 1S SRT 1 SRT 1C

SRT 1S SPS E SRT 1F PDH Radio SRA L

MSN SURPASS hiT 7070 Node SURPASS hiT 7070 Lambda

List of Supported Network Elements

Data Communication Networks (DCN)

Information TNMS Core/CDM 8.5

Technical Description (TED)

SISAGKE QD2 FMX SMA

Data Connections via Different DCNs (Example)

Examples of Networks WDM Networks

Technical Description (TED)

Information TNMS Core/CDM 8.5

SURPASS hiT 7550

SURPASS hiT 7550

SURPASS hiT 7550

SURPASS hiT 7550 Backbone network Regional/Metro network SL64 SL64

SURPASS hiT 7550