TNMS

Technical Product description

Nov. 2017

Disclaimer:

This document contains proprietary and confidential material of Coriant. Any unauthorized, reproduction, use or disclosure of
this material, or any part thereof, is strictly prohibited. This document is solely for the use of Coriant employees and any
authorized customers. Coriant reserves the right to make changes in the specifications at any time and without notice.

1
 TABLE OF CONTENTS

PRODUCT DESCRIPTION ...........................................................................................................................5

INTRODUCTION ............................................................................................................................................5
1. PRODUCT KEY FEATURES .....................................................................................................................6
1.1 Multi-platform .............................................................................................................................6
1.2 Multi-technology.........................................................................................................................6
1.3 Multi-vendor ...............................................................................................................................6
2. FCAPS ...............................................................................................................................................7
3. ARCHITECTURE ....................................................................................................................................8
4. SW PLATFORM AND DATABASE .............................................................................................................8
5. COMMON FUNCTIONS AND SERVICES .....................................................................................................9
6. TECHNOLOGY MANAGERS .................................................................................................................. 11
7. APPLICATION CLIENT ......................................................................................................................... 11
7.1.1 Local craft terminals .......................................................................................................................... 12
7.2 Northbound interfaces ............................................................................................................ 12
7.3 Adaptation layer ...................................................................................................................... 13
7.3.1 Multi-vendor NE integration ............................................................................................................... 13
8. DEPLOYMENT CONFIGURATIONS ........................................................................................................ 14
8.1 Standalone system ................................................................................................................. 14
8.2 Co-deployment with TNMS Core ............................................................................................ 15
9. HIGH-AVAILABILITY DEPLOYMENTS ..................................................................................................... 16
9.1 Hot-standby configuration ....................................................................................................... 16
10. SYSTEM REQUIREMENTS ............................................................................................................... 16
10.1 Hardware ................................................................................................................................ 16
10.2 Software .................................................................................................................................. 17
11. VIRTUALIZATION ............................................................................................................................ 17
11.1 Client Virtualization ................................................................................................................. 17
11.2 Server/Hardware Virtualization ............................................................................................... 18
PRODUCT FUNCTIONALITY DESCRIPTION .......................................................................................... 19
12. COMMON FUNCTIONS AND AUTOMATION ........................................................................................ 20
12.1 User and Security Management ............................................................................................. 20
12.2 License Management ............................................................................................................. 21
12.3 Log Management .................................................................................................................... 22
12.4 DCN Management .................................................................................................................. 23
12.5 Network Map........................................................................................................................... 24
12.6 Fault Management .................................................................................................................. 26
12.7 Performance Management ..................................................................................................... 28
12.8 Network Inventory Management ............................................................................................. 30
12.9 Network Browser .................................................................................................................... 32
12.10 NE Configuration Backup ................................................................................................... 32
12.11 NE SW Download ............................................................................................................... 33
12.12 NE user and security management .................................................................................... 34
13. CONFIGURATION MANAGEMENT ..................................................................................................... 35
13.1 Optical Management .............................................................................................................. 35
13.1.1 DWDM, OTN and SDH Management ........................................................................................... 35
13.2 Path Management .................................................................................................................. 35
13.2.1 Path discovery .............................................................................................................................. 35
13.2.2 Path provisioning .......................................................................................................................... 35
13.2.3 Protection Management ................................................................................................................ 39
13.2.4 Routing and Auto-routing .............................................................................................................. 39

2
 13.2.5 Path management......................................................................................................................... 40
13.2.6 Path hierarchy ............................................................................................................................... 41
13.2.7 Optical Power monitoring .............................................................................................................. 42
13.3 WSON and ASON Management ............................................................................................ 43
13.3.1 Network Discovery ........................................................................................................................ 43
13.3.2 Path Provisioning .......................................................................................................................... 44
13.3.3 ASON/WSON Logical Map ........................................................................................................... 44
13.3.4 Path Management......................................................................................................................... 44
13.4 Ethernet Management ............................................................................................................ 45
13.4.1 Path Discovery .............................................................................................................................. 45
13.4.2 Tunnel provisioning ....................................................................................................................... 46
13.4.3 ERP Management......................................................................................................................... 47
13.4.4 Path provisioning .......................................................................................................................... 48
13.4.5 Routing and Auto-routing .............................................................................................................. 49
13.4.6 Template Management ................................................................................................................. 50
13.4.7 Path Management......................................................................................................................... 51
14. SYSTEM ADMINISTRATION ............................................................................................................. 52
14.1 Backup and restore ................................................................................................................ 52
14.1.1 Scheduled Backups ...................................................................................................................... 52
14.2 Standby functionality .............................................................................................................. 53
14.2.1 Hot-standby configuration ............................................................................................................. 53
15. LIST OF ABBREVIATIONS ................................................................................................................ 54

3
 TABLE of figures

FIGURE 1 – FCAPS VIEW OF TNMS .................................................................................................................7

FIGURE 2 – LAYERED ARCHITECTURE................................................................................................................8
FIGURE 3 – TNMS COMPONENTS .....................................................................................................................9
FIGURE 4 – TNMS COMMON FUNCTIONS ..........................................................................................................9
FIGURE 5 – TNMS TECHNOLOGY MANAGERS ................................................................................................ 11
FIGURE 6 – TNMS CLIENT ............................................................................................................................ 11
FIGURE 7 – LOCAL CRAFT TERMINALS ........................................................................................................... 12
FIGURE 8 – TNMS NORTHBOUND INTERFACES .............................................................................................. 13
FIGURE 9 – TNMS ADAPTATION LAYERS ....................................................................................................... 13
FIGURE 10 – TNMS STANDALONE SINGLE SERVER SYSTEM ............................................................................ 14
FIGURE 11 – TNMS STANDALONE DISTRIBUTED MEDIATION SYSTEM ............................................................... 15
FIGURE 12 – TNMS COMPLEMENTED WITH CORE .......................................................................................... 15
FIGURE 13 – TNMS HOT-STANDBY CONFIGURATION ...................................................................................... 16
FIGURE 15 – POLICY MANAGEMENT ............................................................................................................... 20
FIGURE 16 – LICENSE MANAGEMENT ............................................................................................................. 22
FIGURE 17 – LOG LISTS ................................................................................................................................ 23
FIGURE 18 – DCN MANAGEMENT .................................................................................................................. 24
FIGURE 19 – PHYSICAL TOPOLOGY MAP ........................................................................................................ 25
FIGURE 20 – FAULT MANAGEMENT LIST ......................................................................................................... 27
FIGURE 21 – ALARM SEVERITY PROFILE ........................................................................................................ 28
FIGURE 22 – MODIFY PERFORMANCE LOG ..................................................................................................... 29
FIGURE 23 – GRAPHICAL PERFORMANCE VIEW ALONG A PATH ........................................................................ 30
FIGURE 24 – NETWORK INVENTORY ............................................................................................................... 31
FIGURE 25 – SCHEDULED NE BACKUP........................................................................................................... 33
FIGURE 26 – NE SOFTWARE DOWNLOAD ....................................................................................................... 33
FIGURE 27 – NE USER AND SECURITY MANAGEMENT – USER ACCOUNT ......................................................... 34
FIGURE 28 – OPTICAL PATH PROVISIONING ................................................................................................... 36
FIGURE 29 – NEW OPTICAL PATH – ENDPOINTS SELECTION............................................................................ 37
FIGURE 30 – PM SELECTION ......................................................................................................................... 38
FIGURE 31 – OPTICAL MANAGER – AUTO ROUTING ........................................................................................ 40
FIGURE 32 – OPTICAL MANAGER – PATH MANAGEMENT ................................................................................. 40
FIGURE 33 – OPTICAL MANAGER – PATH PROPERTIES ................................................................................... 41
FIGURE 34 – OPTICAL MANAGER – PATH HIERARCHY ..................................................................................... 42
FIGURE 35 – OPTICAL MANAGER – OPTICAL POWER MONITORING .................................................................. 42
FIGURE 36 – ASON MANAGER – PATH DETAILS ............................................................................................. 45
FIGURE 37 – ETHERNET MANAGER – NEW MPLS-TP TUNNEL WIZARD ............................................................ 47
FIGURE 38 – ETHERNET MANAGER – RING DETAILS ....................................................................................... 48
FIGURE 39 – ETHERNET MANAGER – AUTOROUTER ....................................................................................... 50
FIGURE 40 – ETHERNET MANAGER – TEMPLATES .......................................................................................... 51
FIGURE 41 – DATABASE BACKUP – SCHEDULE ............................................................................................... 52
FIGURE 42 – STANDBY – ORACLE DATAGUARD PHYSICAL REPLICATION ........................................................... 53

4
Product description
Introduction
Mobile broadband network traffic is booming, driven by a host of data applications and over-the-
top services, particularly video. Furthermore, the sheer unpredictability of this demand makes it
difficult to determine the network capacity operators need to deliver the best customer experience
at the lowest cost.

This unpredictability of actual traffic patterns means that the transport network must provide real-
time connectivity dynamically, at any point in the network, from the backhaul all the way through
the core transport network. It is also vital to provide end-to-end Quality of Service (QoS) and low
latency for the best customer experience.

Further pressures on the transport network arise from the need to support fixed and enterprise
services running over a converged infrastructure. Data center connectivity, cloud services, and
residential video are fuelling an even greater traffic explosion that is orders of magnitude higher
than in mobile networks.

Operators need highly flexible, high-capacity transport networks that offer the lowest possible cost
per bit and require the fast deployment of new services and quick implementation of new
technologies. At the same time, they need to maximize the use of the installed networks.

These networks require a network management system which helps the operator to unleash the
network potential and to simultaneously reach high levels of operation efficiency.

TNMS is the next-generation network management system which allows operators to

achieve these goals.

TNMS provides an easy-to-understand network view and simple network navigation coupled with
consistent fault, configuration, security and performance management.

It's ergonomically designed and intuitive user interface simplifies, and therefore speeds up optical
network management. This, in turn, results in higher efficiency, error-free routine operations and
reduced staff training time, lowering overall costs, resulting in OPEX reduction.

The scalable and flexible hardware and software architecture allows the support of networks in
wide range, from small to extra large size, up to thousands of network elements.

TNMS’s open interfaces allow the operators to integrate TNMS into their business and their multi-
vendor environment.

5
1. Product key features

1.1 Multi-platform
TNMS is a truly multi-platform solution. Its state-of-the-art architecture allows deployments in
different Operating Systems. TNMS can be deployed in the following OS:

 Windows 2008/2012
 RHEL Linux 6.6

The deployments in the listed OS are extensively tested. Deployments in other OS are also
possible but Coriant cannot guarantee them proper support.

1.2 Multi-technology
TNMS provides a seamless capability to support new network technologies. Its modular
architecture allows the addition of a new technology management transparently to the system,
minimizing the impact to already supported technologies. This architecture guarantees the lifetime
of the solution resulting in an overall OPEX saving for the operators.

 TNMS supports the following network technologies:

 SDH/PDH.
 DWDM (OCh) / CWDM.
 OTN (ODU).
 ASON (SDH, Och, ODU).
 MPLS-TP.
 Carrier Ethernet.

Coriant is constantly investing in the development of new network technologies as well as

scanning the overall market to identify which technologies are most likely to emerge.

1.3 Multi-vendor
TNMS provides the means to effectively allow an operator to manage a multi-vendor network in
two different ways:

Southbound integration: TNMS provides effective technical solutions to efficiently integrate

third-party network elements. This allows TNMS to manage not only Coriant’s equipment
(including OEMs) but also other equipment that exist in the operator networks. This capability
allows operators to perform network consolidation minimizing the need for different network
management systems, therefore reducing the OPEX and CAPEX need.

Northbound integration: TNMS provides a rich set of northbound interfaces to allow a seamless
integration into operator umbrella systems: SNMP, TMF 814, MTOSI and REST.

6
2. FCAPS

Security Management Performance Management Network Automation

Access control Performance monitoring Network inventory

Domain concept Performance analysis NE configuration backup
Access rights Performance reporting NE SW & user management
User classes Performance logging
Disaster recovery

P
Supervision S System E2E Configuration Management
F Mng A
Alarm reporting & logging E2E multi layer service provisioning
Alarm localization / diagnostic C Network configuration
Service Management Layer
Service alarm correlation Path/circuit provisioning
Test facilities Network Management Layer Protection switching / routing
Element Management Layer

DWDM OTN MPLS-TP MSPP IP Ethernet

Figure 1 – FCAPS view of TNMS

TNMS provides extensive functionality covering Fault, Configuration, Accounting, Performance

and Security(FCAPS) functions as defined by the ITU-T M-3010 across the management layers
defined in the standard, namely:

FAULT MANAGEMENT : TNMS performs alarm surveillance of the managed networks, sub-
networks, and network elements. Alarms coming from the NEs (Network Elements) are monitored
and recorded in TNMS database.

CONFIGURATION MANAGEMENT : TNMS provides the required functionality to allow the network
configuration, including path/circuit routing, provisioning and e2e service management.

ACCOUNTING M ANAGEMENT : TNMS records all actions performed on the network, all network
events and alarms allowing auditing any occurrence which affected the network.

PERFORMANCE MANAGEMENT : TNMS collects and records defined Performance Management

Points in the network. PMPs are recorded in the TNMS database and can be filtered and analyzed
to understand network problems and occurrences.

SECURITY M ANAGEMENT : TNMS guarantees the security of the access to the network resources.
It implements strict security policies and a detailed and granular user access rights policy.

7
3. Architecture

Figure 2 – Layered architecture

TNMS architecture is based on a layered approach for a logical and physical organization of
components. It uses an SOA-based architecture with highly independent components/services.

Its implementation is based on the J2EE standards and uses the field proven JBoss Application
Server software.

TNMS architecture provides:

 Scalability and flexibility

 Maintainability and modularity
 Reusability and portability
 Interoperability and resiliency
 Secure transactional system

4. SW platform and database

TNMS highly modular architecture is built on a reliable SW platform and database.

The JBoss Application Server is field proven and implements the Java Platform Enterprise Edition,
making it suitable for cross-platform deployments.

The Oracle database used provides a multiplatform, reliable, performing and scalable solution.

On top of these reliable SW blocks, TNMS is built on a modular architecture which creates
isolation between the different services and applications.

8
 Figure 3 – TNMS Components

5. Common functions and services

TNMS provides the FCAPS functionality and system management services as independent SW
modules. Although some modules are mandatorily deployed, the system does not require all
modules to be deployed. Operators can deploy the modules which are relevant to the operation
of their network:

Figure 4 – TNMS Common Functions

Mandatory modules:

9
License Management – this module provides the licensing mechanism which allows the operator
to load the licenses that enable the NE management or the access to optional SW modules.

User and Security Management – this module allows the creation of users and user groups in
TNMS and the administration of the access rights for each user and group. The access rights can
be defined on the network object level and on the functionality level allowing a very deep
customization.

System Administration – this module provides the required functionality to administer TNMS. It
provides system supervision functionality as well as the capability to manage system settings and
the backup and restore functionality.

Log Management – this module provides the logging functionality which is used by the whole
system. It allows the recording of all network events, user operations, system events, alarms,
performance records, etc.

DCN Management – this module allows the management of the NEs connection to TNMS,
including the definition of NE network addresses, usernames, and passwords.

Topology Management – this module allows the management of the network topology, the
definition of port connections and view of the network map.

Element Management – this module provides access to the NE craft terminal. It allows the
management of every function and parameter of each NE.

Fault Management – this module provides the functionality to monitor and record all the alarms
raised either by the NEs or by the system itself. It provides an alarm list and a history log.

Network browser – this module provides a resource tree with all the NEs, cards, Ports,
termination points or Ethernet interfaces. Each of those elements shows info as alarm level,
operational state and provide context-based operations for those entities.

Optional modules:

Performance Management – this module allows TNMS to collect performance records from the
network. TNMS is able to collect a large number of performance records per day (several million)
and to keep them in the database according to the operator policies.

Inventory Management – this module provides TNMS with the capability to collect each NE
inventory and to record this information in its database. This allows TNMS to provide the operator
with a complete network inventory view.

NE Configuration Backup – this module provides TNMS with the capability to backup the NE
configuration files (MIBs, VCDBs) in an automatic or scheduled way.

NE SW Management - this module provides TNMS with the capability to manage the NE-SW. It
allows the schedule of the download of new NE-SW to the entire network, and its activation.

NE User Management - this module provides TNMS with the capability to manage the NE users.
It allows creation, deletion and modification of users network wide, including all their details.

10
Node Manager - this module provides a network-wide LCT view for mTera, 7100 and 7090 CE
network Elements.

6. Technology managers
TNMS is highly customizable. Besides the standard FCAPS functionality, TNMS also provides
sophisticated e2e technology managers, which allow the operator to efficiently manage diverse
network technologies.

Figure 5 – TNMS Technology Managers

The technology managers are optional SW modules with no specific dependencies between
these modules. Typical deployments usually consist of technology managers, Optical Manager,
and Packet Manager.

TNMS implements a client-server relationship between the different technology managers which
allows a specific technology manager to use the underlying network managed by a different
manager: e.g. the Packet Manager may use the Optical Manager to determine the existing
connectivity between different NEs.

7. Application client
TNMS uses a rich client framework fully developed in Java. This guarantees the portability of the
client application between different platforms.

Figure 6 – TNMS Client

11
The client application also implements the same modularity principle that is used in the server
architecture. This means that each SW module that can be deployed in the server has a plug-in
which is deployed in the client. This architecture principle simplifies and increases the efficiency
of the installation procedure and a tight alignment between the TNMS client and the server.

7.1.1 Local craft terminals

Tunneling
Mechanism

TNMS Client
Common Functions
GUI
Element Mngt

TNMS Server

Common Functions
Element Mngt

NE Mediation

Figure 7 – Local Craft Terminals

The TNMS client’s Element Management plug-in allows the operator to launch the local craft
terminal (LCT) for each NE. TNMS provides a tunneling mechanism for the client machine,
through the TNMS server, to the NE. This allows the LCT to open as if the operator were directly
connected to the NE.

7.2 Northbound interfaces

In order to provide proper support for the integration of TNMS into operator umbrella solutions, a
rich and diverse offering of northbound interfaces is offered:

 SNMP v3
 TMF 814 release 3.0
 MTOSI release 2.0/2.1
 REST MEF

12
 Figure 8 – TNMS Northbound interfaces

TNMS northbound interfaces provide fault management, configuration management, and

performance management functionalities. TNMS northbound interfaces follow the existing
standards when applicable.

7.3 Adaptation layer

TNMS manages a vast NE portfolio using different protocols and technologies. Its modular
architecture allows the integration of different equipment efficiently. Currently, TNMS manages
NEs over the following protocols:

 SNMP v2 / v3
 QB3
 TL1
 NETCONF
 RMT
 CLI

Figure 9 – TNMS Adaptation Layers

7.3.1 Multi-vendor NE integration

TNMS efficient NE adaptation technology provides short integration cycles making it an
exceptional solution for multi-vendor network management.

13
8. Deployment configurations
TNMS supports different deployment configurations. These configurations depend on the network
dimension, complexity and technologies.

8.1 Standalone system

The standalone system is the typical system configuration. It supports two different configurations
to allow scalability of the network dimension and complexity:

Single server system: TNMS server and mediation SW run on the same single server. This is
the recommended configuration.

TNMS
Clients

TNMS
Server

Network

Figure 10 – TNMS Standalone single server system

Distributed mediation: TNMS server and mediation SW run on different servers. The mediation
SW may be split in different servers - NetServers. This configuration is only used to preserve
investment if the original server dimensioning is overruled by the network growth by adding
additional servers for running the mediation SW. For those scenarios, Coriant support or sales
should be contacted evaluation of the dimensioning based on the existing hardware.

14
 TNMS
Clients

TNMS
Server

TNMS
NetServer

Network

Figure 11 – TNMS Standalone distributed mediation system

8.2 Co-deployment with TNMS Core

TNMS may need to be co-deploy with TNMS Core for managing legacy networks elements, not
natively supported by the new TNMS system. In such scenario, TNMS Core works as a mediator
for TNMS, providing the legacy infrastructure topology and services.

Figure 12 – TNMS Complemented with Core

TNMS and TNMS Core Clients can be install on the same machines.

15
Following functions are available:

- TNMS Core Network Discovery

- Topology
- Fault Management
- Path Management (read only)

9. High-availability deployments
TNMS offers two high availability configurations. These configurations require additional
hardware but have significant benefits for the operation of the network in case of hardware
failures, resulting from the normal usage or from catastrophic events (e.g. earthquake or fire).

9.1 Hot-standby configuration

The Hot-standby configuration is the typical high-availability configuration. It comprises the
deployment of a standby server to account for the failure of the working server.

TNMS
Clients

TNMS Standby
Server TNMS
DB
Server
Synch

Network

Figure 13 – TNMS Hot-standby configuration

The standby server is a second server machine which can be installed locally or on a remote site.
Both the main and standby servers have identical hardware and software configurations.

The system availability is determined by the switchover time, which in turn depends on the
synchronization time of the standby server against the mediation.

10. System requirements

TNMS requirements depend significantly on the managed network dimension and complexity.
The requirements will also depend on the OS and the computing platform to be selected.

10.1 Hardware
The table below shows the recommended hardware configurations. It might be necessary to adapt
configurations over time to take advantage of new hardware availability and consider hardware

16
phase-out plans. The specific Customer Release Notes for each TNMS release will have
additional and updated information on the recommended hardware platforms.

OS / Computing Standard Server Large Server

Platform Configuration Configuration
Windows Server R2 1 or 2 x Intel Xeon E5- 4 x Intel Xeon E7-4850v3
2008/2012 / Intel x86 2680V3 128 GB RAM Memory
32 GB RAM Memory 8 x 300 GB Hard Disk
4 x 300 GB Hard Disk
Redhat Enterprise 1 or 2 x Intel Xeon E5- 4 x Intel Xeon E7-4850v3
Linux 6.6 / Intel x86 2680V3 128 GB RAM Memory
32 GB RAM Memory 8 x 300 GB Hard Disk
4 x 300 GB Hard Disk

The following hardware platforms are recommended for running the TNMS Client application.

Target Use OS / Computing Hardware Configuration

Platform
TNMS Client Windows 7 / Intel x86 1 Intel Xeon i5-4590
4 GB RAM Memory
1 x 300 GB Hard Disk

10.2 Software
The table below presents the main software items used for the deployment of TNMS. The specific
Customer Release Notes for each TNMS release will have the complete list of all used software
items.

Software Item Description

Windows 2008/2012 R2 Standard / Operating system for Server machine
Enterprise Edition R2 64-Bits
Redhat Enterprise Linux 6.6 Operating system for Server machine
Windows 7 Operating system for Client machines

WildFly Application Server 8 Java Based Application Server

Oracle Database 12c Relational database used by the system

to store all relevant data
Java Runtime Environment (JRE) 8 Virtual machine required for execution of
Java code

11. Virtualization

11.1 Client Virtualization

17
TNMS supports Citrix XenApp for application virtualization. This allows that TNMS users can
access a centrally installed TNMS Client application with no need to install TNMS client
application locally on their own machine. In the case of long distances between the TNMS User
workstation and the Citrix XenApp server, this setup can additionally bring performance benefits
since Citrix XenApp protocol is very resilient regarding high network latencies.

In this setup, it is also much easier to deploy strict security policies. The hardening of the
applications needs to be done only on a single machine.

11.2 Server/Hardware Virtualization

TNMS has no restrictions with support for hardware virtualization. The precondition is that the
hardware specification must support at least the minimum requirements, which are mentioned in
the previous chapter. So the CPU performance, network bandwidth and available RAM and disk
space must be equal or exceed the values which were defined for the recommended physical
machine (see the previous chapter).

The used virtualization solutions namely VMWare Workstation, Hyper-V server and VMWare
vSphere for Windows are tested. The final tests for Load, Performance and Scalability are done
with the physical reference machines mentioned in chapter 10.

18
Product functionality description
The following chapters detail all the functionalities made available in TNMS.

19
12. Common Functions and Automation

12.1 User and Security Management

The USM common function manages all user and security relevant data persistently.

The relevant user and security data includes:

 Username, password
 User group
 Domains
 Policies
 Profiles

USM allows the creation of new customized users, policies, and groups.

Figure 14 – Policy Management

TNMS Authentication can also be performed with the Single Sign On functionality using the
authentication mechanism of Windows Domain controller to authenticate the TNMS users. Same
user groups used in TNMS shall exist in the Domain Controller.

Temporary users

20
TNMS allow the creation of temporary user accounts with an expiration date. This is useful for
subcontractor and external parties working temporarily on the system

Display advisories

A configurable advisory message can be displayed after the login before accepting any
commands from the user and it has to be confirmed. This allows compliance with the legal rules
of some countries or advises the user of planned maintenance in the system.

Security log

TNMS keeps track of which users are currently logged in. In addition, it records a security log of
all users logged into the system, including the usage of the Element Manager.

Domain Management

TNMS user and security management provide a mechanism to group NEs into domains, which in
turn can be assigned to users and user groups. TNMS supports the creation/modification/deletion
of individual domains. It is then possible to grant and restrict access to any user or group of users
to any subset of nodes.

12.2 License Management

License Manager is the common function responsible for the licensing in the platform. All the
components that require specific licenses to run have to enquire the license manager about such
licenses.

The licenses in TNMS are divided into three main areas:

 Platform licenses
 Automation licenses
 Technology licenses

License Manager provides:

 Import/Export of licenses
 Display of available/used licenses

21
 Figure 15 – License Management

 License details.
 Print of license list
 Delete of license list
 Filter of license list
 Viewing of license violation log records

12.3 Log Management

TNMS provides a powerful logging functionality which is used by the whole system. It allows
recording of all events like user operations, system events, alarms, performance records, among
others.

TNMS logs are divided into the following categories:

System Event Log - Overall system messages. Used by all components to log system-wide
information, warning and error messages that occur during the execution of commands either in
the network elements or in the application.

Network Event Log – Records spontaneous messages from the network, which are not related
to any previous operation (i.e. direct responses) and which are not related to provisioning.

Provisioning Event Log - This log contains all provisioning requests done by the operator, which
means operations such as service creation or service deletion.

Network Resource Log - This log presents changes in the network on a coarse-grained view
and from the network operator’s perspective. Unlike the network event log, which shows very
detailed events, this log presents changes which are directly related to network resources like
DHCP domains, NEs, bays/shelves, OTS directions, circuit packs, fibers, connections/paths

22
services. This means that the results of the network discovery, e.g. new paths or changed routes
are also logged here.

Performance log – It logs performance and traffic measurement data.

Alarm log – It logs alarm notifications and associated alarm information.

Command log – It logs all types of configuration commands used by other components.

License log – It contains all license log records in a given context as a table.

Security logs – This is a specific log for security management, for example, storage of security
alarm notifications and security configuration commands.

Figure 16 – Log Lists

An authorized operator can access all these logs in GUI, having the possibility to filter and sort,
save or export them. Scheduled exports, maximum log size and log thresholds can also be
configured by the operator.

Export of logs is supported in a variety of standard formats (XML, CSV, ASCII).

12.4 DCN Management

TNMS’s DCN Manager common function allows the management of the NEs connection to
TNMS, including the definition of NE properties, as network addresses, user names, and
passwords among others. The access to the NEs is done through a Mediator (mediation server)
and a DCN channel (mediation type).

23
 Figure 17 – DCN Management

DCN Manager allows following operations:

 Create and delete mediators, and modify their properties.

 Create and modify DCN channels and modify their properties.
 Create and delete NEs, and modify their properties. It is also possible to duplicate
an NE, i.e. to create a new NE from an existing one, only changing some fields
such as an IP address.
 Discovery of NEs – TNMS discovers NEs when managed by a gateway NEs.
 Search for a DCN object on DCN tree or on the Network Map.
 Change the monitoring state of each network element object via an activation
checkbox.

Further to those basic operations, the operator can enable specific functions on the NE
configuration:

 Radius
 (S)FTP, SCP
 Gateway NE
 Debug Level

For each NE type, DCN Manager has a customized property page with specific details needed to
manage this NE type. This allows an easy integration of any other NE type into the system.

12.5 Network Map

24
Topology Management displays the physical network structure and supports the functions and
applications necessary for network surveillance and service provisioning. TNMS Network Map
allows the customer to:

 Position NEs on the map (each NE has its own representation).

 Structure the network with NE Containers (Topological Containers).
 Specify local coordinates for the positioning of graphical objects in the map.
 Auto-link discovery between NEs or manual creation of those physical trails.

The NE container displays graphically the highest alarm severity state of all the NEs inside this
container. NEs can belong to more than one container, but only one of the containers is the real
owner of the NE.

The NE symbol displays graphically the following:

 Operational state
 Communication state
 Commissioning state
 Highest alarm severity
 Alarm acknowledgment state

A tooltip is available over objects (NEs, Physical links, containers) to give more details about them
- for instance, a link’s bandwidth or optical direction.

Figure 18 – Physical Topology Map

25
An object’s context menu offers point-and-click service creation, alarm lists, paths, PM logs, open
of Craft Terminal, etc. filtered by that particular object. Multi-selection is also possible.

The network map also allows to geo-position the NEs with the GPS data present on Network
Elements.

Network map allows an end-to-end highlight of paths (optical, Ethernet or both).

Logical map technology or layer-minded views are available on top of the physical map.

12.6 Fault Management

Fault Management provides the functionality to monitor and record all the alarms raised either by
the NEs or by the system itself. It provides an alarm list and a history log.

The alarm information displayed in the alarm list of the Client is identical for all connected GUI
Clients and works based on a real-time notification mechanism.

Using a user-friendly graphical user interface, the operator can:

 View active alarm details and cleared alarms.

 Acknowledge alarms.
 Insert alarm notes.
 Filter alarms, either by a complex filter or by quick filters.
 Open the affected paths of an alarm.
 Administer the alarm log (retention time, exports, etc).

Alarm list provides information for a quick and easy identification of the problem and its
consequence on the network:

 Alarm severity.
 Raise time
 Alarm Level (primary – real origin, Secondary – consequence of a primary alarm).
 Fault condition (traffic affecting, non-traffic affecting).
 Cause (probable cause of the alarm).
 Location.
 Equipment type.
 NE name, Container location.
 Affected services, their names and affected subscribers.
 Troubleshooting instructions.
 Operator Notes.

Alarm log will additionally add the clear time and acknowledge info (user and time).

26
 Figure 19 – Fault Management List

Alarm Lifecycle

There are the two basic types of alarm events:

 “Raised” indicates the beginning of a certain alarm.

 “Cleared” indicates the clearing of a previously reported alarm.

After having received an alarm raised notification, TNMS assumes that this alarm is present until
a corresponding alarm cleared notification is received.

The acknowledgment state is used by the network operator in the process of fault correction in
order to keep track of the alarm work state.

Alarm Counters

Alarm counters are usually created by managers to allow real-time supervision of services. When
a service is created, Fault Management is informed about the objects of that service. If one of
those objects gets alarmed, Fault Management informs the respective manager, so that it relates
the alarm to the service.

Alarm to Service correlation

27
Using the counter mechanism, it is possible to correlate all the alarms to the affected services.
An operator can request the list of alarms affecting a service at any time, initiating this operation
in the service GUI.

Alarm Suppression

TNMS, at any time, can suppress alarms from the network for objects (ports, cards, etc) not in
use by configured services, in order to hide false alarms to the operator. Whenever a new path is
created, TNMS (un)suppress the respective alarms and suppress them again when the path is
deleted.

NE Alarm Severity Profile Management

The NE Alarm Severity Profile Management is a feature that allows the operator to change and
manage Alarm Severity profiles in TNMS and also on the NE/Network side. It allows the operator
to assign, display, modify, delete, import and export alarm severity profiles, to one or several NEs.

An operator can view the alarm profiles of all NEs they are allowed to manage and modify if they
have the required rights to change severities on the NE side. The operator can copy alarm severity
profiles from one NE to another or change them for a selected number of NEs.

If the operator changes an Alarm Severity profile, it can be saved under a name and reused as
default.

Figure 20 – Alarm Severity Profile

12.7 Performance Management

28
TNMS collects, presents and stores performance data information of the network. PM logs are
collected for 15 minutes and at 24-hour intervals, the time interval or the frequency at which NE
writes the PM data into the PM data historic buffer.

TNMS can support up to 100.000 PMPs (Performance Measurement Point - A point configured
on the network elements where performance metrics will be collected and available for
performance analysis of the network) for 15 min and 300.00 PMPs for 24h. That means ~10
million records per day. The database can keep those records for a retention period of 30 days,
meaning more than 300 million records.

With this information in the database, using TNMS GUI, the operator can filter and sort those
records. Different filter possibilities are available combining options such as time, NE, object
location or PMP.

The operator is able to configure performance data upload settings, including selecting the NEs
from which performance data is uploaded, configure the maximum number of log records to be
logged and configure the file system retention period.

On Path creation and modification, the operator can specify which PMPs and respective counters
he wants to activate.

The scheduled export of logs can also be done, so data can be kept for periods longer than the
specified retention time. This export will be performed daily and do not need any external tool to
be done. TNMS is now developing some instruments for graphical analysis of the data.

Figure 21 – Modify Performance log

29
TNMS includes the possibility to represent the performance data in a graphical view. This
representation is available for current and historical data and along a path.

For historic data, TNMS can represent values of a counter for 96 x 15 min or 12 x 24h interval,
with a start date/time criteria defined.

For current PM data, TNMS can query the Network in regular intervals (15 sec, 30 sec or 1 min)
and will draw/redraw the view with the last 12 measurements.

For paths, TNMS will represent the value of a counter for one interval or for the last current along
the path (route points of the path are the x-axis of the chart).

Figure 22 – Graphical Performance view along a path

12.8 Network Inventory Management

TNMS provides the operator with the ability to have the full inventory of his network.

In the inventory list, the operator can filter, sort, print and save as CSV all the detail information
about the network.

The inventory list is split into 3 tabs:

 Shelves – includes among others attributes the NE name, NE type, Serial Number,
Boot FW/SW code number, HW code number, etc.

30
  Cards – includes among others attributes the Slot, Serial Number, Boot FW/SW
code number, HW code number, Card mode, etc.
 Ports – includes among others attributes the Slot, Port mode, Part number, Module
type, etc.

Figure 23 – Network Inventory

Sorting

The sorting can be done for each column, based on the label field. It is an alphabetical sorting
that sorts each column based on its contents. When sorting is done in a given label the sorting is
extended to the other columns, which means that each complete row will change its position.
Multiple sorts are supported.

Filtering

For filtering, the standard model available in TNMS is used. Each of the attributes allows
specifying the criteria used for filtering, for that particular attribute. Context sensitive filtering is
also supported. By selecting a cell in the context menu there is the option “Filter By”, which sets
a filter configured with the clicked attribute.

Printing

It is possible to print each one of the tabs of the Inventory List window.

Export

It is possible to export the contents of the Inventory List window in CSV format. In this format,
each tab in the Inventory List window is saved as a separate file. These files are for size reasons.
Each row in an Inventory List tab is a separate row in the CSV file. You can select a given number
of rows and export only those rows as CSV with the “Export as CSV” option.

Regular schedule exports are also available.

31
Update

The database is always updated with last info reported by Network Elements. Despite that, and
to minimize notifications server/client, a manual GUI update is needed on the client to update the
list. However, since it is only a DB request, the operation is very fast.

12.9 Network Browser

Network browser provides a tree view of all the network resources managed by TNMS. The
networks resources include Network elements, shelves, Bridges, cards, ports, termination points
and ethernet interfaces.

On each of the above-mentioned entities, TNMS will show the alarm level, operational state,
admin state, path list, among many other info and options.

12.10 NE Configuration Backup

Backing up NE configuration of the entire network, NE by NE, is a time-consuming task. Periodic
repetition compounds the problem.

TNMS offers the ability to perform such backup in an automatic and scheduled way.

There are two types of procedures to back up the NE configuration data.

 Manual
 Scheduled

The operator is able to select the NEs that they want to backup, specifying the schedule and the
destination folder of the backup. The operator is able to delete or modify those scheduled
operations at any time.

The operator can schedule the backup of the entire network at once. They can also specify the
number of NEs of which the backup is performed in parallel. This value will depend on the DCN’s
available bandwidth. TNMS then handles and organizes the schedule by itself.

The operator can specify a retention period for a backup, after which it gets deleted.

All the operations are logged in the TNMS event log. In case a backup is unsuccessful, an alarm
is also generated in the Alarm List.

32
 Figure 24 – Scheduled NE Backup

12.11 NE SW Download
TNMS’s NE software download feature helps on the complex and time-consuming task of
upgrading a network.

Using TNMS, the operator can download the new APS for the entire network with only a few
clicks.

TNMS allows the operator to manage a central repository of APS files in the server used as the
base directory for the software download. The operator can upload the required APS files to the
repository using TNMS. The operator is able to verify all the active APS and inactive APS in the
network, before starting any download operation.

Figure 25 – NE Software Download

During the download operation, TNMS will verify if the APS is valid for this NE and also if the
upgrade path of the NE is rejected. This avoids mistakes by loading the wrong APS.

In order not to overload the DCN, TNMS will also manage the number of parallel downloads. After
that, the transfer is initiated and monitored. Once downloads are completed, the operator can
request to switch the APS and to reboot the NE, if necessary. Alternatively, the operator can

33
schedule the Switch and Reboot operations on the NE, so that these operations are initiated at a
later time.

12.12 NE user and security management

The New NE User Configuration feature allows the creation and management of NE user
accounts and permissions in a single or multiple NEs.

TNMS provides operators and administrators with the possibility to create new NE user accounts,
change passwords or configure password rules in selected NEs or the entire network.

Figure 26 – NE User and Security Management – User account

It is possible to configure several other rules, such as numbers of invalid logins, account
expiration, among others.

34
13. Configuration Management

13.1 Optical Management

13.1.1 DWDM, OTN and SDH Management
The new Colorless, Directionless and Contentionless ROADMs (CDC) together with flexi-grid and
superchannels and Pluggable Optical Layer (POL), bring new challenges to NMS applications. At
the same time, legacy technologies as SDH continue to coexist and interwork with newer
technologies. We have drawn on our vast experience in optical networking to create in Optical
Manager the necessary tools for end-to-end management of all the above-mentioned
technologies.

TNMS provides the capability to provision, discover, monitor and display graphically all kind of
end-to-end optical connectivity in the network.

The TNMS Optical Manager can manage:

 Optical Transport Section (OTS).

 Optical Multiplex Section (OMS).
 Optical Channel (Och) with different modulation formats.
 Optical Transport Unit (OTU) and OTU Containers.
 Optical Data Unit (ODU).
 PDH
 SDH and SONET
 Transparent Ethernet services.

Those layers have a Client/Server relationship in TNMS between them and used in combination
between them or with ASON paths.

Ethernet or MPLS-TP services can use such connectivity as a virtual L2 link, to allow the routing
on top of the optical network.

13.2 Path Management

13.2.1 Path discovery
TNMS is able to discover all the paths created in the network. The operator can choose between
the automatic (default), manual or scheduled modes.

TNMS allows modifying any of the discovered paths. For all the discovered paths TNMS will
activate the alarm correlation and initiate their supervision.

13.2.2 Path provisioning

TNMS allows the provisioning of new paths in an easy and unified GUI. The operator selects the
path name, service container, subscriber, service level and correlation mode.

35
 Figure 27 – Optical Path Provisioning

13.2.2.1 OTN path provisioning

The operator will select the path’s endpoints (TNMS helps with filtering the possible termination
points that can be used), routes the path, and selects the frequency. TNMS will filter the list of
possible frequencies to be used taking into account the NE capabilities for CDC.

36
 Figure 28 – New Optical Path – Endpoints selection

It is also possible to use TNMS to configure the client port mode and the Forward Error Correction
(FEC) mode.

Along with the route path creation, the operator can use a server path as a “highway”. By selecting
the entry port of this server path, the wizard jumps automatically to the other edge of the path.

For performance monitoring, TNMS will present the list of possible PM counters for end and route
points, according to the selected layers. The operator will select the ones desired for 15 min and
24h collection.

37
 Figure 29 – PM selection

Finally, TNMS creates all the necessary configurations of the network giving a feedback about
the state and success of the operation.

In the case of ODU provisioning, and in order to facilitate the ODU switching configuration, the
concept of TP Template is used by TNMS. This type of TP is used to display the possible
allocations left in a given TP instead of showing all the possible ones.

A path can be routed (manually or automatically) using templates as previously described and,
when activated, TNMS automatically chooses how they are configured in the network.
Alternatively, the operator can also manually structure the ODU for an explicit control. More details
on autorouter functionality are available in subchapter 13.2.4.

The creation of high order ODU paths to be used later by a low order ODU as a server path is
also supported by TNMS.

TNMS allows configuration of the TTIs for the layers defined by the ITU-T standards (e.g. OTS,
OTU. RS, …).

13.2.2.2 SDH path provisioning

TNMS allows the provisioning of new SDH path in an easy and unified GUI. As for OTN
provisioning, the operator selects the endpoints of the path and routes the path.

Generally, TNMS can manage three different path types:

38
  Closed path (normal case), where both endpoints of the path are inside of the
managed network
 Open path, where both endpoints of the path are outside of the managed network
 Half-open path, where one endpoint of the path is outside of the managed network

Additionally, special paths carrying several lower-order paths can be defined. These paths are
called “Server Paths” and indicated as highway symbols in the Subscribers & Services window.
A typical example for a server path is a VC4 (STM-1) path carrying up to 63 x VC12 (2Mbit/s)
paths.

TNMS include also the possibility to delete or modify existing paths.

Furthermore, with the function “Path Analyzer” the management system automatically identifies
all the possible paths currently not adopted in TNMS. This analyzer may run continuously in the
background or alternatively can be activated by the user. The operator then can adopt the
proposed paths and store them under Subscribers & Services in the database.

13.2.3 Protection Management

TNMS includes protection for unidirectional and bidirectional paths. The supported protection
schemas are SNC/N, SNC/I and SNC/S which are mapped to SNCP (i.e. a path with two legs and
a head end and tail end cross-connections).

Protection Group based protection schemas like Y-cable, MSP and BSHR (2 fiber or 4 fiber) are
managed by the Protection Manager. The protection manager lists the discovered or created
protections groups and supports the standard operator actions (i.e. switch to working, switch to
protection, etc).

13.2.4 Routing and Auto-routing

Apart from the auto routing functionality, where several options can be selected for routing a
service, TNMS offers also a sophisticated routing tool “Path Wizard” is supported by TNMS to
enable fast and flexible path and service provisioning. The user can open the Path Wizard in
Services mode either from the Configuration option in the Main Menu or directly from the NE
assigned as starting point of the path/service.

After defining the path label, the user defines the path topology by simply dragging & dropping
the source and sink NEs into the Path Wizard window. In the same window, the ports and
termination points, as well as the direction and resilience of the path, can be selected or modified,
if necessary. The system checks and indicates any incorrect choice. Effective filters (e.g. for
layers, connected ports) support the easy selection of ports and TPs. It is also possible to define
routing constraints - e.g. diversity constraints (i.e. NE, link, cable/conduit diverse).

39
 Figure 30 – Optical Manager – Auto Routing

13.2.5 Path management

TNMS does the supervision of all the paths created in the network. The path management window
provides information among others on the associated layer set and characteristics of the path A-
end/Z-end.

Figure 31 – Optical Manager – Path Management

Operators are also able to view some configuration details as the path name, used layer, manage
state, ACS (actual creation state), RCS (required creation state) and TP configuration. ACS and
RCS allow the operator to compare the required configuration done or adopted by TNMS and the
actual configuration of the network. TNMS also distinguish between a problem in the client path
and server path used by this path. The operator can navigate from the client to the server path in
the same window.

Important information is resume in the path management window. In an easy to understand

graphical view, the operator can quickly know the details and status of the path, including the

40
highest severity alarm of a path, the operational state and the route state. The operator is also
able to view some configuration details such as the path name, used layer, manage state, ACS,
RCS and TP configuration.

Figure 32 – Optical Manager – Path Properties

On each path, the operator can request the list of active alarms that affects that path. The alarms
presented will be only the traffic affecting alarms (e.g. fan alarms will not be shown). The operator
can request the list of alarms that have affected that path, but that are no longer active (Alarm
log). This allows a post debug of the related services.

TNMS can retrieve performance management logs per path and present them in a graphical way.
Refer to Performance Management chapter for details on the graphical representation.

13.2.6 Path hierarchy

The properties page of a path gives a view of the path hierarchy with the client/server relationship.
This relationship can be seen in terms of directions, server paths of a client path or all client paths
of a server path.

41
 Figure 33 – Optical Manager – Path Hierarchy

13.2.7 Optical Power monitoring

TNMS provides functionality to supervise and monitor the optical power levels in TNMS for Optical
Multiplex Sections and Optical Channels.

Figure 34 – Optical Manager – Optical Power Monitoring

42
13.3 WSON and ASON Management
TNMS supports the management of ASON/WSON for SDH, Och, and ODU layers.

ASON (Automatically-Switched Optical Network) is a concept for the evolution of transport

networks which allows for dynamic, policy-driven control of an optical network based on signaling.
Requirement and architecture documents have been approved by ITU-T.

WSON (Wavelength-Switched Optical Network) are ASON networks based on the WDM
switching technology (photonic layer). The framework and specific ASON extensions are defined
by IETF.

ASON/WSON functionalities:

 Automated network operation

 Automated topology/resource discovery
 Automated end-to-end service provisioning
 Multilayer network control
 Single and multi-domain networks
 Very High Network Reliability
 Multiple failures network recovery
 Efficient bandwidth usage (sharing) for restoration
 Flexible service provisioning
 Bandwidth on demand
 Class of services at transport layer
 Traffic engineering

TNMS provides the operator with the ability to manage and view the topology of the ASON
network (Component Link creation/deletion, TE-link management, ASON logical map), as well as
call management (creation, deletion, LSP relocation, and external switch requests).

The following objects are managed:

Call - A call is a relationship between two endpoints (with working and protecting paths) within
ASON domains. A call has one or more underlying Label Switched Paths (LSPs).

Label Switched Path (LSP) - A Label Switched Path (LSP) is automatically computed and
signaled by the ASON control plane. You can affect it and (optionally) specify the hops which the
LSP should or should not go through.

TE-Link - TE-Links are connections between ASON nodes. They have configurable traffic-
engineering capabilities. A TE-Link consists of one or more Component Links.

Component Link - A Component Link is a connection between two ASON ports.

All these objects are handled via lists. ASON-capable NEs, Calls, TE-Links, and LSPs are
displayed on a map containing ASON-related information only.

13.3.1 Network Discovery

43
TNMS provides an interface for discovery of ASON/WSON services configured in the network.
All new services discovered are stored in the database and logged in the system event log.

13.3.2 Path Provisioning

TNMS offers a unified graphical user interface to create any Call type (Och, ODU, SDH). The user
only has to select the necessary settings, service endpoints, desired protection and TE
(include/exclude of TE-links).

TNMS allows to:

 create/duplicate/modify/delete Calls.
 activate/deactivate Calls.
 list/filter Calls.
 view Call data.
 view Call event history.
 Highlight Calls and LSPs on the map.

TNMS also allows the entire management of Component Links, TE links and LSP:

 create/modify/delete/activate/deactivate TE-Links.
 create/delete/list/filter Component Links.
 list/filter/relocate LSPs.

13.3.3 ASON/WSON Logical Map

TNMS includes a logical map with a network view of ASON/WSON objects, such as NE and
Component Links. The ASON logical map only shows the NEs that support the technology and
allows the operator to highlight Calls and LSPs on the map, including colored information about
the main and protecting paths. ADON manager supports all protection and restoration schemas
supported by the NEs (e.g. DSR, shared restoration, 1:1 and combinations).

13.3.4 Path Management

All GMPLS paths appear on path management, including their supervision and status.

It is also possible to see a single path with the details of used ports, TE-Links used and traffic
flows.

44
 Figure 35 – ASON Manager – Path details

13.4 Ethernet Management

A new network is emerging for delivering media-rich and bandwidth-hungry content, applications
and services. Traditional SONET (Synchronous Optical Network)/SDH (Synchronous Digital
Hierarchy) architectures, developed for the narrowband world of the previous generation, are
overloaded. Such practices such as stacking SONET/SDH rings to increase capacity are complex
and costly, and Ethernet-over-SONET/SDH protocol conversions waste tremendous bandwidth.

With data traffic exploding and now dwarfing the Time Division Multiplexing (TDM)-based
demands, a move to pure packet-based transport over Dense Wavelength Division Multiplexing
(DWDM) has significant economic benefits by avoiding packet to TDM conversions at each node.

In fact, a Metro Ethernet Forum (MEF) study suggests that an Ethernet over an optical network
costs about half as much to operate as a legacy SONET/SDH one.

By combining packet-processing intelligence and optical-wavelength assignment into a single,

unified system – e.g. Layer 2 Ethernet Switching over DWDM – service providers can achieve
significant operational savings, make better use of their resources, achieve optimal bandwidth
efficiency and gain nearly limitless scalability.

Ethernet Management is a TNMS component that provides Ethernet path connection

management and supervision in an optical network. Ethernet Management allows quick access
to E-line, E-Access, E-transit, CES, E-LAN and E-Tree creation, modification or deletion.

13.4.1 Path Discovery

Discovery process of Ethernet Manager will scan the full network and correlate all the entities to
discover all kind of connectivity (L2VPN):

- MPLS-TP Tunnels

45
 - MPLS-TP Pseudowires
- Ethernet resilient VLAN tunnels (G.8031)
- Ethernet rings (G.8032)
- E-Lines, E-Access, E-Transits, CES, E-LANs and E-Trees VPNs

On discovery process, the physical links and optical trails that can provide a layer 2 connectivity
are used to correlate the E2E entities.

TNMS manages the end-to-end tunnels (in case they are complete) automatically and alarm
correlation is enabled for those. Services can be managed by the operator to start their
supervision (including alarm correlations as well).

13.4.2 Tunnel provisioning

TNMS allows the creation of MPLS-TP tunnels using an easy graphical interface. The
configuration includes:

 Service name and description

 Service level and subscriber
 Protection with configuration of hold off timer, wait time to restore and signal
degraded trigger
 Tunnel source and destination (NEs)
 QoS configuration (CoS and bandwidth)
 Route selection (auto-router and manual router are available for route selection)
 OAM configuration (FM: Transmit/receive CC, CV detection, Source/Destination
locked; PM: Frequency, packet CoS, Packet color and packet length for Frame
loss measurement and framed delay measurements)

46
 Figure 36 – Ethernet Manager – New MPLS-TP tunnel wizard

NNI LAG ports can be used for LSP route, allowing a higher bandwidth for the tunnel. For QoS
and OAM, predefined templates can be used for faster and easy configuration.
Labels used for tunnels are automatically selected by TNMS based on network availability,
however, they can be edited if required by the operator.

TNMS supports also the provisioning of Resilient VLAN tunnels, used in networks elements like
7100 or mTera.
For those the creation process is similar to the MPLS-TP tunnels, with some differences:
- Instead of Labels, those tunnels use VLANs as labeling mechanism
- OAM configuration includes the Maintenance Domain level and name definitions and CCM
intervals.
- No QoS is defined for such tunnels.

13.4.3 ERP Management

TNMS supports also the discovery and supervision of ERP infrastructure based on G8032
protocol.
Setup of the ring is performed on each NE with Node Manager (a TNMS component). Then TNMS
will discover the full ring entity based on connectivity and start the supervision of the ring.
From that point, new services can be configured using the ring as a protected infrastructure.
Details about ring status, ring elements, route or CFM are present in Ring detail window in TNMS.

47
Status of the ring is correlate to the services running on top of the ring.

Figure 37 – Ethernet Manager – Ring Details

13.4.4 Path provisioning

TNMS allow the configuration of end-to-end services for the different packet technologies
(bridging, VLAN-XC or MPLS-TP).

The services can be created on top of previously created infrastructures (tunnels, Rings) or
without it for unprotected services.

Service creation includes:

- Service name and details

- Service type
- Endpoint selection (includes possibility to select LAG ports as endpoints)
- Port mode (UNI, NNI)
- TPID (0x8100, 0x88a8, 0x9100)
- Mapping type (port based, VLAN mapping)
- QoS (CIR, CBS, EIR, EBS, Color-aware and coupling flag)
- Route selection – See next chapter for routing details
- OAM

For CES (Circuit Emulation service) services, there is an additional step to map the E1 timeslots
into the STM1 port.

For E-tree services, the operator needs to define the root and leaf endpoints as well.

VLAN manipulation can be performed for some network elements and include:

- Add VLAN
- Delete VLAN

48
 - Modify Add VLAN
- Modify VLAN

OAM (Operations, Administration, and Maintenance) functions:

 MEG level
 Loopback timeout
 Connectivity Verifications - Monitors if an endpoint is connected to the correct
endpoint(s)
 Packet Loss Measurements – Measures the packet loss between end points
 Packet Delay Measurements – Measures the delay between endpoints

Note that for MPLS-TP services, TNMS will create the pseudowire in the same step of the service
creation. The Operator will be able to adapt some QoS settings in the PW if required.

13.4.5 Routing and Auto-routing

For routing tunnels and services, TNMS provides different options from Manual to full automatic
routing.

Manual routing allows, with point and click on the map, select the required NEs. By this, TNMS
will select the available connectivity between selected nodes (L2 links, rings, tunnels).

Automatic routing will automatically select a route based on shortest path (latency and traffic load
constraints are planned for the end of the year). The operator can select its preferences between
usage of L2 links, Rings and Tunnels (VLAN or MPLS-TP) for the routing.

When working with a pure carrier Ethernet service, routing can be done based on an S-VLAN
constraint or without it, selecting one free S-VLAN for the chosen route. The operator is able to
change this selected S-VLAN.

CAC (connection admission control) is performed by TNMS when selecting a routing (either
automatic or manual) to assure enough bandwidth for the selected Class of Service exists
available in the route.

49
 Figure 38 – Ethernet Manager – Autorouter

13.4.6 Template Management

Currently, templates are available for QoS and OAM for faster end-to-end provisioning. Templates
are available for tunnels and VPN. All QoS and OAM parameters existing in the wizard are
configurable on templates.

The operator ca create different templates for later selection on tunnels or VPN wizards. Specific
templates exist based on technology (MPLS-TP or CE). Selection of a template in the wizard is
performed by name.

By the end of 2016, service templates will be available and include default name, port/VLAN
mapping, QoS, and OAM.

50
 Figure 39 – Ethernet Manager – Templates

13.4.7 Path Management

TNMS does the supervision of all the VPNs created (or discovered) in the network including and
their associated PWs and LSPs. The path management window is a easy to understand graphical
view where the operator can quickly know the details and status of the path, including the highest
severity alarm of a path, the operational state, and the route state.

On the details, Operator is also able to view all the configuration details as the VPN name,
description, ports and their configuration, Policy maps, OAM (including MEPs and MIPs), route,
ACS (actual creation state) or RCS (required creation state). ACS and RCS allow the operator to
compare the required configuration done or adopted by TNMS and the actual configuration of the
network.

TNMS supports alarm supervision for all the VPNs. The aim of this concept is to maintain a global
Alarm State for the service, which reports the highest severity alarm associated with all the
resources of the service.

The operator can open the Alarm List window from the service context menu. In this case, the list
is filtered and displays all alarms correlated to the service.

51
14. System Administration

14.1 Backup and restore

With TNMS, the database is always safe. TNMS offers the database backup and database
recovery options.

Database backup - Backup of the DB information is used to restore TNMS to a previous state in
order to, for example, undo undesired user configurations or restore TNMS on a different server.

Database recovery - Backup used to recover the database from corruption events or unexpected
integrity issues and recover it to its last most consistent state. These backups contain TNMS
specific data plus other Oracle files required for database recovery.

It is also possible to backup together or separately the OpenDS database which contains all the
user accounts and profiles of TNMS.

14.1.1 Scheduled Backups

TNMS allows scheduling regular backups of the database and users. The schedule is very
flexible, so it can be adapted to each customer needs.

Figure 40 – Database Backup – Schedule

52
14.2 Standby functionality
TNMS offers two high availability configurations. These configurations require additional
hardware but bring significant benefits for the operation of the network in case of hardware failures
resulting from the normal use or from catastrophic events (e.g. earthquake or fire).

14.2.1 Hot-standby configuration

The Standby concept in TNMS is based on an active and a standby server that is replicating data
in a bidirectional manner using the Oracle dataguard feature.

TNMS Standby concept is defined by the usage of data replication to support a High-Availability
configuration for the management system. The distance limits between TNMS servers are driven
by the underlining Oracle Database replication mechanism. Oracle Dataguard sends the
transactional information from the Primary to the secondary database where the redo log
information is first stored to release the Primary database and, subsequently, is applied
autonomously to the Standby database. The following picture illustrates the Dataguard concept.

Figure 41 – Standby – Oracle Dataguard physical replication

As a side note, the Dataguard configuration doesn’t ensure a zero data loss but this is also not
required by TNMS since the TNMS system itself has resynchronization mechanisms that reduce
the impact of most data losses.
The TNMS Standby feature complies with some availability metrics. The complete switchover
time from Primary to Standby Server takes less than 15 minutes. The system availability is thus
99.99997% assuming one switchover event in one year, or 99.994% assuming two.

53
15. List of abbreviations
ASON Automatically-Switched Transport Network
CAPEX Capital Expenditure
CORBA Common Object Request Broker Architecture
DB Database
DCN Data Communications Network
DWDM Dense Wavelength Division Multiplexing
EMS Element Management System
ETSI European Telecommunications Standards Institute
GUI Graphical User Interface
IP Internet Protocol
ISO International Standardization Organization
ITU International Telecommunication Union
LAN Local Area Network
LCT Local Craft Terminal
MIB Management Information Base
MVM Multi Vendor Management
NE Network Element
NMS Network Management System
OEM Original Equipment Manufacturer
ON Optical Networks
OPEX Operational Expenditure
OS Operating system
OSI Open System Interconnection
PDH Plesiochronous Digital Hierarchy
PMP Performance Monitoring Point
RAID Redundant Array of Independent Disks/Drives
SCSI Small Computer System Interface
SDH Synchronous Digital Hierarchy
SISA Supervision and Information System for local and remote systems
SLA Service Level Agreement
SNCP Sub-network Connection Protection
SNMP Simple Network Management Protocol
STM Synchronous Transport Module
TCP/IP Transmission Control Protocol/Internet Protocol
TIF Telemetry Interface
TMF TeleManagement Forum
TMN Telecommunications Management Network
TNMS Telecommunications Network Management System
UNO Universal Object
WAN Wide Area Network
XML Extensible Markup Language

54