Element Manager Manual PDF

Element Manager User's Manual
Nimbra One
Nimbra 300 series
Nimbra 600 series
NimOS GX4.12
Copyright 1999-2013 by Net Insight AB, Sweden. All rights reserved. This document may
not be reproduced in whole or in part without the expressed written permission of Net
Insight AB.
The specifications and information in this document are provided “as is” and are subject to
change without notice. All statements, information, and recommendations in this document
are provided without warranty of any kind, expressed or implied, including without
limitation any warranty concerning the accuracy, adequacy, or completeness of such
specifications and information or the result to be obtained from using such specifications or
information. Net Insight AB shall not be responsible for any claims attributable to errors,
omissions, or other inaccuracies in the specifications or information in this document, and
in no event shall Net Insight AB be liable for direct, indirect, special, consequential or
incidental damages arising out of the use or inability to use this document.
GPL source code is available for applicable parts for this product. If you would like a copy
of the GPL source for the costs of preparing, please send a mail to gpl@netinsight.net. A
listing of external software distributed with the product, including copyright notices is
included as appendix to this document.
Net Insight and Nimbra are trademarks of Net Insight AB, Sweden. All other trademarks
are the property of their respective owners.
Net Insight AB
Box 42093
SE-126 14 Stockholm
Sweden
Phone: +46 8 685 04 00

Fax: +46 8 685 04 20
E-mail: info@netinsight.net
April, 2013
Stockholm, Sweden
(NID 4380/A1)
Stockholm, Sweden
Contents
1 ABOUT THIS MANUAL ............................................................................. 13
1.1 Overview .......................................................................................................................... 13
1.2 Intended reader ............................................................................................................... 13
1.3 Support and assistance ................................................................................................. 13
1.4 Organization of content ................................................................................................. 13
1.5 Conventions in this manual .......................................................................................... 14

1.5.1 Information of specific importance ................................................................................ 14
1.5.2 Instructions .................................................................................................................... 14
1.5.3 Terminal output and keyboard input ............................................................................. 14
1.5.4 Web interface examples ............................................................................................... 15
2 GLOSSARY OF TERMS ............................................................................ 16
3 QUICK START GUIDE............................................................................... 21

3.1 Overview .......................................................................................................................... 21
3.2 Configuration of the IP address .................................................................................... 21

3.2.1 Initial settings for VT100 terminal emulator .................................................................. 22
3.2.2 IP settings for Nimbra One/Nimbra 300 series ............................................................. 23
3.2.3 IP settings for Nimbra 600 series .................................................................................. 24
3.2.4 Set the DTM address .................................................................................................... 25
3.2.5 Parameter configuration example ................................................................................. 27
3.2.6 Save the configuration .................................................................................................. 27
3.2.7 System configuration and restart .................................................................................. 28
4 KEY CONCEPTS ....................................................................................... 31

4.1 General ............................................................................................................................ 31
4.1.1 Slot numbering in Nimbra nodes .................................................................................. 31
4.1.2 Module .......................................................................................................................... 32
4.1.3 Device ........................................................................................................................... 32
4.1.4 Connection, TTP and Channel ..................................................................................... 33
4.1.5 Isochronous Transport Stream (ITS) ............................................................................ 33
4.1.6 Ethernet Transport Stream (ETS) ................................................................................. 33
5 THE USER INTERFACE ............................................................................ 34

5.1 Overview .......................................................................................................................... 34
5.2 Connecting to the units ................................................................................................. 34

5.2.1 Required software ......................................................................................................... 34
Element Manager User's Manual About This Manual • 3
©2013 Net Insight AB, All rights reserved

5.3 Command Line Interface................................................................................................ 34
5.4 Web interface .................................................................................................................. 35
5.5 Frequently used terms ................................................................................................... 35
5.6 Default username/password.......................................................................................... 36
5.7 Logging in using the Telnet connection ...................................................................... 36

5.7.1 Terminal connection, General for Nimbra nodes .......................................................... 36
5.8 Logging in using a web browser .................................................................................. 36
6 MAINTENANCE ......................................................................................... 38
6.1 Overview .......................................................................................................................... 38
6.2 Maintenance system settings ....................................................................................... 39
6.3 Maintenance system syslog .......................................................................................... 43
6.4 Maintenance system restart .......................................................................................... 43
6.5 Maintenance Date and Time .......................................................................................... 44
6.6 Users ................................................................................................................................ 45
6.7 Preferences ..................................................................................................................... 47

6.7.1 Configuration handling .................................................................................................. 48
6.7.2 Saving the current configuration ................................................................................... 49
6.7.3 Download of configurations to PC ................................................................................ 50
6.7.4 Upload configurations from PC ..................................................................................... 50
6.7.5 Switching configurations ............................................................................................... 52
6.7.6 Delete a configuration ................................................................................................... 52
6.7.7 Software maintenance .................................................................................................. 52
6.7.8 Alarm I/O configuration ................................................................................................. 55
6.8 Cooling ............................................................................................................................ 60
6.9 Software program error alarm ....................................................................................... 61
7 STATUS MONITORING ............................................................................. 63
7.1 Overview of status monitoring ...................................................................................... 63
7.2 Alarms and events .......................................................................................................... 64

7.2.1 The alarms page ........................................................................................................... 64
7.2.2 Acknowledging an alarm ............................................................................................... 66
7.3 Syslog .............................................................................................................................. 66
7.4 Equipment ....................................................................................................................... 69

7.4.1 Setting the administrative status of a module (board) .................................................. 70
7.4.2 Allocating backplane capacity in Nimbra 600 ............................................................... 71
7.5 Sensors............................................................................................................................ 74

7.6 Inventory.......................................................................................................................... 74
7.7 Who (is currently logged in) .......................................................................................... 77
7.8 NTP (Network Time Protocol) ........................................................................................ 78
7.9 Nodeinfo .......................................................................................................................... 79
8 CONTROL NETWORK .............................................................................. 81

8.1 General about In-band management ............................................................................ 81
8.1.1 Ethernet DLE ................................................................................................................ 81
8.1.2 IP and routing ................................................................................................................ 82
8.1.3 DLE clients .................................................................................................................... 82
8.1.4 DLE server .................................................................................................................... 83
8.1.5 Multiple DLE servers on a DLE segment ...................................................................... 83
8.2 Configuration .................................................................................................................. 83
8.3 Building networks with DLE .......................................................................................... 84
8.4 IP routing ......................................................................................................................... 85
8.5 Control Network main web page ................................................................................... 87
8.6 In-band servers ............................................................................................................... 87

8.6.1 Basic configuration for In-band servers ........................................................................ 88
8.6.2 Advanced configuration for In-band servers ................................................................. 89
8.6.3 Destinations configuration for In-band servers ............................................................. 90
8.7 In-band clients ................................................................................................................ 90

8.7.1 Basic configuration for In-band clients .......................................................................... 91
8.8 Bandwidth requirements of DLE ................................................................................... 93
8.9 IP interfaces .................................................................................................................... 95
8.10 IP routing configuration ............................................................................................. 96

8.10.1 Routes ........................................................................................................................... 96
8.10.2 Setting up IP routes ...................................................................................................... 97
8.10.3 IP route reconfiguration ................................................................................................. 98
8.11 SNMP configuration.................................................................................................... 99

8.11.1 Basic SNMP configuration ............................................................................................ 99
8.11.2 Access control SNMP configuration ........................................................................... 100
8.11.3 Addition of an SNMP trap receiver(s) ......................................................................... 101
8.11.4 SNMP page internal data ............................................................................................ 103
8.11.5 Format of Access control SNMP configuration ........................................................... 104
8.11.6 Configuration Procedure ............................................................................................. 105
8.11.7 Defining SNMPv3 Users ............................................................................................. 105
8.11.8 Defining Community.................................................................................................... 106
8.11.9 Defining MIB Views ..................................................................................................... 106
8.11.10 Defining Groups and Access Rights ....................................................................... 108
8.11.11 Assigning Users ...................................................................................................... 109
9 DTM CONFIGURATION .......................................................................... 110


9.1 Overview of DTM configuration .................................................................................. 110
9.2 Interfaces ....................................................................................................................... 111

9.2.1 Editing a DTM interface .............................................................................................. 111
9.3 Addresses ..................................................................................................................... 114

9.3.1 Adding a DTM address ............................................................................................... 114
9.3.2 Editing or deleting a DTM address ............................................................................. 115
9.4 Hostnames .................................................................................................................... 116

9.4.1 Adding a host .............................................................................................................. 116
9.4.2 Editing or deleting hostnames .................................................................................... 118
9.5 Links .............................................................................................................................. 118
9.6 Routing .......................................................................................................................... 119

9.6.1 General ....................................................................................................................... 119
9.6.2 Static routing ............................................................................................................... 120
9.6.3 Dynamic routing .......................................................................................................... 121
9.7 Static routing ................................................................................................................ 122

9.7.1 Adding, editing or deleting a static route..................................................................... 122
9.8 Dynamic routing ........................................................................................................... 123

9.8.1 Setting the dynamic routing parameters ..................................................................... 123
9.8.2 Area Definition ............................................................................................................ 125
9.8.3 Area Planning ............................................................................................................. 125
9.8.4 Area Prefix Routes ...................................................................................................... 128
9.8.5 Directly Connected Areas ........................................................................................... 128
9.8.6 Indirectly Connected Areas ......................................................................................... 129
9.8.7 Metrics for Area Prefix Routes .................................................................................... 130
9.8.8 Configuration ............................................................................................................... 130
9.8.9 Addition of a dynamic routing entry ............................................................................ 130
9.8.10 Editing or deleting a dynamic routing entry................................................................. 132
10 TRUNKS ............................................................................................... 133

10.1 Overview of Trunks ................................................................................................... 133
10.1.1 Trunk Modules, Nimbra One ....................................................................................... 133
10.1.2 Trunk Modules, Nimbra 300........................................................................................ 134
10.1.3 Fixed trunk interfaces for Nimbra 310/320/360/380 ................................................... 134
10.1.4 Trunk Modules, Nimbra 600........................................................................................ 135
10.1.5 Trunk interfaces configuration .................................................................................... 135
10.2 Editing SDH/SONET Trunk Interfaces ..................................................................... 136

10.2.1 Asymmetric alarm generation ..................................................................................... 140
10.2.2 Optional FEC version for 4 x OC-3/STM-1 Trunk ....................................................... 141
10.3 Editing the DS3/E3 Trunk interfaces ....................................................................... 142

10.3.1 Configuration of DS3/E3 mode ................................................................................... 145
10.4 Editing the IP/Ethernet trunk interface ................................................................... 146

10.4.1 Protocol stacking ......................................................................................................... 146
10.4.2 Configuration of IP/Ethernet trunks – Ethernet ........................................................... 147
10.4.3 Ethernet Interface Parameters and Variables ............................................................ 148
10.4.4 Basic and Advanced Ethernet Interface Variables ..................................................... 149
10.4.5 Ethernet Interface Parameters - Basic settings .......................................................... 150

10.4.6 Ethernet Interface Parameters - Advanced settings ................................................... 151
10.4.7 Ethernet Interface Parameters – Trunk ...................................................................... 151
10.4.8 Configuration of the IP/Ethernet trunk – IP Trunk ....................................................... 153
10.4.9 IP trunk interface variables ......................................................................................... 161
10.4.10 Basic variables ........................................................................................................ 161
10.4.11 Advanced variables ................................................................................................. 163
10.4.12 Alarm configuration page variables ......................................................................... 165
10.4.13 Alarms ..................................................................................................................... 166
10.5 Ports used by IP trunk .............................................................................................. 168
10.6 Statistics .................................................................................................................... 169

10.6.1 General ....................................................................................................................... 169
10.6.2 Overview statistics ...................................................................................................... 170
10.6.3 DPP-IP Trunk level statistics ...................................................................................... 170
10.6.4 Ethernet/IP level statistics ........................................................................................... 171
10.6.5 Forward error correction ............................................................................................. 176
11 SYNC AND TIME TRANSFER .............................................................. 178
11.1 General ....................................................................................................................... 178
11.2 DTM Synchronization distribution .......................................................................... 178

11.2.1 The DSYP Protocol ..................................................................................................... 179
11.2.2 The node synchronization function ............................................................................. 180
11.3 Synchronization sources and priority .................................................................... 182

11.3.1 Default internal synchronization priority ...................................................................... 182
11.3.2 Clock priority mapping in GX4.8 ................................................................................. 182
11.3.3 Synchronization source extracted from DTM links ..................................................... 183
11.3.4 External clocks ............................................................................................................ 183
11.4 Configuration of external clocks ............................................................................. 184

11.4.1 Nimbra One ................................................................................................................. 184
11.4.2 Nimbra 340/340-HD .................................................................................................... 184
11.4.3 Nimbra 360 and 380 ................................................................................................... 186
11.4.4 Nimbra 310 and 320 ................................................................................................... 190
11.4.5 Nimbra 680 ................................................................................................................. 191
11.4.6 Configuration of internal and external synchronization sources ................................. 192
11.5 DTM Synchronization segmentation....................................................................... 194
11.6 Fault Indications – synchronization alarms ........................................................... 195
11.7 DTM and transport layer synchronization .............................................................. 197

11.7.1 Timing modes of SDH/Sonet trunks ........................................................................... 197
11.7.2 Hold-over and free-running properties ........................................................................ 198
11.8 IP/Ethernet Trunk ...................................................................................................... 198
11.9 Configuration recommendations ............................................................................ 199

11.9.1 External reference clocks - requirements ................................................................... 199
11.9.2 Trunk interface configurations .................................................................................... 201
11.9.3 Trunks for Nimbra One/300 ........................................................................................ 202
11.10 Allow as sync source – DTM configuration ........................................................... 203

11.11 Monitoring synchronization performance .............................................................. 203
11.11.1 Slip Seconds ........................................................................................................... 203
11.11.2 Pointer Justification Events ..................................................................................... 204
11.12 Time Transfer ............................................................................................................ 204

11.12.1 Listing of time transfer channels ............................................................................. 207
11.12.2 Time transfer on additional interfaces from GX4.12 ............................................... 207
12 PERFORMANCE MONITORING .......................................................... 208
12.1 Overview .................................................................................................................... 208
12.2 General ....................................................................................................................... 210
12.3 Monitored performance values ............................................................................... 212
12.4 Configuration of PM objects .................................................................................... 213
12.5 Presentation of PM objects ...................................................................................... 215

12.5.1 Interface PM objects ................................................................................................... 217
12.5.2 Services ...................................................................................................................... 219
12.5.3 Direction ...................................................................................................................... 219
12.5.4 Error ............................................................................................................................ 219
12.5.5 Admin and Oper Status............................................................................................... 220
12.5.6 Reset of counters and setting of admin status on multiple objects............................. 220
12.5.7 Particular PM Object web page .................................................................................. 221
13 ACCESS MODULES............................................................................. 223

13.1 Access Module types ............................................................................................... 223
13.2 Overview access interface modules ....................................................................... 223
13.3 OC3 /STM-1 Access Interface – web example ....................................................... 224
13.4 DS3 /E3 Access Interface – web example #2 ......................................................... 226
14 ETHERNET TRANSPORT SERVICE (ETS) ......................................... 228

14.1 Basic concepts .......................................................................................................... 228
14.1.1 Forwarding function (FF)............................................................................................. 228
14.1.2 Ethernet Transport Service interface (ETS)................................................................ 228
14.1.3 ETS channels .............................................................................................................. 229
14.1.4 ETS 1 +1 protection .................................................................................................... 230
14.1.5 ETS interface groups .................................................................................................. 231
14.1.6 Protection type – hitless or standby ............................................................................ 231
14.1.7 Hitless protection ........................................................................................................ 232
14.1.8 Standby protection ...................................................................................................... 232
14.1.9 Interface source and sink – constituent parts ............................................................. 232
14.2 Configuration examples of ETS services ............................................................... 233

14.2.1 DTM network as extension cable ................................................................................ 233
14.2.2 ETS Multicast replication in the DTM layer ................................................................. 234
14.2.3 ETS 1+1 unicast closed ended configuration ............................................................. 234
14.2.4 ETS 1+1 multicast closed ended configuration .......................................................... 235

14.2.5 ETS 1+1 open ended configuration ............................................................................ 236
14.2.6 Ethernet Switching ...................................................................................................... 237
14.2.7 Ethernet switch and VLAN tagging ............................................................................. 239
14.3 Configuration of ETS services ................................................................................ 240

14.3.1 Devices (modules) ...................................................................................................... 240
14.3.2 Forwarding Function – Basic settings ......................................................................... 241
14.3.3 Forwarding function - Advanced ................................................................................. 247
14.3.4 Forwarding function – Diffserv configuration .............................................................. 250
14.3.5 Forwarding function – Spanning tree .......................................................................... 253
14.3.6 Forwarding function – Statistics .................................................................................. 256
14.3.7 Nimbra One/340/340-HD/360 limitations for FF ......................................................... 258
14.3.9 ETH and ETS Interfaces ............................................................................................. 259
14.3.10 Fault management for ETH and ETS interfaces ..................................................... 272
14.3.11 Configuration of Fault management for ETH and ETS interfaces .......................... 273
14.3.12 Destinations configuration for ETS multicast channels ........................................... 275
14.3.13 Spanning tree configuration for ETH and ETS interfaces ....................................... 277
14.3.14 Statistics overview tab on the ETS configuration page ........................................... 278
15 ISOCHRONOUS TRANSPORT SERVICE (ITS) .................................. 280

15.1 Overview .................................................................................................................... 280
15.2 Protection .................................................................................................................. 282

15.2.1 Nomenclature .............................................................................................................. 282
15.2.2 ITS protection cases ................................................................................................... 283
15.3 Interface settings for Access Modules ................................................................... 285

15.3.1 Configurable interface parameters ............................................................................. 285
15.4 Setting up a unicast ITS tunnel ............................................................................... 292

15.4.1 Terminating Connection .............................................................................................. 292
15.4.2 Originating Unicast Connection .................................................................................. 294
15.5 Setting up a multicast ITS tunnel ............................................................................ 296

15.5.1 Considerations for multicast channels ........................................................................ 296
15.5.2 Originating Multicast Connection ................................................................................ 298
15.5.3 Terminating Multicast Connection .............................................................................. 301
15.6 Editing/deleting Connections .................................................................................. 301
15.7 Advanced settings .................................................................................................... 302

15.7.1 Embedded ASI in HD-SDI channels ........................................................................... 303
15.8 Configuration of ASI video stream – an ITS configuration example ................... 304
15.8.1 Configuration of the Terminating TTP......................................................................... 304
15.8.2 Configuration of originating TTP for a unicast connection .......................................... 307
15.8.3 Configuration of the originating TTP for a multicast service ....................................... 310
15.8.4 Configuration of interfaces .......................................................................................... 312
15.9 Configuration of MADI streams ............................................................................... 314

15.9.1 Configuration process ................................................................................................. 314
15.9.2 Configuration of interfaces .......................................................................................... 321
15.9.3 Timing ......................................................................................................................... 323
15.10 Configuration of interfaces - Test Generator ......................................................... 325

15.10.1 AES ......................................................................................................................... 326

15.10.2 MADI........................................................................................................................ 327
15.10.3 ASI ........................................................................................................................... 327
15.10.4 SDI........................................................................................................................... 328
15.11 Configuration of STM-1 Access streams................................................................ 329
15.12 Configuration of JPEG 2000 services ..................................................................... 333

15.12.1 Enabling the encoder .............................................................................................. 333
15.12.2 Sink TTP configuration ............................................................................................ 334
15.12.3 Source TTP configuration ....................................................................................... 336
15.12.4 Multicast .................................................................................................................. 339
15.12.5 Interface configuration ............................................................................................. 341
15.12.6 Basic interface parameters ..................................................................................... 342
15.12.7 Test Generator interface parameters ...................................................................... 344
15.12.8 Timing interface parameters ................................................................................... 346
15.12.9 Video interface parameters ..................................................................................... 347
15.12.10 Audio interface parameters ..................................................................................... 349
15.12.11 Ancillary (ANC) interface parameters...................................................................... 351
15.12.12 Vertical Blanking Interval (VBI) interface parameters ............................................. 353
15.12.13 Statistics .................................................................................................................. 354
15.13 Configuration of 1+1 hitless video .......................................................................... 355

15.13.1 Hitless web parameters and variables .................................................................... 356
16 CHANNEL PERSISTENCE ................................................................... 363
16.1 General ....................................................................................................................... 363
16.2 Persistence Configuration ....................................................................................... 363

16.2.1 Link Class Normal ....................................................................................................... 363
16.2.2 Link Class Persistent .................................................................................................. 364
16.2.3 Link Class Nailed ........................................................................................................ 364
16.2.4 Restart On Error .......................................................................................................... 364
16.2.5 Redundant DLE Servers ............................................................................................. 365
16.3 Handling an Error Situation ..................................................................................... 365

16.3.1 The DTM->Links Page ................................................................................................ 365
16.4 Node Status NoControl ............................................................................................ 366
16.5 Restarting a node in NoControl............................................................................... 366

16.5.1 Restarting via Outband Management ......................................................................... 366
16.5.2 Restarting via Serial Console ..................................................................................... 367
16.5.3 Restarting from a Neighboring Node .......................................................................... 367
16.6 Link Errors ................................................................................................................. 367
16.7 Channels with broken control-paths ...................................................................... 367

16.7.1 Tearing down a unicast channel ................................................................................. 367
16.7.2 Reestablishing a unicast channel ............................................................................... 368
16.7.3 Re-establishing a multicast channel ........................................................................... 368
16.7.4 Channel reestablishment upon link failures ................................................................ 369
16.7.5 DLE ............................................................................................................................. 370
17 CONNECTION AND CHANNEL LISTS ................................................ 371

17.1 Overview .................................................................................................................... 371
18 SOURCE ROUTING.............................................................................. 374

18.1 Loose and strict source-routes ............................................................................... 374
18.1.1 Optional interface specification ................................................................................... 374
18.1.2 Deleting a source-route............................................................................................... 375
18.2 Example of how to define source routes................................................................ 375
18.3 Using source routes ................................................................................................. 378
19 LOOPBACK .......................................................................................... 379
19.1 General ....................................................................................................................... 379

19.1.1 Line loopback .............................................................................................................. 379
19.1.2 DTM Loopback ............................................................................................................ 381
19.2 Behaviorally equivalent configurations.................................................................. 381

19.2.1 Loopback from the line side in 8 x ASI Transport Module for Nimbra One/300 ......... 382
19.2.2 Loopback from the line side in Video Access Modules for Nimbra 600 ..................... 383
19.2.3 Loopback from the DTM side in Video Access Modules for Nimbra 600 ................... 383
20 REDUNDANCY FOR NIMBRA 600 ...................................................... 386

20.1 General ....................................................................................................................... 386
20.2 Node Controller redundancy ................................................................................... 387
20.3 Switch Module redundancy ..................................................................................... 388
21 MODULE INSTALLATION.................................................................... 390
21.1 General ....................................................................................................................... 390
21.2 Differences Nimbra One/300 vs Nimbra 600 .......................................................... 391
21.3 Addition of new modules to existing nodes .......................................................... 392
22 UP- AND DOWNGRADING .................................................................. 398

22.1 General ....................................................................................................................... 398
22.2 Up/downgrading GX version from web GUI ........................................................... 398

22.2.1 Saving the current configuration ................................................................................. 398
22.2.2 Repository ................................................................................................................... 399
22.2.3 Up-/downgrading from the web GUI ........................................................................... 401
22.2.4 Required intermediate system releases ..................................................................... 403
22.3 Addition of functional enhancement ...................................................................... 405

22.3.1 General ....................................................................................................................... 405
22.3.2 FEC to the 4 x OC-3/STM-1 Trunk Module from CLI ................................................. 405
22.3.3 Changing fixed trunk interface on Nimbra 310/320/360/380 ...................................... 406
22.3.4 Setting modes for 4 x DS3/E3 Trunk/Access Modules ............................................... 408

22.3.5 Changing firmware on JPEG2000 Video Access Modules by CLI ............................. 410
22.3.6 Changing firmware on 8 x ASI/AES Access Module .................................................. 412
22.3.7 Changing firmware on 8 x Gigabit Ethernet Access Module ...................................... 414
22.3.8 Module restart ............................................................................................................. 415
23 LICENSE INFORMATION..................................................................... 416
23.1 General ....................................................................................................................... 416
23.2 GNU General Public license GPLv2 ........................................................................ 416
23.3 Other open source third party software ................................................................. 420

23.3.1 libarchive ..................................................................................................................... 420
23.3.2 netkit............................................................................................................................ 420
23.3.3 ntp ............................................................................................................................... 421
23.3.4 uip ............................................................................................................................... 421
23.3.5 zlib ............................................................................................................................... 422

1 About This Manual
1.1 Overview
This manual includes information on how to configure, monitor and maintain network
elements of a network, comprising the Nimbra series of multi-service switches, when being
installed with the Nimbra Element Manager, system software provided by Net Insight. For
further information on how to install and maintain the Nimbra switches please see Nimbra
One / Nimbra300 series / Nimbra 600 series Installation and Maintenance Manuals.
1.2 Intended reader

This manual is intended for network managers and administrators involved in operation and
maintenance of network elements that use Nimbra Element Manager as element
management software platform.
1.3 Support and assistance

If you have any questions about how to use your equipment or software, and if you do not
find the solution to your problem in this manual, please contact your local equipment and
support supplier. If any question still remains, please consult Net Insight's Technical
Support Center.
1.4 Organization of content

The contents of this manual are organized as follows:
Glossary of Terms contains information about different abbreviations and terms used in the
manual.
Quick Start Guide contains procedures to set up and run the unit after initial installation.
Maintenance covers software maintenance, such as backup routines and software upgrades.
Status Monitoring refers to the functions for monitoring the status of the unit.
Control Network contains information on how to set up in-band management and configure
the IP routes of a unit.
DTM Configuration covers information about the node administration for the units.
Trunks describe the trunk interfaces that are used to connect nodes into a network.
In Sync and Time Transfer, synchronization principles are defined and the Time Transfer
option is elaborated.
Performance Monitoring shows how to use the web interface to set up performance
monitoring.
Access Modules covers the access interfaces that are used to feed the network with various
kinds of traffic.

Ethernet Transport Service (ETS) describes how to setup Ethernet transport and the
configuration and maintenance of Ethernet interfaces.
Isochronous Transport Service (ITS) describes how services are used and how to create a
video tunnel, a PDH tunnel or a Sonet/SDH tunnel through the DTM network.
Channel Persistence describes what happens to already established channels if nodes along
their respective routes are taken down.
In Connection and channel lists all lists available from the web interface are described and
explained.
In Source Routing, the concept of source routing is described as well as how to configure a
source route.
In Loopback, this diagnostic feature is described.
Redundancy for Nimbra 600 explains the basic redundancy principles in the Nimbra 600
Series.
In Module installation
installation, installation of additional modules in operational nodes is described.
Up- and Downgrading describes how to upgrade a node from the web interface.
1.5 Conventions in this manual

1.5.1 Information of specific importance
Note: Information for proper function of the equipment is contained in

this kind of boxes, which includes the tip heading and symbol.
Tip: Information for better understanding and utilization of the

equipment is contained in this kind of box, which includes the
tip heading and symbol.
1.5.2 Instructions
The instructions given in this manual are numbered in the sequence in which they should be
performed, as follows
Initial measure
Next measure
…
1.5.3 Terminal output and keyboard input

Examples of text and commands appearing on a terminal screen are marked with a special
font as follows:
Example of terminal text output
Example of command <optional parameters>

1.5.4 Web interface examples
The configurations shown in the displayed web pages in this document are taken from
generic systems and for this reason the parameters might differ from the user’s particular
configuration.

2 Glossary of Terms
Access device Access device is a network component that provides access for
services to the network. Examples of services are ASI, HD-SDI
and ETS.
ADM Add/drop multiplexer
AES/EBU Audio Engineering Society/European Broadcasting Union
ANC Ancillary
AIS Alarm Indication Signal
ASI Asynchronous SCSI Interface
BBE Background Block Error
BPDU Bridge Protocol Data Unit
CATV Cable TeleVision
CENELEC Comité Européen de Normalisation Électrotechnique
CLI Command Line Interface
CCC Client – Client –Connection
CSC Client –Server – Connection
Control Module The control module or node controller of a Nimbra node
handles communication with other nodes. It also handles
resource and network management.
Control slot A DTM frame is divided into data slots for transferring user
data and control slot for sending control messages (DCP
messages) between DTM nodes. There are static control slots
that are set up initially and cannot be altered and dynamic
control slots, which can be set up on demand to change the
signaling capacity of a node.
CPU Central Processing Unit
DCAP DTM Encapsulation, which is the mechanism to adapt a service
for transport in a DTM Network. The protocols DCAP-0/1/3
are defined. DCAP-0 and DCAP-3 is used for ITS
encapsulation and DCAP-1 for ETS encapsulation.
DEG Degraded
DID Data Identifier
DLE DTM LAN Emulation allows DTM to be used as a bridge
between different segments of an Ethernet network.
DLE client DTM LAN Emulation client
DNF DPCP-IP Negotiation Failure
DNU Do Not Use
DRP DTM Routing Protocol
Element Manager User's Manual Glossary of Terms • 16

DSCP Differentiated Services Code Point
DTM Dynamic synchronous Transfer Mode
DTM channel A DTM channel is an end-to-end connection with a defined
route. The route is either defined by the user (source route) in
the source node or by the network at the time of creation
(DRP). A DTM channel has a reserved capacity in steps of 512
kbps.
DTM Frame A DTM frame consists of control slots and data slots. The
number of slots depends on the bit rate of the DTM link. A
DTM frame is 125 µs long.
DTM Link DTM Link is the physical medium connecting DTM Nodes. It
is typically an optical fiber, but other types of media like
electrical cable and microwave links may also be used.
DPCP-IP DPP Control Protocol for DTM over IP
DPP-IP DTM Physical Protocol for DTM over IP
DRP DTM Routing Protocol
DSCP Differentiated Services Code Point
DST Daylight Savings Time
DSTI DTM Service Type Instance. It is a number, unique per service
type (ETS and ITS), direction and node.
DSYP DTM Synchronization Protocol
DVB Digital Video Broadcasting
EP Edge Port
EPS Edge Port Status
ES Errored Second
Ethernet Ethernet is a simple LAN protocol originally developed by
Digital and Xerox for use with servers and workstations. Later
standardized as IEEE 802.3. The success of Ethernet for use
with personal computers has put force between further
developments towards 10Base-T, Fast Ethernet (100Base-T),
Gigabit Ethernet and 10 Gigabit Ethernet. Ethernet is a
CDMA-CD protocol with an exponential back-off algorithm.
ETS Ethernet Transport Service
ETSI European Telecommunications Standards Institute
FCS Frame Check Sequence
FEC Forward Error Correction or Fast Ethernet Card
FF Forwarding Function
GARP Generic Attribute Registration Protocol
GEC Gigabit Ethernet Card
GMT Greenwich Mean Time
GPIO General Purpose Input/Output
GVRP GARP VLAN Registration Protocol
GUI Graphical User Interface
HD/SD-SDI High Definition/Standard Definition – Serial Data Interface

HTTP Hypertext Transport Protocol
IETF Internet Engineering Task Force
IF Interface
I/O Input/Output
IP Internet Protocol is the Internet network protocol handling
addressing and routing in the Internet. IP is the fundamental
protocol in the Internet and usually works in conjunction with
TCP. IP is a connection-less protocol that operates at the
network layer (layer 3) of the OSI model.
IPOD IP Over DTM. This protocol specifies how to run IP directly on
top of DTM.
ITS Isochronous Transport Service
ITU International Telecommunication Union
IPMC Internet Protocol Multimedia Communications
IPTV Internet Protocol TeleVision
JPEG 2000 Joint Photographic Experts Group, year 2000, an image
standard and coding system
LACP Link Aggregation Control Protocol
LAN Local Area Network
LCD Local Configuration Datastore
LCV Line code violations
LED Light Emitting Diode
LLDP Link Layer Discovery Protocol
LOF Loss of Frame
LOP Loss of Pointer
LOS Loss of Signal
MIB Managed Information Base, a set of data definitions for
describing managed objects in a conceptual database that is
accessed using SNMP.
MM Multi Mode
MTU Maximum Transmission Unit
NC Node Controller
Node Network device directly connected to the DTM network, e.g. a
switch or access device.
NTP Network Time Protocol
OC Optical Channel
OID Object IDentifier
OOF Out of frame
OS Operating System
OSPF Open Shortest Path First
PAE Physical Address Extension

PDH Plesiochronous Digital Hierarchy, a way to multiplex several
telephony trunks into one bit-stream
PDH transport/tunnel A service that allows transparent PDH connections across a
DTM network
PLM Payload Mismatch
PM Performance Monitoring
POH Path Overhead
PPS Pulse per second
QoS Quality of Service
RAI Remote Alarm Indication
RDI Remote Defect Indication
REI Remote Error Indication
RFC Request For Comments
RMS Root Mean Square
RSTP Rapid Spanning Tree Protocol
Rx Receiver
SDH Synchronous Digital Hierarchy
SDID Secondary Data Identifier
SCC Server to Client Connection
SCSI Small Computers System Interface
SES Severely Errored Second
SFP Small Form factor Pluggable
SFP+ Small Form factor Pluggable Plus
SLA Service Level Agreement
SLIP Serial Line IP. A framing protocol for transferring IP packets
on serial (point-to-point) links.
SM Single Mode
SNMP Simple Network Management Protocol
SNMPv3 Version 3 of SNMP. Extension to SNMP that addresses
security and administration issues.
SONET Synchronous Optical Network
SPE Synchronous Payload Envelope
SQC or sqc Squelchable clock
SS Slip Second (used for performance monitoring)
SSM Synchronization Status Message
STM Synchronous Transport Module
STP Spanning Tree Protocol
STS Synchronous Transport Signal
TAI Atomic time
TCA Topology Change Acknowledge, a binary variable

TCP Transmission Control Protocol. An Internet protocol that
provides end-to-end, connection-oriented, reliable transport
layer (layer 4) functions over IP controlled networks. TCP
performs the following functions: flow control,
acknowledgement of packets received and end-to-end
sequencing of packets.
TM Timing Marker
TTL Time to live
TTP Train Termination Point
Tx Transmitter
UAS UnAvailable Seconds
UAT UnAvailable Time
UDP User Datagram Protocol
UNEQ Unequipped
USM User-based Security Model
UTC An abbreviation compromise between Temps Universelle
Coordiné (TUC, French) and Coordinated Universal Time
(CUT, English). For all practical purposes, it is equal to
Greenwich Mean Time (GMT).
VBI Vertical Blanking Interval
VC Virtual Container
VLAN Virtual Local Area Network
WDM Wavelength Division Multiplexer
ZS Zero Suppression (Counter) or Zero sessions; number of
measurement intervals without errors before the current
measurement interval (used for performance monitoring)

3 Quick Start Guide
3.1 Overview
There are some initial configurations, which are needed before the nodes could be used in
the network. The instructions in this chapter are intended to guide an operator to quickly get
a Nimbra node active in a network.
Note: Before these procedures are performed, be sure that the unit is properly installed
according to the relevant Installation and Maintenance Manual. In particular, the
node should be mounted, grounded and powered.
In this quick start procedure, only change parameters specifically mentioned.
This chapter details the configuration needed to get a Nimbra switch operational in a
network. The short configuration procedure is:
Set the IP address
ddress from the serial interface
Set the of DTM address from the web interface
Save/back-up
up the configuration
Reboot the node
3.2 Configuration of the IP address

There are two different cases for the IP address. From release GX4.7 there is a default IP
address: 192.168.125.125. This address appears in the factory default configuration, which
appears when all other configurations are removed and the node is rebooted
rebooted. The other case
is the previous case without default IP address. In order to check if there is a set IP address,
connect the PC/Terminal with an IP address on the same subnet and try to ping
192.168.125.125. If there is a reply, the node has the default IIP
P address. In case there is no
reply, it has to be assumed that the node has no IP address. In this case, the serial port must
be used.
In thee default IP address case, change the IP settings (IP address, netmask and gateway)
from the web interface. Proceed with saving the configuration and rebooting the node. Then
set the IP address of the PC/Terminal to fit the LAN and go ahead with DTM address
setting. This procedure is described in chapter 9 DTM Configuration.
If no default IP address is set on the node, i.e. if the node has GX4.6 or earlier system
release software running, in
initially an IP address must be set. When the initial IP
configuration on Nimbra nodes is made, the serial connection must be used for IP network
parameters. Once the IP settings have been made, subsequent configuration can be made
from the Ethernet port and the web interface. All settings can also be made from the
Command Line Interface (CLI) and the serial port.
In
n order to see what is stored in registry, log in to the node (root/neti) and issue command:
registry list
The FactoryDefault
actoryDefault configuration should now appear,, if system release software GX4.7 or
later is running.
Element Manager User's Manual Quick Start Guide • 21

To see the contents, write resedit get -r -n ipconf
Figure 1. FactoryDefault configuration for GX4.7 and later releases.
Another way of finding out if the default configuration is installed on the node is to connect
the Ethernet (management) interface directly with a PC that is configured to be on this
subnet. Writing the IP address in the URL field displays the web interface of the node
immediately, if it does have the default IP address.
3.2.1 Initial settings for VT100 terminal emulator

A serial adapter is provided (RJ45-RS232 adapter, NPA0006-0001) to adapt the serial port
of the Nimbra node to the PC DSUB-9 connector of the PC. Attach the adapter to the serial
port of the PC and connect the other end of the adapter with a straight Ethernet cable to the
serial port of the Nimbra node. Use a VT100 terminal emulator like Tera Term or Hyper
terminal and log in.
The communication settings are:

Port speed: 38.4 kbps
Data bits: 8
Parity bit: No
Stop bit: One
Flow control: No

3.2.2 IP settings for Nimbra One/Nimbra 300 series
Open a VT100 terminal emulator, with settings given above, on the PC and hit the Enter
key. Log on to the node (The default user name/password combination is root/neti).
List current IP registry by issuing the command
resedit get -r -n ipconf.if.0
The system should reply with something like (in this example, GX4.6 or earlier software is
assumed):
.ipconf.if.0
.ipconf.if.0.name "eth0"
.ipconf.if.0.address
.ipconf.if.0.media
.ipconf.if.0.media.current "autoselect"
.ipconf.if.0.media.active "autoselect"
.ipconf.if.0.mac "00:10:5b:00:00:1b"
.ipconf.if.0.mtu 1500
3.2.2.1 Set the IP address and subnet mask

Create an address structure and set the IP address and subnet mask with the following
commands:
resedit create -n ipconf.if.0.address
resedit set -n ipconf.if.0.address.0.inet -v x.x.x.x
resedit set -n ipconf.if.0.address.0.netmask -v y.y.y.y
x.x.x.x is the IP address

y.y.y.y is the subnet mask.

3.2.3 IP settings for Nimbra 600 series
Connect a straight Ethernet cable to the serial port of the active node controller module on
the 600 series Nimbra node. Connect the other end of the cable to an RJ45-RS232 adapter,
NPA0006-0001, connected to a regular DSUB-9 serial port (like COM1) on your working
computer.
Using the previously stated settings, connect to the node with a VT100 terminal emulator
and hit the Enter key. Log on to the node with the default user name/password combination
(root/neti). List current IP registry with
resedit get -r -n ipconf
A typical reply from the node may be (in this case software GX4.6 or earlier is assumed):
.ipconf
.ipconf.if
.ipconf.if.0
.ipconf.if.0.name "eth-aux"
.ipconf.if.0.address.0
.ipconf.if.0.address.0.inet "192.168.101.74"
.ipconf.if.0.address.0.netmask "255.255.255.0"
.ipconf.if.0.media
.ipconf.if.0.media.active "100baseTX half-duplex"
.ipconf.if.0.mac "00:10:5b:20:63:02"
.ipconf.if.1
.ipconf.if.1.name "eth-front"
.ipconf.if.1.media
.ipconf.if.1.media.active ""
.ipconf.if.1.mac "00:30:d6:03:94:3e"
3.2.3.1 Set IP address and subnet mask

Create an address structure and subsequently set the IP address and subnet mask with the
following commands:
resedit create -n ipconf.if.1.address

resedit set -n ipconf.if.1.address.0.inet -v x.x.x.x
resedit set -n ipconf.if.1.address.0.netmask -v y.y.y.y
x.x.x.x is the IP address
y.y.y.y is the subnet mask.

3.2.4 Set the DTM address
In order to proceed with the web interface, disconnect the serial connection and reconnect
the node at the Ethernet port. The PC must have IP connectivity to the node.
Open the web interface (login with root/neti as user/password combination) and navigate to
the web page DTM → Addresses, and click on the Add address button.
Figure 2. Login to the node with the web interface
Set the DTM address of the unit. Make sure that Primary address is set to ‘Yes’. Click
OK.
The DTM Addresses page below appears. The DTM loopback address
(00.00.00.00.00.00.00.01) is always shown in the list as well.
Figure 3. Configuration page of DTM addresses. Click on ‘Add address’ to add/set the
DTM address.
To set a DTM address, write the DTM address in the appropriate field and click on the OK
button.

Figure 4. Addition of DTM address.
Note: A change in the primary DTM address does not take effect until
after the node has been restarted. Remember to save the
configuration before reboot
rebooting.
Figure 5. Listing of the all DTM addresses

3.2.5 Parameter configuration example
There is a CLI configurable parameter, which is neither configurable from the graphical
user interface nor from SNMP.
The parameter is called maxAlarmRate and has two possible values, normal (default) or
high. Normal means that the hold-off (filtering) time for ITS alarms is 2 s and the wait-to-
restore time is 5 s. Corresponding times with maxAlarmRate set to ‘high’ is 100 ms and 1 s.
In CLI, the parameter is set to normal with command
resedit -n its.maxAlarmRate -v normal
The parameter is set to high with

resedit -n its.maxAlarmRate -v high
The parameter value is displayed with

resedit get -r -n its.maxAlarmRate
3.2.6 Save the configuration

In order to save a configuration, you need to navigate to web page Maintenance →
Configurations and click on the Save configuration button. The Save page appears.
Figure 6. Backup of the configuration; the save page.
Enter a suitable name without spaces and a description of the configuration (optional).
Make sure that the ‘Valid’ box is checked. Click on the ‘OK’ button.

Figure 7. Listing of all configurations. Note that configuration with the valid flag set to
‘no’ are never used for restart of the system.
3.2.7 System configuration and restart

The Maintenance → System web page is found by following the Maintenance → System
link. To restart the system, click on the Restart tab. In the new window that appears, click
on the ‘Restart Node’ button. ‘Restart Node’ means that all processes on all modules in the
node are restarted, including the node controller.
Figure 8. Restart node web page
After the node is restarted, contact with the node ceases momentarily. The contact should
be established again when the node is running again, typically in less than a minute.
When an attempt to restart the node is made, a pop-up window opens and requests
confirmation of the command. The web page is simultaneously grayed out.

Figure 9. Confirmation pop-up for node restart.
In case the configuration has been changed since last restart, the system asks if the
configuration should be saved before rebooting.
On the settings tab, the basic configuration of the node is made.
Figure 10. The maintenance – system – settings configuration page

On the syslog tab, the syslog configuration can be made. Default configuration is presented
in the window.
Figure 11. Configuration of the syslog settings, from the Maintenance – System – Syslog
web page.
The parameters are explained in chapter 6.2 Maintenance system settings.

4 Key concepts
4.1 General
In this chapter, a brief description is made of key concepts for DTM networks. They
include services, channel, connection and TTP. DTM slot numbering, common for all
interface modules, is also described.
4.1.1 Slot numbering in Nimbra nodes

Slot and interface numbering is different on different hardware platforms. On Nimbra One,
the slots are numbered from 1 (dedicated for node controller) to 8. The different interfaces
on the modules are numbered in a way clearly seen on the module front. The interfaces are
numbered from 1 and the last number varies depending on the particular interface.
For example, an OC-3/STM-1 Trunk Module in slot six with four ports have the ports
numbered sonet/sdh-6:1, sonet/sdh-6:2, sonet/sdh-6:3 and sonet/sdh-6:4.
Slot numbering for Nimbra 300 series nodes are different.
In Nimbra 340, the node controller (virtual) slot position is 0. The two available, regular
slots are labeled 1 and 2. The interfaces on the modules inserted in these slots are labeled
from 1 and upwards. The fixed ASI interfaces are 3:1 and 3:2. Finally, the fixed Gigabit
Ethernet Access Module Interface is labeled 4:1.
In Nimbra 340-HD and 360/380, slots 0, 1 and 2 are used in the same manner. In Nimbra
340-HD, the fixed HD-SDI interfaces are labeled 3:1 and 3:2, while in Nimbra 360/380 the
fixed trunk interfaces are labeled 3:1, 3:2, 3:3 and 3:4. In Nimbra 340, 340-HD and 360, the
Gigabit Ethernet Access Module is labeled 4:1. In Nimbra 380, the fixed Gigabit Ethernet
ports are labeled 4:1 to 4:8.
Nimbra 380
Ports 1:1 to 1:x
1 Blind Panel 1
155/622/2488 Mbps (SDH)
1 -10/100/1000 Mbps (ETH) - 2
Serial
Ports 2:1 to 2:x Tx Rx Tx Rx
2 Blind Panel 2
Reset ETH PPS Sync PPS Sync
TSI 1 TSI 2 Tx Rx Tx Rx
Status Status Status Status
+ A - + B -
-- 48
48 VDC
VDC Ethernet Alarm I/0 Status L/A 1 Sp L/A 2 Sp L/A 3 Sp L/A 4 Sp L/A 5 Sp L/A 6 Sp L/A 7 Sp L/A 8 Sp Tx On Tx On Tx On Tx On 3 - 155/622 Mbps (SDH) - 4
Ports 4:1 to 4:8 Ports 3:1 to 3:4
Figure 12. Nimbra 380 with port numbering
Nimbra 320 has a different numbering scheme altogether, as it only has one slot available
for a module. Ports in the module in this slot are numbered between 1:1 and 1:x (i.e.
number of ports on this module), the fixed trunk interfaces are numbered 2:1 to 2:2 and the
Ethernet ports 3:1 to 3:8.
Element Manager User's Manual Key concepts • 31

Nimbra 320
Port 1:1 to 1:x
1 Blind Panel 1
Serial
1 2
ETH PPS Sync
Tx Rx Tx Rx
TSI 1
Reset Status Status
+ A - + B - 155/622/2488 Mbps (SDH)

-10/100/1000 Mbps (ETH) -
-- 48
48 VDC
VDC Ethernet Status L/A 1 Sp L/A 2 Sp L/A 3 Sp L/A 4 Sp L/A 5 Sp L/A 6 Sp L/A 7 Sp L/A 8 Sp Tx On Tx On
Power input A Power input B Port 3:1 to 3:8 Port 2:1 and 2:2
Figure 13. Port numbering of Nimbra 320
In Nimbra 680, the slot positions for the interface modules are labeled 1 to 8, the reserved
positions for switch modules SW A and SW B and the reserved positions for node
controllers NC A and NC B. On the front of the node, there is graphical presentation of the
slot numbers.
Figure 14. Slot allocation for Nimbra 680
For Nimbra 688, the principles are the same as for Nimbra 680, but the interfaces slots are
numbered IF 1 to IF 16. The port numbers are added after the slot position and a colon; e.g.
1:4, 3:6, 11:2, 15:7 and 16:1 denotes slot 1, port 4; slot 3, port 6 and so on.
4.1.2 Module
In this text, an item which fits into a slot in a node and is connected to the node via
connectors in the backplane is called module. In other contexts it may be called board,
plug-in unit, PIU or card. The physical interfaces on the module is labeled after the slot
occupied by the module in the node and the interface number on the module. An example is
aes/ebu-3:6, for physical interface number six (from the left) on the module occupying slot
number three. A module can always be pulled out from the node.
4.1.3 Device
In the web interface, device is used many times for module described above. Device,
however, is something wider. Device also includes firmware dependent trunks (the fixed
trunks for Nimbra 320/360/380) and integrated access features like the ASI ports of Nimbra
340, the HD-SDI ports on Nimbra 340-HD and the Ethernet ports on all Nimbra 300 series
nodes.
In other words, a module is always a device but a device is not always a module.

4.1.4 Connection, TTP and Channel
Connection, Trail Termination Point (TTP) and Channel are all related concepts. A
connection is defined by its two end-points, its TTPs. The channel is defined, in addition to
its TTPs, by the route(s) from source to destination TTPs.
The virtual points in the nodes, where the real time streams to/from access equipment are fit
into DTM channels are called Trail Termination Points (TTPs). In setting up ITS streams,
TTPs are the important object to configure. In addition to TTPs, the interfaces may also be
configured. How they are configured varies, depending on the type of service.
4.1.5 Isochronous Transport Stream (ITS)

The real time streams transported over a DTM infrastructure are called Isochronous
Transport Streams. These ITS streams can be of different type (DS3/E3, STM-1 access,
ASI, SD/HD/3G-SDI, AES/EBU or MADI audio) but they are configured basically the
same way.
4.1.6 Ethernet Transport Stream (ETS)

The Ethernet Stream going through the DTM infrastructure from ingress to egress port is
called Ethernet Transport Stream (ETS).

5 The User Interface
5.1 Overview
The implemented software provides necessary functionality for node management, such as
configuration and monitoring of the units.
Among the functions are:
Network configuration changes
Unit handling
Software diagnostics and upgrade
The graphical user interface (web based) is the normal user interface for all node and
network management. Some initial tasks, like setting the first IP address must be done from
a text-based terminal connection (CLI). These CLI based initial commands are detailed in
the various Installation manuals. In this document, only web browser procedures are
described.
5.2 Connecting to the units

Communication with the units is done either locally through a terminal connected directly
to the unit, or when the unit is in operation, remotely over the in-band management network
(DLE).
5.2.1 Required software

Terminal software: To utilize the terminal connection via the Serial Control Port, a
standard terminal emulation software (VT100) is required, e.g. Windows Terminal.
Web interface: For the web interfaces a standard web-browser able to handle Java-script
and cookies should be used. Internet Explorer 7, Firefox 3.6 or later versions are
recommended web browsers.
5.3 Command Line Interface

A Command Line Interface (CLI) is a set of system commands used for management of the
Nimbra nodes via Terminal or Telnet software. E.g. the CLI can be used when connecting
to the unit via the Serial Control Port using Terminal software, or when connecting via
Telnet (TCP/IP) over the Ethernet Control Port or over the in- management network.
Normally the web interface should be used. The CLI is intended mainly for initial
configuration operations.
Element Manager User's Manual The User Interface • 34

5.4 Web interface
The web interface is the easiest and most straightforward way to communicate with the
units. It is designed to be easy to use and to give a good overview of the configuration
status of the unit. Monitoring and configuration is typically done from the web interface.
Figure 15. The web based user interface
5.5 Frequently used terms

The following terms and parameters are frequently used throughout this document:
5.5.1.1 ‘Admin’
Admin is the administrative status of the object (e.g. route, interface, server, module or
function). The operator can either set the administrative status to ‘Up’ if the object is to be
activated, or to ‘Down’ if it is to be deactivated.
5.5.1.2 ‘Oper’
‘Oper’ is the operational status of the object (e.g. route, interface, server, module or
function). ‘Up’ indicates that the object is active, while ‘Down’ indicates that it is inactive.
If the operational status shows Down while the administrative status is Up, this is an
indication of that an error has occurred. Degraded indicates that the object is operational,
but with deficiency. Dormant means that the object is up but temporarily suspended; in
waiting for an event to take it up. Starting is a transitional state indicating that the object is
in a start-up phase. Absent indicates that the object is no longer physically present in the
node.

5.6 Default username/password
The default username/password combination is
user: root
pass: neti
5.7 Logging in using the Telnet connection

5.7.1 Terminal connection, General for Nimbra nodes
If the unit has just been installed, a local serial connection can be used to set an IP address
on the node according to the appropriate Installation and Maintenance Manual.
Start a Telnet client and connect to the node. When the connection is established, log in to
the node (root/neti). Set the IP address according to the particular instruction.
The unit is now ready to receive commands over the web interface.
Alternatively, if the node house system release software version GX4.7 or later, there is a
default IP address (192.168.125.125) on the node. Set the IP address on your connecting
device on the same subnet, open a web browser and write the default IP address in the URL
window should directly open the web browser. In this case, configuration can be made
directly from the web interface.
5.8 Logging in using a web browser

Establish the connection, either locally or remotely, and start the browser.
Enter the name or the IP-address of the unit in the address field. A Login page, shown
below, appears in the browser window.
Figure 16. The login page
Enter user name and password. The default user name/password combination is root/neti.
Click OK. The start page shown below should appear:

Figure 17. The start page of the Element Manager.

6 Maintenance
6.1 Overview
This chapter describes general maintenance of the unit, like how to back-up and modify
configurations, how to set time and date and how to configure the alarm interfaces on the
GPIO Auxiliary Module.
The first maintenance web page is shown below.
Figure 18. The maintenance web page
The available links on the page are:
System: A subset of the administration and log configuration

Date & time: Settings of the system clock
Users: List of logged in users
Preferences: Alarm and event logging preferences
Configurations: Handling of unit configurations and backup
Software: Handling of Operating System (OS) software
Alarm I/O: Configuration of alarms
Cooling: Selection of cooling profile, i.e. how the fans operate
Some of the links are further divided in different tabs. It is important to click on ‘Apply’
before jumping to another tab as clicking directly on another tab removes all changes on the
previous tab.
Element Manager User's Manual Maintenance • 38

Note: Some of the links are further divided in different tabs. It is
important to click on ‘Apply’ before jumping to another tab as
clicking directly on another tab removes all changes on the
previous tab.
6.2 Maintenance system settings

The maintenance system web page is dividivided
ded into three different tabs; settings, syslog and
restart. The bulk of the configuration takes place on the settings web page.
Figure 19. Maintenance system settings web page
The system settings web page contains system parameters,, which are described below.
Configurable parameters:

6.2.1.1 Restart on error
Default value: ‘off’
Type: Boolean variable (tick box)
Range: ‘on’, ‘off’
Description: If one or more links defined in the node are of type persistent or nailed,
these links can enter a state of ‘NoControl’. This means that links are set to up, these links
are normally kept during a node reboot and the node enters state ‘NoControl’. Checking the
tick box disables this feature and causes all links to be instantly torn down upon a node
reboot. In essence, ticking this box makes all nailed or persistent links behave like normal
links.
6.2.1.2 Upgrade readiness

Default value: ‘off’
Description: Upgrade readiness indicates that the node will not switch any more services,
i.e. the node will not allow any new services to pass through it. The node will allow new
services starting and ending on the node and services already passing through the node will
not be affected.
6.2.1.3 System name

Default value: empty string
Type: string variable
Range: Text string, up to 63 characters long, without spaces, restricted to letters A-Z, a-z,
numbers 0-9 and the characters ‘-‘ (dash) and ‘.’ (dot).
Description: The name of the unit, to be used instead of the IP address, for easier
recognition in the web page.
6.2.1.4 Contact
Range: Text string, up to 100 characters long, only with printable ASCII characters
Description: The name or the e-mail address of the contact person.
6.2.1.5 Location
Range: Text string, up to 100 characters long, only with printable ASCII characters
Description: The name of the location of the unit.

6.2.1.6 Name Server
Default value: none, i.e. no server is configured
Type: IP address
Range: 0.0.0.0 – 255.255.255.255
Description: The IP address of the DNS (Domain Name Server) server. Up to three name
servers (with their IP addresses comma separated) can be defined. The system looks them
up in entry order (i.e. first IP address is used first; if it doesn’t respond the second IP
address is tried etc)
6.2.1.7 NTP Server

Default value: none, i.e. no server is configured
Type: IP address
Range: 0.0.0.0 – 255.255.255.255
Description: The IP address of the NTP (Network Timing Protocol) server.
6.2.1.8 Log these events – Config

Default value: ticked, i.e. ‘on’
Description: The parameter determines if configuration events are logged.
6.2.1.9 Log these events – Reset

Description: The parameter determines if reset events are logged.
6.2.1.10 Log these events – Performance

Description: The parameter determines if performance events are logged.

6.2.1.11 Log these events – Debug
Description: The parameter determines if debug events are logged.
6.2.1.12 Log these events – Info

Description: The parameter determines if information events are logged.
6.2.1.13 Log these events – Alarm

Description: The parameter determines if alarm events are logged.
6.2.1.14 Event log size

Default value: 20
Type: Integer
Range: Read from the node and displayed in the web interface.
Description: The parameter defines the size of the event log, in number of events.
6.2.1.15 Alarm log size

Default value: 10
Type: Integer
Range: Read from the node and displayed in the web interface
Description: The parameter defines the size of the alarm log, in number of alarms.
The button ‘Resume full operation’ is grayed out in normal operation.

After the settings have been made, make sure to click on the Apply button before
continuing to next tab, otherwise all configuration will be lost.

6.3 Maintenance system syslog
The syslog file is configured under the syslog tab on the maintenance → system web page.
The configuration is discussed in the Syslog section of the Status Monitoring chapter of this
document.
Figure 20. Maintenance system syslog web page
6.4 Maintenance system restart

Note: Save the configuration before restarting. Otherwise the parameter
changes will be lost! See chapter 6.7.1 Configuration handling for
details.
Navigate to restart tab of the web page Maintenance → System. Click on ‘Restart Node’ to
execute a node reboot.
reboot Observe that this is traffic affecting and all services originating,
terminating
ating or going through the node are affected. ‘Restart Node’
ode’ means that all processes
on all modules in the node are restarted, including the node controller.

Figure 21. The restart tab of the maintenance system web page
When the system is restarted, the contact with the browser is lost. After a short time (less
than a minute) the contact should automatically be reestablished.
6.5 Maintenance Date and Time

On this web page, date and time of the node can be manually set. These parameters can also
be configured to be aligned with an NTP server. The NTP server is configured under the
settings tab of the maintenance → system web page described in chapter 6.2 Maintenance
system settings.
Figure 22. Date & time page
Enter the revised date and time info in the entry fields.
For the time, use the hh:mm:ss format. To avoid involuntary change of the parameters, the
‘Update date & time’ tick box must be selected for any changes to take effect when the
‘Apply’ button is clicked.

Terms and parameters found on the web page:
UTC: Coordinated Universal Time (abbreviated as UTC) is the global standard time.
time
DST: Daylight Saving
Savings Time
Time zone: Name of the standard time zone used, which is selectable
electable from a drop down
menu.
Standard offset to UTC: Hours to add/subtract to the local time (no DST included) to
reach UTC, e.g. GMT
GMT-1, GMT+4. Observe that for places to the east of Greenwich, a minus
sign should be added and for places to the west of Greenwich, a plus sign should be added.
This could be contrary to other conventions, like Windows, which use the other sign. In
other words, Stockholm Daylight Savings time iis set by using GMT-2 2 (or easier by using
Time zone Europe/Stockholm) rather than GMT+2.
If DST (Daylight Saving Time) is enabled, select as Time Zone a proper city like
Europe/Stockholm. In these time zones, relevant DST information is included.
Note: If the internal clock is set to a time or date in the future, all users are
automatically logged out from the system.
6.6 Users
The maintenance users web page lists currently active users. From this page, users
sers can be
added and their privilege level modified.
Figure 23. The Maintenance Users page
To add new users, click on the ‘Add user’ button. To configure a user currently logged in,
click on the link to the user.
The following configuration menu appears:

Figure 24. Add user configuration page
Enter User name, Access Mode (Full/Read only access) and Password (twice). Click on the
‘OK’ button. The new user is now ready for login.
Parameters configured on this web page are:
6.6.1.1 User name

Default value: none
Type: String variable
Range: 1-50 characters long
Description: The user name for the defined user.
6.6.1.2 Access mode

Default value: Full access
Type: Access rights
Range: ‘Full access’ or ‘Read only access’
Description: The access rights or privilege level of the created user.
6.6.1.3 Password
Default value: none
Type: Encrypted string
Range: 1-50 characters long password.
Description: Password for the created user.

6.6.1.4 Retype password
Default value: none
Type: Encrypted string
Range: 1-50 characters long password.
Description: Password for the created user. This password must match the previous line
for the setting to take effect.
To modify the settings for an already created used, go to the page and make the changes.
After confirming the changes with ‘OK’ or ‘Apply’ the settings are in effect but the
configuration must be saved for the settings to remain after a reboot.
6.7 Preferences
The node contains one set of preferences per user for event and alarm presentation. These
preferences are configured on the web page Maintenance → Preferences. Here, the contents
and size of the event and alarm log can be set. The configurable parameters are:
Parameter Description Type

type
Visible events Type of events that the user can see. There are six different Boolean
types: performance, config, reset, debug, info and alarm.
Visible alarms Type of alarms that the user can see. There are five different Boolean
alarm categories the user can select: acknowledged alarms
(i.e. alarms actively acknowledged by the user) plus alarms
of severity levels warning, minor, major and critical.
Event log size Number of events kept in the log and presented for the user. Integer
Note: The log cannot contain more events than is set on the
Maintenance → Systems → Settings tab.
Auto refresh The refresh interval for the alarm list information. 30 s (default) is
recommended
Figure 25. Configurable parameters, user preferences
Click on the Maintenance → Preferences. The Preferences page, shown below, appears.

Figure 26. Maintenance, Preferences page
Enter the desired information for the currently logged in user and click on the ‘Apply’
button and return to the Maintenance main page. Back up the configuration changes, so
they don’t disappear after a reboot.
The default settings are that all events and alarms are visible, the event log size is 20 events
and the auto-refresh interval is 30 seconds. The range of the event log view file size is read
from the module.
6.7.1 Configuration handling

In order not to risk losing the configuration when changes have been verified and approved,
the configuration should be backed up.
Click on the Maintenance menu link and then click on Configurations. The Maintenance →
Configurations page appears.
Figure 27. Configurations page
The table shows active and previous configurations stored in flash memory. The active
configuration is at the top of the table. The maximum number of saved configurations is
eight, numbered between 0 and 7).

The table shows the following information:
Parameter Description
Id The index number of the configuration
Name A user--defined name of the configuration
Description An optional user
user-defined description of the configuration
Valid Indicates if the configuration is allowed (valid) on reboot or not.. The configuration
with lowest Id number and a set valid flag is used for reboot (i.e. it is ‘active’).
Date Date and time when the configuration was saved
Figure 28. Maintenance → configuration parameters
Tip: If Valid is set to “Yes” for more than one configuration

configuration, the first
configuration with Valid set to “Yes” is used at reboot.
The previous configurations are retained in the unit until they are deleted. To
make a previous configuration in the list active, set the Valid flag to ‘No’ for
all configurations prior to the one to be used and restart the node.
6.7.2 Saving the current configuration

Navigate to the Maintenance → Configurations page according to the previous section.
When the ‘Save
Save configuration
configuration’ button is clicked, the ‘Save configurations’ page appears
appears:
Figure 29. Backup (save) configuration to the node
Enter a name for the configuration in the Name entry field, and a suitable description in the
Description field. The Valid checkbox must be ticked,, if the configuration is to be active
active.
Click ‘OK’.
A dialogue box pops up, indicating that the operation may take a while. The Maintenance
→ Configurations page reappears with the new configuration active once the operation is
concluded.

6.7.3 Download of configurations to PC
Note: Changes in a valid configuration occur when
w the unit is restarted. If the
active configuration is made inactive or deleted the entire system is
affected on restart, as another configuration becomes active.
Only one configuration can be active at any given time.
Navigate to the Maintenance → Configurations page according to the previous section.

Click on the Idd of the configuration to be modified in the Id column. The ‘Edit
Edit
configurations’ page appears. On this page, nothing can be configured in the configuration
itself, but the valid flag can be changed.
Figure 30. Edit configuration
Information about the configuration, such as name, when it was created, a description and
its size, is shown. The only parameter that can be set here is the ‘Valid’ flag.
A click on ‘Download
Download file’
file downloads the configuration to a workstation/PC.
Click OK. The Maintenance → Configurations page appears, reflecting the modification.
6.7.4 Upload configurations from PC

To upload a prepared configuration file to the unit, use the following procedure:
Navigate to the Maintenance → Configurations page according
ccording to the previous section and
click on the ‘Upload
Upload configuration’
configuration button. The Upload page appears.

Figure 31. Upload configuration page
Click on the Browse button. A standard File Open dialogue box appears. Select the desired
file and click the OK button.
The Confirm uploaded configuration page, appears.
Figure 32. Confirmation page for Upload configuration
Enter an appropriate name and a description for the configuration in the Configuration
name and Description entry fields. The Valid checkbox should be ticked if the file is to
become active directly.
Click the ‘OK’ button. The Maintenance → Configurations page reappears with the new
active configuration at the top of list.

6.7.5 Switching configurations
To make a previous configuration active, the ‘Valid’ option has to be set to No for all
configurations prior to the wanted one in the list. This is done by following these steps:
Enter the Maintenance → Configurations page according to o the previous section. Click on
the name of the configuration to be modified in the Name
Name column. The Edit configuration
page appears.
Make the configuration inactive by clearing the ‘Valid’ checkbox.
If necessary, repeat to make other configurations inactive. After setting all needed
configurations to inactive (i.e. ‘not Valid’), restart tthe node. The node becomes active with
the configuration file with the lowest Id number that is ‘Valid’.
6.7.6 Delete a configuration
Note: If the active configuration is deleted, the entire system is affected after
the unit is rebooted, as another configuration becomes active. If no
reboot takes place immediately, nothing happens directly. The node
simply runs on the current configuration (wh(which now happens to be
deleted).
Enter the Maintenance → Configurations page according to the previous section. Click on
the id of the configuration to be deleted in the Id column. The Edit configuration page
appears.
To delete the configuration, click on the ‘Delete’ button. Confirm the action in the
confirmation window that opens. The configuration is removed directly.
6.7.7 Software maintenance

New software and firmware is easily installed on the Nimbra switch directly from the web
interface. The newly installed soft
soft- and firmware combination is activated upon a manual
reboot of the node.
Running and installed software images, also known as GX system releases, are shown on
the Maintenance → Software page below. The ‘Running image’ is currently active and the
‘Installed image’ becomes active upon reboot. An image consists of a directory structure
with a number of files and can be downloaded from a Net Insight ftp or http server
server,
provided that the customer has an active support contract
contract.
It is shown how welll the different soft-
soft and firmware modules are aligned to a single GXGX-
release in the variable ‘System alignment status’. To see the current value of this variable,
click on the Maintenance → Software link. The variable can have five values: full, weak,
vulnerable-strong,
strong, vulnerable-weak
vulnerable and none.
The meaning of the different variable values is:

Alignment Meaning
full All running, primary and secondary images (reported by the CLI command swap)
must match entries in the current Packages.list file: the image is found and the board
criteria matches the board article number and revision
weak All running and primary images match entries in the current Packages.list file but
some secondary images differ. Restart of a board or the entire node is OK if all
boards boot from their primary image. If a board with different primary and
secondary images fails to boot the primary image, but succeeds with the secondary
image, this board may become unusable. (Double error: board reboot and image
failure)
vulnerable- All primary images match entries in the current Packages.list file, but some running
strong images differ (node controller and at least one interface board); all secondary images
are the same as the corresponding primary images. Restart of the node will give full
alignment.
vulnerable- All primary images match entries in the current Packages.list file but some running
weak images differ (node controller and at least one interface board); at least one
secondary image is different from the corresponding primary image. Restart of the
node will give weak alignment.
none All other cases
Possible values for the parameter ‘System alignment status’
Figure 33. Maintenance, Software page

The following information is shown:
‘Running image’: Currently running image
‘Installed image’: Image that boots upon restart of the node
‘System alignment status’: The alignment between different software modules is shown in
the variable System alignment status. If its value is not full, all discrepancies are listed.
Possible values for this parameter are full, vulnerable-strong, weak, vulnerable-weak and
none. Under normal operation, the value is expected to be full.
To install a new image, click on the ‘Install image …’ button. A new page asking for a
URL with the location of the repository of the new image appears (see below). The
repository is the directory including all files that belong to a particular system software
release.
To install the image, simply provide the URL and click on install. Observe that the
currently running software image is active until the node has been rebooted.
Figure 34. Maintenance, Software, Install page for ftp servers.
Figure 35. Maintenance, Software, Install page for http servers.


For a better understanding of what this web page does, consult the Up- and Downgrading
chapter.
6.7.8 Alarm I/O configuration

In the current release, alarm in- and output signals are supported for Nimbra One, Nimbra
340, 380 and all Nimbra 600 series nodes.
Nimbra One and Nimbra 300 series nodes with alarm I/O ports have one configurable
output, between pin 5 and pin 9 on the DSUB-9 physical contact and six configurable input
pins (pins 2-4 and 6-8). Nimbra 600 has 16 different configurable interfaces/pins on two
DSUB-9 contacts located on the GPIO alarm module front (optional module).
The pins are numbered according to the following principle:
1:0:<pin number> for Nimbra One, Nimbra 340 or 380
1:<DSUB number on module (1 or 2)>:<pin number> for Nimbra 600.
Example: gpio1:1:4 (Nimbra 600), gpio1:2:8 (Nimbra 600) and gpio 1:0:5 (Nimbra
One/300 series). For Nimbra 600, pin #7 (of both contacts) is connected to ground and is
not configurable.
To configure pins of Nimbra One/300, proceed as follows (Nimbra 380 is shown as an
example):
Enter the Maintenance → Alarm I/O page by clicking on the link. Initially, no alarm pins
are configured, which is displayed as direction ‘unused’ in the list. Click on the direction of
the pin, i.e. the link unused of the pin to be configured.
Figure 36. Alarm I/O configuration page for Nimbra 380.
A new submenu appears.

Figure 37. Alarm I/O configuration direction page
To start configuring the pin, select Direction ‘Output’ for pin 5 or Direction ‘Input’ for pins
2-4 and 6-8 and click on the OK button. The main Alarm I/O menu reappears.
Select the pin to be configured by clicking on the link to the pin (in the example below, on
the link gpio1:0:2).
Figure 38. Alarm I/O configuration page of a specific interface/pin
To start configuring the interface/pin, select if the alarm is active when the circuit (pin to
common ground, pin 9) is open/high or when it is closed/low. Make the additional
parameter settings:

Parameter Default Possible values
Type Equipment Communications
Environmental
Equipment
Processing error
Quality of Service
Severity Warning Warning
Minor
Major
Critical
Text GPIO port active Text string
Figure 39. Alarm I/O configuration parameters
Proceed by clicking on the ‘Apply’ or ‘OK’ button. The configuration is complete.

To configure pins of Nimbra 680, proceed as follows:
Enter the Maintenance → Alarm I/O page by clicking on the link. Initially, no alarm pins
are configured, which is displayed as direction ‘unused’ in the list. Click on the direction of
the pin, i.e. the link unused of the pin to be configured.
Figure 40. Alarm I/O configuration page for Nimbra 680.
A new submenu appears.

Figure 41. Alarm I/O configuration direction page
To start configuring the pin, select Direction ‘Output’ or ‘Input’ as desired and click on the
OK button. The main Alarm I/O menu reappears.
Select a pin to be configured by clicking on the link to it (in the example below, on the link
gpio1:2:9 on the main alarm I/O configuration page).
Figure 42. Alarm I/O configuration page of a specific interface/pin
To start configuring the interface/pin, select if the alarm is active when the circuit (pin to
common ground, pin 7) is open/high or when it is closed/low. Proceed by clicking on the
‘Apply’ or ‘OK’ button.
Now up to eight different criteria can be chosen to activate the alarm. In order to add a
criterion, click on the ‘Add criterion …’ button.

Figure 43. Alarm I/O configuration page for a specific criterion.
Select ‘Cause’, ‘Type’ and ‘Severity’ according to preferences. For these alarm properties,
a drag-and-drop menu guides the user to the available alternatives. For alarm properties
‘Object name’ and ‘Text’, the ‘*’ character may facilitate the selection, but no drag-and-
drop help is available. The ‘*’ character matches any characters to the right of its position,
e.g. LO* matches both LOS and LOF. If in doubt about object name and text, it is strongly
suggested that the default string ‘*’ is kept.
Click on the Apply button if one (or more) additional criterion is wanted; otherwise use the
OK button. Add all criteria. If satisfied, the criteria cause the pin to become active on an
‘or-basis’ (i.e. if one or more of the criteria is satisfied, the pin becomes active).
To remove a configuration, just click on the output link on the Maintenance → Alarm I/O
page, select ‘Unused’ and click on ‘OK’ or ‘Apply’.

Note: If ‘Cause’, ‘Type’, ‘Severity’, ’Object name’ and ‘Text’ has been selected
in a manner not consistent with software defined alarms, the particular
criterion cannot be satisfied and thus never generate
generates an alarm. This
condition does not in itself generate an alarm. In order to avoid the situation,
use the –any- selection whenever in doubt.
For Nimbra360, gpio1:0:2 to gpio1:0:9 pins are shown as absent. They are not implemented
in hardware.
6.8 Cooling
From GX4.8, there is an option to select how the cooling of the node is controlled. This
option is only available for Nimbra 680 and Nimbra 688 nodes.
Figure 44. Drop-down

down menu for selection of cooling profile.
The cooling profiles available are:
Profile Description
Disabled This profile means that the function cooling profile selection is disabled. The
fans run with a constant RPM, namely 80% of maximum.
Silent This profile means that regulation is made with (low) noise level as primary
objective. Suitable for noise sensitive environments, with good ambient
cooing. The slightly higher board temperature saves fan life.
Cool This profile is made with high system life as primary objective. Suitable for
challenging environments
environments, where staff normally isn't located close
lose to the
nodes.
Balanced This profile is default and a compromise between profiles ‘Silent’ and ‘Cool’.
Suitable for normal operating conditions.
Figure 45. Cooling profiles available in Nimbra 600 series

6.9 Software program error alarm
From system release software version GX4.7, an alarm is generated every time an
unexpected (spontaneous) reboot occurs. This alarm is seen when the node has rebooted
and is active again. The alarm has severity warning.
Figure 46. The Software program error alarm with text ‘Crash dump available’ is
generated whenever a crash dump file is found on the node.
The intention behind this alarm is that any time an unexpected reboot occurs, as this is a
serious event, the event should be reported to Net Insight support. To investigate the node
behavior, a nodeinfo file and the particular circumstances around the event are needed. The
alarm could appear after a manual reboot as well; also this case should be reported.
When this alarm is observed, please contact Net Insight support and inform them about the
details, generate a nodeinfo file and send this file to Net Insight support together with the
Trouble Report ticket number.
The nodeinfo file is generated from the link Status → Nodeinfo.
Figure 47. The nodeinfo file is generated from the Status → Nodeinfo link.

Figure 48. Generation in progress of the nodeinfo file.
Figure 49. The generated nodeinfo file is ready for download. To download, click on the
‘Download nodeinfo’ button. The downloaded nodeinfo file should be sent to
Net Insight support for investigation.

7 Status Monitoring
7.1 Overview of status monitoring
This chapter describes how general supervision of status and configuration is performed
over the web interface.
The starting web page for status monitoring is shown as below.
Figure 50. The start web page for Status (monitoring)
The available subpages are:
Alarms: present the alarms in the node

Events: present the events in the node
Syslog: presents a log of the system (node)
Equipment: lists the installed equipment in the node.
Sensors: lists information available on the various sensors in the node
Inventory: presents the cards in the node including all the information about it such as: Art
no, Rev and serial number.
Who: shows the users that are logged in to the node
NTP: shows NTP servers (clocks) available for the node
Nodeinfo: is a link to create a nodeinfo file, needed for advanced troubleshooting.
Element Manager User's Manual Status Monitoring • 63

7.2 Alarms and events
An alarm is the reporting of a fault or a condition in the system. The alarm is always active
or cleared,
red, meaning that an alarm is indicating an actual status. It should always be possible
to examine the fault condition, and from this determine whether an alarm exists or not. An
event is something that happens within the system, but is not necessary a fau
fault
lt or condition.
All alarms are events, but not all events are alarms.
Note: The alarm list will present the alarms which are selected under the
Maintenance →Preferences link.
7.2.1 The alarms page

When clicking on the Status → Alarms link, the following page appears:
Figure 51. Alarms page
More information about the alarms is available by clicking on the link under the ‘Cause’
heading.
The table shows the Active and Cleared alarms as follows.

Cause Describes the cause of alarm
Sev Shows the severity of the alarm. The following values are possible:
Cr Critical (red)
A service affecting condition has occurred and an immediate corrective action
is required.
Ma Major (orange)
A service affecting condition has developed and an urgent corrective action is
required.
Mi Minor (yellow)
The existence of a non-service affecting fault condition and corrective action
should be taken in order to prevent a more serious fault.
Wa Warning (blue)
Detection of a potential or impending service affecting fault, before any
significant effects have been felt.
Info Information
Cl Cleared (green)
The cleared severity level indicates that the alarm is no longer active.
Object name The object that triggers the alarm.
Text More detailed text about the alarm.
Time Time stamp for the alarm.
Ack Flag that tells if the alarm has been acknowledged or not. Not available for
events.
Figure 52. Description of alarm and event properties. For a full specification of the
alarms, see the appropriate Alarms list (Document NID2004.pdf).
To find the event list rather than the alarm list, click on links Status and then Events. The
Events page appears.
Figure 53. Events page

7.2.2 Acknowledging an alarm
The alarms remain in the ‘Alarm monitor’ ‘field at the top of the alarms list web page until
the alarm has been acknowledged. To acknowledge an alarm, do the following:
Go to the Alarms web page described before.. Click on the alarm to be acknowledged in the
Cause column. The Edit page below is shown:
Figure 54. Acknowledge alarm page
This page shows the same information

information as the alarm list, with the addition of an editable
Comment field and an Acknowledged drop
drop-down menu.
Enter any desired comment, set the Acknowledged drop
drop-down menu to ‘Yes’ and click
‘Apply’ or ‘OK’. The alarm now appears with ‘Ack’ (alarm acknowledgement)
owledgement) set to “yes”
on the alarm page.
Note: In some circumstances the cause of the alarm cannot be removed or the alarm should
not be acknowledged until later. In this case, use the Comments field to pass on any
comment regarding the alarm event.
Note that the action of acknowledging an alarm does not remove the alarm from the
alarm list or change its severity.
7.3 Syslog
The Syslog page lists a log of the node. To access the page, click
lick on the Status link and then
on the Syslog tab on the web page that appears. The Syslog page contains two links, Latest
and Older, which takes the user to the latest entries in the syslog or to older entries. For
Nimbra 600 with dual Node Controllers, latest and older syslogs are available for both
Node Controllers (shown).
hown).

Figure 55. The Syslog page for a Nimbra 600 with dual Node Controllers.
Figure 56. The Syslog page (latest) for the active node controller.
Syslog is configured from the syslog tab on the Maintenance→System web page.
page The
default configuration is
*.*;local1.!=info -/var/log/messages
*.alert /dev/console
This configuration logs all system messages, except from local1 info level (that pertains to
the creation, modification and deletion of DTM OAM objects), to the file
/var/log/messages. Furthermore, it also displays all ll critical messages on the console.
The syntax of the configuration items adheres to the standard BSD syslog implementation
as described in the “syslog.conf” man page of most Linux systems.
Note: It is important that the filename, of the file to which the logged
messages are written, is preceded with a ““-“ sign. Otherwise the
performance of the node can degrade significantly.

An alternative useful setting is
*.*;local1.!=info @<IP address of central syslog daemon>
This setting will send all system messages over UDP port 514 to a central syslog server.
This is a convenient way of consolidating node system and events messaging information in
a simple way. Note that the syslog protocol does not guarantee that messages are
transferred between sender and listener.
Generally some care should be taken when changing syslog settings since flooding of
messages that should be written to the internal flash memory can severely affect the
performance of the node.
Figure 57. Definition of the syslog file.

7.4 Equipment
The Equipment page lists the installed modules and gives a temperature reading of the unit.
To access the page, click on the Status → Equipment link. The following page appears:
Figure 58. Equipment page
In order to configure the fan unit (in particular the ‘Enable air filter replacement alarm’),
the link FAN should be used. The following page then appears:
Figure 59. Configuration of the ‘Air filter replacement alarm’.

When a filter is replaced or when the function is first enabled, the ‘Date when air filter was
last replaced’ and ‘Air filter replacement interval’ are filled out and the ‘Enable air filter
replacement alarm’ tick box is selected. Unless the default setting is changed, an alarm is
issued until the alarm is enabled and then disabled or set.
After the tick box is selected, the ‘Apply’ button should be pressed. The variable ‘Date
when air filter shall be replaced’ is calculated and presented on the web page. An alarm
with severity warning is presented when this date is passed, which indicate that a
replacement is needed. For suitable air filter replacement intervals, please see the relevant
Installation and Maintenance manual. Default values, ranges and formatting of the
parameters are indicated in the table below:
Parameter Default Range Format Comment

Enable air filter Disabled Disabled or Tick box The default setting
replacement Enabled generates an alarm by
alarm default, suggesting to the
user to enter a vale.
Date when air Thu Jan 1 1970-2038 Thu Jan 1 Weekday (Mon, Tue,
filter was last 01:00:00 1970 01:00:00 1970 Wed, Thu, Fri, Sat, Sun)
replaced is ignored
Air filter 0 0-24855 Integer Configuration of days
replacement between filter
interval replacement
Date when air Thu Jan 1 1970-2038 Thu Jan 1 Calculated as ‘Date when
filter shall be 01:00:00 1970 01:00:00 1970 air filter was last
replaced replaced’ plus ‘Air filter
(variable) replacement interval’
Figure 60. Air filter replacement parameters and variables.
7.4.1 Setting the administrative status of a module (board)

To set the administrative status of a board, follow the Status → Equipment link. Click on
the position (Pos) of one of the modules. The Board page appears.
Figure 61. Board page

In the roll-down
down menu, the Administrative status is set to ‘Up’ or ‘Down’. Click on ‘OK’ or
‘Apply’ to change the setting. On this page, capacity towards the backplane is also
requested for odd numbered interface slots (i.e. slots IF1, IF3, IF5, IF7, IF9, …). This is
described more in next chapter.
The status of the card can be verified in the administrative status and operat
operational
ional status
columns of the Status → Equipment page.
Note: A change in the Administrative Status of the standby Node Controller

needs to be saved (i.e. the configuration needs to be saved) in order for
the change to remain in place after a system reboot.
reboot
7.4.2 Allocating backplane capacity in Nimbra 600
Note: The following applies only when using 40 Gbps switch modules in the Nimbra 680
or when using 80 Gbps switch modules in Nimbra 688. When using 80 Gbps switch
modules in Nimbra 680 or 160 Gbps switch modules in Nimbra 688, there is always
10 Gbps allocated to each interface position.
40 Gbps switch modules for Nimbra 688 is not supported.
In the Nimbra 680/688 switch, it is possible to configure the capacity allocated to a board
position. Capacity is allocated in a row
row-pair fashion. A row-pair
pair consists of the two
adjacent slots in the same row (for example IF3 and IF4). The left position has an odd IF
number (for example IF3). The total capacity of a row-pair
row is always 10 Gbps,, provided a
40 Gbps switch h module is used in Nimbra 680 or an 80 Gbps switch module is used in
Nimbra 688.. The capacity can be allocated to the two slots as follows:
Option Left slot Right slot

1 (default) 5 Gbps 5 Gbps
2 10 Gbps 0 Gbps
Figure 62. Backplane capacity allocation in Nimbra 680/688.
Default is that both IF position

positions in the row-pair have 5 Gbps allocated. If the left
lef column
interface module should have the whole capacity of the row
row-pair, the module has to be
configured for that. This is described below.
Note: Note that

at both slots of a row-pair
row are affected, according to the Figure
above, by changing the capacity of one slot. Both boards in the row-
pair will be restarted.
Trunk and access modules can be classified in three different categories. Some modules
always require 10 Gbps switching capacity, some modules never require 10 Gbps switching
capacity and some modules require 5 or 10 Gbps switching capacity depending on how
they are used.
Modules that never require more than 5 Gbps switching capacity are:
4 x OC-3/STM-11 Trunk
4 x OC-12/STM-44 Trunk

8 x ASI/AES Access Module
Modules that always require 10 Gbps switching capacity are:

OC-192/STM-64 Trunk
10 Gigabit Ethernet Module (without rate limitation)
4 x OC-48/STM-16 Trunk (all interfaces in working order)
6 x IP/Ethernet Trunk Module (all interfaces in working order)
Modules that work at 5 Gbps are listed below. These modules work with increased
functionality at 10 Gbps.
4 x OC-48/STM-16 Trunk (only interfaces 1 and 2 in working order)
10 Gigabit Ethernet Trunk Module (with total rate limitation to 5 Gbps)
8 x Video Access Module (with total rate limitation to 5 Gbps)
Video Access Module v2 (with total rate limitation to 5 Gbps)
6 x IP/Ethernet Trunk Module (only interfaces 1 to 5 in working order)
J2K Video Access Module v2 (with total rate limitation to 5 Gbps)
To change the capacity allocation of an IF position, do the following:
Follow the Status → Equipment link and click on the position of one of the modules. Note
that it is only possible to change capacity on the left module in a row-pair, i.e. on positions
IF1/3/5/7. The corresponding right slot capacity is adjusted though, according to the
previous discussion. The total capacity for the row-pair is 10 Gbps.
Figure 63. Edit board page, Nimbra 600 series

Select the Requested capacity, 5 or 10 Gbps and click ‘Apply’ or ‘OK’. Furthermore, on
this page information from the various mounted SFPs is available (Digital Diagnostics).
Click the sfp link, like sfp3:1, and the web page shown below is displayed.
Figure 64. Pluggable interface page, with information from the particular SFP.

7.5 Sensors
On the sensors web page, various sensors with current values and alarm limits are shown.
Figure 65. The status sensors web page displays information on the various temperature
and other sensors in the node.
7.6 Inventory
The Inventory function describes the physical entities installed in the system.
A Physical entity or Physical component represents an identifiable resource within a
managed system. Typically, physical entities are resources like communications ports,
backplanes, sensors, daughter-cards, power supplies and the overall chassis which can be
managed. However, software/firmware images are also considered to be physical entities in
this (inventory) context, although they cannot be touched.
The Containment tree (status inventory) describes how entities are structured and contained
within each other. The use of the position entity allows modeling where a resource is

absent, i.e. a board slot position may be empty only to be filled out later. The containment
tree is listed in the inventory table.
To access the Inventory page, proceed as follows:
Click on the Status → Inventory; the Inventory page appears.
Figure 66. The Inventory page, first part
On the inventory page, the containment tree of the entire node is displayed, i.e. what
resources are available in the node and how they are structured.

Figure 67. The Inventory page, second part
For Boards on which more than two FW-images could be stored, the image that is running
is indicated as follows:
Primary: Image stored as primary
Secondary: Image stored as secondary
Running: Image that is running (could be either the primary or secondary)
For boards on which only one FW-image could be stored, only the primary image is
presented. Here, the primary image must be running.

7.7 Who (is currently logged in)
This link (Status → Who) lists all current users. To see the page, click on the link Status →
Who.
Figure 68. The Status Who page
The table shows information about other logged in users; user name, Tty (type of terminal
used), From (IP address), Login (time) and Expire (time). Inactive users are automatically
logged out at Expire time.

7.8 NTP (Network Time Protocol)
Follow the link (Status → NTP) and you’ll find the various NTP servers available for the
node listed. The table shows information about available clocks in the node.
Figure 69. The Status NTP page
Listing Description
Status ‘*’ means active NTP, ‘ ‘ inactive
Peer Address of the clock source (NTP)
Ref Id (IP) Address of the clock source/NTP
Stratum Stratum level of the clock source/NTP
Poll interval (s) is the time between two consecutive interactions with the
clock source/NTP
Delay (ms) The time for the NTP signal to go from the node to the
NTP server and back
Offset (ms) is the time offset used by the node to allow for time transfer
delay
Jitter (ms) is the jitter exhibited by the NTP servers
Figure 70. Headers on the Status → NTP page

7.9 Nodeinfo
In order to generate and download a diagnostic file about the node that is needed for
advanced troubleshooting, the link System → Nodeinfo should be followed.
The nodeinfo file that can be generated contains the status of the node. If there is trouble
with the node, it is very valuable for troubleshooting to generate the file before the node in
rebooted, as a lot of information is lost when the node is rebooted.
Figure 71. Nodeinfo
The nodeinfo file is generated and saved in the node if the button ‘Generate nodeinfo’ is
clicked and the choice is confirmed in the pop-up window.
When the file is generated, it can be viewed (View nodeinfo log). It can also be
downloaded or deleted directly (if the file was generated by mistake).

Figure 72. Nodeinfo page when the file has been generated.

8 Control Network
8.1 General about In-band management
The management network is used for managing the nodes in the Nimbra network. It is used
when an operator or application access the nodes with telnet, HTTP or SNMP. The
management network can also be used by other protocols, such as NTP (Network Time
Protocol).
Typically, the type of traffic on a management network originates from management
stations located in a network outside the Nimbra (DTM) network. The networks are
connected with one or more IP gateways. Management stations interact with relevant nodes
when provisioning connections, collecting network statistics or checking the status of the
nodes. Alarm messages are sent from the managed nodes to a set of management stations.
Communication between the management station and the nodes is usually direct; there is
rarely any communication needed between the nodes. Communication is done through a
network management system such as Nimbra Vision or directly from a web browser or
telnet session.
8.1.1 Ethernet DLE

DLE (DTM LAN Emulation) emulates a LAN (Local Area Network) as an Ethernet
segment on top of Net Insights network. It is implemented using channels throughout the
network. Seen from DLE, each node in the segment has direct connectivity to all other
nodes, as on an Ethernet segment. The underlying physical topology of the DTM network is
not related to the topology of the segment, e.g. two nodes on the same DLE segment may
be located far away from each other.
DLE DLE Segment 1

server server
DLE
Nimbra client DLE Nimbra
X client X
DTM
DLE
Nimbra client
DLE
X client Nimbra
DLE
X
server DLE Segment 2
server
Figure 73. Two separate DLE segments.
Element Manager User's Manual Control Network • 81

Note: Note that the DLE segment is a logical segment. The physical
topology exists only on the DTM level.
8.1.2 IP and routing

Each node that is connected to the DLE segment has a virtual IP interface assigned,
allowing it to communicate with other nodes on the segment using IP. A gateway routes the
IP packets
ckets to and from the segment. This means that each segment has its own IP network
address. Routing can be to other networks, i.e. DLE segments, or to an out-band
out band IP
network.
Routing will load the Control Module CPU of the gateway node. The number of packe packets
that can be routed will therefore be limited by the capacity of th
this Control Module.
8.1.3 DLE clients

Each virtual Ethernet interface is implemented by the DLE client, one client per virtual
interface. When Ethernet packets are sent from one node to another within the segment, the
client establishes a channel to the remote node. The remote node in turn establishes
establish a return
channel for any reply. This means that from each node, there will be a channel established
to every other node in the segment to which packets
packets have been sent. To reduce the number
of channels in a segment, channels can be torn down automatically or manually when they
are no longer used. By default, they are torn down automatically after ten minutes of
inactivity.
It is also possible to force all traffic to go through the server and avoid setting up channels
between DLE clients completely. This means that all DLE clients share one channel from
the server for all traffic.
E F
D A Gateway
C B
Figure 74. A DLE segment with channels between DLE clients

client

In this illustration it is assumed that all nodes communicate via the gateway (A). The
gateway has channels connected to and from all other nodes. Communication has taken
place between nodes (E) and (F) during the past ten minutes (or other configured time
interval, if the default setting is not used), resulting in an established channel between these
two nodes. It is possible to have multiple DLE clients on a single node.
Client to Server Channels and Server to Client Channels are used for broadcast packets, and
for DLE signaling.
Client to Client Channels are used for peer-to-peer communication.
8.1.4 DLE server

Each DLE segment has a DLE server. The responsibility of the server is to provide
information to the clients about other nodes in the segment and thus assist them to establish
connectivity to each other. Because the client and server must always be in contact with
each other, permanent channels are set up between them. One multicast channel is set up
from the server to all clients and one return channel is set up from each client to the server.
The channels between server and clients are also used when distributing broadcast packets.
The broadcast packets from a client are sent to the server, which distributes it to all the
other clients on the segment. Packets are also distributed this way if no client to client
channel is established between a pair of clients. Typically, this would be during the period
when a channel is being established.
8.1.5 Multiple DLE servers on a DLE segment

It is possible to use two DLE servers for a single segment. The servers co-operate and allow
for redundancy. At any time, a client is connected to only one server. The servers are
interconnected through channels, one in each direction. Client packets that would be sent
via the server to other clients are also replicated by the server and sent to the peering server
for distribution to its connected clients.
The two servers are used as alternative servers for the client. For each client, it is possible
to configure two alternative servers, where the servers must serve the same DLE segment.
When a client establishes a channel to a server, it tries the two servers in order. If a server
goes down, the client then establishes a new channel to the alternative server. This is the
way redundancy is implemented.
8.2 Configuration
Management traffic requires only moderate bandwidth. It is therefore adequate to use 512
kbps (equals one DTM slot) per channel, both between DLE servers (server-server) and
DLE clients (client-client). As the DLE client-to-server communication is only used for
signaling and broadcasting, 512 kbps is sufficient for these channels as well.
The recommendations in this document are for an in-band management network that is used
exclusively for management of the Nimbra nodes. No consideration has been taken for
other traffic. To limit the load on the DLE server, there is a recommended maximum of
DLE clients per server in one segment. To limit the load on the gateway, there is a
recommended maximum number of nodes with traffic routed through the gateway.
For availability reasons, when a single DLE server is used, it is recommended that the
gateway for a DLE segment is located on the same node as the DLE server.

Nimbra One
Critical parameters
Nimbra 300
Nimbra 600
Maximum recommended number of DLE clients for one DLE server 16 16 64
When working as gateway: maximum recommended number of 255 255 1000
nodes to route traffic for
Maximum recommended number of DLE clients on a node 3 3 3
Figure 75. Configuration recommendations of the DLE in-band network used for
managing the nodes from external management stations
8.3 Building networks with DLE

When building in-band management networks using DLE, use the recommendations
previously listed.
For networks larger than the number of nodes recommended within one DLE segment, it is
suggested that a tree of segments is built and intermediate nodes acts as gateways between
the segments. Note that the root of the tree will have to route traffic to and from all of nodes
to the external network.
Gateway
192.168.100.1 c 192.168.1.1
Gateway
DLE segment 192.168.100.33 …2
192.168.100.32/27 b
192.168.100.34 …35 …36

External network
a 192.168.1.0/24
Gateway
DLE segment 192.168.100.65 …3
192.168.100.64/27
192.168.100.66 …67 …68 DLE segment

192.168.100.00/27
Figure 76. Example of a network with three DLE segments built as a tree, and one
external network
The DLE segments have a netmask of 255.255.255.224 meaning that there can be 30 nodes
on each network (one address is the network, and one is the broadcast address). The
gateways route packets between the DLE segments and the external network.
If the Nimbra network consists of more nodes than what is recommended as the maximum
for one gateway, it is recommended to split the network into separate in-band management
networks and route the traffic to the external network with a dedicated node as the gateway.

Gateway
Tree of nodes
and DLE
segments
External management
network
Gateway
Tree of nodes
and DLE
segments
Figure 77. Large networks are divided into smaller networks, each with its gateway to the
external management network
8.4 IP routing
Setting up DLE only configures the individual DLE segments; it does not provide routing
between DLE segments. As with all IP networks, routing must be configured in each node.
Setting up IP routing for a DLE segment is not different from setting up IP routing in
general.
A routing entry consists of a destination, a netmask and a gateway. When a packet is sent to
a node outside the network, the IP address to the node is masked with the netmask of a
route. If the masked IP address matches the destination of the route, the packet is forwarded
to the gateway specified in the route. The gateway must be located on the local IP sub-
network.
On each node in the DLE segment, a default gateway routing entry should be specified.
This route is used to forward packets to nodes outside the DLE segment. The default route
is specified as destination 0.0.0.0 with netmask 0.0.0.0. This entry will match all IP
addresses. The gateway shall be the IP address of the gateway on the DLE segment.

Node a
Destination: 0.0.0.0
Netmask: 0.0.0.0 Default route
Gateway: 192.168.100.33
Node b
Netmask: 0.0.0.0 Default route
Gateway: 192.168.100.1
Destination: 192.168.100.64 This route is only necessary if you

Netmask: 255.255.255.224 want to be able to send packets from
Gateway: 192.168.100.3 network 192.168.100.32 to network
192.168.100.64.
Node c
Netmask: 0.0.0.0 Default route. The gateway is the
Gateway: 192.168.1.222 node on the external network that
acts as gateway to other networks.
Destination: 192.168.100.32 This might not be any node, in which
Netmask: 255.255.255.224 case this entry does not exist. In this
Gateway: 192.168.100.2 example, it is assumed that the
gateway is …222, which is not shown
Destination: 192.168.100.64 in the figure.
Netmask: 255.255.255.224
Gateway: 192.168.100.3
External node
Netmask: 255.255.255.0
Gateway: 192.168.1.1
Figure 78. Routing tables for a previously discussed network.
Note: Node c must have two routing entries, in addition to the default route,
one to each network (DLE segments) in the picture shown. If additional
DLE segments are defined, additional routing entries are also needed.

8.5 Control Network main web page
This section describes how to use the web interface to set up IP and SNMP parameters for
in- and out-band management. The starting web page for Control network is shown below.
Figure 79. The Control network web page
The sub-sections (links): In-band servers, In-band clients, IP interfaces, IP routing conf, IP
routing table and SNMP.
8.6 In-band servers

DLE servers use one single multicast channel for connection to all peering DLE servers.
Each server is responsible for re-establishing the originating multicast channel in case
(parts of) it goes down, after verifying that the peering server still is configured as a peer.
A DLE server must be configured in one of the units of the network, according to the
following procedure.

8.6.1 Basic configuration for In-band servers
Figure 80. Basic In-band server configuration
8.6.1.1 Administrative status

Default value: ‘Down’
Type: Boolean variable (only two states possible)
Range: ‘Down’, ‘Up’
Description: The parameter determines if the server is thought to be active (Up) or
inactive (down).
8.6.1.2 Purpose
Default value: Empty string
Range: Length 0-255 characters
Description: The parameter is an arbitrary character string that can be used for
identification purposes.
8.6.1.3 DSTI (DTM Service Type Instance)

Default value: 32769 for first defined server on the node, 32770 for the second etc
Type: Integer
Range: 0-65535
Description: The parameter is the instance number of the DLE server, i.e. the identifier of
this particular service. It is recommended to keep the default value.

8.6.1.4 Server - Client connection capacity
Default value: 0.485 Mbps, i.e. one slot per frame
Type: Real number
Range: 0 to the capacity of the trunk between server and client
Description: The capacity between the server and the client.
8.6.1.5 Server - server connection capacity

Type: Real number
Range: 0 to the capacity of the trunk between the servers
Description: The capacity between the server and the back-up server.
8.6.2 Advanced configuration for In-band servers
Figure 81. Advanced In-band server configuration
From this tab, the parameters of the exponential back-off algorithm of the re-connect time-
out are set (minimum and maximum interval). Also, the connection can be defined as
having high Precedence, which means that in case an intermediary node goes down, this
particular connection is taken down with priority and a replacement connection is set up
with priority (i.e. it has precedence over other connections).
Primary source route alarm suppress: enabled (default) or disabled
Minimum interval: The starting value of the back-off algorithm, 10 ms (default). After
tear down of a connection, connection re-establishment is attempted immediately; if this
attempt fails, another attempt is made after the configured minimum interval.

Maximum interval: The final value of the algorithm, 50000 ms (default). The re-establish
mechanism will never wait longer than the configured maximum interval to re-establish a
channel.
Precedence: Priority to take down (and set up replacement) service; can be normal or high.
8.6.3 Destinations configuration for In-band servers

Clicking on this tab gives the user a way to define a peering (back-up) DLE server. The
peering DLE server operate on the same control level and work together for redundancy
and load balance. In order to have full redundancy, the servers must back up each other.
Figure 82. Page for configuration of destination to a peering (back-up) DLE server.
Observe that destinations to clients are not set on this page.
8.7 In-band clients

An In-band client must be configured on every node in the segment, including the node(s)
with the In-band server. The web page where the configuration is made is found by
following the Control → In-band clients link.

Figure 83. In-band client configuration page
8.7.1 Basic configuration for In-band clients

Type: Boolean variable (only two states possible)
Description: The parameter determines if the client is thought to be active (Up) or
inactive (down).
8.7.1.2 Purpose
Range: Length 0-255 characters
Description: The parameter is an arbitrary character string that can be used for
identification purposes.

8.7.1.3 DSTI (DTM Service Type Instance)
Default value: 0 for first defined client on the node, 1 for the second etc
Type: Integer
Range: 0-65535
Description: The parameter is the instance number of the DLE client, i.e. the identifier of
this particular service. It is recommended to keep the default value.
8.7.1.4 Client to Client connection capacity

Type: Real number
Range: 0 to the capacity of the trunk between server and client
Description: The capacity between the client and other clients.
8.7.1.5 Tear down unused connection after

Default value: 600 seconds
Type: Integer
Range: 1 – 9999999
Description: The time after which an unused connection is torn down. Zero is a special
value that means that the link is never torn down.
8.7.1.6 Server DTM node

Default value: none
Type: DTM address or hostname of DLE server
Range: 00.00.00.00.00.00.00.00 - FF.FF.FF.FF.FF.FF.FF.FF or hostname
Description: The DTM address or hostname of the In-band (DLE) server.
8.7.1.7 Server DSTI

Default value: 0
Type: Integer
Range: 0-65535
Description: The parameter is the instance number of the DLE server that the defined
client attaches to. Observe that this default is different than the default setting of the server
itself (which is 32769).

8.7.1.8 Alternative Server DTM node
Default value: none
Type: DTM address or hostname of back-up In-band (DLE) server.
Range: 00.00.00.00.00.00.00.00 - FF.FF.FF.FF.FF.FF.FF.FF or hostname
Description: The DTM address or hostname of the back-up In-band (DLE) server.
8.7.1.9 Alternative Server DSTI

Default value: 0
Type: Integer
Range: 0-65535
Description: The parameter is the instance number of the alternative DLE server that the
defined client attaches to.
8.7.1.10 Client to server connection capacity

Type: Real number
Range: 0 to the capacity of the link between the client and the server/back-up server.
Description: The capacity between the client and the server.
The Advanced settings are identical to those of the In-band server; see section Advanced
configuration for In-band servers for additional information.
To set the parameters, select the web page by following the link Control Networks → In
band Clients, chose the values and click on ‘Apply’ or ‘OK’.
8.8 Bandwidth requirements of DLE

The bandwidth required by the In-band control function can be divided into three different
parts: server-to-client connections, client-to-server connection and client –to-client
connection. In the illustration, the server and gateway are both located on node A. Nodes B
and C have each a client connected to the server.
SCC-mc
CSC-uc
A CCC-uc
CSC-uc B C
CCC-uc
CCC-uc
CCC-uc
Figure 84. Bandwidth requirement example. Node A has a DLE server and is the gateway
to the outside world. Nodes B and C each run a DLE client.

SCC - Server to Client Connection is a multicast channel. This channel is up all the time. If
all clients are on a long chain, this channel takes one slot on every link.
CSC - Client to Server Connection is the return channel from the client to the server. This
channel is a unicast channel and the server terminates one channel from each client
connected to the server. This return channel is always up.
CCC - Client to Client Connection is a unicast channel which is established between two
DLECs. This is the channel where normally all traffic between the clients travels. The
channel is by default torn down after 600 seconds without transmitted data and is
automatically reestablished when there is new traffic. The channel normally exists between
the gateway and all DLECs. If Nimbra Vision is used, this channel stays up all the time
since NV polls every node every 120 seconds. It is possible to force data traffic to use SCC
and CSC (all data traffic is routed via the DLES server) by setting the CCC bandwidth to
zero slots on all DLECs. However, if CCC is configured to use zero slots, there is a risk that
DLES is overloaded with too much data and the result might be that the DLE server
crashes.
In our example, the bandwidth requirement is:
From A to B 1 SCC + 2 CCC = 3 DLE slots

From B to A 2 CSC + 2 CCC = 4 DLE slots
Note that the CCCs between nodes B and C are omitted in the illustration.

8.9 IP interfaces
IP interface menu configures the physical and logical Ethernet address of the interface as
well as the IP address for all logical In-band clients. This section describes how to change
the address of the physical and logical Ethernet interface and also how to change the
netmask of the subnet.
Follow the Control Networks → IP interfaces web page.
Figure 85. IP interfaces page
eth0: The physical address of the Ethernet interface

dlec0, dlec1, dlec2: The logical addresses of In-band clients
Click on the Id of the interface that should be changed.
Figure 86. IP address page
Click on the IP address and make the changes to the address and the netmask. Alternatively,
click on the ‘Add address...’ button in order to add a valid IP-address.

Note: Certain settings of IP address will make further contact with the node
impossible. This should be considered before the ‘OK’ or ‘Apply’
button is clicked.
8.10 IP routing conf

configuration
8.10.1 Routes
In order to enable routing outside an In
In-band
band segment, routes have to be configured from
the segment to the wider network.
network. Some default routes are always configured in a node, e.g.
to the subnet of a configured Ethernet interface and to the loopback interface.
Note: An IP route must be configured on every node in the DLE segment.

It will tell the node where to send IP traffic to a node outside the
DLE segment.
Click on the Control Networks → IP routing table links to get an overview of the defined
IP routes.
Figure 87. IP routing table page. Default means all addresses not otherwise mentioned.
U means that the routing entry is up, in other words active. G means that in order to reach
the destination you should use the gateway that is “pointed
nted out” by the routing entry.
The first entry, 127.0.0.0 is for the local host, which always will be there. The next four
entries describe that you can reach 192.168.101.0, 192.168.161.0, 192.168.162.0 and
192.168.163.0 directly witho
withoutut gateway. The last entry describes how to reach all other IP-
IP
addresses through the gateway 192.168.101.1.

8.10.2 Setting up IP routes
The configurable parameters for a route are:
Parameter Description Type

Destination The destination IP network that the route will use. 0.0.0.0 is Mandatory
displayed as default
Netmask The network mask to apply for the destination network. E.g. netmask Mandatory
255.255.255.0 (or netmask 0.0.0.0 for the default route)
Gateway The IP address of the node that is connected to the outside network. Mandatory
Figure 88. Configurable routing parameters
Click on the Control Networks → IP Routing Conf link. The IP routing conf page
appears. This page contains the configured IP routes on the node.
Figure 89. IP routing configuration page; default means 0.0.0.0, i.e. all addresses.
Click on the Add route button and the Add page appears.
Figure 90. Add IP route


Enter the parameters and click on ‘OK’. The Routing configuration page reappears with the
new entry.
8.10.3 IP route reconfiguration

To reconfigure an IP route, follow these steps:
Navigate to web page Control Networks → IP Routing conf and click on the route to be
verified or reconfigured. The Edit page appears.
Figure 91. Edit IP route
Change the settings and click ‘OK’ or ‘Apply’. To delete the route, click on ‘Delete’. The
Routing configuration page reappears modified.
If required, back up the configuration changes to the node controller before carrying out
this step.
Note that asymmetric routing may cause problems with SNMP/telnet/ftp. Thus, the return
route should follow the same path as the first route.

8.11 SNMP configuration
This chapter describes the SNMP (Simple Network Management Protocol) configuration
for the network element. It describes setting up of community names, SNMPv3 user, and
notification receivers.
8.11.1 Basic SNMP configuration

Click on the Control Network → SNMP link to view the Basic SNMP configuration page.
Figure 92. SNMP configuration page
The page shows information about the SNMP community names and user configuration.
The SNMP agent is a full SNMPv1/v2c/v3 agent that supports SNMPv3 security levels
noAuthNoPriv, authNoPriv and authPriv. It also shows the configured notification
receivers.
Read-only community name is the community name for SNMPv1/v2c read (i.e. get)
operations. If this community name is provided by the user, the get operations requested are
accepted; write operations are not accepted with this community name.
Read-write community name is the community name for SNMPv1/v2c read (i.e. get) and
write (i.e. set) operations. If this community name is provided by the user, then
SNMPv1/v2c read/write operations are accepted.
Notification (trap) community name is the community name sent with the notifications. If
set, notifications are sent as SNMPv2 traps with this community name. Some trap receivers
require a match of the community name, while others simply ignore this community name.
SNMPv3 user is a user name used in SNMPv3 communication with the node. This type of
user is also called a USM user. If set, SNMPv3 operations from this user are accepted with
a security level that depends on the Authentication key and the Privacy key (described
below).

Authentication key iss the passphrase used for SNMPv3 authentication of the SNMPv3 user.
If empty, then the authentication check is disabled, e.g. security level is noAuthNoPriv.
noAuthNoPriv
Privacy key is a key used for encryption of SNMP messages. If this key is absent, no
encryption takes place. Privacy can’t be used without authentication, but authentication can
be used without privacy.
Security level Explanation Comment

noAuthNoPriv No authentication, no privacy Read only usage of SNMP v3
AuthNoPriv Authentication, no privacy Read/write
d/write usage. Password needed
to communicate with the node, no
encryption
AuthPriv Authentication, privacy Read/write usage. Password needed
to communicate with the node,
encryption of data
Figure 93. Possible ways to operate SNMP v3
A fine tuned Access control can be configured from the access control tab. This tab allows
for advanced configuration of the SNMP agent, including setting up a detailed access
control.
8.11.2 Access control SNMP configuration

Access control configuration of the SNMP agent is done from the Access
ccess control tab on the
SNMP configuration web page. It is suggested that this option is only used by experienced
and knowledgeable users of SNMP agent configuration.
Note: It is strongly recommended that this advanced access control SNMP configuration is
only used by the experienced and knowledgeable user of SNMP agent configuration.
Generally, this page is used for setting up the Local Configuration Datastore (LCD) of tthe
SNMP agent. The LCD describes the configuration of the SNMP agent. All of the SNMP
agent configuration can be done using this page. The simplest and most common tasks are
more easily configured from the basic SNMP configuration page previously described and
from the Trap receiver SNMP configuration page described later.
Configuration
onfiguration done on the SNMP page is internally processed the same way as if the
configuration is made directly into the LCD.
Please refer to section 8.11.4 SNMP page internal data below for a description on how the
form on the SNMP page is internally repres
represented and related to the LCD.
The default configuration of the LCD adds configurations to the SNMP agent, which are
used by the community names, SNMPv3 user, and the notification receivers configured on
the basic SNMP configuration page.
The following is the default configuration:
Access entries for the notifiers, readers, writers, authUsers and privUsers principals are
configured from the Access control SNMP configuration page. The entries define
permissions for the different principals. You can further modify
odify the permissions of these
community names and SNMPv3 users on this configuration page.
A family tree, All, which includes all the OIDs, is used when setting up the access entries.

Entries that define how notifications (traps) are sent are included.
To edit the SNMP agent configuration, select the tab Access control from the SNMP
configuration page. The Access control configuration page appears.
Figure 94. Access control configurations page, default settings
Modify the configuration in the Local Configuration Datastore text box. The button
‘Restore to defaults’ loads the default configuration into the text box. To apply the new
configuration, click the ‘Apply’ button.
When the configuration is applied, it will pass a syntax control. If the configuration
contains syntax errors, the page will be reloaded with errors shown.
The link AuthKey Generator opens a window where an authentication key or privacy key
can be encoded for use in the LCD. The link Configuration Example provides an SNMP
configuration example.
8.11.3 Addition of an SNMP trap receiver(s)

To configure SNMP trap receivers, follow the link Control Network → SNMP and click on
the tab Trap receivers. The Add SNMP notification receiver page appears.
A notification receiver is the management station that will process notifications (SNMP
traps) sent from the network elements. You may send notifications for multiple
management stations.
IP address shows the IP addresses of the configured SNMP notification receivers. UDP port
number shows the UDP (user data protocol) port number for the notification receivers. 162
is the standard port and configured as default port.

Figure 95. SNMP trap receivers tab. Click on the ‘Add receiver’ button to add a new
receiver or the IP address link to edit the IP address of the configured receiver.
Figure 96. Add SNMP trap receivers tab. Add the SNMP trap receiver IP address in the
empty field. UDP port 162 is default, but can be changed if needed.
Click ‘OK’ to add the new notification receiver. The configuration page will be loaded
again, updated with the new notification receiver.

8.11.4 SNMP page internal data
Setting up data on the SNMP page is equivalent to setting up data on the ‘Access
Access control
configurations’ page. This section describes how the equivalent setup on th
thee latter page
corresponds to the form on the SNMP page.
Note that the entries here assume at least the default configuration in the LCD, as the
definitions in the LCD are referred to from the internal entries. Also note that
configurations on the Basic SNMP config
configuration page and the Access Control
configuration page must not be in conflict with each other. In this case, unpredictable
system behavior may happen.
Note: Configurations on the Basic SNMP configuration page and the Access Control
configuration page m
must
ust not be in conflict with each other. In this case, unpredictable
system behavior may happen.
only community name with the value public on the Access control SNMP
Setting of a Read-only
configuration page is equivalent to:
snmpCommunityEntry ‘1’ public standardReader localSnmpID - - nonVolatile

olatile
vacmSecurityToGroupEntry snmpv1 standardReader readers non
nonVolatile
olatile
vacmSecurityToGroupEntry snmpv2c standardReader readers nonVolatile
Setting of Read-write
write community name with the value private on the Access control
cont SNMP
configuration page is equivalent to:
snmpCommunityEntry ‘2’ private standardWriter localSnmpID - - nonV

Volatile
vacmSecurityToGroupEntry snmpv1 standardWriter writers non
nonVolatile
olatile
vacmSecurityToGroupEntry snmpv2c standardWriter writers nonVolatile
Setting of Notification community name with the value public on the SNMP page is
equivalent to:
snmpCommunityEntry ‘3’ public standardNotifier localSnmpID - - nonvolatile

vacmSecurityToGroupEntry
pEntry snmpv2c standardNotifier notifiers nonVolatile
Setting of SNMPv3 user name, authentication key and privacy key on the SNMP page is
equivalent to one of the following entries, depending on the entered data. When entering
user name root only:
usmUserEntry localSnmpID root usmNoAuthProtocol \

usmNoPrivProtocol nonVolatile
n - - -
vacmSecurityToGroupEntry usm root readers nonVolatile
or when entering authentication key public:
usmUserEntry localSnmpID root usmHMACMD5AuthProtocol \

usmNoPrivProtocol nonVolatile - public -
vacmSecurityToGroupEntry usm root authUsers nonVolatile
or when also entering privacy key secret:
usmUserEntry localSnmpID root usmHMACMD5AuthProtocol \

usmDESPrivProtocol nonVolatile - public secret
vacmSecurityToGroupEntry usm root privUsers nonVolatile
Setting of Notification receiver with IP address 192.168.0.1 and port 162 adds the
following per added notification receiver. The index will always be an integer value unique
per entry.

snmpTargetAddrEntry index snmpUDPDomain 192.168.0.1:162 1500 3 \
standardTrapSink standardParams nonVolatile 255.255.255.255:0 2048
8.11.5 Format of Access control SNMP configuration

The Local Configuration Datastore (LCD) is represented by a text format, where each line
represents an entry. Actually, an entry in the LCD is representing an entry in an SNMP
table. The different field for an entry represents columnar objects in the tables. The format
of an entry is in general:
Keyword value
The keyword represents the type of entry, and the value is a list of fields in the entry
separated by spaces. The keyword is actually describing what SNMP table to configure, and
the field values are the columnar objects.
Entries may span multiple lines by using a backslash (\) at the end of the entry's lines.
White-space (space) is ignored.
String values that contain blanks must be delimited by quotation marks (").
A line is considered a comment and ignored if it starts with a hash (#).
Some fields shall have an OBJECT IDENTIFIER as the value. An OBJECT IDENTIFIER
is the complete OID from the root or the MIB tree, written as numbers separated by dots.
E.g. an OBJECT IDENTIFIER for the sysName object defined in the MIB-2 systems group
would be 1.3.6.1.2.1.1.5.
If the OBJECT IDENTIFIER is not part of an enterprise specific object, the OBJECT
IDENTIFIER may be substituted by its name. The sysName object would thus be
sysName. It is possible to start the OBJECT IDENTIFIER with a substituted name, and
continue with the remaining fields. The sysName could be written as system.5 because
system represents 1.3.6.1.2.1.1, or as mib-2.1.5. Similar, all the enterprise MIB objects
can start with enterprises, as this represents 1.3.6.1.4.1.
The following entry keywords are supported. For full description on the meaning of the
entry, please refer to the description in the corresponding IETF RFC.
Keyword See also

snmpCommunityEntry RFC3584
usmUserEntry RFC3414
vacmViewTreeFamilyEntry RFC3415
vacmAccessEntry RFC3415
vacmSecurityToGroupEntry RFC3415
snmpNotifyEntry RFC3413
snmpTargetAddrEntry RFC3413
snmpTargetParamsEntry RFC3413
snmpNotifyFilterEntry RFC3413
snmpNotifyFilterProfileEntry RFC3413
Figure 97. SNMP table entries as keywords

8.11.6 Configuration Procedure
The configuration procedure involves the following steps:
Define an SNMPv3 user or community.
Define a family of view sub-trees, MIB views. The MIB view defines a set of managed
information that may be accessed.
Define a group with associated access rights. The group is assigned the MIB views for read,
write and notification access.
Assign SNMPv3 user or SNMPv1/v2c community names to the group.
The associations between the MIB views, the groups and the principals (users/community
names) are shown in the figure below.
MIB view
vacmViewTreeFamilyEntry
vacmViewTreeFamilyViewName (name)
vacmAccessReadViewName… (read/write/notify)
group
vacmAccessEntry
vacmGroupName (name)
vacmGroupName (group)
user
group
vacmSecurityToGroupEntry
vacmSecurityName (principal) vacmSecurityName (principal)
usmUserName (name) snmpCommunitySecurityName (name)

user community name
usmUserEntry - or - snmpCommunityEntry
Figure 98. MIB views, groups and users or community names
8.11.7 Defining SNMPv3 Users

At least one SNMPv3 user must be configured for the SNMP agent to send and receive
SNMP messages using the SNMPv3 protocol. In contrast, SNMPv1/v2c does not have
users. Instead they have community names, see section Defining Community). An SNMPv3
user can be defined either on the Basic SNMP configuration page (one user) or on the
Access control SNMP configuration page (multiple users).
A user is defined in the User-based Security Model, USM.
Note that an USM user is not the same as the element manager users used for the CLI or
web access of the Nimbra network element. Hence, the users defined for the element
manager are not known by the SNMP agent, and the element manger does not know about
the USM users.
A user entry is represented by the tag usmUserEntry. The format of the entry is:
usmUserEntry engineID name authProtocol privProtocol storage target authKey

engineID is always localSnmpID, which represents the SNMP agent's administratively-
unique identifier.
name is the user name, as a human readable string of up to 32 characters.
authProtocol is the authentication protocol that must be used when sending and receiving
messages for this user. The authentication protocol is used to authenticate the user. The
value is usmNoAuthProtocol if no authentication protocol shall be used,
usmHMACMD5AuthProtocol if HMAC-MD5 protocol shall be used, or
usmHMACSHAAuthProtocol if HMAC-SHA shall be used. (This value is actually an
OBJECT IDENTIFIER that represents the authentication protocol.)
privProtocol is the privacy protocol that must be used when sending and receiving
messages for this user. The privacy protects the messages from disclosure. The value is
usmNoPrivProtocol if no privacy protocol shall be used, or
usmDESPrivProtocol if CBC-DES shall be used. (This value is actually an OBJECT
IDENTIFIER that represents the privacy protocol.)
storage describes how the entry is stored. This is always nonVolatile.
target is always a dash (-).
authKey is the user's authentication password. If no authentication protocol is used, the
value shall be a dash (-). (The password is converted to a key at run-time.) The password
can be given in clear text , or as an encrypted string. To encrypt the password, use the Auth
Key Generator on the Edit Access Control page.
8.11.8 Defining Community

At least one SNMPv2 community must be defined for the SNMP agent to send and receive
SNMP messages using the SNMPv1/v2c protocols. The preferred method to define
community names is using the SNMP page.
snmpCommunityEntry index community name engineID context target storage
index is a unique index string. It does not mean anything, but must be unique.
community is the community name string that will be used.
name is the name of this entry, and will be used as the principal to refer to the entry when
setting up the security, see Defining Groups and Access Rights.
engineID is always localSnmpID, which represents the SNMP agent's administratively-
unique identifier.
context is the name of the context to which the group is part of. To gain access by this
entry, the specified context must be in use. On the Nimbra network elements, the context is
always the default context, which is represented by a dash (-).
target is always a dash (-).
8.11.9 Defining MIB Views

A family of view sub-trees is a definition that includes or excludes managed information
forms a MIB view. A MIB view is used for defining a set of managed information that may
be accessed. The definition of the family view of sub-trees may include wildcards. If no
wildcards are used, the family of view sub-trees becomes a single sub-tree.
If there are multiple sub-trees defined, then the one with most sub-identifies in its OID is
used. If multiple sub-trees are defined with the same number of sub-identifiers, then the
lexographically greatest is used.

A MIB view is represented by one or multiple sub-trees. An entry is represented by the tag
vacmViewTreeFamilyEntry. The format of the entry is:
vacmViewTreeFamilyEntry name subtree mask type storage
name is the human readable name for a family of view sub-trees, i.e. the name for the MIB
view. This is a printable string of no more than 32 characters. Multiple entries may define
one MIB view, which in this case all must have the same name. The name is used when
defining groups (see Defining Groups and Access Rights).
subtree is an OBJECT IDENTIFIER that identifies a sub-tree of the MIB, i.e. what
managed objects to include or exclude from the MIB view. The sub-tree is combined with
the mask.
mask is a bit mask which, in combination with the subtree defines a family of view sub-
trees. The bit mask is represented as a sequence of hexadecimal bytes separated by colons.
Each byte is in the range 0x00 to 0xff. A zero-length string is represented by a dash (-).
The bit mask is a series of zeros and ones, where the zeros represent wildcards, and the
ones represent an exact match. The bit mask is applied on the subtree, where the first bit
masks the first sub-identifier, and so on. The bits are grouped to bytes, which are
represented by the substring 00 through ff, and are all separated by colons (:). The last
byte is padded with ones at the end to fill out to a complete byte.
type indicates whether the entry shall define a family of sub-trees that shall be included or
excluded from the MIB view. The value of this field is included or excluded.
8.11.9.1 Example 1
The example defines a view names "All" that allows access to everything (actually,
everything under the 1 branch in the MIB tree).
vacmViewTreeFamilyEntry All iso - included nonVolatile
8.11.9.2 Example 2
The example defines a view named "noIfTable", that allows access to everything except to
the ifTable.
vacmViewTreeFamilyEntry noIfTable iso - included nonVolatile

vacmViewTreeFamilyEntry noIfTable 1.3.6.1.2.1.2.2 - excluded \
nonVolatile
8.11.9.3 Example 3
The example shows how to define a family of view subtrees that only allows access to row
9 in the ifTable. The 10th bit is a zero, which makes the 10th sub-identifier in the subtree a
wildcard (don't care). This is the columnar object.

Parameter Byte 1 Byte 2
full subtree (OID) 1.3.6.1.2.1.2.2.1.0.9
subtree (OID) 1.3.6.1 2.1.2.2 1.0.9
mask 1111 1111 101
padded mask 1111 1111 1011 1111
mask in hexadecimal 0xff 0xbf
mask as value ff:bf
Figure 99. Parameters for a family of view subtrees
vacmViewTreeFamilyEntry if9 1.3.6.1.2.1.2.2.1.0.9 ff:bf included nonVolatile
8.11.10 Defining Groups and Access Rights

A group is associating the MIB views with access rights A group is represented by one or
multiple entries, for different accesses. An entry is represented by the tag
vacmGroupName.
vacmAccessEntry name prefix model level match read write notify storage
name is the name of the group. The name is a string of up to 32 characters. The name is
used when associating access rights to users (see Assigning Users).
prefix is the name of the context to which the group is part of. To gain access by this entry,
the specified context must be in use. On the Nimbra network elements, the context is
always the default context, which is represented by a dash (-). (The prefix could be the
complete name of the context, or the prefix of a context, as defined by match; see below.)
model is the security model to which the group belongs. In order to gain access by this
entry, the specified security model must be in use. The security model can be snmpv1,
snmpv2c or usm for SNMPv3 using the USM.
level is the minimal security level. In order to gain access by this entry, the security level in
use must at least be the specified security level. The value is noAuthNoPriv if no
authentication is required and authNoPriv if authentication using HMAC-MD5 is
required. If multiple entries are equally indexed, except for this value, then the one with the
highest security level is applied.
match specifies how the prefix shall be matched. For the Nimbra network elements, it does
not make sense to set the value to anything except exact. The value can be exact of
prefix.
read is the name of the MIB view (see Defining MIB Views) that shall be used to control
what management information can be read. In order to gain read access by this entry, the
MIB view must allow access of the management information.
write is the name of the MIB view (see Defining MIB Views) that shall be used to control
what management information can be written. In order to gain write access by this entry,
the MIB view must allow access of the management information.
notify is the name of the MIB view (see Defining MIB Views) that shall be used to control
what management information can be included in a notification. In order to gain read access
for notifications by this entry, the MIB view must allow access of the management
information.

8.11.10.1 Example
vacmAccessEntry FullAccessUser - usm authNoPriv exact All All All

nonVolatile
The example defines a group named "FullAccessUser" that requires the user to have at least
the security level "authNoPriv" (authenticated, but not encrypted). The group permits
access to the MIB view "All" for read (responding to snmp-get operations), write (accept
snmp-set operations) and for notifications.
8.11.11 Assigning Users

A user must be associated with a group, where the group defines the access rights for the
user. For SNMPv1 and SNMPv2c, which do not have the user concept, the community
name is used instead.
An entry maps a security model and its user or community name to a group. An entry is
represented by the tag vacmSecurityToGroupEntry.
vacmSecurityToGroupEntry model principal group storage
model defines the security model for the entry. The model is either snmpv1, snmpv2c or
usm.
principal is the user name for the security model USM (see Defining SNMPv3 Users), or
the security name that represents the community name for SNMPv1/v2c. A default security
name is public. The community name for the public security name is modified from the
web page Status | SNMP config.
group is the name of the group (see Defining Groups and Access Rights) to which the user
or community name shall be associated.
8.11.11.1 Example 1
The example associates the USM user "root" with the group "FullAccessUser".
vacmSecurityToGroupEntry usm root FullAccessUser nonVolatile
8.11.11.2 Example 2
The example associates the community name "public" for SNMPv2 access to the group
"ReadOnlyUser".
vacmSecurityToGroupEntry snmpv2c public ReadOnlyUser nonvolatile

9 DTM Configuration
9.1 Overview of DTM configuration
This chapter describes how to use the web interface to configure and monitor the DTM
DTM-
layer. The starting web page for DTM is shown below.
Figure 100. The starting

ing web page for DTM
The sub-sections (links) are: Interfaces, Addresses, Hostnames,

names, Hostname search, Links,
Routing, Sync and Time transfer.
Note: Make sure to have all the information that the operation requires,
before starting any configuration operation. This will help you to
minimize the downtime of the system.
Element Manager User's Manual DTM Configuration

onfiguration • 110

9.2 Interfaces
The starting web page for Interfaces is presented.
Figure 101. DTM interfaces page
The table lists the DTM interfaces that are present in the unit. For each interface the
following is presented: Name (name of the interface), Capacity (in slots), Free (unused
capacity, in slots), Tx slots (used slots in the Tx direction) and Tx cap % (used fraction of
slots in the Tx direction), Rx slots and Rx cap % (used fraction of slots in the Rx direction).
In addition, Adm and Oper shows the Administrative and Operational state of the interface.
The interface name is written as “dtmX:Y”, where X is position of the card in the node and
Y position of the port, on the card.
9.2.1 Editing a DTM interface

To edit a DTM interface, click on the Name of the interface that should be edited.
Element Manager User's Manual DTM Configuration • 111

Figure 102. DTM Interface, Edit page

The configurable parameters are:
Parameter Description Type Possible Default

name Values
Admin. status The administrative status of the Binary, Up Up, Down Up
board. or down
Purpose Identifying field, selected by the user Text string Any 0-255 Empty
character(s) string
long string
Link class Type of link Enumerated Normal, Normal
list Persistent or
Nailed
Control channel Extra bandwidth of the control Integer 0 to the 0
capacity channel, in addition to one slot capacity of
always allocated, expressed in slots link
per DTM-frame (1 slot = 512 kbit/s)
Enable dynamic This tick box is selected if Dynamic Binary Ticked, Ticked
routing routing (DRP) should be used. unticked
Metric for The cost of using this interface when Integer 1-99999 1
dynamic routing dynamic routing is used.
Allow as sync This tick box is selected if the Binary Ticked, Ticked
source synchronization extracted from the unticked
link should be allowed as DTM
synchronization source in the node.
Figure 103. Configurable parameters for a DTM interface
Read-only parameters (variables) are:
Interface name The interface id, written as “dtmX:Y” (where X is position of the card and Y
position of the port).
Operational status The operational status of the board.
Transmit capacity The total number of time slots available for transmission on this interface.
Used transmit The number of used time slots from this node to the peering node.
capacity
Used receive The number of used time slots from the peering node to this node.
capacity
Interface MAC A globally unique hardware identifier for this interface card.
address
Failure on An error reported by the underlying trunk interface. (LOF loss of frame.)
underlying interface
alarm
Reduced control The node is not able to signal the remote node. This usually indicates a
capacity alarm problem in the TX direction for the link.
Figure 104. Read-only parameters (variables) of a DTM interface

9.3 Addresses
This chapter describes how to configure the DTM addresses of the unit. The DTM address
must be configured before any configuration of services can be done.
Each node can have one primary DTM address and several alias addresses. The primary
address (marked with a symbol in the “Primary address” column), in the table below, is
always used as the source address when the node establishes a channel. In addition to the
primary address, a node also accepts channels to all its alias addresses.
The address “00.00.00.00.00.00.00.01” is a loop back address that all nodes listen to. It is
equivalent to the address 127.0.0.1 in an IP-node.
Click on the DTM menu item and then click on Addresses. The DTM Addresses page
appears.
Figure 105. DTM address page
The table shows information of the configured addresses as follows:

DTM address: The configured (primary) DTM address for the unit and one loopback
(always 00.00.00.00.00.00.00.01) address to the back plane. On occasion, more than one
DTM address can be assigned to the node, but only one address can be primary.
Primary address: Indicates which address is the “default” for the node.
9.3.1 Adding a DTM address

Go to the DTM addresses page and click on the Add address button. The ‘Add address’
page appears.

Figure 106. Add DTM address page
Enter the DTM address and whether the address is Primary or not and then click
lick ‘OK’. The
DTM addresses page will reappear with the new address listed in the table.
Back up the configuration changes and restart the node.
9.3.2 Editing
ing or deleting a DTM address
Go to the DTM addresses page and click on the address that is to be revised or deleted. The
following page appears:
Figure 107. Edit DTM address page
Change the parameters as desired and click ‘OK’.
Note: If the primary address of the node is changed, the configuration must
be saved and the node must be restarted for the changes to take effect.
Note also that the address change does not affect existing channels.

9.4 Hostnames
Nodes in a DTM network can be assigned names using the hostnames function. Hostnames
are configured locally in each node and used as aliases for a DTM address.
To configure host names, click on the link DTM → Hostnames. The following page
appears.
Figure 108. Hostnames page
The Hostnames page shows the DTM nodes with their DTM addresses and hostname.
Remember to include the list of the hostnames in every node; all the nodes in the network
must know all the hostnames!
9.4.1 Adding a host

Go to the hostnames page and click on the Add host button. The following page appears:
Figure 109. Add DTM hostnames page
Enter the DTM address and the selected hostname associated with the address. Click ‘OK’.
The DTM hostsnames page reappears with the newly defined address and hostname.

There are some syntax rules for host names. Host names can consist of letters, numbers and
characters dot ‘.’ and dash ‘-‘, but must start with a letter. Examples of valid hostnames are:
node10.neti.se, node12.academy.net-insight.net
It is possible, but not recommended to specify several names per address, by entering each
name on a separate line. Only the name on the first line will be shown on the hostname
page; use several entries with the same DTM address instead if the need of using multiple
host names exists.
A list of host name suffixes may be defined in the web interface. The completion function
searches for a match, starting with the top suffix defined in the list. To access the suffix
definition page, follow the DTM → Hostname search link.
Figure 110. Editing DTM hostname suffixes. The example with academy.se makes it
possible to name the node node10.academy.se but still only use node10 as
hostname for configurations.
Hostname search Full name Short name

entry(suffix)
lab iov101.lab iov101
academy.se node5.academy.se node5
netinsight.net iov072.netinsight.net iov072
netinsight.net cus033.netinsight.net cus033
Figure 111. Summary of some allowed short names, provided that the suffix has been
defined on the hostname search page defined on the node.
The short names can be used for configuration of these nodes, provided that the appropriate
hostname search page has been saved on all nodes that need to know about the node. As it,
for obvious reasons, is hard to know what nodes must have the definition, it is best to
include the hostname search list in all nodes.

9.4.2 Editing or deleting hostnames
Navigate to the DTM hostnames page and click on the address for the host to be edited or
deleted. The Edit DTM Hostnames
Host page appears.
Figure 112. Editing DTM hostnames
Change the parameters and click ‘Apply’ or ‘OK.

To delete a host, click the ‘Delete’ button. The DTM hostnames page reappearss with the
host removed from the table.
Note: Changes to a hostname do not affect channels that have already been
established. Th
The hostname table is only consulted when a channel is
established.
9.5 Links
The Links page shows all DTM links that the node is connected to. The page can be used to
check if links to surrounding nodes have been properly
prop established. For each link id there
should be two addresses; the node address and the address to the remote node.
The link-table
table lists all the links that this node is attached to along with all other nodes that
are attached to these links. Each line in the table represents an interface and tthehe node that
the interface is located in.
Each link starts with an Id, which is equal to the Idd of a local interface. It lists the other
interface connected to that link before starting a new link with a new id.
Click on the DTM → Links link. The Links page appears.

Figure 113. DTM links page
The variables that are presented are:
Id: The local interface that is connected to the link.

i/f MAC addr: Lists the MAC address of the opposite (remote) interface.
Node MAC addr: Lists the MAC addresses of the opposite (remote) node.
Node addr: Shows the node address or node host name of all opposite (remote) nodes
connected to the link.
Oper: Operational Status (OperStatus)
Last change: Time for last DTM link change
9.6 Routing
9.6.1 General
To establish channels in a network, the nodes must know where to find all other nodes in
the network. The process of finding a path from node A to B in the network is called
routing.
Routing in a DTM network has a lot in common with routing in an IP network. The table
below lists the main differences between IP-routing and DTM routing.
Parameter name IP DTM

What is routed? Packets Channel-setup requests
How do you specify how to One nexthop per All possible nexthops to the
reach a destination? destination destination.
Address type IP address DTM address
Figure 114. Differences between routing in an IP network and a DTM network
This section describes how to configure routing. There are two different ways to configure
routing:

Static routing is where the routing tables are configured manually.
Dynamic routing is where a routing protocol calculates routing tables automatically.
Note: Do not mix dynamic routing with static routing since this can lead to
errors that are difficult to troubleshoot.
9.6.2 Static routing

To use static routing, it is necessary to configure each node in the network with information
on how to reach all other node
nodes in the network. For nodes with a single interface and a
single neighbor, this is as easy as instructing the node that all other no
nodes
des can be reached
via that neighbor; but for nodes with multiple interfaces it is necessary to configure which
neighbor to use to reach each destination or group of destinations.
Static routing is configured in the Routing Table. The routing table can be seen in the DTM
→ Routing page. The routing table consists of a number of routing entries. Each routing
entry contains the fields shown below.
Field Description
Administrative The aadministrative status for the route has to be set to up, in order for the node to
status be taken into account when routing decisions are made
made.
Type Shall be set to “Static” for static routing entries. See the chapter on DRP for a
description of “Link Prefix” and “Area Prefix”.
Destination The ddestination
estination and prefix together specify which destinations this routing entry is
valid for; refer to section Addresses for a description of addressing. The destination
must be a numeric DTM address.
Prefix The number of significant bits in the destination address.
Next hop One possible next hop node that can be used to reach the destination node(s). The
next hop must be the DTM address of a neighboring node.
Metric The cost of using this route entry. If there are several routes to the same
destination, then routes with the lower metric are tried before routes with higher
metric
Figure 115. The routing entries
When a node needs to find a nexthop for a destination it looks in the routing table for all
entries that match the destination address. This gives the node a list of a number of different
nexthops that it tries to use to reach the destination
destination.
Note: If there are several routing entries with different prefix lengths that are
valid for a destination, then only the entries with the longest prefix will
be used. If there are several entries with the same prefix length, then
they will all be tried in order of increasing metric.
Note: If the routing is poorly configured in a node, the operation of the entire
network can be affected.

Figure 116. Configuration of static routes
9.6.3 Dynamic routing

Instead of configuring the routing tables manually in each node; a routing protocol can be
used to populate the routing table automatically. This is called dynamic routing. In a DTM
network, the routing protocol DRP can be used.
Dynamic routing has the following advantages over static routing:
Less manual configuration required for large networks
Automatically updated routing tables when the network topology changes
Automatic routing is not error-prone.
The DRP Protocol is a routing protocol that is very similar to OSPF, but it has been adapted
to the unique characteristics of the Net Insight’s technology. It automatically calculates the
routing tables in all nodes and updates them as changes are detected in the network.
To use DRP, all that is necessary is to enable DRP on all nodes in the network and then
remove all the static routing entries that have been added to the nodes as shown in the
section on Static Routing.

9.7 Static routing
9.7.1 Adding, editing or deleting a static route
Follow the link DTM → Routing. The starting web page for Routing configuration is
shown.
Figure 117. Routing
Click on ‘Add source’ or the specific link that is to be edited or deleted; the Route page
appears.
Figure 118. The edit route page
The parameters and variables used are:
Route id: This is the id of the routing entry

Administrative status: The Administrative status for the defined routing entry; ‘Down’
means that the route is ignored, ‘Up’ means that the routing entry is used.
Type: The type of routing entry. Set to static for static routes. The alternatives ‘Link prefix’
and ‘Area prefix’ are used for dynamic routing and explained later.
Destination: The address of the remote node or network.
Prefix: The length of netmask for the remote subnet, i.e. the number of (starting) bit that
needs to be in agreement with the DTM address of the remote node.
Prefix 64 or /64 is equal to a mask of FF.FF.FF.FF.FF.FF.FF.FF, which means that the

destination is only made for one node. Prefix 56 or /56 is equal to a mask of
FF.FF.FF.FF.FF.FF.FF.00, i.e. the defined route is shared by nodes with identical first 56
bits in the DTM address. Prefix 48 or /48 is equal to a mask of FF.FF.FF.FF.FF.FF.00.00,
i.e. the defined route is shared by nodes with identical first 48 bits in the address.
Next hop: The DTM address of the neighboring node that can be used to reach the
destination. Used only for static routes.
Metric: The cost associated with using this route. A route with a lower metric will be tried
before a route with a higher metric.
After configuration is done, click on ‘Apply’ or ‘OK’ to save the settings. ‘Delete’ is used
to remove the route and cancel is used to cancel the action. Observe that the route is created
when the ‘Add source button is clicked and to remove the route, the delete button should be
used in the second step.
9.8 Dynamic routing

9.8.1 Setting the dynamic routing parameters
Go to the routing configuration web page and click on the Dynamic routing tab.
Figure 119. Dynamic routing

The goal of DRP is to find the lowest-cost
lowest cost path from source node to destination node. The
cost of a path is defined as the sum of the cost of all switches and outgoing interfaces that
the path uses. A good base configuration for DRP is to set the cost of all ll outgoing interfaces
to 1 and the cost for passing through all nodes tto 0 (i.e. to use the default configuration)
configuration).
This means that the lowest cost path is always the path that passes through the least number
of links. In some circumstances, the operator might have a different opinion on what the
lowest cost path is. It is then possible to classify some links or switches as “more
expensive” than other links. This is done via a set of configuration variables called
“metrics”.
Changes to the Metric settings in a node will be automatically propagated to all other nodes
in the network and they will update their routing tables accordingly. This process can
however take some time (on the order of seconds in smaller networks) before all nodes
have received the new information. Changes to metrics do not affect channels that are
already established.
Node metric:: The cost of switching a channel in this node
node,, with default value 00.
Interface metric:: The cost of setting up aan outgoing channel via this interface,, with default
def
value 0.
Enable: Allows the node to communicate and exchange routing information ion with
neighboring nodes via this interface? Th
The check box should be selected when using DRP. It
can be disabled when DRP is not to be used via the specific interface, e.g. when the
interface connects to another operator
operator. The box is selected by default.
Under the header advanced settings, additional configuration is made. If a node is attached
to the rest of the DTM network with a single point-to-pointt link, the node doesn’t need a
complete routing table. The only routing entry necessary is the default route to the node on
the other side of the point-to-point
point point link. In DRP terminology, this type of node is called an
end-node; all other nodes are called switches. By default , the node is configured as a
switch.
Note: If a node is configured as an end node, it can only originate and

terminate channels; it cannot switch channels.
gateway: Ticking this box forces the node to automatically find its gateway.
Detect default gateway
This is only
nly relevant for end-nodes.
end For switches, the box is grayed out (default).
(default)
neighbors This box is only visible when the user selects area number ‘Select
Detect from neighbors:
from neighbors’. Whenever it is visible, it is by default select
selected. This makes the node
request its area number (see below) from its neighbor(s).
Area number: By default, DRP distributes information about all nodes and links to all
nodes in the DTM network. This allows all nodes to make "optimal" routing decisions since
they have complete knowledge about the current topology. As the network grows larger, the
amount
unt of information distributed by DRP grows and eventually becomes too large for a
node to handle efficiently. Exactly how large a network must be before the amount of
routing information becomes too large depends on both the number of nodes, the
connectivity
ity between the nodes (i.e. the number of links) and the types of nodes in the
network. It also depends on how often the network topology changes and the network
topology itself.. As a rule of thumb, it is possible to run a network with 250 nodes without
worrying
rrying about the amount of routing information. If your network is larger than that, you
should consider using Areas.
Areas are also useful to limit the amount of routing
routing-information
information distributed between two
different operators.

9.8.2 Area Definition
An area is defined as a set of interconnected nodes configured with the same area number.
All nodes in an area must be able to reach all other nodes in the area without passing
through a node that belongs to a different area.
A node can only belong to one area.
Links do not belong to an area. A link can interconnect two nodes that belong to different
areas.
Two nodes that belong to the same area will exchange information about all nodes and links
within their area. Two nodes that belong to different areas will only exchange Area Prefix
routes (see below).
n1 n2
Area A1 Area A2
Border nodes
Figure 120. A network divided into two areas.
A node that is a member of one area, but has one or more links to a node in another area, is
called a border node.
9.8.3 Area Planning

Dividing a network into areas require careful planning. There are a number of issues to
consider before deciding where a network should be split into areas.
First of all, connectivity between areas should be as simple as possible. A node in one area
will not know anything about what another area looks like on the inside. It only knows the
shortest path to the area, not which path is shortest towards a particular destination inside
another area. Therefore, all border-nodes for an area should preferably have more or less
the same cost towards all destinations inside the area.

1
2 3 5
Figure 121. A network that has been divided into two areas in a bad way.
In the illustration, the distance from node 1 to node 5 is shorter if the channel is routed via
node 3 than if it is routed via node 2. In addition, the distance from node 1 to node 4 is
shorter via node 2. However, if a single area prefix route is used, then node 1 will think that

the distance to nodes 4 and 5 are the same and it doesn't matter if it routes the traffic via
node 2 or 3. This will lead to sub-optimal routing decisions.
This problem can be fixed by using more than one area prefix route to tell nodes in the
upper area if there are some groups of nodes that are cheaper to reach via one of the border
nodes than via the other. The extreme would be to add one area prefix route per node in the
area, but then you would be better off with all nodes in a single area.
2 3 5
Figure 122. A better way to build the network. Note the new link between nodes 2 and 3.

A better network layout is shown here. Here, a new link has been added between nodes 2
and 3. This means that it matters less if node 1 chooses to run the channel via node 2 or
node 3.
All nodes in an area should share a common addressing prefix. This prefix is independent
from the area number; it is only needed to announce to nodes in other areas which nodes
reside in this area. It is possible to have nodes with different prefixes within an area, as long
as one area prefix route is configured in each border node for each address prefix in the
area.
9.8.4 Area Prefix Routes

Area Prefix routes are used to distribute information about which nodes are inside an area
to nodes in other areas. They are configured in the border nodes and they are only
distributed to nodes in other areas, i.e. not to nodes in the same area as the border node that
the area prefix route is configured in. Area Prefix routes received from another node are
distributed to all nodes in the same area as the receiver, but not to nodes belonging to other
areas.
Example: an area prefix route configured in node n1 in Figure 120/Figure 123 is distributed
to all nodes in area A2. This route tells nodes in area A2 that they can reach nodes in area
A1 by going through node n2.
9.8.5 Directly Connected Areas
Area A1 Area A2
X.17.01.3A X.17.02.21
Figure 123. A network with two areas.
In the above example, the network has been divided into two areas called A1 and A2. All
nodes in area A1 have addresses in the range X.17.01.00/56 (X is used here as a short-hand
for 00.00.00.00.00) and the nodes in area A2 have addresses in the range X.17.02.00/56. If
no area prefix routes are used, nodes in area A1 are not able to establish channels to nodes
in area A2 and vice versa.
To allow nodes in area A1 to find nodes in area A2, an area prefix route must be added to
node X.17.02.21. This area prefix route should advertise the network X.17.02.00/56 to
nodes in area A1.

node X.17.01.3A. This area prefix route should advertise the network X.17.01.00/56 to
nodes in area A2.
9.8.6 Indirectly Connected Areas

If two areas are not directly interconnected, area prefix routes must be configured for all
areas that can be reached through that area.
Area A1 Area A2 Area A3
X.17.03.13
X.17.01.3A X.17.02.21
X.17.02.28
Figure 124. A network with three areas.
In the above example, the following area prefix routes must be configured:
nodes in area A1.
nodes in area A1.
node X.17.01.3A. This area prefix route should advertise the network X.17.01.00/56 to
nodes in area A2.
nodes in area A2.
nodes in area A3.
nodes in area A1.

9.8.7 Metrics for Area Prefix Routes
Each area prefix route has an associated metric that decides how "expensive" it is to use this
particular path to the area. This is useful if two areas are interconnected by two different
pairs of nodes where one path is preferred over the other. It is also useful if it is possible to
reach an area both directly and via another area. Then the area prefix routes can be
configured so that the direct path has a lower cost than the path via another area.
9.8.8 Configuration
To implement DRP areas in your network, the following configurations must be made:
Configure the area number that the node shall belong to in each node. This is done from the
DTM → Routing → Dynamic routing config link.
Configure area prefix routes in the border nodes. This is done from the DTM → Routing
link.
Note that the area prefix is only configured in the area prefix routes; you never actually
configure the area prefix for an area. The correlation between an area and an area prefix is
only maintained to make it possible to configure a single area prefix route that covers all
nodes in an area and no other nodes.
9.8.9 Addition of a dynamic routing entry

To add a dynamic route, follow the DTM → Routing link. Click on the ‘Add source’
button. The static routing web page appears.
Figure 125. Dynamic routing

Figure 126. Dynamic routing, with available Type selections.
For dynamic routes (i.e. not static), the type could be set to:
9.8.9.1 Link Prefix

If there are many end-nodes with addresses with a common prefix attached to a single node,
then it is possible to announce all the end-nodes as a single route instead of announcing
them individually. This is done by configuring the end-nodes as end node (in Dynamic
routing config) and adding a link-prefix route in node s1.
X.17.01 n1
X.17.02 n2 s1
X.17.03 n3
Figure 127. Routing entries
Nodes n1, n2 and n3 are configured as end-nodes and they have DTM addresses that all fall
in the range X.17.00/60 (i.e. from X.17.00 to X.17.0F). A link-prefix route can therefore be
added to the node s1. This means that instead of announcing n1, n2 and n3 individually, s1
will announce only X.17.00/60. Instead of each node in the DTM network having three
separate routes for n1, n2 and n3, they will only have a single route that covers all three of
them (and any possible additional end-nodes added later in the same DTM address range).

9.8.9.2 Area Prefix
A network can be divided into areas to increase the scalability of DRP. Each area is
identified with an area number that must be configured in each node belonging to the area.
The default value of the area number is zero. A border node is a node that has at least one
neighbor that resides in another area. Two border nodes with different area numbers will
not become adjacent and exchange topology state information automatically.
9.8.10 Editing or deleting a dynamic routing entry

To edit a dynamic routing entry, follow the DTM → Routing link and click on the address
of the route to be edited. The page below appears:
Figure 128. DTM Routing config page
Enter the values that should be changed. Click Apply or OK.

To delete the route, click on the ‘Delete’ button instead. The routing entry is removed.

10 Trunks
10.1 Overview of Trunks
Trunks of various types connect the nodes of a Nimbra network. The trunks can be of
different types; 8B/10B, SONET/SDH, PDH and IP/Ethernet.
The trunk interface manager supports 8B10B, SONET/ SDH, PDH and IP/Ethernet
interfaces. The main functional areas covered by the manager are Trunk interface
configuration including alarm reporting and performance monitoring. Performance
Monitoring is described in a separate chapter.
Normally, the trunk is configured from one web page, but the IP trunk and the Ethernet it
runs over are configured on separate web pages.
10.1.1 Trunk Modules, Nimbra One

There are several different trunk modules. Some of the cards are turnable and some are
available in type A and B versions.
Trunk Modules Data rate Category

OC-48/STM-16 X-ADM Module 2 488 Mbps SDH/SONET
OC-12/STM-4 Trunk Module 622 Mbps SDH/SONET
(DTM 622 Trunk Module)
2 x OC-12/STM-4 Trunk Module 2 x 622 Mbps SDH/SONET
4 x OC-3/STM-1 Trunk Module 4 x 155 Mbps SDH/SONET
(DTM 150 Trunk Module)
4 x DS3/E3 Trunk/Access Module DS3 45 Mbps PDH
E3 34 Mbps
3 x IP/Ethernet Trunk Module 1 000 Mbps IP/Ethernet
Figure 129. Available Trunk Modules for Nimbra One.
Element Manager User's Manual Trunks • 133

10.1.2 Trunk Modules, Nimbra 300
There are several versions of trunk modules, according to the table below. From a web
management point of view, all Nimbra 300 trunk modules have a Nimbra One mirror image
and behave identically as it in the GUI interface. Hence, no separate description is made of
Nimbra 300 Series trunk modules.

OC-48/STM-16 X-ADM Module 2 488 Mbps SDH/SONET
2 x OC-12/STM-4 Trunk Module 622 Mbps SDH/SONET
4 x DS3/E3 Trunk/Access Module DS3 45 Mbps/E3 34 Mbps PDH
3 x IP/Ethernet Trunk Module 1 000 Mbps IP/Ethernet
Figure 130. Available trunk modules for Nimbra 340.
10.1.3 Fixed trunk interfaces for Nimbra 310/320/360/380

Nimbra 310/320/360/380 has integrated fixed SDH/SONET trunk interfaces on the base
unit. One interface type is installed among the options below. The difference is in the
firmware, which can be changed in the field. In addition, the IP/Ethernet trunk can run on
two of the fixed ports, provided that the hardware supports it.
Fixed Trunk Interfaces, Nimbra 320/360/380 Data rate Category

OC-48/STM-16 X-ADM Interface (2 ports) 2 488 Mbps SDH/SONET
OC-12/STM-4 Trunk Interface (2 ports 320; 4 ports 360/380) 622 Mbps SDH/SONET
OC-3/STM-1 Trunk Interface (2 ports 320; 4 ports 360/380) 155 Mbps SDH/SONET
IP/Ethernet Trunk Interface; requires Nimbra320, Nimbra 360, 1000 Mbps IP/Ethernet
HW version B or Nimbra 380 (2 ports)
Figure 131. Fixed trunk interfaces for Nimbra 320/360/380.
Fixed Trunk Interfaces, Nimbra 310 Data rate Category

OC-48/STM-16 X-ADM Interface (1 port) 2 488 Mbps SDH/SONET
OC-12/STM-4 Trunk Interface (1 port) 622 Mbps SDH/SONET
OC-3/STM-1 Trunk Interface (1 port) 155 Mbps SDH/SONET
IP/Ethernet Trunk Interface (1 port) 1000 Mbps IP/Ethernet
Figure 132. Fixed trunk interfaces for Nimbra 310.

10.1.4 Trunk Modules, Nimbra 600
There are several versions of trunk modules, outlined in the table below. These modules
look slightly different in the web interface than corresponding ones in the web interface of
the Nimbra One/300.

OC-192/STM-64 Trunk Module 9 952 Mbps SDH/SONET
4 x OC-48/STM-16 Trunk Module 2 488 Mbps SDH/SONET
6 x IP/Ethernet Trunk Module Configurable, up to 1000 Mbps IP/Ethernet
10 GE Trunk Module Configurable, up to 10000 Mbps IP/Ethernet
Figure 133. Trunk Modules for Nimbra 600. The available data rate could be limited by the
amount of capacity between the module and the switch module (i.e. the
aggregate capacity of the DPP links).
10.1.5 Trunk interfaces configuration

The starting web page for the Trunks link is shown in below.
Figure 134. The starting web page for Trunks
The sub-links are: Trunk Interfaces, Ethernet Interfaces and Perf. monitor. Trunk Interfaces
is where the various trunk modules are configured and their state is monitored. Ethernet
Interfaces is where the Ethernet part of IP/Ethernet trunk interfaces is configured and Perf.
monitor is where performance monitoring for the interfaces is defined.
Performance monitoring (PM) is the process whereby transported data is supervised for
quality deterioration. Performance monitoring uses SNMP counters (ITU-T G.826 like) on
trunks, interfaces and connections. For further information, see the chapter on Performance
Monitoring.
To configure the trunk interfaces, just follow the link to Trunk Interfaces. Select the trunk
to be configured by clicking on the Name of the trunk (e.g. sonet/sdh-3:1, pdh-5:1, ipt-5:4).
The following information is presented on the web page:

Name is the name of the interface, according to Net Insight naming convention
Mode is the type of interface
Capacity is the total capacity of the trunk interface in Mbps
Admin is the administrative status of the trunk interface. This is only relevant for IP trunk
interfaces; for interfaces lacking this parameter, nothing is displayed in this column.
Oper is the operational status of the trunk interface (up, down, absent, starting or degraded)
10.2 Editing SDH/SONET Trunk Interfaces

The basic structure of the configuration page is kept constant for the various interfaces in
Nimbra One and Nimbra 300.
First, interface specific variables are presented, followed by configurable parameters. These
parameters are followed by additional configurable “advanced” parameters under the
advanced heading and sometimes by additional variables. Finally, the alarm status is
presented.
The common Read-only parameters (variables) are:
Interface name The interface name. Written as “sonet/sdh-X:Y” where X is slot position of the
module and Y port position of the interface on the module.
Operational status The operational status of the board
Speed Capacity of the interface
SOH S1 (SSM) Synchronization Status Message (4 bits) in the section overhead
Description The number of slots available for transmission on this interface. Used on OC-
3/STM-1 Trunk Module only
Figure 135. Read-only parameters for SDH/SONET interfaces
Additional variables for OC-48/STM-16 X-ADM Module are:
Transceiver temperature Temperature of the transceiver
Transceiver laser bias Laser bias current of the transceiver laser
Transceiver power Optical power transmitted from the transceiver
Receiver power Optical power received on the transceiver
Figure 136. Additional variables for the OC-48/STM-16 X-ADM Module

The configurable parameters for the common interfaces are:
Suppress Alarms When the service is up and running as intended, alarms are by
default suppressed. In order to enable the alarms, the suppress
alarms tick boxes must be unmarked.
All: When marked, all alarms are suppressed.
AIS: Alarm indication signal.
RDI: Remote defect indicator.
Figure 137. Configurable parameters for common interfaces
The configurable Advanced parameters for SDH/SONET trunk modules are:
Parameter Description Comment

Transmit sync Define the sync source for the transmitting (Tx) interface. Not used for OC-
source The parameter can have two values, ‘interface’ and ‘loop’. 48/STM-16 X-ADM
The default setting is ‘interface’, which uses the node sync Trunk Module or
source as source for the outgoing Tx interface. ‘loop’ Nimbra 600 OC-
means that the incoming Rx signal is reused on the Tx 48/STM-16 Trunk
interface. This setting should not be used at both ends of modules
the link!
H1 SS bits Different between Sonet and SDH.
This value is the value of the SS bits in the H1 byte in the
Sonet/SDH section overhead. Older Sonet/SDH equipment
may require other values than the default values
(00 Sonet; 10 SDH)
POH C2 byte Path overhead Used on 4 x OC-
The C2 byte in the path overhead specifies what type of 3/STM-1 Trunk
network is used. ITU-T has not yet assigned a C2 value for Module and OC-
DTM networks, so for DTM networks use ‘05’ as the ITU- 48/STM-16 X-ADM
T ‘experimental’ value. Module
Signal failure Delay time for 1+1. The time that the nodes waits for the
filter period underlying network (SDH/SONET/WDM) to re-establish
connection, in order to avoid a switch-over.
Default 50 ms, Range 0-2000 ms
Degraded Configuration parameters for the “Degraded” alarm, Not used for OC-
defect (DEG) according to ITU G.806 for the interface. 48/STM-16 X-ADM
period Period, default 5 sec. Trunk Module or OC-
3/STM-1 (DTM 150)
Trunk Module
Degraded Configuration parameters for the “Degraded” alarm, Not used for OC-
defect (DEG) according to ITU G.806 for the interface. 48/STM-16 X-ADM
threshold Number of background block errors. Default 1200. Trunk Module or OC-
3/STM-1 (DTM 150)
Trunk Module
Figure 138. Configurable Advanced parameters for SDH/SONET trunks.

Additional read-only parameters (variables) are presented under the Advanced heading:
Parameter name Description

Error counters B1 Section overhead
B2 Line overhead
B3 Path overhead
M1 Remote indication of B1
G1 Remote indication of B3
Pointer adjustment RXPJE+

event, positive and RXPJE-
negative
TXPJE+
TXPJE-
Overhead bytes SS=2 C2=5 (default)
Figure 139. Additional advanced read-only parameters
The OC-3/STM-1 Trunk Module only display error counters B2 and B3.
The Alarms parameters are presented at the bottom of the table as:
Alarm Description
Opto module Alarms from SFP. The Opto Module alarm is not available for the OC-
3/STM-1 Trunk Module.
Unequipped (UNEQ) This alarm is received from the other end of the link, indicating that the
payload is not usable.
Los of signal (LOS) Loss of signal. No signal detected on SONET/SDH network interface,
no light in the fiber.
Los of frame (LOF) Loss of frame. Unable to align SONET/SDH frame, no light in the
fiber.
Los of pointer (LOP) Loss of pointer. No pointer for where payload is.
Alarm indication signal, Alarm indication signal, line or defect detected by upstream
line (AIS-L) SONET/SDH network interface.
Alarm indication signal, Alarm indication signal, path or defect detected by upstream
path (AIS-P) SONET/SDH network interface.
Remote defect indication, Remote defect indication, line or defect detected by downstream
line (RDI-L) SONET/SDH network interface.
Remote defect indication, Remote defect indication, path, RDI-P or defect detected by
path (RDI-P) downstream SONET/SDH network interface.
Payload mismatch (PLM) Payload mismatch.
Degraded signal (DEG) Degraded signal
Loopback Loopback alarm, NA
Figure 140. Alarms parameters
As an example, configuration of one interface on the OC-12/STM-4 Trunk Module is

given.

Figure 141. Configuration page of the OC-12/STM-4 module, part one. Digital diagnostics
are values reported directly from the SFP.

Figure 142. Configuration page of the OC-12/STM-4 module, part two. This page displays
the status of possible trunk alarms.
10.2.1 Asymmetric alarm generation

When the DTM link is taken down between a Nimbra 680/688 and a Nimbra 300
series/Nimbra One, alarms are generated. As it is possible to take down the link in only one
direction on Nimbra 680/688, but this feature is missing on Nimbra 300/Nimbra One
alarms are not generated symmetrically in this case.
Observe that to see these alarms at all, the default setting of alarm suppression on the
SDH/Sonet trunk level must be removed. Also, the described alarm pattern is only valid for
SDH/Sonet trunks.

Figure 143. Asymmetrical alarm generation when a DTM interface is taken down in a
Nimbra 360 (left) and when a DTM interface is taken down in a Nimbra 680.
10.2.2 Optional FEC version for 4 x OC

OC-3/STM-1 Trunk
FEC155 Firmware Module is a value added firmware module for the
4 x OC-3/STM-11 Trunk Modules. Currently, it requires vavariant NPS0009-XS31
XS31 (Nimbra
One) or NPS0009-3S31
3S31 (Nimbra 300 Series) of the Trunk Module. It provides
comprehensive forward error correction to the trunk module. Typically it should be used
when running traffic over unreliable media such as microwave links that are prone to bit
and burst errors. All services are protected since FEC works on the link level. The module
performs Reed-Solomon
Solomon encoding/decoding and Row/Column interleaving.
Reed-Solomon
Solomon encoding/decoding performs
performs a (255,239) encoding/decoding of tthe data and
can detect and correct up to 8 bytes of an STS
STS-3c SPE/VC-4 row.
Note: Only two of the four physical interfaces will be usable when running
the board in FEC mode.
The module is easy installable on the NPS0009

NPS0009-XS31/NPS0009-3S31
3S31 variant of the 4 x
OC-3/STM-11 Trunk Module by a remote firmware upgrade; please see the Up-- and
Downgrading chapter,, chapter 22 of this document.

10.3 Editing the DS3/E3 Trunk interfaces
The presented variables are:
Variable Description
Interface The interface name, written as “pdh-X:Y” where X is number of the slot in the
name chassis and Y is the number of the port on the module.
DTM The name of the DTM interface, written as dtmX:Y. X and Y are used as for the
interface Interface name.
Oper. status The operational status of the board. ‘Up’, ‘Down’, ‘Absent’, ‘Starting’ or
‘Dormant’
Speed The capacity of the interface
Mode The operational mode of the node, DS3 or E3. The mode (DS3/E3) has to be the
same on the entire module, but mixing DS3 and E3 on different modules within a
node is allowed.
Figure 144. Variables of the DS3/E3 Interface
The configurable parameters for the DS3/E3 Trunk Interface are:
Suppress Alarms When the service is up and running as intended, alarms are by
default suppressed. In order to enable the alarms, the suppress
alarms tick boxes must be unmarked.
AIS: Alarm Indication Signal.
RDI/RAI: Remote Defect Indicator/Remote Alarm Indication
Figure 145. Configurable parameters of the DS3/E3 Trunk Interface

The Advanced parameters are:
Line build out (DS3 For operation with physical cable lengths over 68 m (225 feet), the ‘Line
only) build-out’ variable must be selected. With the selection, operation up to 137
m (450 feet) is feasible.
SSM/TM code (E3 Synchronization Status Message/Timing Marker code. Can assume values 0-
only) 15 or auto. Auto is recommended.
Receive sync Select receive DTM sync source. Either the recovered bit clock (Line) or the
(RX_FSYNC) recovered DTM Start of Frame signal (FSP). Normally set to Line, but if
source Time Transfer is used the parameter must be set to FSP. Also, in this case,
the interface must be reset, i.e. the administrative status must first be taken
down and then reset to up. Obviously, this only applies to the case where the
administrative status is up already.
Signal failure filter Delay time for 1+1. The time that the nodes waits for the underlying network
period (SDH/SONET/WDM) to re-establish connection, in order to avoid a switch-
over.
Default 50 ms, Range 0-2000 ms
Degraded defect Configuration parameters for the “Degraded Signal” alarm, according to ITU
(DEG) period G.806 for the interface.
Period, default 5 sec (Number of sequential bad seconds to set/clear DEG),
settable from a roll-down menu to an integer between 2 and 10
Degraded defect Configuration parameters for the “Degraded Signal” alarm, according to ITU
(DEG) threshold G.806 for the interface.
Number of background block errors to declare a bad second. Default 1200.
Overhead BIP 00000 (Number of detected BIP-8 errors since last reload of this page);
information REI 00000 (Number of detected remote error indications since last reload of
this page); LCV 11920 (Number of detected line code violations since last
reload of this page); CP 00000; P 00000 (Number of detected P-bit errors
since last reload of this page)
Figure 146. Advanced parameters of the DS3/E3 Trunk Interface
The Alarms parameters are presented at the bottom of the table as:
Unequipped This alarm is received from the other end of the link, indicating that the
(UNEQ/IDLE) payload is not usable.
Loss of signal (LOS) Loss of signal. No signal detected on PDH network interface.
Loss of frame Out of frame. Unable to align PDH frame.
(LOF/OOF)
Alarm indication signal, Alarm indication signal, line or defect detected by upstream network
line (AIS) interface.
Remote defect indication, Remote defect indication or defect detected by downstream network
line (RDI/RAI) interface.
Payload mismatch (PLM) Payload signal label mismatch.
Degraded signal (DEG) Degraded signal.
Figure 147. Alarms parameters of the 4 x DS3/E3 Trunk Module

Navigate to the Trunks → Trunk Interfaces web page and then on the trunk interface that
should be edited.
Make all your choices and click on Apply or OK. Apply doesn’t change the web page,
whereas OK takes you back to the previous web page (the Trunks Trunk Interfaces).
Figure 148. Edit the Trunk parameters on a DS3/E3 Trunk Interface

Figure 149. Alarms of a DS3/E3 Trunk Interface, presented on the alarms tab.
10.3.1 Configuration of DS3/E3 mode

For a 4 x DS3/E3 Trunk/Access Module used as a trunk module, it is not possible to set the
DS3/E3 mode of the module from the web GUI. The DS3/E3 mode can only be set for the
entire module at boot time, i.e. it must be decided whether the node shall run the 4 x
DS3/E3 trunk modules in DS3 or E3 mode. This is done on a per-module basis. A change
of configuration requires a change in the file modprobe.conf and a reboot of the node.
The mode is set by editing the file /flash/etc/modprobe.d/modprobe.conf.
The string options mau-50 e3=2,3,4 ds3=5,6,7,8 makes all 4 x DS3/E3
trunk/access modules used in trunk mode operate with the E3 protocol if placed in slots 2-4
and with the DS3 protocol if placed in slots 5-8.
To operate all modules in E3 mode, write options mau-50 mode=0.
To operate all modules in DS3 mode, write options mau-50 mode=1.
An empty modprobe.conf file sets all modules to DS3 mode (default).
After the file has been edited, the node has to be rebooted.
For system release versions prior to GX4.3.0.0, it is not possible to mix E3 and DS3 trunks.
The entire node must be set to either DS3 or E3 mode.
The configuration of E3/DS3 mode for a slot position does not affect the operation of other
board types, i.e. it is possible to use any interface module in a DS3/E3 configured slot. The
configuration only applies for DS3/E3 trunk/access modules uses as trunk modules.

If the 4 x DS3/E3 Trunk/Access Module is used as an access module, DS3 or E3 is
configurable from the web interface per interface. Trunk/access operation is determined by
what firmware is installed on the module.
10.4 Editing the IP/Ethernet trunk interface

There are two different IP/Ethernet rates available, on different modules, 1000 Mbps and
10000 Mbps. The IP/Ethernet trunks are configured essentially the same way, as is
described below.
10.4.1 Protocol stacking

On the 10GE and 6 x IP/Ethernet Trunk Modules, the underlying physical Ethernet
interface, the IP Trunk interface and the DTM interface that runs on top of the other two
interfaces are all configured from links in the left column of the main web menu.
DTM interface
IP Trunk interface
Ethernet interface (physical)
Figure 150. The interface structure of the IP trunk.
Configuration of IP/Ethernet trunks starts from the link Trunks in the left column. Clicking
on the link Trunks displays additional links: Trunk Interfaces, Ethernet Interfaces and
Perf. Monitoring.
Configuration must be carried out in the order Ethernet Interface and Trunk Interface. In
particular, in this release, the IP Trunk interface is not created automatically as it has in
previous GX-releases for the 6 x IP/Ethernet Trunk Module, but has to be manually created.

Figure 151. The first configuration page for IP Trunks.
The new 10 GE Trunk Module has two SFP+ ports, which each can transport up to 10
Gigabit. However, the combined capacity for both ports is limited to 10 Gigabit, but the
capacity can be arbitrarily divided between the two ports.
The regular 6 x IP/Ethernet Trunk Module use regular SFP ports, as it has done before.
10.4.2 Configuration of IP/Ethernet trunks – Ethernet

Configuration of both 10 GE Trunk Module and 6 x IP/Ethernet Trunk Module can be
made from the link Ethernet interfaces, found under the Trunks link on the left side of the
web interface.
The particular, Ethernet interface is labeled etht-<slot #>:<interface number>, e.g. etht-
2:3, etht-2:6 and etht-5:2. Both IP trunk modules are named according to the same
principle, but they have different number of interfaces. Example of their numbering is ipt-
2:3, ipt-2:6 and ipt-5:2. Both trunk modules have the same nomenclature for the created
(IP) trunks. Note that there is no longer a numerical coupling between the Ethernet trunk
and IP trunk. In other words, etht-7:2 can have ipt-7:1 on top of it.
Module name Interface data rate (Mbps) Number of

interfaces/module
10 GE Trunk Module 10000 2
6 x IP/Ethernet Trunk Module 1000 6
Figure 152. Interfaces of IP/Ethernet trunks
The Ethernet interface configuration page has four different links: Basic, Advanced,
Statistics and Trunks.
The 10 GE and 6 x IP/Ethernet Trunk Modules are configured on multiple web pages. First
the Ethernet interface is configured.
Connect the Ethernet cable or fiber to the module before starting the configuration. It is
imperative that this step is followed, as the operational state of the etht interface stays down
otherwise.
Now follow the link for Ethernet interfaces and select the appropriate interface, like etht-
5:1. Make sure the administrative status is ‘up’. Proceed with IP-trunk configuration, found
under Trunk interfaces. The particular trunk has to be created, with a selected data rate,
from the specific trunk’s Trunks tab on the Trunks → Ethernet interfaces web page.

Figure 153. Basic (configuration) page of the Ethernet interface of the IP/Ethernet trunk
etht-4:1, Basic settings.
10.4.3 Ethernet Interface Parameters and Variables

The Ethernet interface configuration is quite simple, but on the main page there are four
different tabs for Basic (settings), Advanced (settings), Statistics and Trunks. Observe that
you need to click on OK or Apply on each page before you proceed to the other tabs for
additional configurations, otherwise the setting just made does not stick.
Statistics is described later together with the statistical measures available for the IP trunk
(dpp counters). Trunks have to be individually created, which is made from the Trunks →
Trunk interfaces link. The procedure is described later in the chapter.
In addition to the parameters to configure, there are additional variables (i.e. read-only
entities) presented in the web interface.

10.4.4 Basic and Advanced Ethernet Interface Variables
Figure 154. Basic Ethernet Interface Variables, some of which also are presented on the
advanced page. They are only presented once in this text. The statistics
variables are presented separately.
10.4.4.1 Interface name

Type: Character string (interface name of type etht-x:y)
Description: The name of the Ethernet trunk interface that is configured
10.4.4.2 Operational status

Type: ‘Up’, ‘Down’, ‘Dormant’, ‘Absent’
Description: The operational status of the interface.
10.4.4.3 Last change

Type: Time on format hh:mm:ss
Description: Time stamp of the last change of the configuration.
10.4.4.4 Interface type

Type: Type of physical interface
Description: The physical interface is stated, e.g. 10Gbase-SR, 1000Base-T

10.4.4.5 Active speed
Type: Speed
Description: Speed of the link from the Ethernet interface
10.4.4.6 Active duplex

Type: Duplex
Description: Full/Half Duplex or Simplex used on the interface. Currently only Full
Duplex is supported.
10.4.4.7 Active flow control

Type: Flow control
Description: Flow control technology currently used on the interface. Could also be
‘none’, i.e. flow control is not used. Currently, only none is supported.
10.4.5 Ethernet Interface Parameters - Basic settings

10.4.5.1 Administrative Status
Type: ‘Down’, ‘Up’
Description: The module can be set to administratively active (‘up’) or inactive (‘down’).
10.4.5.2 Purpose
Type: text string, up to 255 characters long
Description: A text tag that can be entered by the user for various purposes.

10.4.6 Ethernet Interface Parameters - Advanced settings
Figure 155. Configuration page of the Ethernet interface of the IP/Ethernet trunk etht-5:1,
Advanced settings.
The advanced settings concern the negotiation of operating mode with the remote (peer)
interface.
10.4.6.1 Autonegotiate
Default value: ‘On’
Type: Boolean variable
Range: ‘On, ‘Off’
Description: The variable tells if the autonegotiate feature is enabled or not.
10.4.6.2 Advertised speed

Default value: ’auto’
Type: Text string, describing the available speeds of the Ethernet interface.
Range: ‘auto’, ’1000, 100, 10’, ’1000, 100’ , ’1000,10’, ’100,10’, ’1000’, ’100’, ’10’
Description: A list of supported Ethernet interface speeds.
10.4.7 Ethernet Interface Parameters – Trunk

IP Trunks have to be specifically created before they can be configured. On the Ethernet
Interface configuration page, follow the Trunks link, to create (and configure) an IP trunk.

Figure 156. Ethernet interface configuration – Trunks page
IP trunks are created by clicking the ‘Add Trunk’ button.
Figure 157. Trunk created with no bandwidth (default)
To configure the trunk, click on the trunk link, in this case ipt-5:1. This link takes you to the
basic configuration page of the IP trunk.

10.4.8 Configuration of the IP/Ethernet trunk – IP Trunk
The tabs of the IP Trunk configuration page are seen on the first (basic) configuration page
are Basic, Advanced, Alarms and Statistics.
Figure 158. Default basic IP trunk configuration page
To configure the capacity of the IP trunk, fill in either TX slots or TX bitrate. Internally,
TX slots are used. If TX bitrate is filled out, an integer number of TX slots are
automatically filled out in the TX slots field and the TX bitrate is reduced slightly.
Make appropriate IP settings for local and remote (destination) node. Set netmask (always)
and gateway if appropriate. It is essential that IP configuration is made correctly, as no link
is established otherwise.
The maximum transmission unit is defined on this page as well (105-1500). Also, the FEC
(Forward Error Correction) parameters are configured here. The configurable basic settings
are described below.

10.4.8.1 Basic settings

Type: Binary
Description: This parameter is the user’s selected state for the IP trunk. If set to ‘Up’, the IP trunk
is trying to establish itself.
10.4.8.3 Maximum transmission unit

Default value: 1500 (bytes)
Type: integer
Range: 105-1500 (bytes)
Description: IP maximum transmission unit, including IP overhead (64 bytes).
10.4.8.4 Tx slots (Tx bitrate)

Default value: The default Tx slot rate is 179. Tx bitrate is internally computed from the Tx slot
rate.
Type: Integer
Range: Displayed immediately to right of the field.
Description: It is possible to express the transmitted capacity either as number of slots per DTM
frame (‘Tx slots’) or directly as bitrate. Only one of the fields should be filled out; the other field is
automatically computed as soon as the fill-out field is left. A Tx slots value of 0 means that the trunk
is taken down in the transmit direction.
10.4.8.5 Local IP address

Default value: 169.254.0.0
Type: IP address, xxx.yyy.zzz.aaa where xxx, yyy, zzz and aaa all are integers in the range 0-255.
Range: 0.0.0.0-255.255.255.255
Description: This is the IP address of the configured trunk interface.
10.4.8.6 Subnet mask

Range: 0.0.0.0-255.255.255.255
Description: This is the subnet mask of the configured trunk interface.

10.4.8.7 Gateway IP address
Range: 0.0.0.0-255.255.255.255
Description: The default IP gateway used to reach remote locations in other subnets.
10.4.8.8 Remote IP address

Range: 0.0.0.0-255.255.255.255
Description: This is the IP address of the remote (peer) trunk interface.
10.4.8.9 Forward Error Correction Transmit Mode

Default value: “none”
Type: text string
Range: Alternatives that are supported by the hardware, shown in a drop-down menu.
Description: “none” means that the function is disabled. “1D” means that the “1D” form of
Forward Error Correction (FEC) is used for transmission (column checksum) from this interface.
“2D” means that the 2D form of FEC is used for transmission (column + row checksums) from this
interface. See the description of FEC (10.6.5 Forward error correction).
10.4.8.10 Forward Error Correction Transmit rows

Default value: 10
Type: integer
Range: Displayed immediately to right of the field, as supported by hardware.
Description: Number of rows in the transmit FEC matrix. The product of FEC Transmit rows and
FEC Transmit Columns must be below 100. The parameter is grayed out if it can’t be configured.
10.4.8.11 Forward Error Correction Transmit columns

Default value: 10
Type: integer
Range: Displayed immediately to right of the field, as supported by hardware.
Description: Number of columns in the transmit FEC matrix. The product of FEC Transmit rows
and FEC Transmit Columns must be below 100. The parameter is grayed out if it can’t be configured.
After the basic parameters have been set and confirmed (by clicking the ‘OK’ or ‘Apply’
button), it is time to define the advanced trunk parameters.

10.4.8.12 Advanced settings
Figure 159. Default advanced IP trunk configuration page
The parameters that can be configured on this page are described below.

10.4.8.13 Transmitted frame type
Default value: “untagged”
Type: text string
Range: One of “untagged”, “priotagged” or “vlantagged”
Description: “Untagged” means that neither VLAN tags nor prio tags are attached to the packets’
header. “vlantagged” means that all packets are labeled in the ‘VLAN ID field. “Priotagged” means
that VLAN id tags on incoming packets are ignored and outgoing packets are not labeled with a
VLAN ID. However, the prio field in the header is set in the Ethernet priority field (default: 0, type:
integer, range: 0-7) and determines the priority of the packets.
10.4.8.14 VLAN id
Default value: No default value
Type: integer
Range: 1-4094
Description: VLAN id is a VLAN tag attached to Ethernet frames that are of transmitted frame
type ‘vlantagged’. As it is only relevant in this case, it is grayed out for the other values of the
parameter Transmitted frame type.
10.4.8.15 Ethernet priority

Default value: 0
Type: integer
Range: 0-7
Description: Ethernet priority is a setting that determines the priority of the Ethernet frames. It is
assigned to Ethernet frames that are of transmitted frame type ‘vlantagged’ or ‘priotagged.
10.4.8.16 DiffServ Code Point

Default value: 0
Type: integer
Range: 0-63
Description: Differentiated Services Code Point is a number that the customer assigns IP packets
over the trunk. It defines a networking architecture that specifies a mechanism for classifying,
managing network traffic and providing QoS guarantees.
10.4.8.17 Time to live

Default value: 30
Type: integer
Range: 0-255
Description: Maximum number of hops allowed between originating interface and terminating IP
interface.
10.4.8.18 Jitter tolerance

Default value: 2000 (µs)

Type: integer
Range: Jitter tolerance depends on type of IP trunk and is displayed in the web interface.
Description: The tolerated jitter and wander of the IP interface, given in microseconds.
In order to configure jitter tolerance, maximum path delay (p-t-p) variation should be
monitored, if necessary for a few hours or even days. The jitter tolerance is then best set to
be p-t-p + 20% or larger. In any event, both the minimum and maximum values displayed
within parenthesis must be respected. The current default value for jitter tolerance is 2000
µs.
Actually, due to a minimum buffering of packets, the jitter tolerance will always be at least
32 divided by the packet rate, where the packet rate is the DPP-IP data packet rate in
packets/s (FEC packets are not included). This means that for packet rates less than or equal
to 16000 packets/s or less, the default value is not used.
Consider a trunk set to TX slots = 179 slots (i.e. slots per DTM frame). The required
Ethernet capacity for this configuration is about 100 Mb/s. Each packet contains 179 slots
@ standard MTU (1500 bytes). The packet rate is in this case 8000 packets/s and the
minimum jitter tolerance is 4 ms (32/8000).
After having done the configuration, make sure to click on ‘OK’ or ‘Apply’ to make the
configuration stick.
10.4.8.19 Alarm settings

In the web interface, some additional settings are made from the Alarms tab on the IP trunk
configuration page.

Figure 160. Default alarms IP trunk configuration page
10.4.8.20 Suppress alarms - All

Default value: “yes”, i.e. ticked
Type: binary
Range: “yes” or “no”
Description: The suppress alarm tick box for all alarms can be used to suppress all alarms.

10.4.8.21 Suppress alarms - RDI
Default value: “yes”, i.e. ticked
Type: binary
Range: “yes” or “no”
Description: The suppress alarm tick box for the RDI (Remote Defect Indication) alarm can be
used to suppress the RDI alarms.
10.4.8.22 Signal failure filter period

Default value: 50
Type: integer
Range: 0-2000
Description: The signal fail filter delay time (in milliseconds), i.e. a system set delay
before a signal fail alarm is generated (after its detection).
10.4.8.23 Degraded defect (DEG) period

Default value: 5
Type: integer
Range: 2-10
Description: Number of consecutive seconds that exceed the threshold before the DEG
alarm is generated. Not implemented in the current release.
10.4.8.24 Degraded defect (DEG) threshold

Default value: 1200
Type: integer
Range: 0-8000
Description: Number of acceptable errored blocks per second. A higher error rate than
this value starts the time counter towards the DEG alarm.
After the configuration is made, make sure to click on ‘OK’ or ‘Apply’ to make it stick.

10.4.9 IP trunk interface variables
Variables, presented with their respective values are shown on the various configuration
pages and are described in the following chapters.
Figure 161. Basic IP Trunk configuration page with (configurable) parameters and
(displayed) variables.
10.4.10 Basic variables

10.4.10.1 Interface name
Type: Character string (interface name of type ipt-x:y)
Description: The name of the IP trunk interface that is configured

10.4.10.2 Physical interface
Type: Character string (interface name of type etht-x:y)
Description: The name of the underlying physical Ethernet interface. A link is provided
for fast access to the relevant configuration page.
10.4.10.3 DTM interface

Type: Character string (interface name of type dtm-x:y)
Description: The name of the DTM interface residing on top of the IP trunk under
configuration.
10.4.10.4 Operational status

Type: ‘Up’, ‘Down’, ‘Dormant’
Description: The operational status of the interface.
10.4.10.5 Max Tx Bitrate

Type: Integer
Description: The highest possible Tx bitrate that can be configured on this interface.
10.4.10.6 Rx slots (Rx bitrate)

Type: Integer
Description: The variables Rx slots and Rx bitrate are proportional. These variables are
configurable from the remote (peer) interface as Tx slots/Tx bit rate. If the Rx slot value is
zero, the trunk is taken down from the other end.
10.4.10.7 Max Rx Bitrate

Type: Integer
Description: The highest possible Rx bitrate that can be received on this interface.
10.4.10.8 Forward Error Correction, Receive mode

Type: text string
Description: The FEC receive mode is equal to the FEC transmit mode defined on the
remote (peer) interface. The value “none” means that the (FEC) function is disabled. “1D”
means that the “1D” form of Forward Error Correction (FEC) is used (column FEC) to this
interface. “2D” means that the 2D form of FEC is used (column + row FEC) to this
interface.

10.4.11 Advanced variables
The advanced variables are the variables that are presented on the advanced configuration
page of the IP trunk.
Figure 162. Advanced IP Trunk configuration page with (configurable) parameters and
10.4.11.1 Mean RX data packet interval

Type: real (µs)
Description: The mean (i.e. not average) time interval between received packets. The
value is found from a measurement consisting of 100000 measurement points, which takes
typically four minutes. As soon as one measurement is finished, another is initiated.

10.4.11.2 Path delay variation (RMS) (µs)
Type: real number
Description: The RMS (root mean square) value of the path delay variation i.e. standard
deviation value of the IP path delay (µs). The value is found from a measurement consisting
of 100000 samples, which takes about fifteen minutes (100 samples/s). As soon as one
measurement is finished, another is initiated.
10.4.11.3 Path delay variation (p-t-p) (µs)

Type: real number
Description: The peak-to-peak value of the IP path delay (µs). The value is found from a
measurement consisting of 100000 measurement points, which takes typically four minutes.
As soon as one measurement is finished, another is initiated.
10.4.11.4 Path delay variation (99.9%) (µs)

Type: real number
Description: The 99.9% IP path delay variation value (µs). The value is found from a
measurement consisting of 100000 measurement points, which takes typically four minutes.
As soon as one measurement is finished, another is initiated.
10.4.11.5 Peer abilities, Max Rx slots

Type: integer
Description: The maximum amount of slots that the remote (peer) IP trunk interface can
accommodate. If the parameter Tx slots exceed this value, an alarm is raised and the trunk
connection cannot be established.
10.4.11.6 Peer abilities, Max Receive Mode

Type: text string
Description: The highest FEC Max Receive Mode that is possible on the interface, where
the FEC Receive Mode is classed as “none” (lowest), “1D” or “2D” (highest).
10.4.11.7 Peer abilities, Min Receive rows

Type: integer
Description: The lowest FEC Receive rows that is possible on the interface.
10.4.11.8 Peer abilities, Max Receive rows

Type: integer
Description: The highest FEC Receive rows that is possible on the interface.

10.4.11.9 Peer abilities, Min Receive columns
Type: integer
Description: The lowest FEC Receive column that is possible on the interface.
10.4.11.10 Peer abilities, Max Receive columns

Type: integer
Description: The highest FEC Receive column that is possible on the interface.
10.4.11.11 Peer abilities, Max Receive elements

Type: integer
Description: The maximum number of Data Elements in the receive side FEC matrix that
is supported by the remote (peer) interface.
10.4.12 Alarm configuration page variables

Variables presented on the alarms configuration IP trunk web page are presented below.

Figure 163. Alarms IP Trunk configuration page with (configurable) parameters and
10.4.12.1 Sync signal status

Type: One of ‘normal’, ‘degraded’ or ‘failed’
Description: The status of the sync signal regenerated from the IP trunk.
10.4.13 Alarms
The IP trunk alarms are also presented on the IP trunk alarms configuration page. Below,
the different alarms are presented and described.

Figure 164. IP Trunk alarms
The listing of alarms, made in the web browser on the IP interface configuration page,
indicates for a selection of alarms if they are active or not. For alarms that are not active,
the text “No Alarm” is displayed on a green background. For alarms that are active, the text
“Alarm” is displayed on a background color associated with the severity of the alarm. For
example, an alarm with severity critical is displayed on a red background and an alarm with
severity warning is displayed on a cyan colored background. The listed alarms are:
10.4.13.1 Unequipped (UNEQ)

Description: This alarm is received when the signal on the receive interface is missing.
Severity: Minor
10.4.13.2 Loss of signal (LOS)

Description: This alarm is received when the signal on the receive interface is missing.
Severity: Critical
10.4.13.3 Loss of frame (LOF)

Description: This alarm is received when the frame on the incoming signal cannot be
properly aligned.
Severity: Critical
10.4.13.4 Loss of pointer (LOP)

Description: This alarm is received when the pointer of the incoming signal is missing
(Bad alignment of DTM frames).
Severity: Critical

10.4.13.5 Loss of multiframe (LOM)
Description: This alarm is received when the FEC matrix on the incoming signal cannot
be aligned.
Severity: Minor
10.4.13.6 Remote Defect Indication (RDI)

Description: This alarm is received when a defect is detected by downstream equipment.
Severity: Warning
10.4.13.7 Degraded signal (DEG)

Description: This alarm is received when the signal on the IP network interface is
degraded.
Severity: Critical
10.4.13.8 Tx not established (TNE)

Description: This alarm is received when Tx path between the nodes cannot be
established.
Severity: Critical
10.4.13.9 Rx not established (RNE)

Description: This alarm is received when Rx path between the nodes cannot be
established.
Severity: Critical
10.4.13.10 ICMP
Description: This alarm is generated when the node receives an ICMP error message. The
text can be one of: ‘Redirect’, ‘Target unreachable’, ‘Source quench’ or ‘Parameter
problem’ depending on the problem, when the signal on the receive interface is missing or
misread.
Severity: Warning
10.5 Ports used by IP trunk

In the table, the UDP ports used by the IP/Ethernet trunk are defined.
UDP port IP/Ethernet trunk Protocol

1024 DPP-IP
1025 DPCP-IP
Figure 165. UDP port usage by IP/Ethernet trunk protocols

10.6 Statistics
10.6.1 General
In order to view the different statistical counters, follow the proper link. The statistical
measures have been divided into DPP-IP counters available from the Trunks→Trunk
Interfaces→Interface name→Statistics link and Ethernet/IP counters available from the
Ethernet Interfaces→Interface name →Statistics link (display of all counters).
Statistics is available on two separate levels for the IP trunk. One level is the underlying
Ethernet/IP layer and one level is the DPP-IP Trunk level. In this description the available
counters are described in separate sections.
DPP-IP counters are found under the Statistics tab on the specific web page for the IP trunk
interface (Trunks → Trunk interfaces → Specific trunk, like ipt-1:2).
Figure 166. IP Trunk statistics

10.6.2 Overview statistics
For the IP trunks, there is also an overview web page for sent and received packets on all
interfaces. This page is found under Trunks → Trunk Interfaces link. On this page, the
Statistics link should be followed.
Figure 167. Overview trunk interface statistics
10.6.3 DPP-IP Trunk level statistics
dppIp dppIp
MissingFrame ReceivedFrame
dppIp dppIp dppIp dppIp

ReorderedFrame DeliveredFrame DuplicateFrame DroppedFrame
dppIp dppIp dppIp

LostFrame RecoveredFrame SentFrame
Figure 168. Relationship between the various DPP-IP counters
10.6.3.1 dppipDeliveredFrames
Description: The total number of DPP-IP frames that have been received and delivered to
the DTM interface.

10.6.3.2 dppipDroppedFrames
Description: The number of DPP-IP frames that have been received and have not been
delivered since the interface was unable to align its data into the DTM trunk stream.
10.6.3.3 dppipDuplicateFrames
Description: The number of DPP-IP frames that were received with a sequence number
of an already processed DPP-IP frame.
10.6.3.4 dppipLostFrames
Description: The number of missing DPP-IP data frames that could not be delivered to
the DTM interface. dppipLostFrames only counts data frames.
10.6.3.5 dppipMissingFrames
Description: The number of DPP-IP frames that were missing in the frame sequence, i.e.
the expected sequence number was not found in the DPP-IP framing buffer.
dppipMissingFrames counts all frames, including non-data frames like FEC frames etc.
10.6.3.6 dppipReceivedFrames
Description: The total number of DPP-IP frames that have been received.
dppipReceivedFrames is the total number of received frames, including FEC frames etc.
10.6.3.7 dppipRecoveredFrames
Description: The number of missing DPP-IP data frames that were recovered by the FEC
procedure. dppipRecoveredFrames only counts data frames.
10.6.3.8 dppipReorderedFrames
Description: The number of DPP-IP frames that were received out of order, but could still
be aligned to the DPP-IP frame sequence.
10.6.3.9 dppipSentFrames
Description: The number of DPP-IP frames that were sent on the DTM interface.
10.6.4 Ethernet/IP level statistics

These statistical counters are specified in IETF RFC 1213 or IETF RFC 2819. In the web
interface, they are available from the Trunks → Ethernet interfaces page. On this web page,
follow the specific interface and the Statistics tab.

Figure 169. Ethernet interface statistics
The counters are standardized. Their meaning is described below.
10.6.4.1 etherStatsBroadcastPkts
Description: The total number of good packets received that were directed to the
broadcast address. Note that this does not include multicast packets.
10.6.4.2 etherStatsCollisions
Description: The best estimate of the total number of collisions on this Ethernet segment.

10.6.4.3 etherStatsCRCAlignErrors
Description: The total number of packets received that had a length (excluding framing
bits, but including FCS octets) of between 64 and 1518 octets, inclusive. The packet had
either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or
a bad FCS with a non-integral number of octets (Alignment Error).
10.6.4.4 etherStatsDropEvents
Description: The total number of events in which packets were dropped by the probe
due to lack of resources. Note that this number is not necessarily the number of packets
dropped; it is just the number of times this condition has been detected.
10.6.4.5 etherStatsFragments
Description: The total number of packets received that were less than 64 octets in length
(excluding framing bits but including FCS octets) and had either a bad Frame Check
Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-
integral number of octets (Alignment Error).
10.6.4.6 etherStatsJabbers
Description: The total number of packets received that were longer than 1518 octets
(excluding framing bits, but including FCS octets), and had either a bad Frame Check
Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-
integral number of octets (Alignment Error).
10.6.4.7 etherStatsMulticastPkts
Description: The total number of good packets received that were directed to a multicast
address. Note that this number does not include packets directed to the broadcast address.
10.6.4.8 etherStatsOctets
Description: The total number of octets of data (including those in bad packets)
received on the network (excluding framing bits but including FCS octets).
10.6.4.9 etherStatsOversizePkts
The total number of packets received that were longer than 1518 octets (excluding framing
bits, but including FCS octets) and were otherwise well formed.
10.6.4.10 etherStatsPkts
Description: The total number of packets (including bad packets, broadcast packets, and
multicast packets) received.

10.6.4.11 etherStatsPkts1024To1518Octets
Description: The total number of packets (including bad packets) received that were
between 1024 and 1518 octets in length inclusive (excluding framing bits but including
FCS octets).
between 128 and 255 octets in length inclusive (excluding framing bits but including FCS
octets).
10.6.4.13 etherStatsPkts1519ToMaxSizeOctets
between 1519 and the highest allowed frame size.
octets).
octets).
10.6.4.16 etherStatsPkts64Octets
Description: The total number of packets (including bad packets) received that were 64
octets in length (excluding framing bits but including FCS octets).
octets).
10.6.4.18 etherStatsUndersizePkts
Description: The total number of packets received that were less than 64 octets long
(excluding framing bits, but including FCS octets) and were otherwise well formed.

10.6.4.19 ifInDiscards
Description: The number of inbound packets which were chosen to be discarded even
though no errors had been detected to prevent their being deliverable to a higher-layer
protocol. One possible reason for discarding such a packet could be to free buffer space.
10.6.4.20 ifInErrors
Description: The number of inbound packets that contained errors preventing them from
being deliverable to a higher-layer protocol.
10.6.4.21 ifInNUcastPkts
Description: The number of packets, delivered by this sub-layer to a higher (sub-) layer,
which were addressed to a multicast or broadcast address at this sub-layer.
10.6.4.22 ifInOctets
Description: The total number of octets received on the interface, including framing
characters.
10.6.4.23 ifInUcastPkts
Description: The number of packets, delivered by this sub-layer to a higher sub-layer,
which were not addressed to a multicast or broadcast address at this sub-layer.
10.6.4.24 IfInUnknownProtos
Description: The number of packets received via the interface, which were discarded
because of an unknown or unsupported protocol.
10.6.4.25 IfOutDiscards
Description: The number of outbound packets which were chosen to be discarded even
though no errors had been detected to prevent their being transmitted. One possible reason
for discarding such a packet could be to free buffer space.
10.6.4.26 IfOutErrors
Description: The number of outbound packets that could not be transmitted because of
errors.
10.6.4.27 IfOutNUcastPkts
Description: The total number of packets that higher-level protocols have requested to be
transmitted to a non-unicast (i.e., a subnetwork-broadcast or subnetwork-multicast) address,
including those that were discarded or not sent.

10.6.4.28 IfOutOctets
Description: The total number of octets transmitted out of the interface, including
framing characters.
10.6.4.29 IfOutUcastPkts
Description: The total number of packets that higher-level protocols requested be
transmitted, and which were not addressed to a multicast or broadcast address at this sub-
layer, including those that were discarded or not sent.
10.6.5 Forward error correction

In order to configure the basic parameters of forward error correction, FEC transmit mode
must be set. This variable has three possible values: “none”, 1D or 2D. “None” means that
the FEC function is disabled. 1D or 2D indicates that one or two parity checks are made, as
described below.
The FEC matrix, defined by ‘FEC, transmit rows’ and ‘FEC, transmit columns’ parameters
can have one or two sets of parity sums. These parity sums are data packets of the same size
as the data packets in the matrix. The packet size is defined by the MTU parameter, which
is an integer in the range 105-1500 (default 1500). To create the 1D parity sum packet, bits
of the same position in all packets in one column are added and divided modulo-2. In the
example below, for the first bit of the 1D parity check sum of the first column, 1+0+1=2,
which is congruent with 0 (modulo-2). In other words, the parity check sum in an even
number. This is true for the second, third and forth bits as well in this example.
For 2D FEC mode, corresponding check sums are formed for both the row and the column.
In this case, the column check sums are used first to correct erroneous packets. After this
operation is finished, a second correction is made with the row check sums. With this
method, it is sometimes (but not always) possible to correct dual faults in one row or
column.
Observe that the size of the packets in the illustration below is kept well below the real
minimum packet size (64 octets), to improve clarity.
2D FEC is only possible between Nimbra 600 nodes. Between Nimbra 600 and Nimbra 300
nodes, 1D FEC is possibly. Capabilities in the nodes are always displayed in the web
interface.

1D mode
1 2 3 4 5
1 1101 1001 0100 0001 1001
2 0010 0000 0111 1101 1000
3 1111 1101 1011 0110 0001
Parity 0000 0100 1000 1010 0000
2D mode
1 2 3 4 5 Parity
1 1101 1001 0100 0001 1001 1000
2 0010 0000 0111 1101 1000 0000
3 1111 1101 1011 0110 0001 1110
Parity 0000 0100 1000 1010 0000
Figure 170. Structure of the FEC matrix for FEC Modes 1D and 2D.

11 Sync and Time Transfer
11.1 General
This chapter describes the synchronization principles of DTM networks (ETSI ES 201
803). While many aspects of network synchronization principles is similar to what is found
in SDH/SONET networks, DTM has introduced some important new features in order to
achieve an automated and robust network synchronization. This extra functionality reduces
the burden of synchronization planning to a minimum and also reduces the risk for bad
configuration of the synchronization network.
DTM maintains its own synchronization mechanism that spans over the entire switched
DTM network layer, independent of lower layer transport. DTM is usually transported over
SDH/SONET, but it can also be transported over PDH (DS3/E3) or over IP/Ethernet (IP
Trunk).
The primary role of DTM network synchronization is to synchronize information carried in
DTM frames for switching. A secondary role is to maintain a timing quality level of the
transported signal that is required by the most demanding services, such as transport of
studio video content. The synchronization mechanism in Nimbra nodes addresses both
these issues.
11.2 DTM Synchronization distribution

The DTM synchronization architecture is based on DSYP, the network-wide
synchronization protocol, and node and interface synchronization.
All nodes in a network are synchronized to one or more reference source(s) in a master-
slave scheme. A source can be either node internal or external to the node. DTM links
transfer clock information automatically between nodes in the network, but they can be
manually disabled. This is configured on the DTM interface and is the configuration is
described in 9.2.1 Editing a DTM interface. All nodes have also an internal clock. If
external sources are missing, these internal clocks are used for synchronization. Unless the
network is very small, external sources should normally be used.
All clocks or synchronization sources can be assigned a priority number. According to the
definition made, the lower the priority number is, the higher the priority of the source is.
If two or more synchronization sources have equal and highest priority (i.e. lowest priority
number) in the network, the source that is used is the source attached to the node with
lowest MAC address. There is an exception to this and that is if the sources have priority 0.
In case there are two or more sync masters with the highest clock priority the Nimbra
network is synchronized by two or more sources. The individual nodes get as sync master
the node that is closest in terms of number of hops. In this way synchronization is
segmented and as a consequence there could be slips in DTM-frames between adjacent
nodes that have different synchronization masters. Users must ensure that phase deviations
are within limits and that frequency errors are insignificant (Primary Reference Clock, ITU-
T G.811)
The synchronization topology is a minimum spanning tree that is calculated by a node
distributed algorithm, which assures shortest path between synchronization source(s) and
the nodes. Furthermore, synchronization loops are eliminated.
Element Manager User's Manual Sync and Time Transfer • 178

If a synchronization source fails, affected nodes enter hold-over mode until a new spanning
tree has been calculated for back-up synchronization sources. This takes at most a couple of
seconds. In hold-over mode, phase and frequency continuity is maintained.
11.2.1 The DSYP Protocol

DSYP, the DTM Synchronization Protocol, is a protocol that exchanges synchronization
information between nodes of the network. The protocol data unit that is exchanged
contains information about sync masters (Node ID, priority level, number of nodes
traversed).
All nodes exchange synchronization information with its neighbors. Based on this
information, a distributed algorithm (Bellman-Ford) calculates a minimum spanning tree
that ensures that each node in the network is synchronized to the synchronization source
with highest priority. If the active master fails, the network automatically synchronizes to
the next clock in the priority list. If two clocks, internal or external, have the same priority,
the one with lowest node ID (MAC address) is used.
Different node types have different quality of their node clocks. This is the reason why they
have different default internal clock priorities. Running the network without an external
clock reference may be adequate for certain applications, but it is strongly recommended to
have at least one primary and one secondary (backup) external reference synchronization
source.
Figure 171. Synchronization of a DTM network. During fault free operation, the network is
synchronized to the external reference (clock 0). A minimal spanning tree is
built from this clock to all other nodes. When it fails, the network is
synchronized to the backup synchronization source (clock 1).

Figure 172. A fault on the leftmost link will automatically result in a new minimal
spanning tree from sync master 0. During recalculation of the spanning tree,
the involved node (in this case the lower left node) is in holdover mode.
11.2.2 The node synchronization function

The node synchronization function coordinates all synchronization tasks that are local to
the node. Among these are
Selection of node synchronization source (as ordered by DSYP)
Smoothing of the synchronization signal
Distribution of the smoothed signal to all outgoing trunk interfaces
Providing a hold-over mode in case of lost synchronization source
Ensuring phase continuity when changing sync source
Supervision of available sync sources
In all releases up to GX4.7, synchronization information is carried automatically over the
DTM interface and DTM layer. On the receiving side of the link, there is always a
synchronization signal to regenerate from the link. The synchronization signal selected by
the node is then the signal with lowest priority number, obtained from any of the links.
A feature, included from system software release GX4.7, is synchronization enable/disable
on DTM-interfaces. By default, this parameter is enabled on all DTM interfaces, but now it
is possible for the user to manually disable the incoming DTM synchronization, per
interface. The usage of this feature is in cases where the synchronization information of a
particular DTM interface is unreliable and should not, under any circumstances, be used at
the receiving node as sync source. As a consequence, the incoming disabled sync route is
not propagated to other nodes in the network from the node with the disabled interface.

Figure 173. By deselecting ‘Allow as sync source’, the user selects not to extract
synchronization information from the DTM interface. The clock is not
distributed further in the DTM network.
Smoothing of the sync signal is done with a digital phase-locked loop (PLL) that smoothes
out jitter from for example pointer justifications on the SDH/SONET layer. This signal is
then distributed to all outgoing trunk interfaces and all outgoing frames are aligned and
synchronized with this signal.
If the node sync function detects that the current sync source is unavailable, the node enters
hold-over mode. In hold-over mode, the node sync signal is obtained from the built-in
oscillator, which is adjusted to the average of the frequency of the sync signal over a certain
time before the fault. The time spent in hold-over mode before a new sync source is found,
is in general much shorter than in traditional SDH/SONET networks. Consequently, phase
drift and wander associated with it, is in general not of importance.
When DSYP orders a new sync source, the node sync function must ensure that the
outgoing phase is undisturbed. This is done by adding, to the new sync source, an amount
of phase corresponding to the difference between the new sync sources and the node sync
signal. This makes the outgoing sync signal “transparent” to sync changes.
The node sync function also monitors and maintains the available sync sources.

The same fundamental concepts are kept for providing sync over an IP/MPLS/Ethernet
network, but the methods for recovering the sync signals are adjusted to handle the higher
levels of jitter and wander associated with a packet based transport.
11.3 Synchronization sources and priority

All synchronization sources in a DTM network have a priority. The scale of the priorities is
0-15, but contrary to what can be expected, lower priority number means higher priority.
Priority 0 is the highest priority and priority 15 the lowest.
A Nimbra node has three possible types of sync sources, which are selected by the DSYP
protocol. The source types are external reference clocks attached to a “Sync In” port,
extracted sync sources from DTM links and internal node clocks. Their relative importance
is typically in this order, but the extracted clock gets its priority from the origin of the sync
source arriving on the link, i.e. the external or internal clock used as its sync master.
The most common sync source for a node is an incoming signal from a trunk interface. The
extracted clocks on all incoming DTM links are normally always used as (possible) sync
sources, but they can be individually disabled in the web interface. The built-in node clock
is typically only used if there is no external reference clock in the network.
When the network is physically divided into two or more parts by a node or link failure, the
parts are synchronized independently with separate master sources. This case essentially
means that the network has been split into two or more separate networks and when the
connectivity is restored synchronization is re-established. There is one exception to this
rule, and that is if two or more external synchronization sources are attached to nodes in the
network.
Since the DTM network is synchronous, there is normally only one sync master active in
the network at any given time. In fact, in all releases prior to GX4.8, there is only one
allowed synchronization source. In GX4.8, multiple sync masters with priority 0 are
allowed. If such synchronization segmentation is used, it is necessary that the sync sources
are really synchronous by means external to the network.
11.3.1 Default internal synchronization priority

Every DTM node has its own clock or synchronization source. From system software
release GX4.8, the internal node clock has a default priority depending on the node type. In
addition, the internal node clock priority is configurable, making it possible to set the node
clock priority to any value from 4 to 15.
The default clock priority for Nimbra nodes are detailed below.
Nimbra node Default clock priority
Nimbra 360 GOLD 13
Nimbra 310, 320, 340, 340-HD, 360, 380 and 600 series 14
Nimbra One 15
Figure 174. Default internal node clock priority
11.3.2 Clock priority mapping in GX4.8

Because external clocks could have a configured priority of 13 or 14 in GX-versions before
GX4.8 and any usage of these priorities must have been for external clock as the internal
clocks could not be configured (they were hard set to priority level 15), priority levels 13

and 14 are mapped to other priority levels in GX4.8 and later releases. In the table, the
mapping is detailed.
The reason behind this mapping is that priorities 13 and in particular 14, the old default
external clock priority, are now used as new internal default priority levels. As a defined
priority level, they should (normally) remain higher in priority than any node internal
clocks. When changing to GX4.8, no external clock sources should have priority level 11 or
12 as they would get a lower priority than sources with priority level 13 or 14. For more
precise instructions, please see the release notes.
Clock priority level before Clock priority level in GX4.8

GX4.8 and later releases
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 11
14 (default for external clocks) 12
15 (used for all internal clocks) 15
Figure 175. Clock priority level mapping from previous GX-versions to GX4.8 and later
releases
11.3.3 Synchronization source extracted from DTM links

From all incoming DTM links, the synchronization signal is extracted by the node. The
signal is extracted from the DTM frame start and has a frequency of 8 kHz. In the
IP/Ethernet trunk the frame sync signal is encoded as a time-stamp in the DPP-IP overhead
in the IP/UDP packet.
By default, all extracted clocks can potentially be used by the node as a synchronization
source. It is possible to disable this feature by removing the tick on the DTM → Interfaces
web page on a link by link basis. In this manner it is possible to tailor the sync distribution
and only use reliable links to transfer (allowed) synchronization sources.
The priority of these clocks/synchronization sources is transferred from the clock source via
DSYP.
11.3.4 External clocks

There are ways to attach external clocks (synchronization sources) to all Nimbra nodes.
How this is done differs between the different nodes, but the node specific configuration is

made from the link Ext. clock → Interfaces in all cases. In Nimbra 680, there is no web
interface to configure an external clock.
11.4 Configuration of external clocks

11.4.1 Nimbra One
Configuration of the external clock in Nimbra One is not recommended to carry out from
the web. If you still do, you need to make sure that you have enough amplitude of a square
wave signal. In Nimbra One nodes, one external clock interface (to configure) is available
from the link Ext Clock → Interfaces. The external clock source is attached to the front of
the node controller (leftmost module) with an SMB connector (75 Ω). To emphasize, it is
not recommended to use the Nimbra One as a synchronization source, as the quality of its
internal node clock is not sufficient for the network.
Figure 176. Configuration of the clock interface sqc-1:1 in Nimbra One. It is configured to
send out a 2048 kHz signal.
11.4.2 Nimbra 340/340-HD

In Nimbra 340 nodes, one external sync interface is available. The external clock source is
attached to the front of the node with a BNC connector (75 Ω). This is the only available
clock interface for Nimbra 340. The clock is configured in the web interface.

Figure 177. Configuration of sqc-1 in Nimbra 340.
The parameters for Nimbra One and Nimbra 340 are:
11.4.2.1 Direction
Default value: ‘In + Out’
Type: One of ‘In + Out’, ‘In’, ‘Out’
Range: ‘In + Out’, ‘In’, ‘Out’
Description: Active direction for the external synchronization clocks. ‘In + Out’ means
that both in- and output interfaces are enabled, ‘In’ means that only the input interface is
enabled and ‘Out’ means that only the output interface is enabled.
11.4.2.2 Output frequency

Default value: 2048 kHz
Type: One of 8 kHz, 1544 kHz and 2048 kHz.
Range: 8 kHz, 1544 kHz or 2048 kHz
Description: This is the frequency delivered to the external sync output when it is
enabled, i.e. when the parameter ‘Direction’ is either ‘In + Out’ or ‘Out’.
11.4.2.3 Clear defects

Default value: Unticked
Type: Checkbox
Range: Ticked, unticked
Description: In order to remove all old defects to be displayed on this web page, this tick
box is selected and the OK or Apply button are clicked. This triggers a fresh reading of
active defects.

11.4.3 Nimbra 360 and 380
In Nimbra 360 and 380 nodes, there are two different external clock interfaces, sqc-1
sqc and
sqc-2.
2. On the physical node, they can be found at the lower right side, with notations TSI
TSI-1
(sqc-1) and TSI-22 (sqc-2).
(sqc
Figure 178. Nimbra 360 front. The sync interfaces are found at the lower righ
rightt side.
Nimbra 380 is identical to Nimbra 360 with respect to TSI
TSI-1/TSI-22 (sqc
(sqc-1/sqc-
2).
Configuration of TSI--1/sqc-1
1 includes one parameter, time dual frequency mode, with
wi
possible values ‘none ‘or ‘PPS
‘PPS + 10 MHz’. With the parameter set to none, the port is
transformed to a regular external clock interface of the same type as on Nimbra 340/Nimbra
One.
Out In
Figure 179. Nimbra 360 with TSI
TSI-1/sqc-1 1 configured with Time Dual Frequency Mode
equal to ‘None’,
‘None’, i.e. the two ports of the interface are used as regular sync in
and sync
ync out ports.
The sqc-11 interface for Nimbra 360/380 looks a bit different from the corresponding
interface in Nimbra One/340. There are some additional parameters to configure.

Figure 180. Configuration of sqc-1/TSI-1 of Nimbra 360/380 with Time dual frequency
mode set to none.
When Time Dual Frequency Mode is set to ‘none’, the parameters to configure are the
same as for the Nimbra One/340 case. The parameter ‘Time input offset’ is irrelevant for
Time Dual Frequency Mode is set to ‘none’ and is grayed out in the web interface. Time
input offset is a calibration factor for the time it takes for the clock signal to reach the
Nimbra 360/380 node (from its source), but it is only relevant for Time Dual Frequency
Mode set to PPS + 10 MHz, described in next section. Square sync signals of 1544 kHz or
2048 kHz are automatically recognized by the node (According to ITU-T G.703-13).
When Time Dual Frequency Mode is set to PPS + 10 MHz, TSI-1 expects to receive two
signals: one PPS (pulse per second) on the PPS port and one 10 MHz signal on the Sync
port if the Direction parameter is set to In. If the parameter is set to ‘Out’ these signals are
sent to the ports. Selecting the clear defects box and clicking on OK or Apply makes a new
reading of the defects.
If one or both expected signals are missing or of poor quality, it can be deducted from the
web interface where the problem is. It is sufficient to look at Input frequency and Defects.
Unless the node identifies two acceptable signals, the signal is not recognized as an external
sync source and not used by the network. This can be seen on the Ext. clocks → Interfaces
web page.
Input frequency Defects Interpretation

(MHz)
0 Loss of signal, Signal PPS and 10MHz are faulty
Frequency Error, PPS or not attached
(Loss of Signal)
10 OK, PPS(Loss of PPS is faulty/not attached,
Signal) but 10 MHz is OK
PPS Loss of Signal, Signal PPS is OK, but 10 MHz is
Frequency Error faulty/not attached
PPS+10MHz OK Both PPS+10Mhz are OK
Figure 181. The four different ways of connecting PPS and 10 MHz to the TSI interface.
Under normal time transfer operation, PPS should always be attached.

The web page for the case where no PPS is attached but 10 MHz is attached is shown
below.
Figure 182. Defect presented on the sqc-1 web page.
Figure 183. Configuration of sqc-1/TSI-1 of Nimbra 310/320/360/380 with Time dual

frequency mode set to PPS+10 MHz. Note that as the direction is ‘In’, the
parameter Output frequency is not used and is grayed out.

The one remaining parameter to configure is Time input offset. This parameter is to
compensate the transit time from source to Nimbra 310/320/360/380 of the PPS signal.
The other interface on Nimbra 360/380, TSI-2/sqc-2, can be used as an output interface
with time dual frequency mode set to PPS+10 MHz. In this case, some additional
parameters can also be configured. This interface is absent on Nimbra 310/320.
Figure 184. Configuration of sqc-2/TSI-2 of Nimbra 360/380 with Time dual frequency
mode set to PPS+10 MHz.
The parameters to configure, in addition to time dual frequency mode, are:
11.4.3.1 Output frequency (kHz)

Type: one of three values, real
Range: 8 kHz, 1544kHz, 2048 kHz
Description: This is the frequency delivered to the Out port when the interface is in sync
mode, i.e. when Time dual frequency mode is set to ‘None’. The parameter can be set
independently on both configurable ports.

11.4.3.2 Time output offset
Default value: 0 ns
Type: real value, unit ns
Range: -999999999 to +999999999
Description: This is delay from the Nimbra 360/380 to the destination of the sync signal.
The parameter cannot be set independently on both configurable ports.
11.4.3.3 PPS output pulse width

Default value: 20 µs
Type: real value, unit µs
Range: 0.1-999999.9
Description: This is the pulse width of the PPS output pulse, configurable in steps of 0.1
µs.
11.4.3.4 Time output deviation realignment limit

Default value: 2000 ns
Range: 0-999999999
Description: If the deviation between the node internal time and the time derived from
the PPS + 10 MHz pair (displayed) exceeds this setting, an alarm is generated.
11.4.3.5 Time output deviation reassignment limit

Default value: 62500 ns
Range: 0-999999999
Description: If the deviation between the node internal time and the time derived from
the PPS + 10 MHz pair (displayed) exceeds this setting, the PPS/10 MHz pair is silently
squelched and reset to match the node internal time.
11.4.4 Nimbra 310 and 320

Nimbra 310/320 has one TSI/sqc interface, sqc-1, which can be used for in and output
signals. The interface can be used to input regular sync signals in the same way as Nimbra
360/380 and it accepts the same 1544 and 2048 kHz sync signals. Nimbra 310 or 320 can
also be used as an entry point for time transfer, the same way as Nimbra 360 or 380. It is
limited, though, by one interface for time transfer signals. The time transfer signal interface
pair (PPS + 10 MHz) can either be used for input or output.

Nimbra 320
1 Blind Panel 1
Serial
1 2
ETH PPS Sync
Tx Rx Tx Rx
TSI 1
Reset Status Status
155/622/2488 Mbps (SDH)

+ A - + B - -10/100/1000 Mbps (ETH) -
-- 48
48 VDC
VDC Ethernet Status L/A 1 Sp L/A 2 Sp L/A 3 Sp L/A 4 Sp L/A 5 Sp L/A 6 Sp L/A 7 Sp L/A 8 Sp Tx On Tx On
Sync Out In
Time transfer in PPS In 10 MHz In
Time transfer out PPS Out 10 MHz Out
Figure 185. Nimbra 320 configurable TSI-1 interface
11.4.5 Nimbra 680

Nimbra 680 accepts 1544 kHz or 2048 kHz synchronization signals. They are attached to
the front of the switch modules and the frequency is automatically recognized. The external
clock source is attached to the front of the node with a BNC connector (75 Ω).
DSYP handles redundant switch modules in Nimbra 680 transparently to the operator. Both
modules lock to the selected synchronization reference signal and deliver a node
synchronization signal in phase with each other. At fail-over, the standby switch module
becomes active and its internal clock becomes the synchronization source of the node.
There is one operational aspect of having redundant switch modules in a Nimbra 680. If the
Nimbra 680 node receives an external synchronization signal, this signal must be delivered
to both switch modules. The external signal must be split and connected to both modules as
the node cannot use an external synchronization source connected only to the standby
switch module.
Figure 186. Configuration of external clock interface on Nimbra 600 systems.
The parameters to configure are:

11.4.5.1 Direction
Default value: In + Out

Type: one of three values; ‘In’, ‘Out’ or ‘In + Out’
Range: ‘In’, ‘Out’ or ‘In + Out’
Description: This is the configured direction of the sync signal. ‘In’ means that the node
expects a signal on the ‘Sync In’ port. ‘Out’ means that the node generate a sync signal on
the Sync Out port. ‘In + Out’ means that the node expects a signal on the Sync In port while
simultaneously delivering a signal to the Sync Out port.
11.4.5.2 Output frequency (kHz)

Type: one of three values, real
Range: 8 kHz, 1544kHz, 2048 kHz
Description: This is the frequency delivered to the Out port when Direction is set to either
‘Out’ or ‘In+Out’.
11.4.5.3 Clear defects
Default value: not selected

Type: binary
Range: selected, not selected
Description: Selecting this check box and clicking on the OK or apply button reads out
the defect status anew. This clears “old” defects that are no longer present.
11.4.6 Configuration of internal and external synchronization

sources
The external reference clock is configured on two separate web pages. They are found on
web pages DTM → Sync and Ext clock → Interfaces. The latter step has already been
discussed. The link DTM → Sync shows the following configuration page.

Figure 187. The Sync page where internal and external clock priority are configured.
The parameters to configure are:
11.4.6.1 Internal clock priority

Default value: Dependent on node type, 15 for Nimbra One, 14 for Nimbra 300 and 600
nodes expect Nimbra 360 GOLD which has default priority level 13.
Type: integer
Range: 4-15
Description: The lower the priority setting is, the higher the priority is. The
administrative status of the internal clock is not configurable and it is always ‘Up’.
11.4.6.2 External clock priority

Default value: 12
Type: integer
Range: 0-12
Description: The lower the priority setting is, the higher the priority is.
11.4.6.3 External clock admin status

Default value: Down
Type: binary
Range: ‘Down’ or ‘Up’
Description: If the external clock administrative status is set to down, the clock cannot be
used by the network; if it is set to ‘Up’ it is available to the network.
The variables presented on the page are:

Variable Value Meaning
Sync oper. State ‘Up’ The node is synchronized

(Synchronization
operational state)
‘Pending’ The node is starting up
‘Down’ Error in sync function. If there is an error, it is
shown in the alarms list
Type Internal Node clock
External External, attached clock
Interface Clock extracted from DTM link
Id Interface Id
Current source ‘yes’ The source is currently sync source for the node
‘no’ The source is currently not sync source for the
node
Backup source ‘yes’ The source is currently a backup sync source for
the node, i.e. it can be used as a sync source
‘no’ The source is currently not a backup sync
source for the node
TR prio 0-15 Clock source priority, where a lower number
means a higher priority
Figure 188. Variables presented on the DTM → Sync web page.
The web page shows the different synchronization sources and their status, as follows:
If the node has access to several clocks with the same priority, different from 0, the clock
originating from the node with the lowest Node Mac address becomes the active clock. If
there are two external clocks with priority 0, both are allowed as master sync sources and
the sync network is segmented. This case is described in the subsequent chapter.
11.5 DTM Synchronization segmentation

A novelty of GX4.8 is that it allows several network master synchronization sources. In
previous system release versions, only one clock could be the master of the network. In this
case, if several external clocks are used (in different nodes) with the same priority level, the
clock attached to the node with the lowest node MAC address becomes the sync master of
the network.
In GX4.8, this is also true for all clock priority levels of 1 and higher. For clock priority
setting 0, a new feature called synchronization segmentation is introduced. If multiple
clocks with priority level 0 are used, they have to be very much in tune. In practical cases,
GPS synchronization of all such sources is recommended.
In this case, i.e. with multiple external clocks all with priority 0, the nodes select as their
source the external clock with shortest distance in terms of number of hops. If the distance,
in terms of number of hops is equal, the sync source for the node is the clock that is
attached to the node with lowest MAC address.
In the illustration below, node 12 has a lower MAC address than node 2.

Master clock, prio 0
node2 node3 node20 node14
Nimbra 340 Nimbra 360 Nimbra 680 Nimbra One
node1
node11
Nimbra One
Nimbra One
node4 node10 node13 node12
Nimbra One Nimbra 680 Nimbra 360 Nimbra 340
Master clock, prio 0
Figure 189. Illustration of sync distribution in a case with two master sync sources, both
with priority 0. The nodes take their sync from the closest sync master. In case
the distance is equal, the sync source attached to the node with the lowest
MAC address is preferred.
11.6 Fault Indications – synchronization alarms

There are no alarms directly associated to the external clock interfaces. Instead alarms are
handled through DSYP and Time Transfer objects in following way. Input faults, i.e. a
lacking or poor quality input synchronization input, generate a ‘No external sync source
available’ alarm. More details can be viewed from the sqc interface web page.
Figure 190. The sqc-1 interface of node1, a Nimbra One node, details the defect (Loss of
(sync) signal).

From Nimbra 310, 320, 360 and 380, Output faults of the time transfer signal
(PPS+10MHz) generate a ‘Threshold crossed’ alarm. More details concerning faults can be
viewed as ‘Defects’ from the web page of the relevant sqc interface.
On Nimbra 310, 320, 360 and 380, faults are also indicated by LED colors in following
ways. There are two indicator LEDs (Status and TxOn) per port (PPS and Sync) and one or
two interfaces (TSI-1/sqc-1 and TSI-2/sqc-2).
Figure 191. The LEDs on the two interfaces TSI-1/sqc-1 and TSI-2/sqc-2 on Nimbra
360/380. On Nimbra 310/320, only TSI-1/sqc-1 is available.
LED ‘Tx On’ LED ‘Status’ Description

Green Off Tx disabled
Green Green Tx enabled and transmitting error free
Green Red Unable to transmit requested signal
Off Off Rx disabled
Off Green Receiving error free
Off Flashing red Error and not Loss Of Signal
Off Red Loss Of Signal
Figure 192. Interpretation of LEDs for the synchronization/time transfer input ports. When
used as sync interface, the sync port is used for input and the PPS port for
(sync) output. When used as time transfer interface, both ports of the interface
(PPS and Sync) are either used as input or output.
Details on the faults described can be found by following the link Ext. Clocks → Interfaces
and sqc-1 or sqc-2 depending on which clock is faulty.
Defect Description
Loss Of Signal (LOS) No input signal detected.
Loss Of Frame (LOF) Input signal not properly aligned to reference
clock. Most frequently caused by too large
frequency deviation between reference clock
and input signal (should probably be renamed
to something better).
Signal Frequency Mismatch (SFM) Input frequency does not match requirements
of operational mode (e.g. 2048kHz in
PPS+10Mhz operational mode).
Excessive Phase Deviation (EPD) Output realignment limit has been exceeded.
Loss Of Alignment (LOA) Output reassignment limit has been exceeded.
Ok No defect detected
Figure 193. Details of Defects of the squelchable clocks described above.

On Nimbra 310 and 320, the TSI-2 interface described for Nimbra 360 and 380 is absent,
but the TSI-1 interface is present and has the same functionality.
11.7 DTM and transport layer synchronization

In a modern SDH/SONET/DTM network, the two synchronization mechanisms are co-
operating. DTM maintains its own “overlay” timing domain, which is governed by the
DTM synchronization reference clock. This timing domain controls and synchronizes the
transmission of the DTM frames, i.e. the VC-4 -Xc/STS-3Xc of the network. The frequency
difference between this domain and the various parts of the SDH/SONET network is
handled by pointer justifications in the SDH/SONET layer.
The synchronization protocol treats IP/Ethernet transport layer in the same way as a
SDH/SONET layer. An 8 kHz clock is transported over the underlying packet network and
recovered to become the node synchronization signal. Of course, the transport properties of
a packet based network are different from those of a synchronous or optical network. The
IP/Ethernet trunk has different mechanisms, like Forward Error Correction, to overcome
packet loss and jitter that are prevalent in the packet network.
11.7.1 Timing modes of SDH/Sonet trunks

The functionality of the Nimbra DTM interfaces with respect to SDH/SONET trunks is to
set a timing mode for the line interface. Each trunk interface support all or a sub-set (see
Figure 195) of the following timing modes:
Network timing: The line rate is synchronized to the DTM network frequency. This applies
to all new Nimbra One/300 trunks, 4 x DS3/E3 and all Nimbra 600 series trunks.
Interface timing: The line rate is synchronized to an on-board local oscillator. Applies to:
4xOC-3/STM-1 Trunk (NPS0009-X/3S31), OC-12/STM-4 Trunk and 4xOC-3/STM-1
Access for Nimbra One and 300 series.
Loop timing: The line rate is synchronized to the incoming line frequency. Applies to:
4xOC-3/STM-1 Trunk (NPS0009-X/3S31), OC-12/STM-4 Trunk and 4xOC-3/STM-1
Access for Nimbra One and 300 series.
In Interface timing mode, the line frequency is asynchronous to DTM Network timing and
pointer justifications are performed in the transmit direction in order synchronize the VC-4
-Xc/STS-3Xc to the line rate.
In Loop timing mode, the line frequency may be asynchronous to DTM network timing, but
it may also be synchronous if the SDH/SONET network is synchronized with the same
reference clock that is used by the DTM network. In this case, we have a fully synchronous
network, since we have then no pointer justifications at all. Otherwise, pointer justification
in the transmit direction applies as in the Interface mode described above.
Finally in Network timing mode, the line rate is synchronized to the DTM network
frequency and hence no pointer justifications are needed in the transmit direction. In this
case we can also have a fully synchronous SDH/SONET/DTM network if the same
reference clock is used for both SDH/SONET and DTM.
The IP/Ethernet trunk is timed in a way that is similar to the Network timing mode.
Note that when running in either “Interface” or “Loop” timing modes the trunks are not
intended for SDH/SONET synchronization; they are rather “DNU” (Do Not Use for
synchronization) clocks. This applies especially for the older trunk interfaces, the 1-port
OC-3/STM-1 and OC-12/STM-4 trunk, which have Stratum 4 clocks. The 4 x OC-3/STM-1
Trunk/Access Module has a Stratum 3 clock and can, if necessary, be used to source
synchronization to a SDH/SONET sub-net.

Interfaces that support Network timing mode can be used to transport SDH/SONET
synchronization, provided that the network is synchronized by a suitable external reference
clock. This applies to the OC-48/STM-16 X-ADM and the 4 x DS3/E3 trunk modules.
11.7.2 Hold-over and free-running properties

A Nimbra switch is never in hold-over for longer than at maximum a couple of seconds.
This is by the design of the DTM synchronization mechanism. During this time, the clock
in hold-over mode obtains the network frequency as learned while in a synchronized state.
The effect of the residual frequency difference between the real network frequency and the
sourced frequency in the short hold-over time is about 0.1 ppm and is negligible due to the
short time the node is in hold-over mode. This residual frequency difference will cause a
phase ramp during holdover.
If the network does not have an external clock source, the network is synchronized to one
of the node internal clocks that is free-running. In this case, all other node-clocks are locked
to this internal clock, all network timing properties are also governed by this clock. This is
not an ideal situation and it is strongly recommended to use an external clock reference of
sufficient quality.
11.8 IP/Ethernet Trunk

The synchronization performance of the IP/Ethernet trunk is affected by the quality of the
IP connection. The more packet jitter, the more jitter/wander on the recovered sync signal.
The quality of the IP/Ethernet trunk can be monitored by inspecting the Synchronization
Signal Status. This Status has three values.
Normal – Recovered node sync is of G.813 quality, i.e. of the same quality as given by a
SDH/Sonet equipment clock (ADM).
Degraded – Recovered sync is not of G.813 quality, due to packet delay variations outside
what can be handled, but is still used. Performance degradation can be expected.
Failed – Recovered sync is not usable, the node selects another synchronization source as
decided by the DSYP protocol. Frame slips can be expected.
Other performance indicators related to the synchronization signal recovery are available in
the Web GUI; Packet jitter delay variation, Peak-to-peak packet jitter, 99.9% percentile
packet delay variation and RMS packet jitter.
Time transfer is now available over certain IP Trunk links, between fixed interfaces in
Nimbra 300 nodes. This is described in the last section of this chapter (11.12 Time
Transfer).

11.9 Configuration recommendations
11.9.1 External reference clocks - requirements
A strong general recommendation is to use an external reference clock with high accuracy
and stability. Some networks works perfectly well without an external reference clock
while other networks may function but with lower service quality. Some networks may fail
to operate completely without an external clock reference. In the table some suggestions are
listed:
External Network contains Why?

reference
clock
needed?
Yes, must Only Nimbra One with If there is no external reference clock, the network may
have OC-48/STM-16 X-ADM synchronize to a Nimbra One with a built-in Stratum 4
or 2 x OC-12/STM-4 oscillator, and since the listed trunk supports only
or 4 x OC-3/STM-1 network timing mode this may result in a line rate that
or 4 x DS3/E3 Trunk exceeds the ±4.6 ppm SDH/SONET standard limits.
If several types of nodes are combined in the network,
this should not happen in GX4.8 as the nodes have an
internal clock priority according to the accuracy of the
clocks.
Yes, SDI Video service This service has a very hard requirement on drift rate that
preferred can only be guaranteed with a high stability clock
reference.
No None of the above OK for smaller networks with less requirements on

wander performance, such as for Ethernet transport for
example.
Figure 194. External clock recommendations.
The requirements on the external reference clock are:

High stability (preferably PRC/Stratum 1, which could be obtained from GPS)
2.048 MHz signal, according to ITU-T G.703.13, sine or square wave1
Alternatively, a 1.544 MHz signal with the same electrical properties as the 2.048 MHz
clock described above may be used.
1
Note that 2.048/1.544 MHz signals shall be “clock signals”, i.e. sine or square wave.
The port does not support E1/DS1 framed signals. The external sync in port
automatically detects if a 2.048 or 1.544 MHz clock is attached.

Note: Please note, D4, SF or ESF formatted T1 timing signals cannot be used
as synchronization source.
Nimbra 310, 320, 360 and 380 can also use a 10 MHz signal as reference input.
Redundant GPS controlled sources are preferable. If the primary reference clock goes
down, DSYP will switch over to a secondary reference clock with the same frequency, and
thus avoid a possible frame
frame-slip in the transition process. These excellent sources may be
configured as external sources with priority 0, to use synchronization network
segmentation.
It is recommended
ecommended to connect the external reference clock to a centrally positioned node, in
order to get as few hops as possible to all or most nodes.
Note: Regardless of external clock source, it must disable its output upon
error in order to signal to the network that the clock source has failed.
This may require configuration in the
th source. PRC sources not
supporting mute/squelch of outputs on detected errors are not
recommended since they have a high probability of causing large
network errors difficult to pinpoint to the timing source.
Note: Nimbra One should not be used as a timing node. If still used, only
square wave signals of high amplitude must be used.

11.9.2 Trunk interface configurations
Different trunk interfaces have different capabilities with respect to SDH/SONET
synchronization. In this section, the various interfaces are discussed and recommended
settings are given. Below is a table that summarizes capabilities and recommended settings.
Trunk interface Capabilities Choices Default Recommendation Comments
Nimbra One/300 series
4 x OC-3/STM-1 Transmit sync Interface

Interface Interface See 11.9.3.2
Trunk (-X/3S31) source Loop
Transmit sync Internal Internal =
Loop Loop
source Loop Interface
4 x OC-3/STM-1
Access Synchronization
Status message 0..15 15 15 15 = Do Not Use
(SSM)
DS3: Line =
synchronized to
4 x DS3/E3 Receive sync Line line signal
Line
Trunk/Access (RX_FSYNC) Line FSP (if Time transfer FSP =
FSP
used as trunk source is used) synchronized to
Frame Start
Pattern
OC-12/STM-4 Transmit sync Interface
Trunk source Loop
OC-3/STM-1 Transmit sync Interface
Trunk source Loop
STM-1/4/16 See 11.9.3.1
3 x IP/Ethernet
See 11.9.3.4
Trunk
Nimbra 600 series
4 x OC-3/12/48 /
STM-1/4/16 See 0
Trunk
OC-192 / STM-64
See 0
Trunk
3 x IP/Ethernet See 0
Figure 195. Capabilities of Nimbra trunks
The parameter ‘Allow as sync source’, which was defined on the trunk configuration page
in GX4.7, has now been moved to the configuration page of the DTM interface.

11.9.3 Trunks for Nimbra One/300
11.9.3.1 OC-48/STM-16 X-ADM, 2 x OC-12/STM-4 Trunk and 4 x OC-3/STM-1 Trunk
Module (NPS0009-X/3S32)
These modules only support Network sync mode, so there is no timing mode to configure.
Note that it is important that the network frequency is kept within ±4.6 ppm in order to
comply with SDH/SONET standards. The on-board clock quality is of SEC/Stratum 3.
11.9.3.2 OC-12/STM-4 Trunk, 4 x OC-3/STM-1 Trunk/Access (NPS0009-X/3S31) and

OC-3/STM-1 Trunk Module
These modules support interface and loop timing modes. Default is interface timing mode
and this is also the recommended mode. Loop timing mode may be used when the trunk
interface is connected to SDH/SONET network that sources timing.
When two OC-3/STM-1 or OC-12/STM-4 trunks are directly connected with a fiber pair or
wavelength the following combinations exists:
Interface <-> Interface OK
Interface <-> Loop OK
Loop <-> Interface OK
Loop <-> Loop Not OK
The last combination would lead to a timing loop and possibly a fault.
The 4 x OC-3/STM-1 Trunk/Access Modules have SEC/Stratum 3 quality clocks, the
others is of Stratum 4 quality.
11.9.3.3 4 x DS3/E3 Trunk/Access Module

This module is always slaved to the network frequency and thus it has no timing
configuration options. The same external synchronization condition that applies to the OC-
48/STM-16 X-ADM also applies for this board.
FSP (Frame Sync Pattern) is required when the Time Transfer is used.
11.9.3.4 IP/Ethernet Trunk for Nimbra One/300 and built-in ports on Nimbra
310/320/360/380
This module has one option, Enable sync recovery, which is by default enabled. The option
may be disabled in e.g. the following cases.
Interconnection of two Nimbra networks via an IP/MPLS/Ethernet link.
If each of the two Nimbra networks is synchronized via a centralized external
synchronization source, it may be beneficial not to not transport the sync from one network
to the other over the IP connection but rather use two synchronization sources for the two
parts of the network. This requires that both external references are synchronized (for
example both references are tied to GPS clocks) to avoid slips.
Single Frequency networks (SFN).
When feeding transmitter sites with the IP/Ethernet trunks in an SFN use case, GPS clocks
are needed to provide time synchronization for SFN operation, since the IP/Ethernet trunk
does not support the Time Transfer functionality.

11.9.3.5 All trunks for the Nimbra 600 series
These trunks have a parameter ‘Allow as sync source’ on the DTM interfaces. By default, it
is selected, but by disabling synchronization distribution along certain trunks the user can
tailor the synchronization according to customer specific requirements. These trunks all use
Network timing mode.
11.10 Allow as sync source – DTM configuration

On the DTM → Interfaces web page, all DTM interfaces are configured, and it is also here
where you now can find the configuration parameter ‘allow as sync source’.
This parameter is by default selected, i.e. the synchronization signal extracted from the link
is available as sync source in the node. This behavior is the same as in GX4.7 and earlier.
Removing this selection is the new feature in GX4.8.
Figure 196. Allow as sync source is defined on the DTM interface.
11.11 Monitoring synchronization performance

11.11.1 Slip Seconds
The single most important tool for monitoring the synchronization performance is to
inspect the Slip Seconds (SS) performance counters. These counters indicate if there have
been one or more DTM frame slips during a second. This could hypothetically happen if
node sync, for some faulty reason, is not synchronized to a trunk interface that is part of the
synchronization spanning tree. Then it will pace out frames at another frequency than the
network frequency. This should never happen. The counters are found in the Web GUI
under Perf. Monitor → Trunks
These should always indicate “0”. Anything else indicates a serious problem. During
extreme conditions, such as changing to a new reference source with another frequency, or

if there has been very many sync changes (due to many intermittent topology changes for
example) the slip counter may step one count. In former case due to that all phase relations
are altered when the network frequency changes. In the latter case due to accumulated
residual phase errors in the synchronization source change process. However, in steady
state there should be no slips if the network synchronization works alright.
It is also possible to trigger an alarm, by enabling a threshold crossing alarm. Use a
threshold of “1” in order to be sure to catch a single slip.
11.11.2 Pointer Justification Events

Pointer Justification Events (PJE) at SDH/SONET interfaces are available for monitoring.
There are counters for
RPJE +
RPJE –
TPJE +
TPJE -
on the Trunks → Interfaces web page. These counters are reset each time the web page is
accessed. (Note that if several users are logged in, it may be reset of another user accessing
the page). These counters give information about the difference between the line rate of the
interface and the DTM network frequency. For interfaces in Network timing mode the TX
counters should be zero. In the RX direction an intermediate SDH/SONET network could
introduce pointer justifications also when in Network timing mode.
11.12 Time Transfer

Time transfer is an optional software feature available on Nimbra 310, 320, 360, 380 and
the Nimbra 600 series. It requires Nimbra 310, 320, 360 or 380 nodes for PPS/10 MHz
input/output interfaces.
Time transfer is based on node clocks and network synchronization available in all DTM
networks. The Time Transfer functionality distributes absolute time to all participating
nodes of a Nimbra Network. With Time Transfer, Time delay between two neighboring
nodes is constantly measured and communicated between the nodes. This allows the nodes
to calculate absolute time with great accuracy, with all intrinsic, static and dynamic time
delay constantly taken into account.
Time transfer is distributed according to a DSYP spanning tree configuration. Time transfer
is an add-on feature of the synchronization distribution and follows the same path as the
sync distribution. A consequence of this is that whenever time transfer is active, the
synchronization source of the network must be the external clock introduced in the time
transfer master node.
This is useful for many applications. For example, in DTT contexts a Single Frequency
Network is used for transmitter sites to simultaneously broadcast programs on the same
frequency. This means that the received signal is stronger and that the network operator
gets a simpler network/frequency plan.
Time transfer specific information is sent between nodes on dedicated, automatically set-up
time transfer channels. They can be listed from the link All connections → Channels or
from Nimbra Vision.
The time transfer function utilizes DSYP to find the shortest path for time distribution and
to find an alternative path in case of node or link failure. The time transfer accuracy is
better than ± 1.5 µs for ten consecutive node hops.
To configure time transfer, the PPS/10 MHz input node must also be used as an external
synchronization source. Start from the DTM → Sync page.

Figure 197. Configuration of the external clock admin status in the node that is the source
for time transfer.
In our case, the external clock priority is set to 4 and the administrative status is set to ‘Up’.
The second step in configuring time transfer is to enable the links on all nodes using or
passing time transfer signals. This is made from the DTM → Time transfer link.
Figure 198. Time transfer configuration web page for node iov101, the source for time
transfer.

The admin status of these links must be set to ‘Up’ at both ends of all relevant links as Time
Transfer is enabled on a per link basis
basis. The easiest way is to set it to
o ‘Up’ for all links in all
nodes.
Operational status is ‘Up’ when time transfer is active and sync is taken from the interface
interface.
If sync is only delivered to the link, the operational status remains stated as ‘dormant’ in the
web interface. That is why no link has operational status ‘up’ in the illustration; the source
node only delivers time transfer signals, it does not receive them.
Timing reference is the synchronization source that is currently active.
Time scale status describes the cucurrent
rrent operating mode. In can take on three different
values; uninitiated, reassigned and compensated. The initial state is Uninitiated, which
indicates that the time of the time scale is not initiated and may not be used for any time
keeping. When the time scale of the node have a degenerated time offset from neighbor
nodes (being Compensated
Compensated) or a local TAI/UTC (atomic time/universal time coordinated )
source, the node reassigns the time scale and enters the reassigned state, during which the
time scale mayy not be used for precision timekeeping.
timekeeping When the time scale of the node has
been initiated to TAI/UTC, it is compensated and can be used for time keeping..
To configure a particular interface, click on the link to the interface in the Time sources
column.
Figure 199. Time transfer configuration web page for a specific interface.
On this page, the administrative status can be set. The administrative status is set to ‘Down’
for all trunks by default. In order to let the system handle selection of a suitable
synchronization
tion source, it is strongly recommended to set the administrative status on all
trunk interfaces to ‘Up’ when using the time transfer feature. Time transfer channels are
then established exactly where they are needed, automatically.
Note: Setting the administrative status to ‘Down’ on an interface with operational status
‘Up’ forces the operational status to state ‘Down’ and disab
disables
les the time transfer
function.
No warning is given to nodes further down in the synchronization chain, but an
event is gene
generated in the event log.
This setting is strongly discouraged.
The parameter ‘Calibrated Round trip ratio’ is the difference between the return trip time
divided with the round trip time and ½,, expressed in ppm of the round trip time. Observe

that it is the return time to the node that counts, not vice verse. The parameter is in the
range -499999 to 499999.
10,1 ms
A 9,9 ms
B
CalRTT_RA = 9.9/(10,1+9,9) - 1/2 =

- 0.1/20 = - 5000 ppm
CalRTT_RB = 10.1/(10,1+9,9) - 1/2 =
+ 0.1/20 = + 5000 ppm
Figure 200. Definition of calibrated round trip ratio, given as an example.
11.12.1 Listing of time transfer channels

The time transfer channels are seen under All Connections → Channels are listed. They are
listed as Time transfer services.
Figure 201. All Channels listed, including all Time Transfer channels.
11.12.2 Time transfer on additional interfaces from GX4.12

Time transfer was first introduced and only available on SDH interfaces. In GX4.12, time
transfer is also supported from fixed IP Trunk interfaces in Nimbra 310/320/360/380, but
currently not from the plug-in modules of the same node types. Neither is it supported for
IP trunks in the Nimbra 600 series.
Inclusion of time transfer on such links requires supporting firmware, which needs to be
downloaded to the module. Support for such downloads is included in the web interface.

12 Performance Monitoring
12.1 Overview
The Performance management function collects measurement data to allow a network
operator to troubleshoot, plan maintenance on their network and discuss quality-of-service
issues with their own customers.
Performance monitoring is based on ITU-T G.826 standards for SONET/SDH trunks.
Performance monitoring for other measurement points follows the standard as well as they
can, but in some cases were the standard is not applicable, other measures are used to
evaluate performance in the network.
Monitoring is available on all
Trunk interfaces, on the receiving ports
Access interfaces, on the receiving ports (from external equipment)
ITS services (end-to-end), on the egress from the DTM layer towards the outgoing access
port. This monitoring is available, regardless if the stream is sent to the sink interface or
used as an available (standby) backup stream. For PM to be available on standby streams,
the stream must be terminated on a separate sink TTP. Protection cases may be open ended
or closed ended, the important thing is that they are terminated on separate TTPs.
Figure 202. Open ended protection with performance monitoring on both streams on
(separate) sink TTPs.
Element Manager User's Manual Performance Monitoring • 208

Figure 203. Closed ended (hitless/standby) protection with performance monitoring on
both streams.
Ethernet ports, both physical interfaces on the nodes and virtual ETS interfaces. On these
ports, monitoring is available for two different logical objects in each port. The source
object monitors outgoing streams and the sink object monitors inbound streams to the port.
They are shown as eth-source, eth-sink, ets-source or ets-sink on the performance
monitoring web pages.
Node A Node B
eth-sink ets-src ets-sink eth-src
Forwarding Forwarding
function function
eth-src ets-sink ets-src eth-sink
Point of PM measurement
Figure 204. Illustration of a bidirectional ETS connection between two Nimbra nodes. The
four performance monitoring objects per node track incoming traffic (shown as
small circles here).
The monitoring points are sampled every second and a new performance monitoring period
is started every 15 minutes, on the quarter (hh:00, hh:15, hh:30, hh:45). The 24h periods are
synchronized with the 15m periods, i.e. the first 24h period and the first 15m period start at
the same time. Timing is taken from the Date/time function of the various nodes.
When a new period starts, all regular counters are reset to zero and, if appropriate, the ZS
counter is increased with one. The Zero Suppression (ZS) counter registers number of fault
free periods prior to the current period.
Performance reports are issued at the end of the measurement intervals. Performance
reports are logged and the size of the PM log is configurable to be large, small or none. A

small PM log consists of 15 15m periods and one 24h period. A large PM log consists of 96
15m periods and 30 24h periods. None disables the PM log.
Alarms can be configured to be generated for unavailable time and defined threshold on
counters (15m ES/SES/BBE/SS or 24h ES/SES/BBE/SS). The threshold crossing alarms
(which is singular) is ceased after a complete measuring period (15 min or 24 h) below the
threshold value.
Zero suppression is by default enabled, which means that performance monitoring periods
with ‘all zeros’ are not entered in the PM log and thus not listed in the web interface.
Entries in the PM log can generate events and subsequently sent as SNMP traps; by default
this feature is disabled.
If a parameter cannot be calculated, e.g. because a sample is unavailable or a sample is
outside the range of the measurement variable, the performance interval is declared invalid.
12.2 General
In the web interface, Performance monitoring is found under the Perf. monitor link.
Figure 205. Performance monitoring web page. The sub-sections are Configuration and
Data.
The general configuration settings for all performance measurement points in a node are set
on the Perf. Monitor → Configuration web page.
Figure 206. Performance Monitoring configuration menu
The configurable parameters on this page are described in the table below:

Parameter Type Range Default Description
Administrative Binary Up, Down Up The administrative status of all performance
status monitoring in the node. Setting it to ‘Up’
enables performance monitoring while
setting it to ‘Down’ disables performance
monitoring in the node.
Small history Integer 0 - 4294967295 128 Consist of 15 PM report entries of 15
log (max (232-1) minute and one entry of 24 hrs. Allocated
number) system resources for the small history log.
Large history Integer 0 - 4294967295 4 Consist of 96 PM report entries of 15
log (max (232-1) minute and 30 entries of 24 hrs. Allocated
number) system resources for the large history log.
Figure 207. Configurable performance monitoring parameters in the node.
Even though very large values are allowed for the number of large and small history logs, it
is recommended to stay at or close to the default values. Excessive values leads to out-of-
memory problems at some unspecified time in future.
When the parameters have been set, click on ‘OK’ or ‘Apply’ to store the settings in the
node. Apply takes the user back to the starting page for performance monitoring, while OK
keeps the user on the configuration web page.

12.3 Monitored performance values
The following performance parameters are monitored:
(G.826)
UAS Unavailable Second is a second of unavailable time. Unavailable time starts after
ten consecutive SES and ends after ten non-consecutive SES.
SES Severely Error Second (Subset of ES) is a second of seriously faulty available time.
One second of available time containing ≥30% EB or at least one defect. Ten
consecutive SES seconds begin UAT state while ten consecutive non-SES seconds
end UAT.
ES Error Second is a second of available time with one or more BBE.
BBE Background Block Error is the number of errored blocks found during one second
of available time that is not part of SES.
SS Slip Second is one second containing one or more Slips, which is Applicable for
trunk modules.
Suspect If this parameter value is yes, all counter values may be erroneous and should be
interpreted with care. Incomplete measurement periods are set to yes; otherwise it
can be expected to be no.
ZS Zero suppression (counter) tells the number of periods with all performance
parameters being zero before the current period.
Figure 208. Performance Monitoring, monitored parameters
The block sizes are different for different trunks, accesses and services. The current block
sizes are:
Trunk/Access/Service Block size
IP Trunk 1 frame, 8000 frames/s

T1 (1544 kbit/s) 4632 bits
E1 (2048 kbit/s) 2048 bits
E3 (44736 kbit/s) 4760 bits
STM-1 (VC-4) 18792 bits
STM-4 (VC-4-4c) 75168 bits
OC-48/STM-16 (VC-4-16c) 300672 bits
Ethernet access 1 Ethernet packet
AES/EBU Audio 12288 bits
MADI Audio 125000 bits
SDI Access 1000 block/s, bit rate dependent
ASI Access 1000 block/s, bit rate dependent
Figure 209. Block size for different trunks, accesses and service

12.4 Configuration of PM objects
The monitored PM objects; trunks, access interfaces, ITS (sinks) and Ethernet ports
(sources and sinks) are all individually configurable. To configure an individual PM object,
go to web page for configuration of the specific object. This is done by following the link
(in the example below) Perf. monitor → Data → sonet/sdh-3:2 → Configuration tab.
Figure 210. The data presentation web page is also the entry point for configuration of a
single PM object (by following the Configuration tab).
Below, the object is configured. All different types of objects are configured the same way.

The configurable parameters are:
Parameter Type Range Default Description

Administrative Binary Up, Up This parameter enables (‘Up’) or disables (‘Down’)
status Down PM on the PM object.
Enable UAT Binary On, Off Off This parameter enables (‘On’) or disables (‘Off’)
alarms UAT alarms on the PM object. The alarm is
generated when the PM object is in an ‘Unavailable
Time’ state (after ten consecutive SES)
Enable Binary On, Off Off This parameter enables (‘On’) or disables (‘Off’)
threshold threshold crossing alarms on the PM object. One of
crossing alarm two possible alarms is received when one or more of
the threshold values (defined below) are equaled or
surpassed. The alarms are ‘15 min’ and ‘24 h’
threshold crossing alarm.
Enable zero Binary On, Off On This parameter enables (‘On’) or disables (‘Off’) zero
suppression suppression on the PM object. Zero suppression
means that PM entries with all counters equal to zero
are not stored in the PM log, but instead the ZS
counter is increased with one. The next entry in the
PM log is the next entry with one of the PM counters
(ES/SES/BBE/SS/UAS) not equal to zero.
Enable periodic Binary On, Off Off This parameter enables (‘On’) or disables (‘Off’)
history reports periodic history reports to be generated as events and
thus subsequently sent as SNMP traps to SNMP
managers like Nimbra Vision.
History log size Drop None, Small None: No history log is used.
down Small, Small: Small history log is used.
Large Large: Large history log is used.
15m ES Integer 0-900 2 Value for 15m ES threshold, where zero has a special
threshold meaning of disabling the threshold.
15m SES Integer 0-900 1 Value for 15m SES threshold, where zero has a
threshold special meaning of disabling the threshold.
15m BBE Integer 0- 2 Value for 15m BBE threshold, where zero has a
15m SS Integer 0-900 1 Value for 15m SS threshold, where zero has a special
24h ES Integer 0-86400 10 Value for 24h ES threshold, where zero has a special
24h SES Integer 0-86400 1 Value for 24h SES threshold, where zero has a
24h BBE Integer 0- 10 Value for 24h BBE threshold, where zero has a
24h SS Integer 0-86400 1 Value for 24hm SS threshold, where zero has a
Figure 211. Configurable parameters for PM objects.

12.5 Presentation of PM objects
Available PM data is presented in the web interface from the link
Perf. Monitor → Data. The top row is by default set to view all PM objects with non-zero
entries in the 15m PM log, shown below.
Figure 212. Performance Monitoring Data web page
All headings on this page within parenthesis like (interface), (service), (direction) etc
include all values for this parameter. If a set value is chosen, like setting (interface) to
‘Trunk’, then only PM object with that value are displayed in the listing generated with a
click on the show button. The entries in these drop-down menus depend on the particular
configuration of the node. In the pictures below, this is illustrated.
Figure 213. Possible values for the parameter (interface). The default value shows all
entries, Trunk show all trunk PM objects, Access show all access PM objects
and TTP show all PM objects ending on TTPs (previously called connection).

Figure 214. Possible values for the parameter (service). The default value shows all entries;
the values that show up in the menu are available but different values appear
depending on the node configuration.
Figure 215. Possible values for the parameter (direction) are ‘source’ or ‘sink’. Source
means signals originating from the measuring point and sink means signals
terminating on it.
Figure 216. Possible values for the parameter (errors) are ‘15m errors’ and ‘24h errors’.

Figure 217. Possible values for the parameter (admin status) are ‘Admin up’ and ‘Admin
down’.
Figure 218. Possible values for the parameter (oper status) are ‘Oper up’ and ‘Oper down’.
All the parameters shown in the top row form a filter, through which all PM object log
entries are passed. Only those PM object log entries that satisfy all conditions are listed on
the web page.
All configured PM objects in the node are presented in the lists that are seen in the drop-
down menus. Available PM objects depend on the node configuration.
12.5.1 Interface PM objects

Under this listing, in a typical node, there are three different choices; trunk, access and TTP
(known as ‘Connections’ in previous GX releases). Selection of trunk, access or TTP
presents only those types of PM objects, in the same way as the main links in previous GX
releases.
Trunk PM objects are monitored on the incoming (Rx) port of the trunk interface, which is
illustrated below.

Node A Node B
Trunk Rx Trunk Tx Trunk Rx Trunk Tx

Access Access
Modules Modules
Trunk Tx Trunk Rx Trunk Tx Trunk Rx
Point of Trunk PM measurement
Figure 219. Trunk PM objects
Trunk PM available
IP/Ethernet trunks Yes
SONET/SDH trunks Yes
PDH trunk (4 x DS3/E3 for Nimbra 300) Yes
Figure 220. PM implementation on different trunks
Access PM objects are monitored on the incoming Rx port of the access interface on the
access modules which has the feature implemented.
Node A Node B
Access Access
Modules Modules
Tx Rx Tx Rx
Point of Access PM measurement
Figure 221. Access PM objects
Access module PM available

8 x Gigabit Ethernet Access Module Yes
8 x Video Access Module Yes
8 x 3 Gbps Video Access Module Yes
JPEG 2000 Video Access Module Yes
ASI/AES Access Module (also for MADI) Yes
Figure 222. PM implementation on access modules for Nimbra 600

Access module PM available
4 x DS3/E3 Trunk/Access Module Yes
Gigabit Ethernet Access Module Yes
Fast Ethernet Access Module No
8 x ASI Transport Access Module Yes
8 x AES/EBU Access Module Yes
SDI Video Access Module Yes
8 x SDI Video Access Module Yes
4 x OC-3/STM-1 Access Module Yes
E1/T1 Access Module No
Figure 223. PM implementation on access modules for Nimbra One/300
TTP objects can be monitored both on their source and the sink interfaces, i.e. they are
logically divided into two separate objects. PM on the sink interface is supported in most
cases, whereas PM on the source interface is limited to Ethernet PM objects (physical ETH
and logical ETS interfaces).
Node A Node B
Access Access
Modules Modules
DTM
TTP TTP TTP TTP
sink src sink src
Tx Rx Tx Rx
Point of TTP PM measurement
Figure 224. TTP PM objects
Note that for the source PM objects, errors occur in particular when the buffer for the
outgoing stream is filled and packets are dropped. This is quite different from sink
interfaces, where the cause of errors is lost packets in transit.
12.5.2 Services
Under the (services) heading, PM objects can be sorted by service. Observe that the
combination of (interface) and (service) can create logically inconsistent and for that reason
empty sets. For example, if interface is chosen as Trunk and Service SDI, the created set is
always empty as an SDI trunk is logically inconsistent.
Some services, like Ethernet, can be both trunk and access. Other services are either always
trunk or always access.
12.5.3 Direction
Under this heading it is possible to select if you want PM data only for points in the
network where traffic is terminated (i.e. sink) or where traffic originates (i.e. sources).
12.5.4 Error
Under this heading, it is possible to filter out all entries for15m or for 24h. The default
setting is to look only at those entries with one or more non-zero counters for the past 15
minutes or in other words only look at those counters with some action.

12.5.5 Admin and Oper Status
Under the two last headings, it is possible to sort the PM objects on their administrative or
operative status. It is possible to select object with administrative status up/down and
operative status up/down, independently of each other.
12.5.6 Reset of counters and setting of admin status on

multiple objects
In the list that is presented after a search has been made, i.e. after the different headings has
been selected and the button ‘Show’ has been clicked, tick boxes appear for all entries.
To select all entries in the list, just tick the box on the row with the headings.
Figure 225. All entries in the list are selected by selecting the tick box in the top row, with
the headings. Objects can be removed from the selection by clicking in the tick
box in the leftmost column.
With all selected PM objects, it is now possible to reset the counters with a single click on
the ‘Go’ button. Alternatively, the admin status of the PM objects can be set to either ‘Up’
or ‘Down’. Just change the value in the (change selected item) drop-down menu and click
on the ‘Go’ button.

12.5.7 Particular PM Object web page
If details of a particular interface are of interest, click on this link in the listing and the web
page is presented.
Figure 226. Details of trunk sonet/sdh-3:1 is obtained by clicking on the link to this trunk.
On this web page, the current values of the counters are presented as well as a graph of
previous measurement periods. For a tabular form of the data, the link History details can
be used. Similar graphs and history details are available for 24h counters.

Figure 227. Graph and history details for sonet/sdh-3:1

13 Access Modules
13.1 Access Module types
Access Modules can be of two different types in Nimbra nodes, ITS (Isochronous Transport
Service) or Ethernet Transport Service (ETS). Configurable parameters of the modules are
described under the ITS or Ethernet sections.
13.2 Overview access interface modules

The access interfaces are used to feed the network with various kinds of traffic. A wide
range of interfaces allowing access modules interacting of most kinds of data, voice and
video equipment or external network are available. For Nimbra One some of the interfaces
are available in type A (odd slot) and B (even slot) versions, but most of the modules can be
used as A/B.
Access modules without specified hardware are available in Nimbra One and Nimbra 300
versions.
Access Module Nimbra node Service supported Type

E1 Access Nimbra One/300 Switched E1 tunnel ITS
T1 Access Nimbra One/300 Switched T1 tunnel ITS
4 x DS3/E3 Trunk/Access Nimbra One/300 Switched DS3/E3 tunnel ITS
Fast Ethernet Access Nimbra One/300 Ethernet Tunnel service ETS
Gigabit Ethernet Access Nimbra One/300 Ethernet Tunnel Service ETS
4 x OC-3/STM-1 Access Nimbra One/300 4 x OC-3/STM-1 Access ITS
SDI Video Access Nimbra One/300 Streaming SD-SDI video ITS
8 x SDI Video Access Nimbra One/300 Streaming SD-SDI video ITS
8 x ASI Transport Access Nimbra One/300 Streaming ASI service ITS
8 x AES/EBU Access Nimbra One/300 Streaming AES/EBU audio ITS
8 x Video Access Nimbra 600 Streaming ASI, SD/HD-SDI ITS
8 x 3Gbps Video Access Nimbra 600 Streaming SD/HD/3G-SDI ITS
JPEG2000 Video Access Nimbra 600 Streaming SD/HD/3G-SDI ITS
8 x Gigabit Ethernet Access Nimbra 600 Ethernet Tunnel service ETS
8 x ASI/AES Access Nimbra 600 Streaming ASI, AES or MADI ITS
Figure 228. Access module overview
Element Manager User's Manual Access Modules • 223

13.3 OC3 /STM-1 Access Interface – web
example
Configuration of STM – 1 Access Interfaces is shown as an example of web configuration
of interfaces. The basic configuration web page is shown below:
Figure 229. Basic Parameters to configure
The displayed variables are:
Interface name The name of the interface, STM1/OC-3-8:1
Source TTP Source TTP for the outgoing STM-1 stream
Sink TTP Sink TTP for the incoming STM-1 stream
Operational status The operational status of the board: Up, Down or Absent
Description A description of the connection, e.g. SDH/SONET path
Speed The capacity of the interface, 150.336 Mbps.
Purpose Input string, inherited from the source TTP.
Errored blocks Number of errored blocks detected
Defects Presents the defect status of the module; e.g. if the SFP is
absent, the defect status is NSFP (No SFP)
Figure 230. Read-only parameters
The configurable basic parameter for the module is:

Suppress When the service is up and running as intended, alarms are by default suppressed. In
Alarms order to enable the alarms, the suppress alarms parameter must be set to ‘None’.
Other possible parameter values are:
Warning: Suppresses all active alarms with severity warning
Figure 231. Configurable basic parameter
The configurable SDH/Sonet parameters for the module are:
H1 SS bits Configurable path overhead, transparently forwarded through Nimbra nodes.
These bits (‘00’, ‘01’, ‘10’, ‘11’) are not used by Nimbra nodes.
Performance B1 Section overhead
monitoring counters B2 Line overhead
B3 Path overhead
M1 Remote indication of B1
G1 Remote indication of B3
Overhead bytes: SS & C2
Pointer adjustment RPJE+ (Rx Pointer Justification Event, plus)
event, positive and RPJE- (Rx Pointer Justification Event, minus)
negative
TPJE+ (Tx Pointer Justification Event, plus)
TPJE- (Tx Pointer Justification Event, minus)
FJE+ (Frequency Justification Event, plus)
FJE- (Frequency Justification Event, minus)
Figure 232. SDH/Sonet variables and parameters

13.4 DS3 /E3 Access Interface – web example #2
Configuration of the DS3/E3 Access Interface is shown below as another example of web
configuration of interfaces. Follow ITS → Interfaces → Link to the specific interface.
Figure 233. Configuration/edit web page of a DS3/E3 access interface.
The displayed variables are:
Variable Description
Interface name The name of the interface, pdh-1:2
Source TTP Originating TTP
Sink TTP Terminating TTP
Operational status The operational status of the board: Up, Down or Absent
Description A short description of the module
Speed The capacity of the access interface
Errored blocks Number of errored blocks
Defects Defect(s) on the interface are presented here
Figure 234. Read-only parameters
The configurable parameters for the module are:

Output action on How is the case with a failing signal on the far-end access interface handled?
signal fail If set to ‘Mute’, the failed signal muted (i.e. shut down) on the output access
interface. Muting may speed up fail-over switching time when using external
fail-over switches. If set to ‘None’, different actions are taken depending on
service type.
Output action on signal fail is irrelevant on the source interface.
Suppress Alarms When the service is up and running as intended, alarms are by default
suppressed. In order to enable the alarms, the suppress alarms parameter must
be set to ‘none’. Other possible parameter values are:
Warning: Suppresses all active alarms with severity warning
Loopback The loopback parameter can have three values; None, line or DTM
None means that loopback is disabled
Line means that the signal is looped back on the line side, i.e. that a signal that
comes from an external equipment is sent back to that equipment directly at
the interface.
DTM means that the incoming signal from the DTM network is looped back
to the DTM network. See chapter 19 Loopback for a more detailed discussion.
PDH signal to Type of PDH signal is configured here. DS3 (default) and E3 are the available
transport options.
PDH framing PDH framing used; ‘none’ means no framing, g751 or g832 are two different
ITU-T framing formats.
Figure 235. Configurable parameters for the DS3/E3 trunk/access module, used in access
mode.
Table for ‘output action on signal fail’:
Type of service Action

PDH AIS sent on the output access interface if the channel is up and there is an
error. ‘Mute’ action otherwise.
SDH AIS sent on the output access interface if the channel is up and there is an
ASI IDLE packets are sent on the output access interface if the channel is up and
there is an error. ‘Mute’ action otherwise.
AES/EBU, MADI ‘Mute’ action, possibly involving some extra noise from short cables, if the
channel is up and there is an error. ‘Mute’ action otherwise.
SDI, Native ‘Mute’ action, possibly involving some extra noise from short cables, if the
SDI, JPEG Repeat of last frame or black picture (in case no frame has been received) if
compressed the channel is up. If the channel is down, a black picture is generated.
Figure 236. Actions taken on the output access interface for the parameter ‘Output action
on signal fail’ having value ‘None’.

14 Ethernet Transport
Service (ETS)
Net Insight offers a flexible Ethernet Transport Service. Ethernet interfaces on access
modules in physically separated nodes can be combined into logical network segments,
with or without VLAN tags all according to preferences of the network operator. Ethernet
switching is implemented in some Nimbra nodes, but even earlier Nimbra node types
without this feature can be configured to take at least partial advantage of this switch
feature.
14.1 Basic concepts

14.1.1 Forwarding function (FF)
The forwarding function is a virtual Ethernet switch integrated in Nimbra nodes. When
configuring Ethernet services, this is the first object that needs to be specified. Depending
on type of node, it has different properties. The full functionality is only available on
Nimbra 310/320/380 and Nimbra 600 series nodes.
To the forwarding function, there are both physical ports (Ethernet interfaces) and logical
ETS interfaces attached. The two types of ports are configured in principle in the same way,
with small differences.
The properties of the forwarding function determines if Ethernet switching is active (Mac
mode = mac), if VLAN tags are used for switching (VLAN mode = Customer) and if
Spanning tree is used to remove unwanted Ethernet loops in the network.
The forwarding function is numbered by the user at the time of its creation. It is labeled
after the module on which it is defined with an integer to keep it unique. An example is
ff7:2, the defined FF numbered two on the module that is occupying slot number seven.
The configuration number is customer selectable and can be between 1 and 999999, but
handled by the node a consecutive sequence number is used.
14.1.2 Ethernet Transport Service interface (ETS)

The bidirectional interface in the DTM layer is called ETS interface2. From this point, a
unicast ETS service can be established to another ETS interface or a multicast service can
be established to any number of ETS interfaces. This type of service can be set up as a
unidirectional service, a service with a small return channel from all (or some) of the
destinations or as a complete hub service, i.e. all ETS interfaces have equal bandwidth to all
other ETS interfaces. This is discussed further in the multicast chapter.
Numbering of ETS interfaces is made automatically when unicast or multicast services are
defined. All physical interfaces gets the lowest interface numbers, like eth-x:1. The first
ETS interface created gets the lowest number available after the physical interfaces have
2
Earlier, this endpoint of the ETS connection was called TTP (Trail Termination
Point). This term is no longer in use for ETS, but is still used for ITS services.
Element Manager User's Manual Ethernet Transport Service (ETS) • 228

been numbered. On a Gigabit Ethernet Access Module, this is ets-x:9, where x is the slot
number of the module. The second ETS interface is labeled ets-x:10 and so on. For a
Gigabit Ethernet module on Nimbra One or 300, the first ETS interface becomes ets-x:2.
This is the general principle.
The ETS interfaces are configured in the same manner as the physical interfaces (see 14.3.9
ETH and ETS Interfaces).
14.1.3 ETS channels

ETS channels are set up from one ETS source interface to one (unicast) or multiple
(multicast) ETS sink interfaces. On top of the ETS channels, ETS services are run. ETS
services and ETS channels may be used interchangeably in the text.
14.1.3.1 ETS unicast connection

A schematic picture of an ETS unicast connection is shown below. It consists of two
channels, one in each direction. These channels are used to send packets through the DTM
network from the ETS interface at iov072 to the ETS interface at iov137 and vice versa.
Bandwidth need not be symmetrical in this case.
In the illustration, the DTM network acts like a giant extension cord between two Ethernet
interfaces of the nodes.
Node iov072 Node iov137
function function
DTM
eth5:1 ff5:1 ets5:9 ets4:9 ff4:1 eth4:1
Figure 237. An ETS channel can be defined between two ETS interfaces. The physical
interfaces (ETH) are tied to the ETS interface via the Forwarding Function.
14.1.3.2 ETS multicast connection

An ETS multicast connection connects several sink ETS interfaces to one source ETS
interface. It can be defined with any number of destinations (including zero). Both source
and destination sites must be defined as ETS interfaces. The connection provides a point to
multipoint service.

Node iov137
Forwarding
function
Node iov072 ets4:9 ff4:1 eth4:1
Forwarding
function
eth5:1 ff5:1 ets5:9 Node iov136
Forwarding
function
ets3:9 ff3:1 eth3:1
Figure 238. A multicast ETS connection, with a source (iov072) and two destinations
(iov136 and iov137). In this case the traffic is unidirectional, from iov072 to
iov136 and iov137.
In order to define the ETS service as a unidirectional service from the source to all
destination sites, it is sufficient to define the source and destination ETS interfaces.
Multicast service is by default unidirectional. If return traffic is needed, a second
connection must be defined in the opposite direction. Bandwidth need not be symmetrical
in this case.
14.1.4 ETS 1 +1 protection

The ETS 1+1 protection feature requires a different firmware on the 8 x Gigabit Ethernet
Access Modules. This firmware requires a separate license. This firmware is downloaded as
described in chapter 22 Up- and Downgrading.
Two ETS services can be grouped in such a way that they protect each other. A pair of
ETS-interfaces, starting points for the two services, in one node can be configured as an
ETS interface group. This means that properties that have to be identical for both interfaces
are set on the interface group level, while properties that may be different (like bandwidth)
are set on the ETS level. Note that even the properties that may differ in most cases should
be equal, for best operation.
For a unicast, 1+1 protected service, one ETS interface group is needed at both ends. For a
multicast 1+1 protected services, protection is configured and made on the terminating
nodes.
The interface group in the source node adds sequence numbers to the different packets. In
the sink node, the sequence numbers are used to build up the egress stream with packets
from both steams. Sink nodes can also be configured to ignore the sequence numbers and
not part of interface groups at all.
There are two configurable, different protection types; hitless or standby. They are
configured on interface group level. In hitless protection, a sequence number is added at the
source and both streams are used at the sink to generate the output stream. Normally, one
channel (the primary channel) is used, but in case of lost packets the alternative stream is
used to complement this primary channel. The design is such that the outgoing stream is
placed in a play-out buffer and a delay in introduced on the sink interface. It also means
that the streams are assumed to be identical.

The selection of protection type at the sink nodes means that one multicast stream may have
destinations terminated in different ways. Potentially, they may be hitless, standby or
without the 1+1 protection feature completely (individual ETS interfaces).
14.1.5 ETS interface groups

ETS interface groups are objects that can be located in the web user interface as ETS
interfaces. The interface groups must be created, much like forwarding functions. ETS
interface groups are needed for ETS 1+1 protection; otherwise they are not needed.
Up to two ETS interfaces can be associated to an ETS interface group. These interfaces
must in some respects have identical properties, which are then configured on the interface
group level. In other respects, they can have different properties, which then are configured
on the ETS interfaces themselves.
When two ETS interfaces are associated to an interface group, they can be configured to act
as backup for each other. This backup can be configured as standby, in which case traffic
goes through either of the ETS interfaces entirely, i.e. one stream is used and the other
stream is discarded. Alternatively, two streams can carry identical traffic and be
reconstructed as a single outgoing stream at the output. In the latter case, packets from both
streams may be used to put together the combined stream.
When the interface group is created, a forwarding function has to be assigned to the
interface group. When later, a first ETS interface is associated with the interface group; all
properties of this interface are copied to the interface group. Furthermore, they can now
only be changed on the interface group level and not on the ETS interface level. When a
second ETS interface is associated with the group, all properties are copied from the
interface group to the new ETS interface. There are a couple of parameters that still can be
set on the individual ETS interfaces, as exceptions to this rule.
Node iov137 - Forwarding function ff4:1
Forwarding
ets-4:9 ets i/f group function
i etsg4:1 ff4:1 eth-4:1

Node iov072 e Pr
ut ets-4:10
Ro
Forwarding ec
function ets i/f group eS
ets-5:9 ut
Ro
eth-5:1 ff5:1 etsg5:1 Ro
ut Node iov137 - Forwarding function ff4:2
eP
ets-5:10 ri
Ro Forwarding
ut ets i/f group function
eS ets-4:11
ec
etsg4:2 ff4:2 eth-4:5

ets-4:12
Figure 239. Example of multicast hitless setup of ETS 1+1 protection with two
destinations.
14.1.6 Protection type – hitless or standby

ETS 1+1 protection type can be configured to be either “Hitless” or “Standby”. The two
different types have fundamentally different properties and it is important to understand the
implications of hitless protection before using it. If conditions are suitable for hitless
protection, packets are used from two incoming streams to form a combined stream without
errors. If conditions are not suitable and one of the streams is missing, a single error in a
packet leads to reset of the buffer and a loss of content.

One ETS interface group, or rather one ETS interface in an ETS interface group can form a
channel (or channels) with sinks that are not part of an interface group. Sinks may even
reside on nodes without the capability to have interface groups. Of course, in these cases,
no protection is available.
14.1.7 Hitless protection

Hitless protection means that the two streams are combined in the play-out buffer on the
sink. The egress stream in composed on packets from both streams. This imposes two
requirements on the streams. First of all, the streams have to originate on the same
TTP/input interface to get the sequence number added simultaneously for both streams. To
get protection, the streams have to go through the Nimbra network along two different
routes. In other words, protection has to be closed ended, i.e. the streams start on the same
TTP in one node and traverse the network in different routes.
The physical Ethernet interface on the module is labeled after the slot occupied by the
module in the node and secondly, the interface number on the module. An example is
eth3:6, for physical interface number six (from the left) on the module occupying slot
number three.
The physical ports are configured under Ethernet → Ethernet interfaces (see 14.3.9 ETH
and ETS Interfaces).
14.1.8 Standby protection

Standby protection of an ETS interface group means that one of the two streams is used
completely (and the other stream is not used at all). Switching between the two streams is
made for the usual reasons (LOS, AIS, DEG or RBR). The selection is made at the receiver
and there is no requirement that the two streams are identical. This also means that the two
streams can originate on different nodes and have different content.
14.1.9 Interface source and sink – constituent parts

Ethernet (ETH) and ETS interfaces are each divided into two separate parts, source and
sink. The source part of the interface is the part that sends packets out from the interface
and the sink part of the interface is the part that receives packets destined to the interface.
Thus, there are four distinct parts all associated with the forwarding function (eth-source,
eth-sink, ets-source and ets-sink). These constituent parts are described in the performance
measurement section (12 Performance Monitoring)
Figure 240. Illustration of the objects eth-source, eth-sink, ets-source and ets-sink.

14.2 Configuration examples of ETS services
In this chapter different examples of ETS services are discussed, while in the next chapter a
comprehensive discussion of configuration of the different objects discussed in the previous
chapter (Forwarding Function, ETH and ETS interfaces and ETS interface groups). These
objects have many configurable parameters and it is obviously a good idea to grasp the
concept before trying to configure it.
For some parameters, there are explicit warnings about configuring them without proper
insight to their operation. In order to save the operator much trouble and unnecessary
downtime of their system, please follow this advice.
In the configuration examples below, different use cases are discussed. The details in the
configuration are described in the following chapter.
14.2.1 DTM network as extension cable

It is possible to configure the DTM network to act as an Ethernet extension cable, where the
signal on a physical Ethernet interface is transported transparently through the DTM
network to another physical Ethernet interface.
ETH Forwarding ETS ETS Forwarding ETH

function function
DTM
Figure 241. A unicast connection between two Ethernet interfaces.
The Forwarding Functions ff5:1 and ff4:1 should be configured the same way. In this
example we choose:
VLAN Mode Transparent
MAC Mode Auto or Nomac
MAC Aging Time Any allowed value works, default is recommended
Spanning Tree Auto (default) is recommended
Jumbo Frames On (default) is recommended
Fault propagation Off (default) is recommended
The Ethernet interfaces (eth5:1 and eth4:1) must be tied to their respective Forwarding
Functions (ff5:1 and ff4:1). ETS unicast connections between ets5:9 and ets4:9 are set up
on two separate web pages; the local DSTI number must match the destination DSTI set up
on the other ETS configuration page.
This configuration is typically set up as a bidirectional channel, but it is not necessary to set
up the return channel in case the traffic pattern is just a stream without return traffic.

14.2.2 ETS Multicast replication in the DTM layer
Multicast Ethernet, where traffic originates on one ingress interface and leaves the DTM
network for further distribution on several egress interfaces, is illustrated below. This traffic
pattern is typical for IP multicast distribution in applications like IP-TV.
Node iov137
Forwarding
function
Forwarding
function
eth5:1 ff5:1 ets5:9 Node iov136
Forwarding
function
ets3:9 ff3:1 eth3:1
Figure 242. A multicast connection between one ingress and two egress interfaces.
All Forwarding Functions can be defined with VLAN mode transparent and Mac mode
auto. Mac Aging Time can be chosen as the default, 300 s, as well as Jumbo Frames (On)
and Fault Propagation (Off). In ff5:1, an ETS multicast connection is set up with two
destinations. On the terminating ETS interfaces, a multicast ETS connection is defined.
Make sure the used local DSTI matches the destination DSTI entered in the originating
ETS interface. No destinations should be entered at the egress sites, unless the intention is
to set up return traffic to the originating node.
In this case, Ethernet capacity is reserved from the ingress interface to the egress interfaces,
but no capacity is reserved in the other direction.
The respective Forwarding Functions need to be connected to relevant Ethernet interfaces.
VLAN settings may be Acceptable Frame Type: All; Default VLAN: 1 and Transmitted
Frame Type: Tagged.
14.2.3 ETS 1+1 unicast closed ended configuration

In the simplest case of closed ended protected configuration, one Ethernet interface in one
Nimbra node is connected to another Ethernet interface in another Nimbra node. Defined
on both ingress and egress modules are a forwarding function, one ETS interface group and
two ETS interfaces. The ETS interfaces form two channels between the nodes, which
protect each other. Hence, the term ETS 1+1 protection can be used.
In the illustration below, which is used as a configuration example, all streams are unicast.
function ets i/f group Route pri ets i/f group function
ets-5:9 ets-4:9
eth-5:1 ff5:1 etsg5:1 etsg4:1 ff4:1 eth-4:1

Route sec
ets-5:10 ets-4:10
Figure 243. ETS 1+1 protection in a point to point case.


14.2.3.1 Configuration procedure
The configuration procedure is straight forward. A stepwise guide is:
Create two forwarding functions in the sink and source module. If we intend to use VLAN
tagged traffic, so we can choose to set VLAN mode to customer for the forwarding
functions.
Create an ETS per forwarding function. Combine the ETSes with DSTI numbers, i.e. form
channels between them.
Create an ETS interface group per ETS and move the configured ETS to the interface group
in one node. Repeat for the other node.
Create a second ETS per forwarding function. Put them into the ETS interface group and
combine the new ETS interfaces with DSTI numbers, i.e. form a channel between them.
Configure the Ethernet interfaces to be included in respective forwarding function. Put
admin status to up on the interfaces.
In the example below, nodes iov072 and iov137 are put together, from eth-5:1 in iov072 to
eth-4:1 in iov137.
14.2.4 ETS 1+1 multicast closed ended configuration

In the closed ended case of protection, two point-to-point connections are defined between
two ETS interface groups. In order to get protection, the connections have to be routed
different ways in the network. On both sides of the connection, one forwarding function,
one ETS interface group with two ETS interfaces must be configured. For distribution, one
physical Ethernet interface is natural to use in the source node, while in the sink node one
or more Ethernet interfaces are possible.
Node iov137 - Forwarding function ff4:1
Forwarding
i etsg4:1 ff4:1 eth-4:1

Node iov072 e Pr
ut ets-4:11
Ro
Forwarding ec
function ets i/f group eS
ets-5:9 ut
Ro
eth-5:1 ff5:1 etsg5:1 Ro
ut Node iov137 - Forwarding function ff4:2
eP
ets-5:10 ri
Ro Forwarding
ut ets i/f group function
eS ets-4:10 eth-4:5
ec
etsg4:2 ff4:2
ets-4:12 eth-4:6
Figure 244. 1+1 closed ended ETS Protection, multicast case
This type of protection can be used for streams between one source and one or more
destination(s) (i.e. the physical Ethernet ports in this case). In our example, we have two
destinations in the same node (and even module). The different destinations can be
configured independently of each other, i.e. they can have a mixture of hitless protection,
standby protection and even unprotected ETS interfaces.

The configuration procedure is straight forward. A stepwise guide is:
Create forwarding functions in all sink and source modules. In our case, we need to create
two forwarding functions in node iov137 as we intend to take out two independent streams
from this module.
Create an ETS per forwarding function. Combine the ETSes with DSTI numbers, i.e. form
channels between them.
Create an ETS interface group per ETS and move the ETS to that interface group in one
node. Repeat with the other ETSes.
Create a second ETS per forwarding function. Put them in the ETS interface group and
combine the new ETS interfaces with DSTI numbers, i.e. form channels between them.
Put admin status to up on the Ethernet interfaces that carry the Ethernet Traffic.
In the example below, nodes iov072 and iov137 are put together, from eth-5:1 in iov072 to
eth-4:1 in iov137 and eth-4:5/eth-4:6. Observe that the two different forwarding functions
in iov137 operate independently. They need not reside on a common module or common
node.
14.2.5 ETS 1+1 open ended configuration

Open-ended 1+1 configuration can be used both for unicast and multicast channels. The
setup is naturally made with streams duplicated outside the DTM network and entered in
two different nodes, at two different hub sites, or as in our example in different Ethernet
interfaces but in the same node.
The protection type allows the user to use a separate stream as protection. The two streams
must both be of the same type (i.e. Ethernet), but the bandwidth may vary.
Node iov072 - ff5:1
Forwarding
function
eth-5:1 ff5:1 ets-5:9

Route Pri
Node iov137
Forwarding
etsg4:1 ff4:1 eth-5:1
ets-4:10
Node iov072 - ff5:2
Route Sec
Forwarding
function
eth-5:5 ff5:2 ets-5:10
Figure 245. Open ended configuration of ETS 1+1 protection. This type can be used both
for unicast and multicast connections. The streams can be bidirectional, but for
practical applications they are mostly unidirectional.

The described procedure has two source nodes/modules/forwarding functions, use unicast
connections with one destination node/module. The ETS interface group is only used in the
destination node, where the selection of stream is made. If multiple destinations are used,
this selection is made in each destination, independently of other destinations.
In our example, the ingress points are iov072/ff5:1 and iov072/ff5:2. The destination is
iov137/ff4:1 and ETS interfaces defined in this forwarding function. To configure an open-
ended ETS 1+1 protected channel, proceed as follows:
Create one FF in the destination node (iov137) and two in the source node (iov072). The
two in the source node should be associated with different ETS interfaces in the next step.
Create one ETS interface per FF in the source node and two ETS interfaces in the
destination node/forwarding function.
Associate the ETS interface in iov072/ff5:1 with one ETS interface in iov137. Configure
routing with source route Route Pri. Associate the ETS interface in iov072/ff5:2 with
another ETS interface in iov137, using Route Sec. Configure 20 Mbps bandwidth
downstream and 1 Mbps upstream.
Group the two ETS interfaces in node iov137 together in the newly created ETS interface
group. They now protect each other.
Connect three physical Ethernet interfaces (eth port) to the three different forwarding
functions. Set administrative status to up on all ETH interfaces. Now the connection should
be up and running. Insert the same Ethernet stream in ports eth-5:1 and eth-5:5 in iov072.
The protected stream should egress on interface 4:1 in node iov137.
14.2.6 Ethernet Switching

Ethernet switching can be configured by connecting multiple ETS interfaces to one
common Forwarding Function. In the illustration below, one node is configured as hub
node and three as spoke nodes. Three unicast ETS connections are defined between node
iov072 and nodes iov136, iov137 and iov138 respectively. These ETS interfaces are all
associated to one forwarding function, which also is associated with node A. All nodes
should have VLAN Mode set to ‘Transparent’ and Mac mode set to Auto’.

Node iov136
Forwarding
function
ets5:9
Forwarding
function
Node iov137
eth5:1 ff5:1 ets5:10
Forwarding
function
ets5:11
ets4:9 ff4:1 eth4:1
Node iov138
Forwarding
function
ets5:9 ff5:1 eth5:1
Figure 246. Ethernet switching with one switch and three more nodes.

14.2.7 Ethernet switch and VLAN tagging
VLAN 1 VLAN 2 VLAN 3
External Ethernet
Switch
VLAN 1-3
Node A eth1:1
VLAN 1-3
VLAN Mode: Customer
ff1:1 Mac mode: Auto
VLAN 2 VLAN 3
ets1:9 VLAN 1 ets1:10 ets1:11
Acceptable frame type All
Transmitted frame type VLAN tagged
DTM

Transmitted frame type VLAN tagged
ets7:9 ets5:9 ets1:10
ff7:1 ff5:1 ff1:2

Transmitted frame type Untagged
eth7:2 Node B eth5:7 Node C eth1:3 Node D
VLAN Mode: Customer VLAN Mode: Customer VLAN Mode: Customer

Mac mode: Auto Mac mode: Auto Mac mode: Auto
Figure 247. An external Ethernet switch with aggregated traffic from three separate
VLANs has its traffic separated on three different Ethernet interfaces.
Different customers can share one common Ethernet interface in the Nimbra network.
VLAN tagging makes it possible to separate the different VLANs in a Forwarding Function
(in this case ff1:1) to three different ETS interfaces. On the outgoing Ethernet interfaces,
typically the tags are removed, but this is dependent on the particular application.

14.3 Configuration of ETS services
ETS service configuration requires configuration of all physical (ETH) and virtual Ethernet
(ETS) interfaces and the Forwarding Function (FF) tying the different interfaces together.
In addition, ETS interface groups must be configured for ETS 1+1 protection.
Configuration, starts from Ethernet in the left column. Additional submenus pop up:
Devices; Forwarding Functions; Ethernet Interfaces; ETS Interfaces and Perf Monitor. To
continue, follow the Devices link.
14.3.1 Devices (modules)
Figure 248. The first configuration page for Ethernet.
Figure 249. The configuration page obtained by clicking on the Devices link.
The starting point for configuration of Forwarding Functions and ETS interfaces is found
by clicking on the name of the particular device to be configured or use the ‘Create FF’
button.

Figure 250. The configuration page for a particular Ethernet device (i.e. module) is found
in this example when the link (name) eth1 is used.
14.3.2 Forwarding Function – Basic settings

A Forwarding Function (FF) is a virtual Ethernet switch defined on a module. In this text,
we first treat the case without ETS 1+1 protection.
The FF is created and deleted by the user. The first time an 8 x Gigabit Ethernet Access
Module is detected no FFs exist on the module. In order to use the device, at least one
Forwarding Function must be created. To create a FF, select Ethernet → Devices, click on
the link to the selected device (like eth1) and the button ‘Create forwarding function’.
The forwarding function in a Nimbra node must be associated with a physical device in a
node. Physical interfaces can only be attached to a forwarding function residing on the
same device/module.
When a forwarding function is deleted, a confirmation window is opened. The deletion is
confirmed with the OK button.

Figure 251. Creation of a forwarding function and selection of the index number (in this
case ff-5:1 is created).
Although only (at most) eight forwarding functions can exist on a module, they can be
numbered between 1 and 999999. It is recommended to use automatic selection and use
numbers sequentially, unless there is a compelling reason.
ETH Forwarding ETS ETS Forwarding ETH

function function
DTM
Figure 252. The relationship of different fundamental concepts in Ethernet switching.
Each Forwarding Function is associated with a number of Ethernet (ETH) and ETS
interfaces. All Ethernet and ETS interfaces associated with a specific FF must be defined on
the same module as the Forwarding Function itself is defined.

Figure 253. Configuration of a Forwarding Function in a Nimbra 680.
The basic configurable parameters (settings) for a forwarding function are: Customer ID,
Purpose, VLAN Mode, Mac Mode, Mac Aging Time, Spanning tree, Jumbo Frames and
Fault propagation.
A Forwarding Function can currently be set in two different VLAN modes and three Mac
modes (auto, mac, nomac). When set to auto, nomac mode is selected if only two ports are
connected to the FF and mac mode otherwise.
In the table below the behavior of the forwarding function is discussed as a function of
these two parameters.

Mac Mode → nomac mac
VLAN Mode↓
Transparent Transparent mode Bridged MAC mode

Forwards all incoming packets to the VLAN transparent
ports belonging to the same FF. Switching mode
IEEE802.1D
Customer Customer mode Bridged VLAN/Mac mode

Forwarding based on customer VLAN aware Switching
VLAN only. Forwards incoming mode
packets to the interfaces belonging to IEEE802.1Q
the same FF and (customer) VLAN.
Only mode supported in Nimbra
One/340/340-HD/360 products
Figure 254. The table shows available VLAN and Mac Mode settings of Forwarding
Functions. The operation of the FF is lined out for the different cases.
There are five tabs to configure in a Forwarding Function, Basic settings, Advanced
(settings), Diffserv, Spanning Tree and Statistics (see Figure 253). Note that you have to
use the Apply or OK button on each page before moving on to the next tab configuration.
14.3.2.1 Basic setting – Customer ID

Default value: 0
Type: integer
Range: 0- 4294967295 (232-1)
Description: A number to identify the customer or another entity
14.3.2.2 Basic setting - Purpose

Default value: Empty (text) string
Type: text string
Range: string consisting of 0 to 255 characters
Description: an arbitrary text string
14.3.2.3 Basic setting – VLAN mode

Default value: Transparent
Type: All choices available are presented in a drop down menu
Range: ‘Transparent’ or ‘Customer’
Description: Transparent means that no switching is made based on VLAN ID. The tags
are passed on transparently through the switch, without changes. Customer means that Q-
tags are used for switching by the forwarding function.
No VLAN configuration is possible with VLAN mode equal to transparent. The selections
are grayed out in the web interface.
In VLAN mode ‘customer’, VLAN-handling is in accordance with IEEE 802.1Q. All
frames belong to a VLAN, either from a tag present in the header or from a default tag

added by the Ethernet/ETS interface in case no VLAN tag is included in the incoming
frame.
14.3.2.4 Basic setting – Mac Mode

Default value: auto, the currently used value (nomac/mac) is seen in the web interface
Range: auto, nomac, mac
Description: auto means that nomac mode is used if only two ports/interfaces are attached
to the forwarding function and mac mode if three or more ports/interfaces are attached.
nomac means that no switching is made on the mac address, i.e. the FF never looks at the
source/destination MAC address of forwarded packets. It only forwards all frames
according to the settings of VLAN mode (if VLAN mode is customer, otherwise not).
mac means that the FF performs MAC address based forwarding and learning (i.e.
traditional Ethernet switching).
14.3.2.5 Basic setting – Mac Aging Time

Default value: 300 (seconds)
Type: integer
Range: 0-65500 (seconds)
Description: ‘Mac Aging Time’ defines how long time the stored Mac addresses remain
listed before they are removed from the list. The removal of entries can be disabled by
entering the value zero for this parameter. In this case, the entries are never removed.
14.3.2.6 Basic setting – Spanning tree

Default value: auto
Type: List
Range: auto, forward, drop, process
Description: The configurable parameter ‘Spanning Tree’ defines how BPDU packets are
handled by the Forwarding Function. BPDU stands for Bridge Protocol Data Unit and these
frames are exchanged between adjacent Ethernet Switches and carry STP information.
The ‘Spanning Tree’ parameter can assume values ‘Auto’, ‘Forward’, ‘Drop’ and ‘Process’
for Nimbra 310/320/380 and 600 nodes. ‘Auto’ and ‘Forward’ for other nodes. In the table
below, it is outlined what actions are taken depending on the values of the spanning tree
parameter.

Nimbra type Spanning Tree VLAN mode Action
Nimbra One Auto Transparent Forward; All BPDU packets
Nimbra 340/340-HD/360 are forwarded by the
forwarding function
Nimbra One Auto Customer Forward; All BPDU packets
Nimbra 340/340-HD/360 are forwarded by the
forwarding function
Nimbra One Forward All All BPDU packets are
Nimbra 340/340-HD/360 forwarded by the forwarding
function
Nimbra 310/320/380 Auto Transparent Process; BPDU packets are
Nimbra 600 nodes processed by the spanning tree
algorithm
Nimbra 310/320/380 Auto Customer Drop; All BPDU packets are
Nimbra 600 nodes dropped by the forwarding
function
Nimbra 310/320/380 Forward All All BPDU packets are
Nimbra 600 nodes forwarded by the forwarding
function
Nimbra 310/320/380 Drop All Drop; All BPDU packets are
Nimbra 600 nodes dropped by the forwarding
function
Nimbra 310/320/380 Process All Process; BPDU packets are
Nimbra 600 nodes forwarded or dropped
depending on the spanning tree
algorithm
Figure 255. Spanning tree settings in different nodes, with actions taken.
14.3.2.7 Basic setting – Jumbo frames

Default value: on
Type: binary (drop down)
Range: on or off
Description: The parameter ‘Jumbo frames’ must be set to ‘On’, if over sized packets
should be accepted. In this case, frames with up to 9208 bytes are accepted. In case the
parameter is set to ‘Off’, frames up to sizes 1518 bytes untagged and 1522 bytes Q-tagged
are supported. The default setting of the parameter is ‘On’.
14.3.2.8 Basic setting – Fault propagation

Default value: off
Type: binary (drop down)
Range: on or off
Description: Fault Propagation’ is a parameter that by default is ‘off’, but it must be set to
‘on’ if the forwarding function should send out or propagate the alarm indication signal
(AIS) instead of a poor signal. AIS can be generated in two different cases on either the
Ethernet (ETH) or ETS interface; when a degraded signal fault (DEG) is detected or when a
reduced bit rate fault (RBR) is detected. In addition to having the fault propagation
parameter set to ‘on’, it is needed to have the ‘Generate AIS on Degraded’ and/or the
‘Generate AIS on Reduced Bit Rate’ parameter set to ‘yes’ for the interface where the fault
is detected.

In addition to send AIS if warranted, the fault propagation setting passes on other alarms
through the forwarding function.
It is not presented on Nimbra One, Nimbra 340/340-HD /360.
14.3.3 Forwarding function - Advanced

A number of reserved group MAC addresses, 01-80-C2-00-00-0X (X ranging from 2 to F
hexagonally), should not be used to forward packets to according to IEEE standard 802.1D.
Recently, some applications require this mode of action to be overridden. To support such
applications, it is now possible to configure the forwarding function to drop or forward
packets addressed to these destinations in the advanced configuration web page for a
forwarding function.
Users not familiar with these concepts are strongly encouraged to leave the default settings
intact. This ensures an identical behavior to previous GX releases and the standard.
These settings can only be made on Nimbra 320/380 and Nimbra 600 models.
Figure 256. Configuration of advanced settings of a forwarding function.

14.3.3.1 Advanced – Reserved address 01-80-C2-00-00-02
Default value: drop
Type: binary, selectable from a drop-down menu
Range: drop, forward
Description: This is a reserved address for LACP, Ethernet OAM. Packets to this address
are dropped according to the IEEE 802.1D standard, but this standard can be overridden by
setting this parameter to forward.

Default value: drop
Description: This is a reserved address for 802.1X PAE. Packets to this address are
dropped according to the IEEE 802.1D standard, but this standard can be overridden by

Default value: drop
Description: This is a reserved address. Packets to this address are dropped according to
the IEEE 802.1D standard, but this standard can be overridden by setting this parameter to
forward.

Default value: drop
forward.

Default value: drop
forward.

Default value: drop
forward.

Default value: drop
Description: This is a reserved address for Provider Bridge STP. Packets to this address
are dropped according to the IEEE 802.1D standard, but this standard can be overridden by

Default value: drop
forward.
14.3.3.9 Advanced – Reserved address 01-80-C2-00-00-0A

Default value: drop
forward.
14.3.3.10 Advanced – Reserved address 01-80-C2-00-00-0B

Default value: drop
forward.

14.3.3.11 Advanced – Reserved address 01-80-C2-00-00-0C
Default value: drop
forward.
14.3.3.12 Advanced – Reserved address 01-80-C2-00-00-0D

Default value: drop
Description: This is a reserved address for Provider Bridge GVRP. Packets to this
address are dropped according to the IEEE 802.1D standard, but this standard can be
overridden by setting this parameter to forward.
14.3.3.13 Advanced – Reserved address 01-80-C2-00-00-0E

Default value: drop
Description: This is a reserved address for LLDP. Packets to this address are dropped
according to the IEEE 802.1D standard, but this standard can be overridden by setting this
parameter to forward.
14.3.3.14 Advanced – Reserved address 01-80-C2-00-00-0F

Default value: drop
forward.
14.3.4 Forwarding function – Diffserv configuration

Prioritization is performed on traffic within the ETS channel, which makes it possible to
provide a differentiated service to the customers. For customers utilizing equipment with or
without VLAN-tagging, diffserv prioritization can be used to prioritize the traffic.
Diffserv user priority is supported according to the standard for prioritizing IP-packets
based on information in the IP DSCP field, [RFC2474] and [RFC2475]. The DSCP field is
a 6-bit field, which is used for packet classification purposes. DSCP stands for
Differentiated Services Code Point. Each DSCP value has to have a defined per-hop-
behavior, which is determined by the defined Flow Group. On the Diffserv configuration
tab (web page), all of these settings have to be made.

Flow Group is defined as an integer in the range 0-7. Diffserv configuration is applied per
forwarding function, but for each interface there is an option to select Ethernet or Diffserv
prioritization. Hence a Forwarding Function may have some interfaces with Diffserv and
some with Ethernet prioritization, but all interfaces with Diffserv prioritization must have
the same Diffserv (i.e. code point to flow group) configuration. The configuration of DSCP
is made on the forwarding function, under the link Diffserv.
The mapping of flow group to priority is made on the Ethernet interface configuration page.
Figure 257. Priority selection: Two priority modes are allowed (Diffserv and Ethernet) on a
per-Interface basis. Traffic class mapping leads to two queues. The number
after the \ sign is the number of bits used.
Ethernet user priority is supported according to the standard for prioritizing Ethernet frames
based on information in the Ethernet user priority field, which is part of the VLAN tag.
This Priority Code Point (PCP) field only exists in VLAN tagged Ethernet frames and is
standardized by IEEE in [802.3] and [802.1D]. On Ethernet packets without VLAN tag
using Ethernet user priority, a default Ethernet priority is defined on the Advanced
configuration page of the ETH/ETS interface, just below MAC learning.

Figure 258. Default Ethernet priority is defined for all untagged packets reaching the
forwarding function is made under the ETH interface Advanced tab/Traffic
Priority heading.
Furthermore, on the Ethernet/ETS interface configuration page, there is a mapping of the

eight Flow Groups numbered 0 to 7 into Traffic Classes (numbered 0 or 1). The Traffic
Class is a strict priority function, where all packets in Traffic Class 1 are handled before
any packets in Traffic Class 0 are handled. In other words, dual queues are used.
DSCP or Diffserv configuration is made per forwarding function, under the Diffserv link on
the forwarding function configuration page.

Figure 259. Diffserv (DSCP) configuration, from code point to flow group, for all
interfaces in a forwarding function using DSCP prioritization. All 64 possible
values for code point are mapped into eight possible values for flow groups (0-
7). These flow groups are later mapped into traffic classes on the ETS/ETH
interfaces.
14.3.5 Forwarding function – Spanning tree

One well known problem with Ethernet switching is that packets can travel in loops, never
to reach a final destination. In some topologies, their number can be multiplied per loop and
eventually all available bandwidth is used by this circulating traffic. The “Spanning Tree
Protocol” is defined to resolve such problems.
Spanning tree is configured first on the basic configuration page for the forwarding
function. Then the details are filled out from the Spanning Tree link on the same web page.
The basic setting ‘Spanning Tree’ of a forwarding function is described in chapter 14.3.2.6
Basic setting – Spanning tree. Depending on the value assigned to the parameter ‘Spanning
Tree’, different web interfaces are shown for the details in the spanning tree configuration.

For spanning tree equal to ‘auto’, a transparent forwarding function will have spanning tree
equal to process and a customer forwarding function will have spanning tree equal to drop.
For spanning tree set to drop or forward (or auto resulting in drop or forward), the status
values of spanning tree cannot be read out. This implementation is made on purpose, as the
values are not relevant. For spanning tree set to process (or auto, resulting in process), the
status values are presented.
In both cases, the spanning tree parameters detailed below can be configured. These
parameters are only relevant when spanning tree is in process mode, but allowing them to
be configured prior to usage is a feature that reduces the number of reconfigurations.
Figure 260. Spanning tree configuration for spanning tree mode process

Figure 261. Configuration page for Spanning tree on a forwarding function in drop mode.
The appearance is identical in forward mode.
The configurable parameters are on this page:
14.3.5.1 Spanning Tree – STP version

Default value: RSTP
Range: RSTP, STP
Description: Defines what version of the spanning tree protocol (from IEEE 802.1D) the
forwarding function is using.
14.3.5.2 Spanning Tree -priority

Default value: 8000
Type: Hexadecimal, four digit number, selectable from a drop down menu
Range: One of 0x0000, 0x1000, 0x2000, 0x3000, … , 0xF000
Description: A hexadecimal four digit number added before the Mac address to define the
identifier. The addition of this number is a way to change the (numerical) order of the
identifiers.

14.3.5.3 Spanning Tree – Max Age (seconds)
Default value: 20
Type: Integer
Range: 6-40
Description: The maximum allowed time for BPDU packet. If this value is exceeded the
packet is immediately aged out.
14.3.5.4 Spanning Tree – Hello time

Default value: 2
Type: Integer, all choices available are presented in a drop down menu
Range: 1, 2
Description: The time between periodic transmissions of BPDU packet from the
ports/interfaces
14.3.5.5 Spanning Tree – Forward delay

Default value: 15
Type: Integer
Range: 4-30
Description: The delay used by the forwarding function to change ports/interfaces to
forwarding of BPDU packets
14.3.5.6 Spanning Tree –Transmit hold count

Default value: 6
Type: Integer
Range: 1-10
Description: This number designates the highest transmission rate of BPDU packets. A
lower number means a lower transmission rate.
14.3.6 Forwarding function – Statistics

From the Statistics link, a summary of basic statistics for all interfaces associated with the
Forwarding Function are shown. There are links to the specific interfaces, for additional
and more detailed interface statistics.

Figure 262. Forwarding function , statistics web page
Heading Description
Rx Accepted Number of accepted packets
Rx Drops Number of dropped packets
Rx Errors Numbers of errored packets
Tx Sent Number of transmitted packets
Tx Drops Number of transmitted packets
forced to be dropped
Figure 263. Interface statistics, headings

14.3.7 Nimbra One/340/340-HD/360 limitations for FF
The products Nimbra One, Nimbra 340, Nimbra 340-HD and Nimbra 360 all have common
hardware restrictions for some of the configuration parameters of the forwarding function.
As an example, configuration of a Nimbra 340-HD, is shown below.
Figure 264. Configuration of a forwarding function in Nimbra 340-HD
In the table below, the basic settings for of these products are shown below.
Property Possible values in Nimbra One/340/340-HD/360
Customer ID No restrictions
Purpose No restrictions
VLAN mode Customer (not settable and not presented)
Mac mode nomac (not settable and not presented)
Mac Aging time In the web, only ‘0’ is allowed. The value is irrelevant and not used.
Spanning tree Forward (not settable and not presented)
Jumbo frames off (not settable and not presented)
Fault propagation Should not be presented
Figure 265. Capabilities for Nimbra One, Nimbra 340/340-HD and 360
As can be seen in the web GUI for Nimbra 340-HD, two links from Nimbra 600 are
missing (Advanced and Spanning Tree). This is also true for Nimbra One/340/360.

14.3.9 ETH and ETS Interfaces
Ethernet switching has two separate interface types that in all important aspects are
configured the same way. They are physical interfaces (Eth) and virtual Ethernet Transport
Service (ETS) interfaces, i.e. end points of Ethernet transport in the DTM network. In the
illustration below, the two types of interfaces are tied together with a forwarding function.
The key parameters of the forwarding function, VLAN mode and Mac mode are
emphasized.
Access Network
Ethernet interfaces side side ETS interfaces
(physical) (logical channel end points)
Priority Priority
Hi Hi
Lo Lo
VLAN mode
Ethernet Hi Hi
Forwarding
frames
Lo
Function Lo
Mac mode
Hi Hi
Lo Lo
8 physical interfaces Up to 247

logical interfaces
Figure 266. Illustration of the two types of interfaces, connected with each other through a
forwarding function. On all outgoing interfaces, there are two queues or traffic
classes (Hi=1 on config page, Lo=0 on config page).
14.3.9.1 Common configurable basic interface parameters, VLAN mode transparent

On both physical Ethernet and ETS interfaces, most common features are configured in the
same way.
First, these common configurations are described. Later, the differences between the two
interface types are detailed.
As the feature ETS 1+1 requires different firmware than what is needed without it, the web
pages may also differ. In the text, both web interfaces are described.

Figure 267. Configuration of Ethernet basic interface settings.

Figure 268. Configuration of ETS basic interface settings. The illustration shows the
appearance with firmware NSX0022-ET11. The appearance with firmware
NSX0022-0001 is identical, but only option (none) for the Interface group is
allowed.

The common interface parameters are:
Parameter Type Default Range

Administrative Binary Down Down (disabled)
status Up (enabled)
(Admin status)
Customer ID Integer 0 0-4294967295 (232 – 1)
Purpose Text string Empty text Text string of 255 or less
string characters
Forwarding Enumerable list/drop- None None (disables switching), All
function down menu defined forwarding functions
Figure 269. Common basic Ethernet/ETS/ETS 1+1 interface parameters for a forwarding
function in transparent mode.
14.3.9.2 Additional common configurable basic interface parameters, VLAN mode

customer
For VLAN mode customer, there are some additional parameters to configure on the
interfaces, namely VLAN tagging and VLAN membership.
Figure 270. Basic configuration settings for an Ethernet interface with a forwarding
function in VLAN mode customer set to accept all VLANs.

Figure 271. Basic configuration settings for an ETS interface with a forwarding function in
VLAN mode customer set to accept all VLANs (1-4094).
Additional configuration parameters to configure for Ethernet and ETS interfaces, when the
forwarding function has value ‘customer’ are presented in the next table.

Parameter Default Possible Explanation
values
Acceptable all all All frames are accepted
frame type vlantagged Only VLAN tagged frames are accepted
untagged Only untagged and priority tagged frames are
accepted
Default 1 1-4094 If no VLAN tag is attached to a packet, the
VLAN default VLAN tag is added where appropriate.
The default VLAN tag is interpreted as an IEEE
802.1Q VLAN tag.
Transmitted vlantagged vlantagged, Describes if tagging is used on flows leaving the
frame type untagged, interface, i.e. for the Ethernet interface in the
legacy direction of external equipment and for ETS
interfaces in the direction of the DTM network.
Legacy means that Ethernet frames are sent
unmodified, but that information about the
VLAN ID is sent in the ETS header.
The ETS header is terminated on the ETS
interface in the terminating node. The VLAN ID
information is used for VLAN assignment in the
terminating node.
This is a way for Nimbra One, Nimbra 340,
Nimbra 340-HD and Nimbra 360 to be
compatible with Nimbra 320/380 and Nimbra 600
series nodes.
Figure 272. Common basic Ethernet/ETS interface parameters for a forwarding function in
VLAN mode customer.
The implementation is made as required by IEEE 802.1Q, section 8.4.3

VLAN membership is defined both on the ETH and ETS interfaces. Only packets with
VLAN tags included in the list are passed through the interface.
14.3.9.3 VLAN configuration for ETH and ETS interfaces

To access the configurable parameters, click on the ‘Add VLAN’ button at the bottom of
the basic ETH/ETS interface configuration page.
Figure 273. VLAN membership configuration on the ETH interface.

Figure 274. VLAN membership configuration on the ETS interface.
The configurable parameters for VLAN settings are very basic:
Parameter Default Possible values Explanation

VLAN set Empty Integer or a List of integers Allowed VLAN(s);
in the range 1-4094 Example: 1,3-18,47,62-68, 4092-4094
Customer ID 0 0 - 4294967295 (232 – 1) Integer identifier
Purpose Empty Text string, 0-255 Text string identifier, to the user’s
string characters disposal
Figure 275. Configurable parameters for VLAN settings
A VLAN id is always interpreted in context of the VLAN mode set for the FF that the
VLAN is associated with. If the FF is in VLAN mode Customer, then the VLAN id is
identical to an IEEE 802.1Q tag.
If ‘VLAN Mode’ of the FF is set to transparent, there is no need to define a VLAN as the
FF then ignores the VLAN tag.
14.3.9.4 Basic ETS specific interface configuration parameters

An ETS interface behaves much in the same way as a physical Ethernet interface: In
addition to the common parameters, the following parameters are needed specifically for
ETS interfaces, in order to define channels to other ETS interfaces at other nodes.

Parameter Default value Possible Explanation
values
Local DSTI (DTM Lowest unused Integers between 0 Must be unique in the
Service Type Instance) integer, starting and 32767 node in order to
with 0. identify an object
during connection setup
Destination node None DTM address or
Hostname
Destination DSTI Lowest unused Integers between 0 Must match the local
integer, starting and 32767 DSTI of the ETS
with 0. unicast or multicast
interface defined in the
destination node.
Required capacity 0.000 Mbps Values between 0 Capacity allocated to
(Mbps) and the trunk the channel, rounded
capacity upwards to an integer
slot number.
Source routes (Up to None All defined source Used if the defined ETS
three) routes in the node channel is source
routed
Interface group None None plus all The ETS interface
defined ETS group is used for ETS
interface groups. 1+1 protection.
Figure 276. Specific basic interface parameters for ETS interfaces.

14.3.9.5 Common configurable advanced interface parameters
The web pages to configure advanced settings for Ethernet and ETS interfaces are shown
below.
Figure 277. Configuration of Ethernet advanced interface settings


Figure 278. Configuration of ETS advanced interface settings.

There are some common advanced settings for all Ethernet/ETS interfaces:

MAC Learning On On Upon reception of a return packet,
the association between source
MAC address and the port/interface
is learnt. Subsequent frames are
only distributed to relevant
interfaces. (on)
MAC Learning disabled (Off)
Off
Default Ethernet 0 Integer, 0-7 Assigned on the ingress interface

priority Selectable from a for untagged packets. Used on the
drop-down menu egress interface if the outgoing
packet is tagged.
Priority mode Ethernet Ethernet Priority according to Ethernet

Diffserv Priority according to Diffserv
Default traffic 0 0 All packets, lacking prioritizing

class information, have lowest priority
1 All packets, lacking prioritizing
information, have highest priority
Flow Group to 0 0 All packets in the flow group have

Traffic Class lowest priority (traffic class 0)
mapping, flow
groups 0 to 7 1 All packets in the flow group have
highest priority (traffic class 1)
Queueing Auto on all Max frames: auto, With these parameters the length of
parameters four disabled, manual the queue on the interface can be
parameters set. If manual is set, an integer must
Max bytes; auto, also be given in the input box for
manual integers.
Both max frames and max bytes
can be set.
Unless familiar to these settings, it
is recommended to keep the default
settings.
Figure 279. Common advanced Ethernet/ETS interface parameters.
It is strongly recommended that the Queueing parameters are left with their respective
default values. Setting these parameters manually requires skill and experience. Setting max
frames to disable means effectively that all packets are dropped as the queue is turned off.
Setting them to manual and a number controls the maximum number of frames in the queue
and the total number of bytes in those frames. Contact Net Insight for more information.

14.3.9.6 Specific Advanced Ethernet (ETH) interface parameters
There are some specific Ethernet interface parameters to be configured, in addition to the
auto-negotiation protocol described later.

‘Force None Integer, or a VLANs included in this field are
VLANs combination and tagged, despite the general setting of
tagged’ range of integers. Transmitted frame type ‘Untagged’
Example: 1,2,5-8,16 tags VLAN 1,2,5
to 8 and 16 on egress traffic.
This field is only available if
Transmitted frame type of the interface
is ‘Untagged’
‘Force None Integer, or a VLANs included in this field are not
VLANs combination and tagged, despite the general setting of
untagged’ range of integers. Transmitted frame type ‘Tagged’
Example: 1,2,5-8,16 untags VLAN
1,2,5 to 8 and 16 on egress traffic.
This field is only available if
Transmitted frame type of the interface
is ‘Tagged’
Figure 280. Ethernet specific Interface parameters.
Autonegotiation of interface rate, protocols etc is made with the Autoneg feature on the
Ethernet interface set to ‘On’. This is also an Ethernet interface specific advanced feature.
Figure 281. Autonegotiation of an Ethernet interface

The settings of the auto-negotiation features are:
Parameter Default Possible Explanation

values
Auto On On The autonegotiate feature is enabled
negotiate Off The autonegotiate feature is disabled
Advertised Auto Auto All HW supported speeds (by module and SFP) are
speed advertised. Recommended
1000 Only 1 Gbps is advertised
100 Only 100 Mbps is advertised
10 Only 10 Mbps is advertised
100,10 100 and 10 Mbps are advertised
1000,100 1000 and 100 Mbps are advertised
1000,10 1000 and 10 are advertized
1000,100,10 1000, 100 and 10 Mbps are advertised
Advertised Auto Auto All supported duplex forms are advertised.
duplex Recommended
Full Only full duplex is advertised
Half Only half duplex is advertised
Advertised Auto Auto All supported flow-control forms are advertised.

flow-control PAUSE flow-control is advertised
PAUSE ASM_DIR flow-control is advertised
ASM_DIR PAUSE and ASM_DIR are advertised. For a
PAUSE, description, see IEEE802.3-2005 Section Two.
ASM_DIR
Figure 282. Auto negotiation parameters for Ethernet interfaces. The available parameter
values are always presented in the web interface, but could vary depending on
interface type.

14.3.9.8 Advanced ETS specific interface configuration parameters
Under the ‘Connection re-establishment’ header, the parameters of the exponential back-off
algorithm and the reconnect time out can be set. Also, the connection can be defined as
having “Precedence”, which means that in case an intermediary node goes down, this
particular connection is taken down with priority. This also means that a replacement
connection is typically set up with priority (i.e. it has precedence over other connections).
Minimum interval: The starting value of the back-off algorithm. When a connection is
torn down, a first connection re-establishment attempt is made immediately; if the attempt
fails, another attempt is made after the minimum interval of the back-off algorithm. The
default setting is 10 ms.
Maximum interval: The end value of the algorithm, 50000 ms. The re-establish
mechanism will wait no longer than 50000 ms to re-establish a channel. If not successful,
another attempt is made after 50000 ms.
14.3.10 Fault management for ETH and ETS interfaces

The goal with the fault management and performance management system is to monitor the
behavior of a service. If a fault occurs somewhere that affects the delivered service, an
alarm shall be raised in exactly one node and performance management shall register the
error in exactly one object. This means that all faults must be detected and handled in one
well-defined object and all other objects that transport the service must be notified that a
fault has been detected and handled in another object.
The fault propagation mechanism makes sure that if a fault is detected that affects a service
somewhere along the path that the service takes, then that fault is propagated upstream and
downstream from the point where the fault was detected. This makes it possible for failover
mechanisms to react.
In SDH networks, the fault propagation is done with the AIS (Alarm Indication Signal) and
RDI (Remote Defect Indication) signals. The same terminology has been used in our
implementation of fault propagation.
However, the physical Ethernet interfaces cannot be regarded as separate source and sink
interfaces as Ethernet services are often bi-directional. There is also a relationship between
the signals in both directions. There have been recent additions to the Ethernet standards of
AIS and RDI signals, but since these are not yet widely supported, we have chosen to not
support them now. As long as AIS and RDI is not supported, the only way to signal across
an Ethernet port that there is an error further down the path is to force the Ethernet link
down and that is how we have chosen to distribute the message. The response affects the
signal in both directions, which makes the fault state of the two directions dependent on
each other.

14.3.11 Configuration of Fault management for ETH and ETS
interfaces
Figure 283. Configuration of ETH and ETS interfaces, illustrated with multicast ETS
interface. Parameter ‘Expect channel’ is only present on the ETS interface and
this is the only parameter differing between ETS and ETH interfaces.
There are some parameters to configure on the interfaces:
14.3.11.1 Degraded detection

Default value: ‘off” on source interfaces, ‘on’ on sink interfaces
Type: Boolean, ‘on’ or ‘off’
Range: ‘on’ or ‘off’’
Defined on object: eth-source, eth-sink, ets-source, ets-sink
Description: For the fault Degraded to be detected on the interface, this parameter must
be set to ‘on’. If the fault is detected on a sink interface, the parameter Fault Propagation on
the FF must be set to ‘on’ for the fault to pass the FF and exit the node on the source
interface, towards the destination node as an AIS signal.

14.3.11.2 Degraded threshold – in packets/s
Default value: 0 on source interfaces, 100 on sink interfaces
Type: integer
Range: 1- 4294967295 (232-1)
Description: For source interfaces: As ‘Enabled Degraded detection’ is by default ‘off’,
this parameter is by default 0. When ‘Enabled Degraded detection’ is set to ‘on’, the value
of this parameter cannot be 0; hence the default setting must be changed to an integer value
must be assigned to the degraded threshold in the range specified above.
For sink interfaces, this parameter is by default 100.
14.3.11.3 Degraded period – in seconds

Default value: 7
Type: integer
Range: 2-10, selectable from a drop down menu
Description: The degraded period is the number of consecutive seconds, with an error
level exceeding the degraded threshold value, required to generate the degraded signal
fault.
14.3.11.4 Minor Reduced Bit Rate threshold – in Mbps

Default value: 0
Type: real value
Range: 0.000001- 99999.998 Mbps
Description: The effectively used bit rate is measured once per second. If the used bit rate
falls below a used defined threshold (i.e. this parameter), a minor reduced bit rate threshold
alarm with severity minor is raised.
14.3.11.5 Major Reduced Bit Rate threshold – in Mbps

Default value: 0
Type: real value
Range: 0.000001- 99999.998 Mbps
Description: The effectively used bit rate is measured once per second. If the used bit rate
falls below a used defined threshold (i.e. this parameter), a major reduced bit rate threshold
alarm with severity major is raised.
If both reduced bit rate thresholds have been configured to 0, the detection of reduced bit
error rate is disabled.

14.3.11.6 Generate AIS on Reduced Bit Rate
Default value: ‘no’
Type: Boolean, ‘yes’ or ‘no’
Range: ‘yes’ or ‘no’
Description: Setting this parameter to ‘yes’ generates an AIS on all ports on the
forwarding function except the port which generated the Reduced bit rate fault. It is
necessary to configure the forwarding function with Fault propagation set to ‘on’ as
otherwise no AIS is passed through the forwarding function despite this setting.
14.3.11.7 Expect channel

Type: Boolean, ‘no’ or ‘yes’
Range: ‘no’ or ‘yes’
Defined on object: ets-sink for multicast
Description: This parameter determines if the lack of a channel should be regarded as an
anomaly or not. If it is set to ‘yes’, an alarm should be generated if no channel terminates
on the ETS interface. This alarm is, however, not implemented in GX4.8.
14.3.11.8 Generate AIS on Degraded

Type: Boolean, ‘yes’ or ‘no’
Range: ‘yes’ or ‘no’
Defined on object: eth-sink, ets-sink
Description: Setting this parameter to ‘yes’ generates an AIS on all ports on the other
side of the forwarding function that are configured to receive the signal. It is necessary to
configure the forwarding function with Fault propagation set to ‘on’ as otherwise no AIS is
passed through the forwarding function.
14.3.12 Destinations configuration for ETS multicast channels

ETS multicast channels are, when admin status is set to up, operational even without
destinations. The destinations are added one by one from the Destinations tab on the ETS
configuration page. For unicast channels, the (single) destination is configured on the basic
configuration page of the interface.

Figure 284. Addition of multicast destinations is made from the Destinations tab on the
Ethernet → ETS Interfaces → <Specific interface> web page.
Addition of new interfaces is made from the ‘Add destination’ button. Here the admin
status of the destination is set together with destination node, destination DSTI and source
routes to the destination. Add source routes as needed. New source routes are defined under
All connections → Source routes.
To add a destination, click on the ‘Add Destinations’ button and define:
Parameter Possible values

Administrative status Up or Down
Destination DTM node DTM address or hostname of the destination node
Destination DSTI DSTI of the connection at the destination node
Figure 285. Configuration parameters for Ethernet/ETS destinations for multicast
connections.
Figure 286. Add destination configuration web page.

14.3.13 Spanning tree configuration for ETH and ETS
interfaces
The spanning tree parameter can have four different values, ‘auto’, ‘forward’, ‘process’ and
‘drop’ configured as a basic setting on the forwarding function. The spanning tree
functionality is by default set to ‘auto’. This means process for VLAN mode transparent
and drop for VLAN mode customer. The exception to this rule is for the fixed ports of
Nimbra One/340/340-HD/360 and Fast Ethernet/Gigabit Ethernet Access Modules where
‘auto’ means ‘forward. What is actually running is shown on the detailed spanning tree
page of the interfaces.
Spanning tree is enabled by force on the configuration page of the forwarding function by
setting the value of the parameter ‘Spanning Tree’ to ‘process’. Spanning tree for the
forwarding function is configured from a tab on the forwarding function basic configuration
page. In the illustration below, the FF spanning tree configuration page is shown.
Some spanning tree settings are made on the interface configuration page. This part of the
configuration page is identical for ETH and ETS interfaces.
Figure 287. Detailed spanning tree configuration on the ETH/ETS interface
Spanning tree is specified in IEEE 802.1D from 2004. Net Insight adheres to the
specification. The configurable spanning tree parameters on the interfaces are ‘Port path
cost’, ‘priority’, ‘edge port’ and ‘point-to-point’. The parameters are explained in the table
below:

Parameter Default Range Type Comment
Port path Auto Auto, Manual (0- Auto or Integer Manual enables an input
cost 200000000) (manual) field.
Priority 80 Drop-down; Two hexadecimal Drop-down menu
0x00,10,..,F0 digits
Edge port Auto Auto, True, False Boolean variable Drop-down menu
Point-to- Auto Auto, True, False Boolean variable Drop-down menu
point
Figure 288. Configurable spanning tree parameters for an ETS/ETH interface.
Port path cost defines a cost associated with the particular port/ interface. If two or more
interfaces are available for a connection to a particular node, the spanning tree algorithm
ensures that only the low-cost interface is used.
Priority defines the priority of the particular interface. Two hexadecimal digits plus two
hexadecimal 0s are added as a prefix on the MAC address of the interface to create the
identifier. The lowest identifier interface is used, in case there are two interfaces with equal
cost.
Edge port is a Boolean variable used to signal if the interface is connected to equipment not
part of the DTM Ethernet universe (true). Auto means that auto detection is used.
Point-to-point is a Boolean variable used to signal if the interface is connected to a link and
a node with a point-to-point connection. Auto means that auto detection is used.
14.3.14 Statistics overview tab on the ETS configuration page

On the ETS configuration page, there is one tab under which statistical values for the ETS
interface could be found.
This in only present if there is a destination defined.
Figure 289. Statistics for a specific ETS interface

If statistics for all ETS interfaces are wanted, it is best found from Ethernet → ETS
Interfaces and the Statistics tab.
Figure 290. ETS statistics for all ETS interfaces in a particular node.

15 Isochronous Transport
Service (ITS)
15.1 Overview
The ITS menu handles configuration of all Isochronous Transport Services (ITS). These
services are used to create 3G/HD/SD-SDI, JPEG2000, ASI, AES/EBU, MADI, PDH and
Sonet/SDH tunnels through the DTM network.
The services can be of two different types, unicast or multicast. Unicast ITS services
transport a stream through the network from one originating to one terminating interface.
Multicast ITS services transport a stream from an ingress interface to multiple egress
interfaces.
PDH
Video
Video access
DTM channel interface
Remote
DTM
i/f
DTM
Video access
interface Local
DTM
i/f
PDH
Video
Figure 291. Video traffic through a unicast DTM channel.
Interface Originating
Connection Terminating Interface
asi-2:1
Connection asi-1:2
itso-1
itsi-2
TTP Source
TTP Sinc
Figure 292. ASI,TTP connection, unicast
Element Manager User's Manual Isochronous Transport Service (ITS) • 280

HD-SDI HD-SDI
Terminating Terminating
DTM node DTM node
DTM
Originating
DTM
node
HD-SDI
Figure 293. HD-SDI video transported with a DTM multicast channel to two destinations
This chapter describes how to configure ITS services, both uni- and multicast. The main
web page for ITS is shown below.
Figure 294. ITS main page

The sub-sections of the Isochronous Transport Services (ITS) are:
Source TTPs: Configuration and editing of ITS source TTPs (Trail Termination Points), i.e
the logical starting points of the connections.
Sink TTPs: Configuration and editing of ITS sink TTPs (Trail Termination Points), i.e the
logical end-points of the connections.
Interface: Configuration and editing of the interfaces.
Perf. monitor: Shortcut to the Performance monitoring menu, which is seen in chapter
Performance monitoring.
To configure ITS services, start with creating TTPs with destinations (i.e. ITS sources).
Continue with matching TTPs at the various ITS destinations (one or multiple). After
finishing the configuration, all ITS channels should be set up if the required bandwidth is
available.
15.2 Protection
15.2.1 Nomenclature
15.2.1.1 Closed ended protection
Closed ended protection is a protection case where one video stream enters the Nimbra
network. It is split at the entry point and routed two separate ways through the Nimbra
network to the destination node. At the destination node both streams come together and an
egress stream is designed by either one of the streams or a combination of the two streams.
15.2.1.2 Open ended protection

Open ended protection is a protection case where two video streams enter the Nimbra
network separately. The streams can either be identical, only split outside the Nimbra
network, or different. Nevertheless, in the last case one stream is acting as protection for the
other stream.
15.2.1.3 Standby protection

Standby protection is a protection case which can be used for both closed and open ended
protection. The protection type uses only one of the two available video streams for the
output stream on the outgoing access interface. Monitoring of the state of the stream that is
not used, makes sure that switchover is only made to a working stream.
15.2.1.4 Hitless protection

Hitless protection is a special protection case that only can be configured in the closed
ended protection case. Hitless protection uses both streams incoming to the sink interface,
where packets from both streams are used to synthesize a common video stream.

15.2.2 ITS protection cases
15.2.2.1 Type 1 protection
Figure 295. Source stream sent through DTM network along two independent routes for
type 1 protection. This protection type only supports unicast connections and
standby protection on sink Interface B.
15.2.2.2 Type 2 protection- open ended
Figure 296. Open ended type 2 protection of ITS streams. This protection type supports
standby protection with uni- or multicast streams.

15.2.2.3 Type 2 protection - closed ended
Source TTP A1 Route One Sink TTP B1
DTM
Interface A Route Two Interface B
Source TTP A2
Figure 297. Stream sent through the DTM network along two independent routes for type
2 protection (closed-ended). This protection type supports standby protection
with uni- or multicast streams. This configuration is the single source (closed
ended) version (previous case).
15.2.2.4 Type 3 protection - open ended
Figure 298. Type 3 protection, open ended case, of ASI and JPEG2000 streams. This
protection type supports standby protection with uni- or multicast streams.

15.2.2.5 Type 3 protection – closed ended
DTM
Interface A Interface B
Source TTP A2 Route Two Sink TTP B2
Figure 299. Source stream sent through DTM network along two different routes for type
3 hitless or standby protection. This configuration is the closed ended version
of type 3 protection (previous case). Hitless or standby protection is
configured on the sink interface.
15.3 Interface settings for Access Modules

The configurable settings for the access cards are found either under ITS or Ethernet
headings in the web browser interface. The interface settings of ITS services are found
under ITS → Interfaces web page, described below.
15.3.1 Configurable interface parameters

15.3.1.1 Enable signal speed autosensing
Default value: Ticked
Type: Binary
Range: Ticked, Unticked
Description: If ticked, the rate of the input signal is automatically detected. If configured
for another rate, the signal is still passed through the channel if the signal fits the allocated
bandwidth, otherwise an alarm is raised. Example: if a channel is defined between two
nodes as HD-SDI (1.485 Gbps), SD-SDI signals are nevertheless passed on (270 Mbps) but
3G-SDI signals (2.970 Gbps) are not passed on. If unchecked, the signal is not passed on
and an alarm is raised.
Autosense cannot be changed when the TTP has admin status ‘up’.
15.3.1.2 Output action on signal fail

Default value: ‘None’
Type: Binary
Range: ‘None’, ‘Mute’
Description: If set to ‘Mute’, the failed signal muted (i.e. shut down) on the output access
interface. Muting may speed up fail-over switching time when using external fail-over
switches. If set to ‘None’, different actions are taken depending on service type.

15.3.1.3 Ignore TS-packet synchronization errors

Default value: Unchecked
Type: Binary
Range: Checked, Unchecked
Description: If checked, synchronization errors in the Transport Stream packets are
ignored. This option will allow the Nimbra equipment to accept ASI streams which do not
comply with accepted international standards. The robustness of the transport stream cannot
be guaranteed in this mode and it should be seen as a customer specific workaround for
deficiencies in equipment from other vendors. The setting should be made on the receive
side of the connection.
15.3.1.4 Output mode

Default value: Auto
Type: One of Auto, Spread, Burst
Range: Auto, Spread, Burst
Description: Determines how MPEG TS packet bytes are transmitted from the ASI TX
port.
In Burst mode, all bytes of a TS packet are sent back-to-back in one burst. IDLE bytes are
sent between bursts to adapt the bit stream.
In Spread (spread-byte) mode, TS packet bytes are spread out as evenly as possible, with
IDLE stuffing between TS packets as well as between bytes within a TS packet.
In Auto mode, Burst or Spread mode is automatically selected to be the same as detected on
the corresponding ASI RX port. In general, Spread mode is the preferred mode.
Output mode is only available for ASI signals.

15.3.1.5 Suppress alarms
Default value: None
Type: Drop-down menu
Range: None, Warning, All
Description: None does not suppress any alarms; Warning suppresses only alarms with
severity warning and All suppress all alarms.
15.3.1.6 Loopback
Default value: None
Type: one of None, Line or DTM
Range: None, Line, DTM
Description: None sets No loopback; Line sets Line side traffic is in loopback mode, i.e.
traffic arriving at the Rx interface is sent back on the associated Tx interface; DTM sets
DTM side traffic in loopback mode, i.e. traffic exiting on a Tx interface is looped as closed
to the interface and returned on the corresponding Rx interface. Some modules may not
have all capabilities.
15.3.1.7 Interface mode

Default value: SDH
Type: One of SDH, Sonet
Range: SDH, Sonet
Description: This parameter determines if the interface works in SDH or Sonet mode.
15.3.1.8 JPEG 2000 encoding

Default value: disabled
Type: binary; enabled, disabled
Range: enabled or disabled
Description: This parameter determines if the interface works in SDH or Sonet mode.
15.3.1.9 Signal format

Default value: none
Type: drop-down menu; the various alternatives are read out from hardware
Range: SDI, HD-SDI, HD-SDI (U.S.), 3G-SDI, 3G-SDI (U.S.)
Description: Identified signal format on the interface, either through speed autosensing or
through hard setting on the interface by the operator. Only available if speed autosensing is
disabled and JPEG encoding is enabled.

15.3.1.10 Transmit sync source
Default value: Loop
Type: one of Loop, Internal
Range: Loop, Internal
Description: This parameter determines which clock is used for the outgoing signal from
the interface. When Transmit sync source is set to Loop, the clock from the incoming signal
on the interface is extracted and used as clock for the outgoing signal. When Transmit sync
source is set to Internal, the node internal clock is used as clock for the outgoing signal.
15.3.1.11 SDH Sync message

Default value: 15
Type: Integer, 0-15
Range: 0-15
Description: Sets the outgoing Synchronization Status Message (SSM) in byte S1. The
default value is 15. (Do not use for synchronization!)
If Transmit sync source is set to Internal, the value 11 should be set (G.813 Option I)
15.3.1.12 H1 SS bits
Default value: 10
Type: Two bits in any combination
Range: One of 00, 01, 10, 11
Description: Sets the two SS bits (bit 5 and 6) in the H1 byte. These bits typically should
not need to be changed from the default setting. If the external equipment attached to the
interface is older, there might be a need to change them but this should be elaborated in the
documentation for the external equipment.
15.3.1.13 Interface to monitor

Default value: None
Type: interface
Range: None, sdi-1:1-1:8, asi-1:1-1:8 etc depending on module and slot position.
Description: This parameter describes which interface is monitored, i.e. which incoming
or outgoing video stream that is duplicated and sent to the configured interface.
15.3.1.14 Enable front panel selection button

Default value: No
Type: Binary
Range: Yes or No
Description: This parameter describes if the front panel selection button is activated or
not. The front panel button is only available on some interface like the 8 x ASI module for
Nimbra 300 nodes.

15.3.1.15 Interface direction to monitor
Default value: In
Type: Binary
Range: In, Out
Description: This parameter describes which direction is monitored for the selected
interface.
15.3.1.16 PDH signal to transport

Default value: DS3
Type: DS3 or E3
Range: DS3 or E3
Description: PDH type to transport, configurable per interface.
In the cross-reference table below, it is shown on which modules/fixed interfaces the

different configurable parameters are found.

Configurable
Fixed HD-SDI i/f (Nimbra 340-HD)

8 x ASI Transport Access Module
parameter
Fixed ASI interface (Nimbra 340)

4 x OC-3/STM-1 Access Module
ASI Transport Access Module

8 x SDI Video Access Module
8 x AES/EBU Access Module

4 x DS3/E3 Access Module
SDI Video Access Module

E1/T1 Access Module
Enable signal speed
autosensing
Output action on signal fail x x x x x x x x x
Output mode x
Ignore TS-packet
synchronization errors
Suppress alarms x x x x x x x x x x
Loopback x x x x x x x
Interface mode x
Transmit sync source x
Synchronization Status x
Message (SSM)
H1 SS bits x
Interface to monitor M M M
Interface direction to
monitor
Enable front-panel selection M M M
button
PDH signal to transport x
Figure 301. Cross-table Configuration parameters vs. Access Module for Nimbra 300. M
designates monitor interface.

8 x ASI/AES Access Module, AES/MADI
8 x or 8 x 3Gbps Video Access Module,
HD/SD or 3G –SDI configured interface
HD/SD or 3G –SDI configured interface

8 x ASI/AES Access Module, 8 x or 8 x
Configurable
JPEG2k Video Access Module v2,

3Gbps Video Access Module, ASI
parameter
configured interfaces
configured interface
JPEG encoding
JPEG decoding
Enable signal speed x x x
autosensing x
Output action on signal fail x x x x x x
Output mode x
Ignore TS-packet
synchronization errors x
Suppress alarms x x x x x x
Loopback x x x x x x
JPEG 2000 encoding x
Signal format x
Interface mode
Transmit sync source
Synchronization Status
Message (SSM)
H1 SS bits
Interface to monitor M M M
Interface direction to
monitor M M M
Enable front-panel selection
button
PDH signal to transport
Figure 302. Cross-table Configuration parameters vs. Access Module for Nimbra 600. M
designates monitor interface.

15.4 Setting up a unicast ITS tunnel
Tip: Configure the terminating connections before the originating
connections when doing so the establishment time is 5 ms compared to
connections;
50 ms. This tip oonly works for unicast connections.
15.4.1 Terminating Connection

Follow the ITS → Sink TTPs link; a page appears like the page below.
Figure 303. ITS setup sink TTPs main terminating page
Click on Add TTP to configure the Termination; see figure below.
Figure 304. ITS, TTPs, Add page
On this ITS → Sink TTPs → Add TTP web page, type can be set to terminating (sink) or
originating (source). If type is set to terminating, Mode can’t be set. As soon as terminating
type is selected, the parameters for mode become irrelevant and are grayed out..

The local interface drop down menu lists all possible available options for the local
interface. The selected interface is tied to the connection and TTP.
When the add button is selected, the sink TTP is configured/defined in a web page.
Figure 305. Configuration of terminating TTP of an ITS unicast channel.
15.4.1.1 Reference information

Administrative status is either Down (when the TTP is disabled) or Up (when attempts to
establish a channel to this TTP is made). Customer ID (integer) and Purpose are freely
configurable fields. In the local interface drop down menu, all available interfaces are
listed. DSTI is the DTM Service Type Instance, a unique number per service type, direction
and node. A default DSTI is selected by the system but it can be user modified. The DSTIs
don’t have to be consecutive.
Suppress alarms can have valued none, warning or all. Active channel when protected can
be set to first or second. This is the defined channel. It is grayed out if it cannot be set.
Note that there are two terminating connections connected to one single TTP. This is
because of the open ended 1+1 protection feature, described in chapter Source Routing.
When finished; Click ‘OK’ or ‘Apply’.

15.4.2 Originating Unicast Connection
Note: Even if there are 2 in + 2 out connectors on the 340-HD

340 for HD-SDI,
SDI,
there is only one HD
HD-SDI in and one out stream that can be
configured. One of the two in or out connectors can be used at a time!
The preferred in and out HD-SDI
HD SDI streams should be configured via the
web. Both out ports can be used for a multicast HD
HD-SDI stream.
Follow the ITS → TTPs link; a page appears like the page below.
Click on Add TTP … to enter the setup page. A page similar to the page below will appear.
Figure 306. Definition of the ITS Source TTP.
In the web page, the same settings as for the terminating TTP can be
b made.
Make the settings required (Originating/Unicast), uuse the drop-down
down menu to set the local
interface and click on the Add button.
Element Manager User's Manual Isochronous Transport

ransport Service (ITS) • 294

Figure 307. ITS, TTPs, create connection page
In addition to the settings made for the termination, in the originating node the destination
DTM node with associated destination DSTI are needed. The required capacity must be
specified, either as a bandwidth (0.8-212 Mbps) for ASI or SDI (270 Mbps), SDI
compatible (from Nimbra 600 to Nimbra One/300), HD-SDI (1.485 or 1.485/1.001 Gbps),
3G-SDI (2.970 or 2.970/1.001 Gbps) or SDI compressed with the requested (compressed)
bandwidth.
We must also specify if we use protection and the source route(s) we use (if any). If a
source route is used, this is indicated on the web page with the text ‘currently used’ within
parenthesis to the right of the source route itself.
See chapter Source Routing for additional information on how to setup a source route.
Once both terminating and originating nodes are configured, the channel is established if
enough transport bandwidth is available.

Note: The lower part Destination DSTI is the sink (destination) TTP
DSTI number. To establish the connection, this number must
match what is used for the sink TTP.
15.5 Setting up a multicast ITS tunnel

A multicast ITS tunnel is a channel from one IN interface to multiple OUT interfaces. The
channel is unidirectional, i.e. traffic only flows from the source to the destination. No traffic
is transmitted in the back direction.
In our example, an HD
HD-SDI channel is set up between iov129 and iov132.. The channel is
terminated on several interfaces in node20.
Ingress
DSTI 2 iov129
v129 iov132
sdi2:5 itso-2 sdi4:3 Egress
itsi-3 DSTI 3
sdi2:6 Egress
itso-3 itsi-4 sdi4:4 DSTI 4
Figure 308. Setup of Multic

Multicast Channel.
15.5.1 Considerations for multicast channels

There are two things that must be considered when a combination of source
source-routes
routes and
multicast channels are used.
First, if source routes are used for multiple destinations, the source routes must be subsets
of each other and the exact same definition has to be used in both cases. For instance, if one
source route specifies the interfaces, the interfaces must also be specified in all other source
routes used to set up the channel
channel.
Figure 309. Example of source routes

r used for multiple destinations.
In the figure above, let sr C from node1 to node2 via node4 and node3 be defined by

Figure 310. Definition of sr C in node1.
The source routes to node3 (sr B) and node4 (sr A) must then be defined as
Figure 311. Definition of sr B in node1, a subset of sr C.
Figure 312. Definition of sr A in node1, a subset of sr B and sr C.

Another consideration is that multiple destinations in a multicast channel cannot use source
routes in such a way that the channel defined enters an intermediate node on two different
interfaces. This is interpreted by the network as a disallowed loop.
This is displayed in the picture below. This setting of multiple source routes is thus NOT
ALLOWED!
Figure 313. Illustration of a disallowed combination of source routes for a multicast

channel. sr C and sr D both enter node3 on two different interfaces (3:1 and
3:2), which is interpreted as a rooting loop and is disallowed.
Problems of this type are avoided if DRP is used for routing of multicast channels. DRP
routing of multicast channels have other, possibly undesirable, features though. With the
DRP protocol, routing is made destination per destination and conservation of bandwidth is
not considered. In other words, bandwidth allocation may not be optimal.
15.5.2 Originating Multicast Connection

Follow the Source ITS → TTPs link and the Add TTP button; a page appears like the page
below.
Figure 314. ITS basic setup for source TTP and multicast service.

Chose the type of interface (originating) and type of mode (unicast/multicast), use the pull-
down menu to select the local interface and click on the Add button.
A webpage similar to page below will appear.
Figure 315. ITS source TTPs basic configuration web page
In addition to common parameters with the unicast case, there is an extra link to
Destinations, where the details about the various destinations are entered.
Click on the Destinations in the middle of the page, to set the multicast destinations for the
originating connection. This page shows the nodes that are configured in this connection.
Figure 316. ITS Source configure TTP destinations web page.
In order to define the destinations, click on the button Add destination and enter the
parameters for the sink TTPs. In the following figures, the two destinations of our example
are shown.

Click on Add destination to add a new node.
Figure 317. Destinations to a source ITS TTPs are defined.
Set Administrative status to ‘Up’, Destination DTM to iov132 and destination DSTI to 3
and 4 for the two different cases. The destinations have now been added. In this case, we
have not used source routes.
When all the nodes are added click on the Cancel button, a list of the destinations is shown
in the Destination page. As the terminating side is not yet defined, the destinations are listed
as down.

Figure 318. Destinations defined in the originating TTP.
15.5.3 Terminating Multicast Connection

Follow the ITS → Sink TTPs link and the button ‘Add TTP’; a page appears like the page
below.
Figure 319. ITS TTPs create Multicast page
Select the type to Terminating and use the pull-down menu to set the local interface.
Click on the Add button. Repeat for all destinations.
15.6 Editing/deleting Connections

Follow the ITS → Source TTP or ITS → Sink TTPs link and the click on the connection to
be edited or deleted. Make the change and click on OK or Apply if it is an edit; set admin
status to down first, the delete the TTP with the delete button if the TTP is to be removed.

15.7 Advanced settings
Note: Before changing the max and min settings in a production network
please consult Net Insight support services fir
first.
Follow the ITS → Source TTPs link,, open an originating TTP by following the TTP name
link, open the Advanced link; a page appears like the page below.
Figure 320. Edit ITS Source TTP Advanced Configuration
This menu controls the parameters of the exponential back-off algorithm (Connection re
re-
establishment),, including the re
re-connect time out.
alarm: This tick box is selected by default. In case it is
Suppress primary source route alarm:
not selected, an alarm with severity warning is raised when the primary source rou
route is not
used.
Minimum interval:: 10 ms. The starting value of the back-off algorithm. After a tear down
of the connection, the system tries to re
re-establish the connection immediately. If
unsuccessful, after a wait of 10 ms a second attempt is made. A thirdd attempt is made after
a longer time according to the algorithm.
Maximum interval:: 50000 ms. The end value of the algorithm. The rere-establish
establish
mechanism will wait not longer than 50000 ms to re
re-establish a channel.
Precedence: This drop-down
drop menu determines if the connection has precedence or not,
not i.e.
if it is torn down fast (and is re
re-established fast).. Maximum five are recommended per
node.
If required, back up the configuration changes; see chapter Maintenance,, section
Configuration handling for details.

15.7.1 Embedded ASI in HD-SDI channels
A feature of release GX4.4 and later is that ASI channels can be embedded in HD-SDI
channels. These channels use all the reserved bandwidth of an HD-SDI channel (1.485
Gbps) in the network at all times, but the feature enables mixing of video formats.
To set up an embedded ASI channel in an HD-SDI channel, start with the HD-SDI channel
and reserve 1.485 Gbps capacity. Below is an illustration of the ITS → Source TTPs basic
configuration web page.
Figure 321. Configuration of the HD-SDI channel that is used for transportation of an ASI-
signal. Requested capacity is 1.485 Gbps.
After configuration of the HD-SDI channel, the ASI stream is simply attached to the proper
port. A look on the ITS -> interface web page of the source interface then shows the
bandwidth used by the ASI stream.

Figure 322. ITS → Interfaces web page of the inserted ASI stream.
15.8 Configuration of ASI video stream – an ITS

configuration example
Configuration starts on the terminating (destination) TTP. This is true whether the service is
uni- or multicast. Having defined the terminating TTPs, the originating TTP is defined.
After all TTPs are defined and the channel is established, some additional configuration can
be made on the interfaces.
In this text, an example of an ASI stream configuration is given. From this example,
configuration of all ASI streams and all ITS services in general can be understood.
An ASI stream from interface asi-2:1 in iov129 to interface asi-4:5 in iov132 is used as
example. It is also shown, how to set up an ASI multicast stream from interface asi-2:1 in
iov129 to multiple interfaces in iov132.
15.8.1 Configuration of the Terminating TTP

All configuration of Isochronous transport services (ITS) is made from the ITS page. To
configure the terminating TTP, go to the sink TTPs web page and click on the ‘Add TTP’
button. Select the interface on which the outgoing stream is wanted.
Note that, once Terminating Type is selected, mode selection is grayed out. This is because,
for the terminating TTP, configuration is identical for uni- and multicast service.

Figure 323. ASI Configuration example
Figure 324. The Add TTP configuration page for ITS. In this example, a terminating TTP
on local interface asi-4:5 in iov132 is set up.
Clicking on ‘Add’ takes the user to the configuration page of the sink TTP.

Figure 325. Configuration parameters for the terminating TTP.

Parameter Type Possible values Default Comment
Administrative Drop-down Up/Down Down
status
Toggle admin Check box Ticked/Not ticked Not ticked Toggle admin sets admin status
to down, does the requested
action and sets admin status to
up.
Customer ID Integer 0 - 4294967295 0 Identifier
(232-1)
Purpose String Character string Empty Identifier
string
Local interface Drop-down Any interface in Selected
the list interface
DSTI Integer 0-32767 (215-1) Lowest Unique per service type,
available direction and node
Suppress Drop-down None/Warning/All None Should alarms associated with
alarms the TTP be suppressed
Connection Drop-down On/Off Off Should two streams be allowed
protection to terminate on the TTP?
Active channel Drop-down First/Second First What channel should be used
when protected when two channels ends at the
TTP.
Figure 326. Configuration parameters for terminating TTP
15.8.2 Configuration of originating TTP for a unicast

connection
The originating TTP is where you configure if the channel is uni- or multicast. If you define
the channel as multicast, the different destinations are entered under a separate link
(Destinations) on the configuration web page of the source TTP. This link can be viewed as
a subpage of the configuration page, only needed for multicast streams. Multicast streams
are described separately.
To configure a unicast connection, click on ITS → Source TTPs and the Add TTP button
on the page. Select originating type, unicast mode and local interface asi-2:1, according to
Figure 327. When the add button is clicked, the configuration page of the originating TTP
is presented (Figure 328).

Figure 327. The Add TTP configuration page for ITS. In this example, an originating TTP
on local interface asi-2:1 is set up.

Configuring the originating TTP is made from the following web page.
Figure 328. Configuration parameters for ASI service on an originating TTP

The configuration parameters are defined in the table below.

value
Administrative Drop Up/Down Down
status down
Customer ID Integer 0 - 4294967295 (232-1) 0 Identifier
string
Local interface Drop- Any interface in the Selected
down list interface
DSTI Integer 0-32767 (215-1) Lowest Unique per service
available type, direction and
node
Destination String Defined hostname or None
DTM node DTM address
Destination Integer 0-32767 (215-1) 0 Number unique
DSTI per service type,
direction and node
Requested Real 0.8-212 Mbps 2 Mbps Capacity dedicated
capacity (Mbps) number to the stream
Connection Drop- On/Off Off Should two
protection down streams originate
from the TTP?
First/Second Drop- All defined source- (none) Three source
Channel Source down routes in a node. Three routes possible to
Route routes are available per select (in priority
channel. order) per channel
Figure 329. Configuration parameters for originating TTP
15.8.3 Configuration of the originating TTP for a multicast

service
The multicast case is very similar to the unicast case; the difference is that you define all
destinations from the link Destinations. This is also where you specify source-routes in the
multicast case.

Figure 330. Configuration of a multicast originating TTP. Destinations are defined under
the Destinations link on the configuration page.
Figure 331. Configuration of a new destination for a multicast channel. New destinations
can be added while the channel is active. They are specified with destination
node/DSTI and optional source routes. All configuration parameters here are
already defined in the unicast case (Figure 329).

15.8.4 Configuration of interfaces
The physical ASI interface is a 75 Ohm BNC connector.
This interface has three parameters to configure; ‘Suppress alarms’, ‘Loopback’ and
‘Output action on signal fail’ on all interfaces. In some cases the settings are not relevant;
the parameters are presented in the table below. To configure the interface, click on ITS →
Interfaces and the particular interface.
Figure 332. Interface configuration

Parameter Type Value range Default Comment
Output action on Drop-down None, Mute None If set to ‘Mute’, the failed signal
signal fail muted (i.e. shut down) on the
output access interface. Muting
may speed up fail-over switching
time when using external fail-
over switches. If set to ‘None’,
different actions are taken
depending on service type.
Suppress alarm Drop-down None, warning, all None Should alarms be disabled on the
interface? None means no,
Warning means all alarms with
severity warning and all means
all alarms.
Loopback Drop-down None, DTM None Is it allowed to use the physical

port for both ingress and egress
(DTM) or not (None) traffic?
TS packet sync Tick box Ticked, not ticked Not

errors ticked
Output mode Drop-down Auto, Spread, Auto How should the outgoing ASI
Burst stream be sent, in spread or burst
mode?
Figure 333. Interface configuration parameters
Table for ‘Output action on signal fail’ and possible services.


15.9 Configuration of MADI streams
In a MADI application example, the transport of a MADI signal (AES10) can be set up
between one source and one destination point (unicast) or between one source and multiple
destinations (multicast) in a Nimbra network. The service type can be set up without
protection or with a defined 1 + 1 protection. This stream uses 245 slots in the DTM frame
and is displayed with speed 125 Mbps.
It requires the ASI/AES module for Nimbra 600 with MADI firmware running on the
module. This firmware only supports MADI signals; it does neither support regular
AES/EBU streams nor DVB-ASI video streams. To install MADI firmware, look in the Up-
and Downgrading chapter (chapter 22).
48 kHz 48 kHz
MADI Nimbra DTM Nimbra MADI
Figure 335. Timing of a MADI signal on ingress and egress interfaces. The 48 kHz is a
reference clock, which needs to be attached to the outgoing interface module
of the terminating Nimbra node.
Observe that MADI does not use the through-timing of all other services. Instead, a
separate clock is needed to synchronize the egress traffic of the stream.
15.9.1 Configuration process

Configuration starts on the terminating TTP, whether the service is uni- or multicast.
Having previously defined all terminating TTPs for the service, the originating TTP is
defined. After all TTPs are defined and the channel is established, some parameters on the
interfaces can be set. The parameters can also be configured during the setup process.
In this text, an example of a MADI stream is given.
A MADI stream from interface aes/ebu-8:1 in node iov044 to interface aes/ebu-6:1 in node
iov018 is used as example. It is shown, starting from this example, how to set up a MADI
multicast stream from interface aes/ebu-1:1 in node iov044 to multiple interfaces in node
iov018.
It is necessary for the proper extraction of the MADI signal from the terminating TTP that
an output reference clock is configured on the ITS → Interfaces → Timing link in the web
interface and that this reference is attached to the interface. In addition, the output interface
of the MADI signal must also be configured. All these configurations are discussed under
Configuration of interfaces.
15.9.1.1 Configuration of the Terminating TTP

All configuration of Isochronous transport services (ITS) is made from the ITS link. To set
up the terminating TTP, follow the TTPs link and click on the ‘Add TTP …’ button. Select
the interface on which the outgoing stream is wanted.
Note that, once Terminating Type is selected, mode selection is grayed out. This is because,
for the terminating TTP, configuration is identical for uni- and multicast service.

Figure 336. AES/EBU Configuration example with a MADI stream between interface
aes/ebu-8:1 in iov044 and aes/ebu-6:1 in iov018.
Figure 337. The Add TTP configuration page for ITS. In this example, a terminating TTP
on local interface aes/ebu-8:1 in iov018 is set up.
Clicking on ‘Add’ takes the user to the configuration page of the terminating TTP.

Figure 338. Configuration parameters for the terminating TTP.
The configurable parameters are defined in the table below.

Administrative Drop- Up/Down Down
status down
Toggle admin Check Ticked/Not ticked Not Toggle admin sets admin status to
box ticked down, does the requested action and
(re)sets admin status to up.
(232-1)
string
Local interface Drop- Any interface in Selected
down the list interface
DSTI Integer 0-32767 (215-1) Lowest Unique per service type and node
available
Suppress alarms Drop- None/Warning/All None Suppression of alarms on the
down terminating TTP is possible. The
options are:
None No alarm suppression
is made
Warning Suppression of alarms
with severity Warning
is made
All All alarms are
suppressed
Connection Drop- On/Off Off The terminating TTP can allow for
protection down 1+1 protection. If it does so, two
channels are terminated on the TTP.
One of the channels is forwarded to
the outgoing access interface, while
the other is used as backup.
Active channel Drop- First/Second First When the channel is 1+1 protected,
when protected down one of the channels (the ‘Active
channel when protected’) is
forwarded to the access interface.
With admin status ‘up’, the
forwarded channel can be changed
manually by altering this parameter.
Figure 339. Configuration parameters for terminating TTP
15.9.1.2 Configuration of originating TTP for a unicast connection

The originating TTP is where you configure if the channel is uni- or multicast. If you define
the channel as multicast, the different destinations are entered under a separate link
Destinations on the configuration web page. This link can be viewed as a subpage of the
configuration page, only needed for multicast streams. Multicast streams are described
later.
To configure a unicast connection, click on ITS → Source TTPs and the Add TTP button
on the page. Select originating type (unicast mode) and local interface (in the example
aes/ebu-8:1), according to Figure 340. When the add button is clicked, the configuration
page of the originating TTP is presented (Figure 341).

Figure 340. The Add TTP configuration page for ITS. In this example, an originating TTP
on local interface aes/ebu-8:1 is set up.
Configuration the originating TTP is made from the following web page.
Figure 341. Configuration parameters for a unicast MADI stream on the originating TTP

The configuration parameters are defined in the table below.
Parameter Type Range Default Comment

Administrative Drop Up/Down Down
status down
Toggle admin Check Ticked/Not ticked Not ticked Toggle admin sets admin
box status to down, does the
requested action and (re)sets
admin status to up.
(232-1)
Purpose String Character string Empty string Identifier
Local interface Drop- Any interface in Selected
down the list interface
(Local) DSTI Integer 0-32767 (215-1) Lowest Unique per service type and
available node
Destination String Defined hostname None
DTM node or DTM address
Destination Integer 0-32767 (215-1) 0 Number unique per service
DSTI type and node
Connection Drop- On/Off Off The originating TTP can
protection down allow for 1+1 protection. If
it does so, two channels are
originating on the TTP, with
one common destination
TTP.
First/Second Drop- All defined source- (none) Three source routes possible
Channel Source down routes in a node. to select (in priority order)
Route Three routes are per channel. If no source
available per route is selected, DRP
channel. routes the channel(s). For
1+1 protection, source
routes are strongly
recommended.
Figure 342. Configuration parameters for originating TTP. The bandwidth is not
configured as it is always 125 Mbps.

15.9.1.3 Configuration of the originating TTP for a multicast service
The multicast case is very similar to the unicast case; the difference is that you define all
destinations from the link Destinations. This is also where you specify source-routes in the
multicast case.
Figure 343. Configuration of a multicast originating TTP. Destinations are defined

thorough the Destinations link on the configuration page.
Figure 344. Configuration of a new destination for a multicast channel. New destinations
can be added while the channel is active. They are specified with destination
DTM node/DSTI and optional source routes. All configuration parameters here
are already defined in the unicast case (Figure 329).

15.9.2 Configuration of interfaces
15.9.2.1 Basic settings
The physical interface of the ASI/AES module, which is used to transport MADI services,
is a 75 Ohm BNC connector. The basic interface settings is defined from the ITS →
Interfaces → Basic (Settings), illustrated here with node iov018.
Figure 345. Basic interface settings configuration
This interface has three parameters to configure; ‘Output action on signal fail’, ‘Suppress
alarms’ and ‘Loopback’. In some cases the settings are not relevant, but as originating and
terminating interface are configured the same way they are nevertheless presented. The
parameters are presented in the table below.

Parameter Type Range Default Comment
Output action on Drop-down None, None If set to ‘Mute’, the failed signal muted (i.e.
signal fail Mute shut down) on the output access interface.
Muting may speed up fail-over switching time
when using external fail-over switches. If set
to ‘None’, different actions are taken
depending on service type.
Suppress alarm Drop-down None, None Suppression of alarms on the terminating TTP
warning, is possible. The options are:
all None No suppression is made
Warning Suppression of alarms
with severity Warning is made
All All alarms are suppressed
Loopback Drop-down None, None The physical port can be used for both ingress
DTM and egress traffic (DTM Loopback) or this
possibility can be disabled (None)
Figure 346. Interface configuration parameters
Table for ‘output action on signal fail’:


The basic interface settings are defined from the ITS → Interfaces → Basic Settings. On
the basic settings page for the interface, there are also a number of variables presented.
Variable Possible values Comment

Operational Up, Down
status
Description Interface A description of the interface is given.
description
Speed Positive value The currently used bandwidth over the interface.
Purpose String with 0-255 Default value is the empty string.
characters
Errored Zero or positive This counter registers the number of errored blocks since
blocks value it was last read out from the interface. Observe that
refreshing the web browser resets the counter.
Unaligned Zero or positive This counter registers the number of seconds that the
seconds value output interface does not find proper alignment of the
stream and its stream synchronization source on the
module of the outgoing video stream. The counter is
cumulative and is not reset to zero when good (i.e.
synchronized) seconds occur. Observe that refreshing the
web browser resets the counter.
Defects All possible All present defects on the interface are presented.
defects on the Observe that refreshing the web browser reads out
interface present defects again.
Figure 348. Variables presented on the interface configuration page.
15.9.3 Timing
MADI timing is defined under the tab ITS → Interfaces → Timing.
Figure 349. Timing definition for an interface. There are two parameters to define, ‘Output
reference’ and ‘Operating mode’.
The parameters Operating mode and Output reference exist both on the source (input) and
sink (output) interfaces. On the source interface, output reference is irrelevant and is
ignored and Operating mode must be configured as ‘Audio transport’. For sink interfaces,
the parameters are described in the table below.

Parameter Type Value range Default Comment
Output Drop- aes/ebu-x:1 to aes/ebu-x:8 Output reference to which the signal

reference down aes/ebu-x:8 is aligned. This interface has to
have a word clock timing source
attached.
Operating Drop- Audio Audio transport Audio transport forwards a MADI

mode down transport stream. Word clock timing source is
Word clock used for timing source input.
timing source
Figure 350. Interface configuration parameters. They exist both for source and sink
interfaces, but are irrelevant for source interfaces.
In the following, three examples of the interface configuration are made.
Figure 351. For the outgoing signal from interface aes/ebu-6:3, the timing is obtained from
the timing provider in aes/ebu-6:8. The configuration of this timing provider is
shown in the next picture.

Figure 352. Configuration of the timing reference, which is attached to interface aes/ebu
aes/ebu-
6:8. The timing provider uses a word
word-clock timing source. In this case, the
output reference parameter is irrelevant and thus grayed out.
Figure 353. Configuration of the MADI signal on the incoming interface. Here, no timing
provider is used. Interface 8:8 is the default output reference,, a parameter that
is irrelevant on an input interface.
15.10 Configuration of interfaces - Test Generator

From GX4.10,, test generators for MADI, AES, ASI and all SDI versions (SD-SDI, SDI, HD
HD-SDI
and 3G-SDI)
SDI) are available. When the test generator is active, no channel can originate or
terminate on the interface. If channels are already using the interface, the test generator
cannot be enabled.
Note: When a test generator is enabled on an interface, no channel can

originate or terminate on that interface. When channel(s) is/are
using the interface, the test generator cannot be enabled.

In order to access all these test generators, go to the link ITS → Interfaces → Test
Generator.
Note: The test generator integrated in the web interface was developed
to internal Net Insight requirements only. Although it may be
used for others, there is no warranty – neither implicit nor
explicit – for such usage. External users use the integrated Test
Generator entirely on their own risk.
15.10.1 AES
Under the Interface link to the specific AES interface, a Test generator link is available.
Figure 354. Test generator configuration for an AES interface.
The configurable parameters of the AES test generator are shown in the table below.
Parameter Type Default Range Explanation
Enable Binary Disabled Enabled The test generator on the interface is on

Disabled The test generator on the interface is off
Sample Drop- 48.0 kHz 32.0 kHz Sample rate for the (non-configurable
configurable) 1 kHz
rate down 44.1 kHz test tone.
48.0 kHz
88.2 kHz
96.0 kHz
176.4 kHz
192.0 kHz
Figure 355. Configurable AES interface test generator parameters.

15.10.2 MADI
There is only one parameter to configure for a MADI test generator and that is to enable the
test generator itself.
Figure 356. Configuration of MADI test generator
The test generator generates valid MADI frames and can be aligned to the output reference.
The test generator operates at the nominal sampling rate ± 175 ppm.
15.10.3 ASI
Under the Interface link to the specific ASI interface, a Test generator link is available. This
link is available on the 8 x Video Access Module, 8 x 3 Gbps Video Access Module and the
JPEG2000 Video Access Modules.
Figure 357. Test generator configuration for an ASI interface.

The configurable parameters are described in the table below.
Parameter Type Default Range Comment
Enable Binary Disabled Enabled The interface is enabled (checkbox selected)

Disabled The interface is disabled (checkbox not selected)
Pattern Drop inc The test pattern sent from the output port.
down
inc ‘inc’ means that the null-packet traffic stream is
stuffed with bits in an incrementing pattern –
0x01, 0x02, …, 0xff. Then the pattern repeats
itself.
all0 ‘all0’ means that generated null-packet transport
stream consists of only zero bits
‘all1’ means that the stream consists of only
all1
binary ones
Speed Real 5.000 0.8-212 This is the transport stream bit rate (in Mbps).
Mbps
Forward Binary Disabled Enabled The interface is enabled, which means that 16
Error FEC bytes are added to all packets (204 bytes
Correction instead of 188 bytes)
(FEC)
Disabled The interface is disabled, i.e. no FEC is added
Multi Binary Disabled Enabled MFN is enabled, i.e. all sync bytes are set to
Frequency 0x47
Network
Disabled SFN is enabled, i.e. every eighth sync byte is set
(MFN)
to 0xb8. All other sync bytes are set to 0x47.
Figure 358. Configurable ASI interface test generator parameters.
15.10.4 SDI
Under the Interface link to the specific SDI interface, a Test generator link is available.
Figure 359. Test generator configuration for an SDI interface.

The configurable test generator parameters are described in the table below.
Parameter Type Default Possible Comment

values
Enable Binary Disabled Enabled The test generator on the interface is

Disabled enabled/disabled (ticked/not ticked)
Format Drop- 576/50/i 480/59/i # of active lines/# of fields per

down 576/50/i second/interlaced (i) or (p)
720/23/p progressive picture
720/24/p
Observe that some values are only
720/25/p
possible for HD-SDI or 3G-SDI
720/29/p
720/30/p
720/50/p
720/59/p
720/60/p
1080/23/p
1080/24/p
1080/25/p
1080/29/p
1080/30/p
1080/50/i
1080/50/p
1080/59/i
1080/59/p
1080/60/i
1080/60/p
Pattern Drop- matrix black ‘black’ means a digital black pattern;

down matrix ‘matrix’ means pathological equalizer
color75 and PLL pattern; ‘color75’ means 75
% color bar pattern. pattern is
increasing with one per packet.
Figure 360. Configurable Test generator on an SDI interface.
15.11 Configuration of STM-1 Access streams

Regular STM-1 streams may be transported through the DTM infrastructure. In this case, a
point-to-point connection is defined between two interfaces on 4 x OC-3/STM-1 Access
modules, which are available for Nimbra One (NPS0020-3S31) and Nimbra 300 series
(NPS0020-XS31). These unidirectional connections are easily set up from the web
interface.
In the illustrated example, two streams have been defined within the STM-1 access module.
Like with other ITS services, they are best defined at the termination node first. Go to ITS
→ TTPs and follow the Add TTP… link.

Figure 361. Configuration of a terminating TTP of an STM-1 access connection between
two STM-1 interfaces. Observe that the connection is unidirectional; if
bidirectional connections are preferred they must be defined in both directions.
Figure 362. Configuration of the terminating TTP. The configuration parameters are
identical as for the previously described ITS streams.
The corresponding originating TTP is defined the same way as other originating streams.

Figure 363. Creation of an originating TTP for an STM-1 access.
The configuration is made according to the previously described pattern for ITS services.
Figure 364. Configuration of the originating TTP for an STM-1 access module, using a
local interface of vc4/sts3c-4:1

Configuration from the Advanced link is made as previously described for other ITS
services. What is different is how the interface is configured.
Both the originating and terminating interfaces must also be configured. From the link ITS
→ Interfaces, there is a possibility to configure the OC-3/STM-1 interface carrying the
payload interfaces used for ITS TTPs.
Configuration of the vc4/sts3c-4:1 looks like this:
Figure 365. Basic configuration of the vc4/sts3c-4:1. The parameter ‘Suppress alarms’ can
have values ‘None’ (default = no suppression), ‘Warning’ (= suppression of
alarms with severity warning) and ‘all’ (=suppression of all alarms).
The sonet/sdh configuration page gives the user a chance to set the two H1 bits (to ‘00’,
‘01’, ‘10’ or ‘11’).
Figure 366. Sonet/SDH settings of H1 SS bits.

15.12 Configuration of JPEG 2000 services
On both source and sink side of the connection, one TTP object and one interface object
must be configured. In order to complete the channel as fast as possible, it is beneficial to
start with configuration of the terminating TTP/interface and continue with the source
module. This is the way the setup is described.
15.12.1 Enabling the encoder

Encoding is configured per interface and not per module.
Autosense enables all transport (audio, ANC, VBI). If all bandwidth is not required,
whatever bandwidth not required can be removed after autosense has been selected.
In order to work properly, autosense has to be enabled on both the source and sink
interfaces.
The default setting is that the encoder is disabled and that autosensing is enabled. In order
for the module to carry a JPEG encoded stream, the encoder has to be enabled. The setting
is made on the encoder interface web page.
Figure 367. JPEG 2000 encoding must be enabled in the ‘Enable JPEG 2000 encoding’
tick box on the basic interface configuration page.

15.12.2 Sink TTP configuration
Figure 368. Configuration of the terminating TTP in a unicast HD-SDI or SD-SDI

JPEG2000 channel. Observe that the termination TTP must be configured on a
decoder configured JPEG2000 Video Access Module if the channel is
compressed.
All that needs to be configured on this page is the terminating type and the local interface.
The selection of Type equal to ‘Terminating’ immediately grays out the Mode parameter,
as it becomes irrelevant. Clicking on the ‘Add’ button displays the specification web page
of the terminating TTP.
Figure 369. Configuration of the sink TTP.


In this example, admin status is set to Up and Connection protection to Off. Default DSTI
is kept at 5, the lowest unused DSTI available. After clicking on Apply or OK, the TTP
goes in operational state dormant, which indicates that it is awaiting action by other
node(s).
Proceed with the configuration of the interface by clicking on the link with the interface
name. In our case, the ‘Speed autosensing’ parameter is enabled and grayed out, which it
always is on the sink interface.
Figure 370. Configuration of the terminating interface

15.12.3 Source TTP configuration
After finishing the configuration of the sink side, proceed with the source side. In this
example, interface 3:2 in iov129 is used as source interface.
Figure 371. Creation of the originating TTP.
The ‘Add’ button takes the user to the configuration page of the originating TTP. The
interface has to have JPEG encoding enabled (and the parameter is disabled by default),
which is done from the Interface link, if the signal shall be a JPEG2000 compressed video.
Unless JPEG is enabled on the interface, only uncompressed configurations will work.

Figure 372. Configuration of the originating TTP, basic settings.
The default setting of the requested capacity is 270 Mbps. The options in the drop-down
menu are the same, no matter if the interface is configured with encoder enabled or encoder
disabled. However, depending on the setting of encoder enabled, some choices in the drop-
down menu are irrelevant but nevertheless available to the user. They are also selectable
and are accepted by the system. The setting SDI uncompressed 270 Mbps is treated exactly
the same way as the setting SDI compressed User defined 270 Mbps.
Figure 373. Available settings for ‘Requested capacity’, with the default SDI
uncompressed 270 Mbps setting.

Figure 374. The setting User defined 270 Mbps is treated exactly the same way as
uncompressed SDI 270 Mbps.
JPEG Encoder Relevant drop-down Irrelevant drop-down menu choices

enabled on interface menu choices
Yes SDI compressed, i.e. SDI uncompressed (all six
User defined with alternatives), but the default setting
rate set in the box User defined 270 Mbps is presented
as uncompressed SDI 270 Mbps.
No SDI uncompressed SDI compressed, i.e. User defined
(all six alternatives) with rate set in the box
Figure 375. Relevant and non-relevant settings on the ‘Requested capacity’ parameter
depend on the setting on the interface for JPEG Encoder enabled.
The default settings are that all ANC/VBI data and all audio groups are enabled. A way to
transport the compressed streams with less bandwidth is to reduce the amount of
audio/ANC/VBI data transported, in particular the data that is not used in the stream.
In the table below, the required capacity for different types of streams are detailed. The sum
of these values is what should be configured on the source TTP for the stream.
Type of stream Video Audio ANC/VBI

SD-SDI 10-125 0-36 0-15
HD-SDI 10-250 0-74 0-2.5
3G-SDI 10-500 0-138 0-2.5
Figure 376. Capacity requirement for different types of (compressed) streams
In addition to Basic settings, also Advanced settings can be configured.

Figure 377. Configuration of the originating TTP, advanced settings. In this case, the
channel is set up as compressed HD-SDI with 100 Mbps bandwidth.
15.12.4 Multicast
Multicast is configured the same way as unicast on the terminating side. When the selection
of multicast is made, originating and terminating are grayed out in the web interface. This
indicates that the selection now is irrelevant and can no longer be made.
On the originating side, a multicast TTP is setup without destinations. The destinations are
added one at a time. Addition of destinations can also be made on active channels, making
it possible to add new destinations to services already in operation.
Destinations are added from the Destinations tab on the configuration page and the ‘Add
destinations’ button on this web page.

Figure 378. Configuration of a multicast channel, in this case uncompressed.
Figure 379. Add destinations to a multicast channel. To get to this web page, click on the
Destinations link in the previous picture.

Figure 380. Addition of a new destination to an originating multicast TTP.
15.12.5 Interface configuration
Figure 381. Configuration of the originating interface of the connection. Make sure to
enable JPEG2000 encoding if the channel is using encoded JPEG traffic.

The interfaces of both source and sink modules must be configured. This is done on the
interfaces. Some parameters are configured on the encoder side and some on the decoder
side. Configuration is made from several different links, which are described in the
following text one by one. The tab VBI is only relevant for SD-SDI signals.
15.12.6 Basic interface parameters

15.12.6.1 Output action on signal fail
Default value: None (No action taken)
Type: Enumerable list
Range: None, Mute
Description: If set to ‘Mute’, the failed signal muted (i.e. shut down) on the output access
interface. Muting may speed up fail-over switching time when using external fail-over
switches. If set to ‘None’, different actions are taken depending on service type.
Table for ‘output action on signal fail’ and different services.

15.12.6.2 Suppress alarms

Type: Enumerable list
Range: possible values are ‘None’, ‘Warning’ and ‘All’
Description: The default setting ‘None’ does not suppress any alarms. ‘Warning’
suppresses all alarms with severity warning and ‘all’ suppresses all alarms.

15.12.6.3 Loopback
Type: Enumerated list
Range: ’None’ does not configure the interface in loopback mode. ‘DTM’ copy the stream
on a sink interface and makes it possible to reuse the stream as a source for another
channel. DTM loopback sends back the uncompressed stream and not the compressed
stream, i.e. it uses significant amounts of bandwidth.
Description: Sets the DTM loopback mode. DTM loopback is a way to send a signal,
destined for a Tx interface, back to the path of the Rx signal on the very same interface.
The signal is split at the interface and sent out on the Tx interface as well as being looped
back. It can be (and normally is) used as a signal source for another destination.
The return video stream (the looped back signal) is returned after passing the JPEG
decompression block and is thus uncompressed.
Interface in DTM loopback mode
Nimbra node
Figure 383. DTM loopback mode.
15.12.6.4 Speed autosensing

Default value: Enabled
Type: Binary (tick box)
Range: Enabled, Disabled
Description: Selection of this parameter enables speed autosensing. The parameter has to
be set on both source (ingress) and sink (egress) interfaces to work properly, but on the sink
interface it is always enabled and not configurable.
15.12.6.5 JPEG 2000 encoding

Default value: Disabled
Type: Binary (tick box)
Description: Selection of this parameter enables JPEG 2000 encoding. The parameter is
only available on a JPEG2000 module with JPEG 2000 encoding firmware.

15.12.6.6 Signal format
Default value: HD-SDI (1.485 Gbps)
Range: Available signal formats for the JPEG2000 Video Access Module v2 are: 3G-SDI
(2.970 Gbps or 2.970/1.001 Gbps), HD-SDI (1.485 Gbps or 1.485/1.001 Gbps) and SD-SDI
(270 Mbps).
Description: The available format on the interface. This parameter is only available with
auto-sense disabled and JPEG2000 encoding enabled.
15.12.7 Test Generator interface parameters

Under the Interface tab to the specific SDI interface, a Test generator link is available.
In order to access the test generator, administrative status of all TTPs defined on the
interface has to be down.
Figure 384. Test generator configuration for an SDI interface.

Parameter Type Default Possible Comment
values
Enable Check Unticked Ticked Test generator function enable/disable.

box Unticked
Format List 576/50/i 480/59/i # of active lines/# of fields per

576/50/i second/interlaced (i) or (p) progressive
720/23/p picture
720/24/p
Observe that some values are only possible
720/25/p
for HD-SDI
720/29/p
720/30/p
720/50/p
720/59/p
720/60/p
1080/23/p
1080/24/p
1080/25/p
1080/29/p
1080/30/p
1080/50/i
1080/50/p
1080/59/i
1080/59/p
1080/60/i
1080/60/p
Pattern List black black ‘black’ means a digital black pattern;

matrix ‘matrix’ means pathological equalizer and
color75 PLL pattern;
‘color75’ means 75 % color bar pattern.
Figure 385. Configurable Test generator on an SDI interface.

15.12.8 Timing interface parameters
This is a web page that is currently not configurable. The only thing currently implemented
is the ‘Dropped frames’ and ‘Repeated frames’ shown at the bottom. The text describes the
intended way of operating, when implementation is finished.
In order to have access to the timing parameters, administrative status of all TTPs defined
on the interface has to be down.
Figure 386. Timing configuration on an SDI interface, only relevant on the decoder side.
15.12.8.1 Operating mode

Default value: ‘SDI Transport’
Range: Alternatives that are supported by the hardware are shown in a drop-down menu.
Description: ‘SDI Transport means that the signal is not used by the system as a timing
source, ‘digital timing source’ that is it used as a digital timing source.
15.12.8.2 Output reference

Default value: sdi-x:8
Range: Node sync, sdi-x:1, sdi-x:2,…, sdi-x:n, where n is number of interfaces on the node
in question, except the interface itself.
Description: Reference is the outgoing timing signal used to clock out the signal from the
interface being configured.

15.12.8.3 Vertical delay (lines)
Default value: 0
Type: integer
Range: 0 to the number of lines in the frame minus one
Description: Number of lines offset between the timing source and the signal itself.
15.12.8.4 Horizontal delay (pixels)

Default value: 0
Type: integer
Range: 0 to the number of pixels per line minus one
Description: Number of pixels offset between the timing source and the signal itself.
15.12.9 Video interface parameters

This is a JPEG2000 encoder side configuration only and neither the link nor the web page
is available with decoder or no JPEG2000 firmware.
Figure 387. Video configuration on an SDI interface. The page is only available on the
encoding side.
15.12.9.1 Auto chroma weight

Default value: Selected
Type: Tick box
Range: Selected, Not selected
Description: Determines if the chroma weight setting is automatic or not. If it is, the two
parameters that follow become irrelevant and are grayed out.

15.12.9.2 Cb weight (%)
Default value: 5
Type: real number
Range: 2-15
Description: Weight of the Cb or blue difference component of the video.
15.12.9.3 Cr weight (%)

Default value: 5
Type: real number
Range: 2-15
Description: Weight of the Cr or red difference component of the video.

15.12.10 Audio interface parameters
Figure 388. Audio configuration on the encoding side. On the decoding side, it is possible
to monitor what ANC parameters have been transported. Audio groups five to
eight are only available for 3G-SDI speeds.

15.12.10.1 Audio group enable (for groups one to eight)
Default value: Selected
Type: Tick box
Range: Selected, Not selected
Description: Only audio groups which are enabled will be transported together with the
JPEG encoded video.
Note that in order to optimize bandwidth usage, it is important to disable unused audio and
ancillary (ANC) data.
15.12.10.2 Select all audio groups

Default value: Disabled
Type: Tick box
Description: This setting selects all audio groups on the web page. Individual audio groups
can later be individually removed from the selection.
ancillary (ANC) data.
15.12.10.3 Extra configuration for SD-SDI video streams

For SD-SDI streams there is one additional setting. It is a setting to define if the audio
stream carried with the compressed SD-SDI signal is sampled with 20 bits or 24 bits. The
parameter is called Audio Mode.
Figure 389. Audio mode setting of SD-SDI compressed video streams.
15.12.10.4 Audio Mode (for SD-SDI compressed streams only)

Default value: 20-bit
Type: Binary, 20 or 24 bit settings allowed
Range: 20 or 24 bit audio (A/D) encoder setting
Description: Enables (24-bit) or disables (20-bit) forwarding of the extended audio ANC
packets, carrying four bits extra of audio information in 24-bit mode.
ancillary (ANC)/vertical blanking interval (VBI) data.

15.12.11 Ancillary (ANC) interface parameters
Figure 390. ANC parameter configuration on the encoding side. The web page makes it
possible to transport only some of the ANC parameters while leaving others.
Default is that all ANC data is transported. On the decoding side, it is possible
to monitor what ANC parameters have been transported.
On the encoding interface, the ancillary (ANC) parameters can be enabled for transport or
not. The parameters are presented in the table below. DID and SDID are Data Identifier and
Secondary Data Identifier respectively.

Service DID SDID Comment
AFD 0x41 0x05 Active Format Description
WSS 0x50 0x01 Wide Screen Signaling
ATC 0x60 0x60 Ancillary Time Code
OP-47, SDP 0x43 0x02 Subtitling Distribution Packet
OP-47 VANC multi 0x43 0x03 Vertical ANC Packets

packet
Caption Distribution 0x61 0x01

Packet (CEA-708)
CEA-608 0x61 0x02 Only usable in 30/60 frames

per second systems
VPID 0x41 0x01
ANSI/SCTE 104 0x41 0x07

messages
Figure 391. ANC data to be enabled/disabled
Note that in order to optimize bandwidth usage, it is important to disable unused audio,
ancillary (ANC) and VBI data. Typically, this information takes up similar amounts of
bandwidth as the video itself.
On decoder interfaces, no Audio, ANC or VBI tabs are included.

15.12.12 Vertical Blanking Interval (VBI) interface parameters
Figure 392. Configurable VBI parameters for JPEG 2000 SD-SDI compressed signals with
PAL encoding.
On the encoding interface, VBI lines are individually enabled/disabled. The default setting
is that all VBI lines are enabled and thus sent multiplexed with the encoded stream. The
VBI lines are information carrying lines sent after the last line of one frame but before the
first line of the next frame. VBI lines differ between NTSC and PAL. To select all PAL or

all NTSC lines, use the PAL/NTSC button. To select all or no lines, use the Select All/None
button.
15.12.13 Statistics
Figure 393. Statistics page on the encoder interface.
On the statistics page on the encoder interface, various pieces of information are presented
about the stream that passes through the interface.

Parameter Example Comment
Frame format 1280x720p@ Written as

60 Hz [Pixels/line]x[lines/frame][i=interlaced/p=progressiv
e]@[field frequency] Hz
SDI Speed Bitrate of the Supported: 270, 1.485, 1.485/1.001, 2.997,

video stream 2.997/1.001 Gbps
Channel capacity 11 Mbps Requested capacity on the encoding/source TTP.

Has to be greater than 10 Mbps plus all configured
audio, ANC and VBI capacity.
Current JPEG Momentary JPEG 2000 video rate

2000 video bit rate
Maximum JPEG Highest possible value of the previous counter

2000 video bit rate
Audio bit rate Bit rate of the (entire) audio stream
ANC bit rate Bitrate of the stream of ANC data (excluding radio)
VBI bit rate 0 Bitrate of the VBI stream, which is associated with
the SD-SDI format.
Total current bit Sum of used bit rates in all channels passing through
rate the interface
Total maximum Highest possible value of the previous counter

bit rate
Figure 394. Variables shown on the Interface Statistics web page.
15.13 Configuration of 1+1 hitless video
Hitless video 1+1 protection is a value added feature providing a completely hitless
protection switching for ASI and JPEG2000 compressed SDI.
Hitless Video 1+1 Protection switching provides a mathematically lossless protection
switching by aligning and merging two identical packet streams. It is an inherently state-
less protection approach that besides protecting against defects and link failures also
protects against random packet drops. In addition to the hitless 1+1 protection mechanism,
this release introduces support for monitoring both redundant channels. Such monitoring is
also available for open-ended protection, i.e. protection with dual sources.
Hitless Video 1+1 Protection is available for Nimbra 600 nodes on the following Access
Modules:
• JPEG2000 Video Access Module (NPS0074-6001)
• SFP Video Access Module (NPS0054-6001)

Nimbra network
Interface A Interface B
Source TTP A2 Route Two Sink TTP B2
Node A Node B
Figure 395. Source stream sent through Nimbra network, using two independent routes
for closed-ended 1+1 hitless/standby protection.
Configuration of 1+1 hitless video streams is a new feature for GX4.12, although it looks
like the earlier closed ended protection case. In the new case, either one of the streams can
be sent to the sink interface (interface B; called standby protection) or both streams can be
used to create the outgoing stream (hitless protection). It is the hitless protection feature that
is new in this release and a configuration example of this case is presented.
One video stream is split at the source interface and sent to two separate source TTPs. The
streams traverse the network along different routes and are terminated in two separate sink
TTPs with a common interface. Configuration of closed ended 1+1 hitless protection starts
on the sink side, in our case interface asi-6:1in node iov136.
15.13.1 Hitless web parameters and variables

There are two new configurable web parameters in the hitless video 1+1 protection release.
They appear at the bottom on the outgoing sink interface web page. A closer look at this
part of the web interface is shown below.
Figure 396. New parameters to configure in Hitless Video 1+1 Protection.

In the table, parameters and their possible values are detailed. Included are also the (non-
configurable) variables.

Parameter/Variable Description
Member interfaces Member interfaces are zero, one or two sink TTPs associated with
the sink interface. A TTP appears as a member interface when the
sink interface is configured as the interface to the sink TTP.
Type Type of protection on the interface. All available types are
presented automatically. Currently, ‘Hitless’ or ‘Standby’ are
supported. Hitless means that both streams are used to generate
the outgoing video stream. Standby means that one of the streams
is used as the outgoing stream and the other stream is a monitored
redundant stream.
Status Current state in the Hitless/standby state machine. There are five
states altogether (in order low to high): Unavailable →
Unprotected → Standby protected → Hitless capable → Hitless
protected
Expected status If ‘status’ is “lower” than ‘expected status’ in the Hitless/standby
state machine, a major alarm with text ‘Protection status lower
than expected’ is generated.
Active interface Answers the question “What interface is passed on to the output
interface?”. Only relevant for standby protection.
Differential delay Time difference between the streams on the member interfaces, as
measured by the sequence numbers added at the source interface.
Figure 397. New parameters and variables on the sink interface in Hitless video 1+1
protection.
15.13.1.1 Creation of sink TTPs

Create two separate sink TTPs (Sink TTP B1 and Sink TTP B2) and tie both of them to the
same interface (Interface B). Set the TTPs to admin status up for faster completion of the
channel. The TTPs should appear with administrative status up and operational status
dormant in the list of sink TTPs.
Select ITS → Sink TTP and the ‘Add TTP’ button.
Figure 398. Addition of the first sink TTP in the destination node.

Figure 399. Configuration of a sink TTP (itsi-0 or Sink TTP B1). It is suggested that you
set admin status to up and keep the other default settings.
Repeat for the other sink TTP in the destination node.
Figure 400. Addition of the second sink TTP in the destination node.

Figure 401. Configuration of the second sink TTP (itsi-1 or Sink TTP B2). It is suggested
that you set admin status to up and keep the other default settings.
The sink TTPs created so far are listed below.
Figure 402. Created sink TTPs.
15.13.1.2 Creation of source TTPs

Now continue with creation of the two source TTPs in the source node, in our case on
interface asi-8:1 in iov072. Follow the link ITS → Source TTPs and the button ‘Add TTP’.
Make sure to define the destination node and destination DSTI (matching the first sink
TTP), requested capacity and the first channel source route. In the second source TTP that
is configured, it is necessary to select a different destination DSTI (matching the other sink
TTP) and a different source route. Different source routes are needed to get proper
protection.

Figure 403. Configuration of first source TTP (itso-1 or Source TTP A1). The channel is
set up along route ‘Route pri to iov136’. Source routes are defined under All
connections → Source routes in web

Figure 404. Configuration of second source TTP. (itso-2 or Source TTP A2). The channel
is set up along route ‘Route sec to iov136’. Observe that both source TTPs
are associated with the same physical interface. Source routes are defined
under All connections → Source routes in web.
15.13.1.3 Configuration of the sink interface

The final configuration item is the sink interface (asi-6:1 in iov136).
Go to ITS → Interfaces and select the interface.

Figure 405. Type of protection is selected in the Type drop-down menu. Hitless is
available only if there are two sink TTPs (Member interfaces; itsi-0 and itsi-
1) attached to the sink interface. Hitless makes sense only for closed ended
protection, i.e. one incoming stream that is split at the input interface.

16 Channel Persistence
16.1 General
Given a large network, it is inevitable that failures occur from time to time. These failures
can affect transmission links as well as switching nodes. When an error occurs somewhere
in a DTM network, the default action is to tear down all channels that are affected by the
error. The reason for this is that the network can hopefully find another path through the
network for the channel and restore the service quickly.
Tearing down the channels is however not always the best course of action. In some
situations, channels can continue to forward data even though a node-controller has stopped
working or a link has become unidirectional. In other situations, it might be appropriate to
let a channel remain established even though a link that it is running over has failed. This
will lead to faster recovery when the link is repaired. The Channel Persistence functionality
allows the operator to configure the behavior of the network when failures occur. Three
main types of failures are handled:
A node-controller that restarts due to a software or hardware error.
A node-controller that fails completely due to a hardware failure.
A link that fails in one or both directions.
16.2 Persistence Configuration

The main configuration parameter for channel persistence is the Link Class for each
interface. The Link Class decides how a node shall behave if it detects that the neighboring
node stops responding or the link fails. It is configured on a per-interface basis on the
DTM->Interfaces->Edit page. The link class must be configured with the same value at
both ends of a link.
16.2.1 Link Class Normal

Link Class Normal means that the node will consider the link as Down if it detects an error
with the link (Signal Failure) or if the node at the other end of the link fails to respond to
the periodic supervision messages. When a link is considered Down, all channels utilizing
that link are immediately torn down. . This means that as soon as an error is detected, all
channels affected by the error are torn down. Link Class Normal is the default for all
interfaces.
An interface configured with link class Normal will never have status NoControl or
DownKeep. It will go directly to status Down instead.
Element Manager User's Manual Channel Persistence • 363

16.2.2 Link Class Persistent
Warning: This option is for advanced use only. Used inappropriately, the
option may cause multiple problems. It is strongly suggested
that the user should understand the feature properly before
employing it.
With Link Class Persistent, the node will not tear down channels if the neighboring node
stops responding. Instead, it will classify the link as NoControl and leave all existing
channels in place, but deny any new channels from being established via the interface to the
peering node that has stopped responding. Furthermore, if a node has one or more links
configured as Persistent, the node will by default enenter
ter a NoControl mode if the node-
node
controller restarts. In the NoControl mode, the node will not run the normal DTM protocol
stack and instead leave the hardware configured as-is.
as is. This means that all existing channels
will continue to forward data, but it wi
will
ll not be possible to supervise the links and channels
or setup any new channels.
If an interface is configured with Link Class Persistent and the node receives an indication
that the link on that interface has failed completely (e.g. a Signal Failure cond
condition),
ition), it will
tear down all channels over that link.
Persistent links are useful to protect end
end-nodes
nodes that are single points of failure for a service.
An interface configured with link
link-class
class Persistent will never have status DownKeep, it will
go to statuss Down instead.
16.2.3 Link Class Nailed
Warning: This option is for advanced use only. Used inappropriately, the
option may cause multiple problems. It is strongly suggested
that the user should understand the feature properly before
employing it.
With Link Class Nailed, the node will never tear down channels unless the operator sets the
administrative status of the interface to down or if the channel is removed via the
management interface. This means that the node will leave channels in place even if it
knows
ows that the channels cannot forward any data since there is a loss
loss-of-signal
signal situation on
the interface.
If the neighboring node stops responding or if the link to or from the neighboring node
fails, the node will leave all existing channels in place, but deny any new channels from
being established via the interface to the peering node. Furthermore, if a node has one or
more links configured as Nailed, the node will by default enter a NoControl mode if the
node-controller
controller restarts. In the NoControl mode, the node will not run the normal DTM
protocol stack and instead leave the hardware configured as as-is.
is. This means that all existing
channels will continue to forward data, but it will not be possible to supervise the links and
channels or setup any new channchannels.
Nailed links are useful since they allow links that break in one direction to continue
forwarding data in the other direction. They also allow faster recovery after the link has
been restored again, since all channels are already established.
16.2.4 Restart On Error

If a node is configured with at least one interface with a link class of either Persistent or
Nailed, the node will by default enter node status NoControl if the local node controller

restarts. See the section on “Node Status NoControl” for an explanation of the
consequences of this.
The “Restart on error” setting allows the operator to tell the node that it shall always go
directly to Up mode and tear down all existing channels if the node controller restarts. This
means that the only time the node stops in NoControl is if the node-controller fails and
needs to be replaced.
The Restart on error setting can be found on the Maintenance →System page.
16.2.5 Redundant DLE Servers

If persistent channels are used in a DTM network, it is strongly recommended to configure
all nodes with access to two redundant DLE servers. Otherwise, it may happen in an error
situation that a node looses contact with the DLE server and becomes impossible to reach
via the in-band management network.
It is also important to place the DLE servers in nodes that can be reached via in-band-
management without passing through the DLE segment that the DLE server handles.
Otherwise, if a DLE server fails for some reason, then it becomes impossible to reconfigure
the DLE server since to reach the node with the DLE server, we need to use the DLE
segment that just failed. One possible location for the DLE server is in the gateway to the
DLE segment in question. The backup DLE server can be placed in a node connected to a
different DLE segment.
16.3 Handling an Error Situation

When the Persistent Channel functionality is used (i.e. when at least one interface in the
network is configured with link-class Persistent or Nailed), the network will try to tolerate
some types of failures without tearing down all affected channels. If such an error occurs in
the network, the network will run in a somewhat degraded state. This section describes how
to diagnose a network in such a degraded state, the behavior that can be expected from the
network in the degraded state and how the network can be repaired.
16.3.1 The DTM->Links Page

The DTM->Links web page displays the status of communication with all neighboring
nodes. It shows a list of all local DTM trunks with the administrative status set to Up. For
each interface it shows the status of the RX interface followed by the status of the TX
interface. Since a DTM network only requires bi-directional connectivity between a pair of
nodes and not bi-directional links, it is possible for the status of an RX interface to be
different from the status of the corresponding TX-interface. It is even possible (but not
recommended) for the RX and TX interfaces to be connected to different nodes.
The status of a TX interface can be
Down – No peering node has been detected.
Up – Full, bi-directional communication with the peering node is possible.
NoControl – The communication with the peering node has been Up, but the peering node
has now stopped responding. This indicates that the peering node-controller has either
entered the NoControl state or it has failed completely and needs to be replaced.
DownKeep – The communication with the peering node is still Up, but an error has been
detected on the trunk to or from the peer.
An RX-interface can have the same statuses as a TX-interface plus

Pending – A node has been detected at the other end of the link, but it has not been possible
to establish full communication with the node. This indicates that we only have uni-
directional communication (from the peer to this node) with the peering node.
Loopback – The RX-interface is connected to a TX-interface in this node.
In status Pending and Loopback, only the interface-address of the peer is known and
displayed. In status Up, NoControl and DownKeep, the node-address and DTM address of
the peer is also shown.
In normal operation, all interfaces with attached fibers shall show a status of Up. If you
suspect that a node has entered a NoControl state and you cannot reach the node directly,
look at the DTM Links page in a neighboring node to determine what the neighbor thinks
about the node.
If any link has status NoControl, the node will raise a Major alarm with cause “Response
time excessive” and description “Peering node is in state NoControl or is not responding”.
If any link has status DownKeep, the node will raise a Major alarm with cause
“Communication subsystem failure” and description “Link is in state DownKeep”.
Note that unless we have several links between two nodes, both the RX and TX direction of
the link will get status NoControl or DownKeep at the same time. This means that two
alarms will be raised in each node, one for each direction.
16.4 Node Status NoControl

If a node is configured with one or more links with link-class Persistent or Nailed and the
node-controller restarts, the node will by default enter a state called NoControl. In this state,
the node will run with the DTM protocol stack disabled and it will not be able to
communicate with its neighbors. It will however retain all existing channels, both to, from
and via the node.
Since the DTM protocol stack is disabled, it is not possible to contact the node via the in-
band management network (DLE). If the node is contacted via outband management, it will
show a very limited view of the node and it will not display any information about the
status of the hardware or services. The only meaningful action in this state is that the node
can be restarted. When this is done, the node will activate the DTM protocol stack, tear
down any existing channels and try to reestablish them from the beginning.
The idea behind the NoControl state is that if an error occurs, the node tries very hard not to
disrupt any existing traffic. It is then up to the operator to choose when he wants to tear
down the channels and restore the node to full working condition.
16.5 Restarting a node in NoControl

A node in NoControl state can be brought into full working state (“Up”) in three different
ways:
Via outband management
Via serial console
From a neighboring node
16.5.1 Restarting via Outband Management

To restart the node via outband management, you can either use the “Resume full
operation” button on the Maintenance->System web page or the CLI-command “node-
restart local”.

16.5.2 Restarting via Serial Console
To restart the node via serial console, use the CLI-command “node-restart local”.
16.5.3 Restarting from a Neighboring Node

To restart a neighboring node, look at the DTM → Links page. It will show the status of all
its neighbors. If any neighbor appears to be in status NoControl, click on the interface name
for the row that displays NoControl. It will take you to the DTM Interface page for that
interface. From that page, you can send a restart command to the node connected to the TX-
part of the interface. This is done with the Restart Neighbor button. Note that a node will
only respond to the Restart Neighbor command if the node has status NoControl. If the
node is already up and running, the Restart Neighbor button will have no effect.
It is also possible to send the same restart command to a neighbor via the CLI using the
command “node-restart dtm3: 1”.
16.6 Link Errors

If a link configured as Nailed reports an error such as Signal Failure, all channels will
remain established over that link. To force the system to tear down the channels, set the
administrative status of the interface to Down or reconfigure the link-class as Normal. This
must be done on both nodes connected to the link in question.
16.7 Channels with broken control-paths

If a link configured as Nailed fails, or if a node-controller enters the NoControl state, all
channels running over that link or to, from, and via that node have broken control paths.
This means that the network will preserve the channels, but it will have limited control over
them. Depending on the type of error that has occurred, channels with broken control-paths
may or may not continue to forward data.
The best way to get rid of the broken control-path is to resolve the underlying problem, i.e.
to restart or replace the node-controller that is in NoControl state or repair the broken link.
Alternatively, the operator can also choose to disable the broken link by setting the
administrative status of the link to Down in both nodes connected to the link. All these
measures will however affect traffic if only the control-path is broken but the data-path is
actually working.
Another alternative is to selectively tear down and reestablish channels. This gives exact
control over which channels will be affected, but is more complex to perform. This is
because it is generally not possible to send control messages all the way from the source to
the destination for a channel. Control messages will only reach the node before the error
and there they will be buffered, waiting for the error to be resolved. Therefore, special
measures are sometimes needed to resolve the situation.
The rest of this chapter describes how to tear down or reestablish different types of
channels when the channels have broken control-paths.
16.7.1 Tearing down a unicast channel

To tear down a unicast channel with a broken control path, it is necessary to tear it down
from both sending and receiving side. This can be done by setting the administrative status
for the service to Down at both ends. If this is only done at the sending side, the receiving
side will show that it is still receiving the channel, but the sending side will show that the
channel has been torn down.

16.7.2 Reestablishing a unicast channel
By reestablishing a unicast channel, we can force the network to find an alternate route
through the network that avoids the error. To force a channel to be reestablished, open the
webpage for the TTP at the sending side and click the connection id (Conn id) that you
want to reestablish under “Originating connections”. On the displayed page, click the
button labeled “Re-connect channel”.
In some (rare) circumstances, the channel must be torn down at the receiving side before it
can be reestablished. If the channel is not reestablished properly, go to the TTP at the
receiving side and click on the connection id under “Terminating connections”. Then use
the button labeled “Delete” to tear down the channel from the terminating side as well.
16.7.3 Re-establishing a multicast channel

If a multicast channel is affected by a broken control-path, there are two different ways to
reestablish the channel to the affected destinations. The easiest way is to reestablish the
entire multicast tree by toggling the administrative status of the originating TTP. This will
tear down the entire multicast tree and replace it with an entirely new channel. This of
course affects all destinations and not just the destinations that are affected by the broken
control-path. Note that since the control-path is broken, it may take slightly more than one
minute to tear down the old multicast tree.
If it isn’t possible to reestablish the entire multicast tree, you can also choose to tear down
and reestablish only the affected destinations. To do this, it is necessary to perform two
different tear downs:
First, we want to tear down the channel downstream from the break in the control path. To
do this, we first need to find out the channel identifier for the channel. This id consists of
the source DTM address for the channel and a numerical identifier. To find the channel
identifier, go to the webpage for the originating TTP and click on the number in the column
“Conn Id” for the failed originating multicast channel. This will display the “Connection
Details” page for the connection. The Channel id can be found on that page. Write down
the Channel id or copy it by selecting it and pressing Ctrl-C.
Now, we need to find the node directly after the break in the control-path for the channel. If
the error is a link in DownKeep state, then it is the node connected directly downstream
from that link. If the error is a node in NoControl state, then it is the node connected
directly downstream from that node.
Log in to the node in question via the CLI. Use the “dcp list” command to verify that you
have found a node that the channel passes through. This can be done by issuing the
command “dcp list <channel id>” (e.g. “dcp list 02.00.00.00.00.00.00.41 65538”). If the
node answers with a lot of output, then the channel exists. If the node answers “No such
channel”, then the channel does not exist in this node.
If the channel exists, you can tear it down using the command “dcp remove <channel id>”
(e.g. “dcp list 02.00.00.00.00.00.00.41 65538”). This will tear down all multicast
destinations in this node and any downstream nodes.
Second, we need to remove the destinations from the source to the point where the control
path is broken. If the control path wasn’t broken, you would have torn down the channel
from the source to all downstream nodes in the first step. However, since the control path is
broken, the source application still thinks that the destinations are properly established. To
fix this, locate the originating TTP for the channel. Click on the “Destinations” link to see
all destinations for this TTP. Put a checkbox before the destinations that you tore down in
the previous step and click the button “Re-connect checked”. Note that since the control-
path is broken, it will take approximately one minute before the destinations are torn down
and can be reestablished along an alternate path.

16.7.4 Channel reestablishment upon link failures
16.7.4.1 DRP
A channel that is routed with DRP will be rerouted every time a link used by the channel
goes down. This condition (that a link goes down) happens as soon as the link has a defect
noted in the web interface. In the web interface, this can be seen on all trunks – in the two
examples below, the sonet/sdh and iptrunk are illustrated.
Figure 406. Possible alarms or defects on a SONET/SDH trunk. All alarms except RDI-
L/RDI-P take down the trunk and cause a rerouting of all channels using that
trunk.
Figure 407. Possible alarms or defects on a IP trunk. All alarms except RDI take down the
trunk and cause a rerouting of all channels using that trunk.

16.7.4.2 1 + 1 with source routes
Channels set up with source routes, i.e. in the normal case where one source route
(secondary) is backup to another source route (primary), will switch to the alternative
source route as soon as there is a problem with the received signal in the destination. In
addition to be caused by a problem on one of the constituent trunks (according to the
previous chapter), it can be caused by a LOS on the access interface or other reason
generating an AIS signal in the destination. For ETS services, this alarm can be generated
by Reduced Bit Rate alarm or DEG (degraded) alarm from a forwarding function along the
route of the service.
Switchover to the backup/secondary channel starts directly and as the backup channel lacks
monitoring, there is no guarantee that the backup signal is operational.
16.7.5 DLE
DLE will automatically tear down and reestablish channels to maintain functionality as
long as there is an available path for control signaling. It is however very important to have
two redundant DLE servers for each DLE segment, since it may happen that a DLE server
is unable to reestablish a channel to a DLE client that has been affected by an error. This
will be resolved automatically when the DLE client decides to move to the other DLE
server since the first one is non-functional.
However, there are some situations when channels between DLE clients cannot be
reestablished automatically. The symptoms of this is that there does not seem to be
anything wrong with the node judging from the DTM Links page on its neighbors, but it is
impossible to reach the node via DLE from some node(s). The easiest way to fix this
situation is to force the DLE server that the failing node is attached to re-establish the
channel to all the DLE clients. This is done from the page for the In-band server (Control
network->In-band servers, click on the relevant server id, e.g. dles0). On that page, click on
the connection id of the only entry under the heading “Originating client connections” and
then click Re-connect channel on the resulting page. This forces the DLE server to re-
establish the channel to all DLE clients.

17 Connection and channel
lists
17.1 Overview
In the web interface, information about originating and terminating connections is
available, as well as information about originating, terminating and pass-through channels.
These listings are informational only.
Figure 408. List of originating connections
Figure 409. List of terminating connections
Element Manager User's Manual Connection and channel lists • 371

Figure 410. List of channels to, from and via the node
Figure 411. List of data statistics
Selecting All connections, Statistics provides data statistics of all connections since the last
reset. Furthermore, on the data statistics page information about errors (error statistics) is
also retrievable

Figure 412. List of error statistics

18 Source Routing
When establishing a connection between two (or more for multicast) endpoints at the rim of
the network, it is usually not important to know exactly which path the connection takes
through the network.
The default routing method is therefore to let the network itself decide the best (shortest and
most efficient on transmission resources) path via hop-by-hop routing.
The alternative routing method is to define precisely the path in the network that should be
used, from the source to the destination. Optionally, used interfaces can also be defined.
Such routes are defined in the source node and are called source routes.
The obvious usage for source routes are 1+1 protection, where it is essential that a single
network fault does not take down both the primary route and the backup route
simultaneously. Other reasons could be network operator preferences or preparations for
network maintenance.
18.1 Loose and strict source-routes

There are two different types of source routes, strict and loose. A strict source defines all
intermediate nodes between the source and the destination. Note that neither the source
node nor the destination node should be included. Optionally, the interfaces in the nodes
(including the source node) can also be specified.
For a loose source route, only nodes that are required to be passed are specified; the path
between the specified nodes is found via hop-by-hop routing (i.e. by DRP).
To define a source route that only uses DRP (a contradiction in terms), a loose source route
without any specified nodes should be defined. Such a route can be (and typically is) used
as a last alternative for services if all specified source routes are non-usable.
Source-routes are configured in two steps. The first step is to create a source-route in the
source node and give it a descriptive name. The second step is to configure a channel to use
the specified source-route.
18.1.1 Optional interface specification

Sometimes there are several trunks available between two nodes and it is of interest to
specify which trunk is used by a source route. This is made with a specification after the
node specification, but on the same line for intermediate nodes. On the source node itself it
is made in a separate box (Outgoing interface). The interface nomenclature is the regular
for the nodes, described in the Chapter Key concepts.
Element Manager User's Manual Source Routing • 374

Figure 413. A source-route with explicit interface specifications
18.1.2 Deleting a source-route

Before you can delete a source-route entry, you must make sure that the source-route is not
used by any TTP. This is easy to check by clicking on the link Used by in the page
describing the path for the source-route. If you try to delete a source-route that is currently
in use, the node will return an error message and refuse to delete it.
18.2 Example of how to define source routes

Consider the network below. We want to establish a 1+1-protected channel from node
iov072 to node iov101. The first connection, Far-route-to-iov101, passes through nodes
iov137, iov136 and iov102. The second channel passes through nodes iov136 only.
Figure 414. Example network to illustrate source routing. The two source routes are Far-
route-to-iov101 and Close-route-to-iov101.

First, we need to define the source routes in iov072. We force the connections to use the
desired paths through the network with two different source-routes. Both of these source-
routes are “strict”, since we specify all nodes on the path from the source to the destination.
The interfaces that we are using in the example are optional.
To define the source routes, follow the link All connections → Source routes in web
interface of node 1.
Each source-route is specified as a list of all the nodes that the source-route passes through.
Each node is written on a separate line and it can be represented either by its node name (if
it has been configured in the hostname list under DTM → Hostnames) or by its DTM
address directly.
Figure 415. Specification of the first source route
Figure 416. Specification of the second source route


Finally, we define a loose source route without any nodes. This is needed later if we want to
combine source routes and DRP.
Figure 417. Definition of a loose source route without intermediate nodes. This definition
is needed if we want to use DRP as a last resort.
It is also possible to view, edit and delete specific source routes from the link All
connections → Source routes. Click on the Id number of the specific link, do the needed
changes and click on ‘Ok, ‘Apply’ or ’Delete’ as appropriate.
An alternative is to use loose source routes. In this case, only some intermediate nodes are
included in the source route definition and the rest of the route is completed with DRP.
Figure 418. Definition of a loose-far-route-to-iov101.

In the same way, a loose version of Close-route-to-iov101 can be defined.
Figure 419. Definition of a loose version of close-route-to-iov101.
18.3 Using source routes

The source routes are used when all types of channels are set up, to get control of traffic
routing in the network. The alternative to using source routes is to use DTM Routing
Protocol (DRP) and let the network do the routing.
At a later stage, if it is decided that certain services need protection, the two streams that
protect each other must traverse the network along different routes (otherwise, there is no
protection). The channels that those services use may be rerouted with source routes at this
point.
In general, it is good practice not to mix source routes and DRP. If source routes are used,
the operator wants to control the traffic pattern in the network. In this case, partially using
DRP removes such control. For this reason, when source routes are used, the default is not
to use DRP in case none of the (maximum three) defined source routes can be used. If the
operator still wants to use DRP as a last resort, a loose source route with no defined
interface or nodes acts like DRP. This is the solution needed in this case.

19 Loopback
19.1 General
Loopback is a function that makes it possible to loop the incoming signal on an interface
(Rx port) to the outgoing port on the same interface (Tx port) or to loop the signal destined
for the outgoing Tx port on an interface back to the Rx port on the same interface. The first
type of loopback is called line loopback and the second type DTM loopback in this
document, as well as in the web interface of the Nimbra nodes.
19.1.1 Line loopback

Line loopback is illustrated below. It is currently implemented explicitly on the ASI
Transport Access Module for Nimbra One and 300 (NPS0004-3001, NPS0004-X001) as
well as on the fixed interfaces of Nimbra 340.
Interface in line loop mode
Nimbra node
Figure 420. Schematic illustration of line loopback.
To explicitly configure the interface in line loopback mode, proceed as follows:

Go to the web page ITS → Interfaces → Specific interface, like asi-3:1. In this case, a
Nimbra 340 with fixed interfaces is used as an example.
The following web page should then be opened:
Element Manager User's Manual Loopback • 379

Figure 421. Configuration of line loopback on a fixed interface in Nimbra 340.
To configure the interface in line loopback mode, set the value of the parameter Loopback
to Line from the drop-down menu and click on ‘Apply’ or ‘OK’. The signal reaching the
Rx port on the interface should now be directly returned to the Tx port, in addition to being
sent along the regular path of an incoming signal.
In addition to the Loopback parameter, there are two more parameters to configure.
Suppress alarms can be set to suppress alarms, either ‘none’ (default), ‘all’ or ‘warning’.
‘All’ suppresses all alarms on the interface and warning suppresses all alarms with severity
warning. The last parameter is ‘Output action on signal fail’ has values ‘None’ and ‘Mute’.
If set to ‘Mute’, the failed signal muted (i.e. shut down) on the output access interface.
Muting may speed up fail-over switching time when using external fail-over switches. If set
to ‘None’, different actions are taken depending on service type.
Table for ‘output action on signal fail’ is shown below.


19.1.2 DTM Loopback
DTM loopback is a way to send a signal, destined for a Tx interface, back to the path of the
Rx signal on the very same interface. The signal is split at the interface and sent out on the
Tx interface as well as being looped back. To configure the fixed ASI port of a Nimbra 340
or the ASI port of the ASI Transport Access Module for Nimbra One and 300 (NPS0004-
3001, NPS0004-X001) in this manner, set the parameter Loopback to DTM.
Interface in DTM loopback mode
Nimbra node
Figure 423. DTM loopback mode. The signal is copied to the Rx port on the same interface
before being sent out on the Tx port.
Figure 424. Configuration of DTM loopback on a fixed interface in Nimbra 340.
19.2 Behaviorally equivalent configurations


Strict implementation of DTM and line loopback, with a loop very close to the actual
interface, is only found in the ASI Transport Module and the ASI ports of Nimbra 300.
However, an equivalent system behavior can be configured in some other ways in other
Nimbra products.
19.2.1 Loopback from the line side in 8 x ASI Transport

Module for Nimbra One/300
In 8 x ASI Transport Module, the monitoring port (the ninth port) can be used for loopback.
In this case, the monitor port copies the incoming signal on a port and sends the copy back
towards the line.
The loopback is set up by creating an ITS from one node to another. In our case, it is made
between iov101 and iov102. The signal is sent from iov102 to iov101, where the signal
received on asi-1:1 is sent to the monitor interface (i.e. returned to the line side).
The monitor port on the module in iov101 is set to listen to this local interface (asi-1:1),
which is used as an Rx port. To configure the monitor port, select Interfaces from the ITS
link after the ITS unicast service is set up between iov102 and iov101. The ITS unicast is
configured as a regular ITS unicast. If in doubt, see the specific description of ITS
configuration.
Select interface asi-8:1 to be monitored and connect the return cable to the external ASI
player. The ASI signal now enters the module on interface asi-1:1 and leaves the module on
the monitor interface. The line loopback is complete.
Figure 425. Configuration of the monitor interface.
The front panel selection button makes it possible to disable the output directly from the
hardware or to toggle the interface monitored (Each press on the button moves the selected
monitor interface in the cyclic sequence disabled → asi-x:1 → asi-x:2→ asi-x:3→ asi-x:4
→ asi-x:5→ asi-x:6→ asi-x:7→ asi-x:8→ disabled).
Configuration of DTM side loopback is made in an analogous fashion as for the 8 x Video
Access Module for Nimbra 600 described below.

19.2.2 Loopback from the line side in Video Access Modules
for Nimbra 600
In one of the multiple Video Access Modules compatible with GX4.11, one of the
interfaces can be used as a monitor port and configured in the same manner as the 8 x ASI
Transport Module for Nimbra One/300 described in the previous section. If configured in
this way, the physical port will be busy in this configuration and one less interface is
available for active signals.
First, an ITS unicast is defined. Another port is selected as monitor port from the ITS →
Interface link. The original port is selected as ‘Interface to monitor’. The direction of the
original signal also has to be configured, but the ‘Enable front-panel selection button’ is not
relevant as the button is lacking.
After configuration, select ‘OK’ or ‘Apply’ and the configuration is made.
Figure 426. Configuration of line type loopback on an 8 x Video Access Module on

Nimbra 680. Interface asi/sdi-7:2 is monitored in the out direction.
19.2.3 Loopback from the DTM side in Video Access Modules

for Nimbra 600
In order to configure a module for a DTM type of loopback, the interface already
configured as an end point of the ITS unicast can be used as an originating interface of
another ITS unicast. In this manner, the outgoing signal is both sent out from the interface
towards the line and returned towards the DTM side and the terminating interface of the
second ITS unicast. The principle is illustrated below.

Interface terminating one ITS
unicast and originating a second
First ITS unicast
Second ITS un
icast
Nimbra node A
Nimbra node B
Figure 427. Loopback from the DTM side in 8 x Video Access Module for Nimbra 680.
To configure the output interface for usage as source for another channel, Loopback must
be configured as DTM.
Figure 428. In order to set up the output interface to also be used as an input interface
(associated with another source TTP), Loopback must be set to ‘DTM’.

The second ITS service is configured as a regular ITS service, with source TTP tied to the
interface set to DTM loopback mode.

20 Redundancy for Nimbra
600
20.1 General
Redundancy is available with the Nimbra 600 Series and software NimOS GX 4.1.0 and
later versions. In order to keep the node operating normally or with a minimal interruption
upon module failure or degradation, Node Controllers and Switch Modules can be
duplicated. A failure of an active module causes an automatic switchover to a standby
module with minimal or no loss of traffic. In order to understand how the duplicated
modules operate, three module specific state variables (AdminStatus, OperStatus and
RedundancyRole) are important and described.
AdminStatus is set by the user to either Up or Down on each module. Down implies that
the module is not intended to take an active role as Node Controller or Switch Module.
OperStatus can be one of Up, Degraded, Starting, down or Absent. OperStatus Up means
that the module is working properly. Note that this does not imply that the module is active,
only that it may be. State variable RedundancyRole (see below) determines if it actually is.
OperStatus Degraded means that an error has been detected on the module, but it may be
able to function anyway. Starting (a transient state) means that the module is starting up.
Down means that the administrative status for the module is set to Down, or that the
module has suffered a serious failure and cannot take over control of the node. Absent
means that there is no module physically present.
RedundancyRole can be one of Active, Standby or None. Active means that the module is
operational. Only one of the two duplicated modules can be active at a given time. Standby
means that the module is prepared to immediately take over the critical tasks and become
active. None indicate that the module is unable to take over as active for the moment.
LEDs on the module front display current status of OperStatus (Status LED) and
RedundancyRole (Redundancy LED). A green Status LED indicate operStatus ‘Up’ and a
green Redundancy LED indicate RedundancyRole ‘Active’.
Figure 429. Node controller for Nimbra 600.
Another state variable, nodeStatus, is tied to the node, not individual modules. Normally, it
has value ‘Up’. In case persistent channels are set up and the Node Controller reboots for
some reason, the persistent channels are kept and the nodeStatus variable takes the value
NoControl. No traffic interruption is seen on these persistent channels during the reboot,
but the Node Controller lacks proper control of node hardware afterwards. In order to
Element Manager User's Manual Redundancy for Nimbra 600 • 386

complete the reset, nodeStatus has to be set to Up by the user. At this point, traffic
disturbance follows on the persistent channels.
20.2 Node Controller redundancy

The key idea in order to have a properly working node at all times is to replicate (copy) any
changes in software or configuration on the active Node Controller as soon as they occur to
the other Node Controller. In this manner, the standby Node Controller always has the
latest software and configuration and is ready to take over.
The replication procedure is initiated by the active Node Controller. It updates software and
configuration on the standby Node Controller to match its own settings. After successful
completion of the replication procedure, the Standby Node Controller reads some necessary
information from the new registry file but is not rebooted.
Replication takes place when the Node Controller is promoted to active or when the state
variable OperStatus on the other Node Controller is changed to Up or Degraded.
Replication also takes place when software has been upgraded or the configuration has
changed on the active Node Controller. When software has been upgraded, the standby
node controller is always rebooted.
Upon failure or restart of the active Node Controller, the standby Node Controller takes
over as active Node Controller (i.e. its RedundancyRole state variable changes from
Standby to Active) immediately if the value of its OperStatus state variable is Up. In case
this value is Degraded, the standby Node Controller waits for the (previously) active Node
Controller to restart before taking any actions. If the OperStatus state variable of the latter
Node Controller is Up after restart, it becomes active again and continues to run the node
and the standby Node Controller remains standby. If the (previously) active Node
Controller comes up with an OperStatus state variable value of Degraded, Down or Absent
after reboot, the Standby node-controller is promoted to Active, even though its OperState
state variable value is Degraded. It is not recommended to run the node in this way for any
prolonged period of time.
When the operator restarts the node, both Node Controllers are restarted. The Node
Controller that is fastest to boot becomes the active one. Typically, the standby node
controller is faster to reboot as it has fewer running processed that needs to be taken down
before it can reboot.
In order to maintain changes in the Standby Node Controller’s state variable AdminStatus
upon soft or hard reboot, it is essential to save any altered configuration on the active Node
Controller. Saving the configuration copies the (saved) configuration to the Standby Node
Controller automatically. Replicaton takes place directly after the configuration is saved.
The node should be configured from the serial port of the active Node Controller. The
active Node Controller is identified from its green Redundancy LED, whereas the
Redundancy LED of a standby Node Controller is amber. Once the initial IP configuration
has been made, it is suggested that an Ethernet switch be introduced before the two Node
Controllers. In this way, the user sees the node as one entity with one IP address
irrespective of which Node Controller is active.

Figure 430. Hardware configuration of redundant Node Controllers and Switch Modules.
It should be observed that the Node IP address is associated with different hardware
(different MAC addresses) depending on which Node Controller is active.
In the web based user interface, it looks like the user manages the node and not the node
controllers. The user needs not be concerned about which Node Controller is active, only to
manage the Node. The Node Controllers manage the node collectively.
20.3 Switch Module redundancy

From a user perspective, switch mode redundancy works transparently. Plug in one Switch
Module and there is no redundancy; plug in two Switch Modules and there is redundancy.
There is no problem to power the switch with dual Switch Modules mounted; in fact that is
the suggested way to work if redundancy is planned from the start.
Internally, as long as the active Switch Module has OperStatus Up, it continues to be active.
If its OperStatus value for some reason changes to Degraded, negotiation with the standby
Switch Module begins and as a result its RedundancyRole state variable changes to Standby
and the RedundancyRole variable of the previously Standby Switch Module changes to
Active.
The Node takes its synchronization signal from the active switch module. For this reason,
an external synchronization signal has to be split before the interface to the switch modules.
The signal is distributed to the modules. Make sure the connecting cables from the splitter
to the switch modules are as identical as possible. In this manner it is ascertained that the
same synchronization signal reaches both Switch Modules and it does not matter which
module is active.
On the Status/Equipment page in the web interface, the active module can be found (shown
below).

Figure 431. Status/Equipment web page of a system with duplicated Node Controllers and
Switch Modules.

21 Module installation
21.1 General
There are a few things to consider when modules are added to a node installed in a network
in full operation. It is critical to have complete nodes aligned to a system release software
and the delivered new module(s) may have different system release software than the node.
In order to make sure that the system release software running on the node is downloaded
to the new module and the module is properly aligned, it is very important to follow the
procedure described in this chapter when installing new or replacement modules.
The system release software should be stored in a so called repository on a computer or
server with connectivity to the Nimbra node where the new module is installed. The
repository is a collection of files stored in a directory with the name of the system release.
An example is shown below:
Element Manager User's Manual Module installation • 390

Figure 432. The repository, here for GX4.6.0.0, is shown.
21.2 Differences Nimbra One/300 vs Nimbra 600

Implementation of administrative status is different on Nimbra One/300 and Nimbra 600. If
a module has administrative status set to ‘Down’ on a Nimbra One/300 node, power is shut
down to the module. Hence, the module is incommunicado and no software realignment is
possible. For this reason, all software realignment on Nimbra One/300 must be made with
admin status ‘Up’. Otherwise, the procedure outlined below can be followed. Make sure to
click on the ‘Bring new image into service’ at the end of the procedure and ‘OK’ in the
confirmation window irrespective of the misleading confirmation window.
The procedure below describes how to realign a Nimbra 600 node

21.3 Addition of new modules to existing nodes
Before new modules are inserted in existing nodes, it is crucial that the administrative status
of the slot position is set to down in the Nimbra 600. If it is not, the module comes up
directly. This may cause various problems if the system release software is not aligned.
Connect to the node via the web interface. Log in to the node and follow the link System →
Equipment. Click on the interface link (IF1 – IF8) of the slot(s), which will receive the new
module(s). In the drop-down menu, select Down as value for Administrative status, then
click the ‘Apply’ button.
Figure 433. Status equipment page, with administrative status of all interface slots set to
up, except slot IF8.
After the administrative status of the slot/module has been set to down, the new module
may be inserted in the slot. While the administrative status is still down, alignment of the
system release software of the node and the module is made.

Figure 434. Status equipment page, with administrative status of all interface slots set to
up, except slot IF8 which is intended for the new module.
To check if the new module already is aligned with the rest of the node, click on the link
Maintenance → Software. If the system alignment status parameter has value ‘full’, no
alignment is needed. In this case, all that remain is to change the value of the administrative
status parameter to ‘Up’ on the new interface. If this is not the case, alignment is needed.

Figure 435. A node with full system alignment status after the new module is inserted does
not need additional software alignment. All that remain is to set the
administrative status of the new module to ‘Up’.
Figure 436. A node with other system alignment status than ‘full’ needs realignment
between the new module and the node. This process is described below.

In order to align node and module system releases, the repository of the node system
release software is stored on an http or ftp server. Follow the link Maintenance → Software
and click on the button ‘Install image’. The page below appears on the screen.
Figure 437. Install image web page.
Type the URL to the http or ftp server. The syntax below gives two examples, one for http
and one for an ftp server.
Figure 438. Example of an http server. The repository of system release software
GX4.10.0.1 is found under directory official/GX4.10.0.1/GX4.10.0.1/ of the
http server.

Figure 439. Example of an ftp server, with user root and password neti. The repository of
system release software GX4.10.0.1 is found under directory /repos of the ftp
server.
Clicking on the install button starts the alignment process to the repository system release
software version, i.e. the installation of the system release software to the entire node
including the parts with administrative status down. After a brief interruption, a progress
report is generated.
Figure 440. Progress report of installation.
When the installation is complete, the web interface communicates this.

Figure 441. Message of complete installation.
For details, the installation log can be viewed.

Click on the link Maintenance → Software. If alignment exists, the system alignment status
parameter has value full. In this case, just change the administrative status of the module to
‘Up’. Then the system is aligned and operational.
Otherwise, the inserted module must have its ipmc software restarted (this software is never
automatically rebooted). To manually reset this process, follow the link Maintenance →
Software. Click on the ‘Bring installed image into service’ button.
If this step is required, click on the ‘Bring installed image into service’ after saving the
configuration. A general confirmation window pops up, asking if the user wants to restart
the node controller. However, the installation software ensures that only software that needs
to be restarted is restarted. If this procedure has been followed, there is no need for a restart
of the node controller and no such restart will occur. In order to align software,
confirmation must be given in the confirmation window (i.e. the question must be answered
with ‘OK’, not ‘Cancel’).
After this set is completed, just set the administrative status to ‘Up’ and the module is
operational and the node is fully aligned.

22 Up- and Downgrading
22.1 General
Changing system release software, i.e. a defined collection of soft- and firmware modules,
can be made to a higher or lower system release. In addition, an enhanced
software/firmware feature, requiring a separate software license, can be added without
modifying the system release.
In this chapter, the regular up/downgrading procedure is described first. Addition of
enhanced features without altering system release is described later in this chapter, on a
case-by-case basis. Currently, there are a many different enhanced features; addition of
FEC on a 4 x OC-3/STM-1 Trunk Module; change of trunk speed on Nimbra
310/320/360/380; change of mode on the DS3/E3 Trunk/Access Module; change of
firmware (ASI/AES/MADI) on ASI/AES Video Access Module; change of firmware
(Encoder/Neutral/Decoder) on JPEG 2000 Video Access Module and change of firmware
(Regular ETS, ETS 1+1) on 8 x Gigabit Ethernet Access Module.
The regular up/downgrading procedure is described on a node basis, from the web
interface. Changing the system release software in a Nimbra network is conveniently
handled by the Nimbra Vision software. Using this software, checks are made that proper
software and firmware are loaded in all places where they are needed.
22.2 Up/downgrading GX version from web GUI

In GX4.1.2 and all later system releases, software and embedded software modules (i.e.
application packages) are delivered in a release “repository” file. This file is a compressed
file with a directory and an internal file structure. The file is intended to be unpacked on a
file server. The unpacked repository, which is what we in this text refer to as repository, is a
flat file structure with a directory that carries the name of the repository. All files belonging
to the repository are located directly under the (repository) directory.
The node has to be able to reach the file server with http or ftp in order to be upgraded.
22.2.1 Saving the current configuration

Before any up- or downgrade is started, the current configuration should be saved and
preferably labeled with current system release version. If a downgrade is ever needed, a
saved configuration file from relevant previous release should be transferred to the node
before the downgrade is carried out. A configuration name of ‘Config_for_GX4.11.0.0’ or
similar (for the appropriate system release) is suitable to keep track of the system release
under which the configuration file was generated.
During the upgrade process, the version of the configuration (not identical to the system
release software) is read by the system. If the configuration is “from the future”, i.e. newer
than the system release software version, the configuration is skipped and the reboot is
attempted with the next configuration file in the registry list. If all configurations are “from
the future”, i.e. a downgrade is made on the node without a usable configuration, the node
reboots without configuration, i.e. without IP settings, and the only way to communicate
with the node is through the serial interface (console port).
Element Manager User's Manual Up- and Downgrading • 398

In the table below, configuration version numbers and system release software are
specified.
System release software Configuration version number
GX4.4 4
GX4.5 5
GX4.7 5
GX4.8 5
GX4.9.0.0 5
GX4.9.0.1 6
GX4.10 6
GX4.11 6
GX4.12 6
Figure 442. System release software and configuration version numbers
For a configuration file with unknown version number, the easiest way to find out is to
open the file in e.g. WordPad. The version number is displayed at the very top of the file.
Figure 443. Header for configuration file BasicConfigGX47
22.2.2 Repository
A repository is a file structure, with one directory and all files belonging to the repository
located directly in this directory. The tarred and compressed file of this structure is
sometimes also called a repository. From Net Insight support portal it is possible to
download software for different releases. In addition to the compressed repository,
compressed MIB files for the release are included in the package. The release repository
file for release GX4.10.0.2 is called “GX4.10.0.2.tgz” and analogously for other system
releases.
Unpack the .tgz file on an ftp or http server. In the example below, the “.tgz” file is
unpacked in the <target-dir> directory. The sub-directory GX4.10.0.2 is created in the
process.
On a Linux server, proceed as follows (from the directory <target-dir>)
# tar xzf GX4.10.0.2.tgz
This will unpack the GX4.11.0.0 repository to the directory
<target-dir>/GX4.10.0.2/
On a Windows server, if the tar/gzip commands are not available, the file can be unpacked
with a file decompression utility like 7-zip or Winrar. Note that WinZip does not
decompress all files correctly! For that reason it cannot be used.

The unpacked repository contains all the files that constitute the new GX release. To check
the integrity of the repository directory, go to the directory and run (Linux):
# md5sum -c md5sums
If all files are printed with an OK after the file name, the repository is correctly set-up and
ready to be used. If the checksum is not correct, the file transfer has not been successful. In
that case, don’t use the files and call Net Insight support.
Below all files belonging to repository ~/repos/GX4.10.0.2/GX4.10.0.2 are shown.
rippo:~/repos/GX4.10.0.2/GX4.10.0.2> ls –la
total 96952
drwxr-xr-x 2 gunlar users 4096 2012-08-28 11:08 ./
drwxr-xr-x 3 gunlar users 4096 2012-09-28 10:02 ../
-r--r--r-- 1 gunlar users 67317 2012-08-28 10:59 AP_install
-r--r--r-- 1 gunlar users 5412 2012-08-28 11:06 fingerprints
-r--r--r-- 1 gunlar users 3122 2012-08-28 11:08 md5sums
-r--r--r-- 1 gunlar users 511152 2012-08-27 08:18 NPM0006-0155_B3.flow
-r--r--r-- 1 gunlar users 7864588 2012-08-28 11:02 NPM0013-N101_R3.flow
-r--r--r-- 1 gunlar users 8034048 2012-08-28 11:02 NPM0013-N301_R3.flow
-r--r--r-- 1 gunlar users 76300 2012-04-13 08:50 NPM0014-N101_A10.flow
-r--r--r-- 1 gunlar users 303060 2012-08-27 08:18 NSF0010-0141_B9.flow
-r--r--r-- 1 gunlar users 511152 2012-08-27 08:18 NSF0011-0001_A36.flow
-r--r--r-- 1 gunlar users 1027760 2012-08-27 08:18 NSF0013-0001_C6.flow
-r--r--r-- 1 gunlar users 580016 2012-08-27 08:18 NSF0014-A001_A8.flow
-r--r--r-- 1 gunlar users 356484 2012-08-27 08:18 NSF0019-HD01_A28.flow
-r--r--r-- 1 gunlar users 1896780 2012-08-27 08:18 NSF0020-AEB1_A20.flow
-r--r--r-- 1 gunlar users 2149868 2012-08-27 08:18 NSF0020-SD01_A12.flow
-r--r--r-- 1 gunlar users 393764 2012-08-27 08:18 NSF0021-0360_E4.flow
-r--r--r-- 1 gunlar users 88292 2008-02-20 08:28 NSS0004-0001_1.2.2.flash
-r--r--r-- 1 gunlar users 849172 2012-04-13 09:10 NSS0006-X001_E1.flow
-r--r--r-- 1 gunlar users 3627900 2012-04-13 09:10 NSS0011-0001_R1.flow
-r--r--r-- 1 gunlar users 46008 2012-04-13 08:50 NSS0012-0001_A4.flow
-r--r--r-- 1 gunlar users 9668940 2012-08-28 11:02 NSS0013-0001_S3.flow
-r--r--r-- 1 gunlar users 13456 2012-03-26 16:06 NSS0019-APP1_G6.flow
-r--r--r-- 1 gunlar users 1268876 2012-04-13 09:10 NSX0011-0001_T1.flow
-r--r--r-- 1 gunlar users 1762124 2012-06-21 08:10 NSX0022-0001_R2.flow
-r--r--r-- 1 gunlar users 2224732 2012-06-21 08:10 NSX0027-0001_S2.flow
-r--r--r-- 1 gunlar users 3010248 2012-06-21 08:10 NSX0030-E0D0_F2.flow
-r--r--r-- 1 gunlar users 4451752 2012-06-21 08:10 NSX0030-E0D4_D2.flow
-r--r--r-- 1 gunlar users 4414920 2012-06-21 08:10 NSX0030-E4D0_D2.flow
-r--r--r-- 1 gunlar users 569480 2012-08-28 11:02 NSX0031-3602_J2.flow
-r--r--r-- 1 gunlar users 3531420 2012-08-28 11:02 NSX0031-N013_J2.flow
-r--r--r-- 1 gunlar users 1546984 2012-06-21 08:10 NSX0033-A001_C2.flow
-r--r--r-- 1 gunlar users 1527272 2012-06-21 08:10 NSX0033-E001_G2.flow
-r--r--r-- 1 gunlar users 1503144 2012-06-21 08:10 NSX0033-M001_E2.flow
-r--r--r-- 1 gunlar users 2417672 2012-08-28 11:02 NSX0034-E601_J3.flow
-r--r--r-- 1 gunlar users 1452464 2012-06-21 08:10 NSX0036-0002_C2.flow
-r--r--r-- 1 gunlar users 4631752 2012-06-21 08:10 NSX0037-0001_B2.flow
-r--r--r-- 1 gunlar users 3103400 2012-06-21 08:10 NSX0040-E0D0_B2.flow
-r--r--r-- 1 gunlar users 10951 2012-08-28 11:06 Packages.list

22.2.3 Up-/downgrading from the web GUI
To up- or downgrade the system release software on a node, start with saving the
configuration. This is good practice, as you’ll never know if you need the configuration
again, in case you need to revert after an unsuccessful installation.
This is made from web page Maintenance → Configuration and the button ‘Save
configuration’.
Figure 444. Save configuration web page.
After this step is taken, continue with web page Maintenance ՜ Software. The button
‘Install image’ takes you to a web page where you can install software from a repository
and change firmware while keeping the system release software constant.
Figure 445. Install system release software web page.
In the field for ‘Install from URL’, write the URL directly after the double slash sign. This
will assume that the repository is on an http server. In case an ftp server is used instead,
replace http with ftp and proceed the same way. The structure is of the commands are:

http://<IP of Repository server>:<Port used by http>/<Repository>
ftp://user:pass@<IP of Repository server>:<Port used by ftp>/<Repository>
If standard ports are used, they don’t need to be specified.
Figure 446. Installation from http server 10.100.0.82. Repository GX4.10.0.2 is residing on
directory /official/GX4.10.0.2.
Figure 447. Installation from ftp server 192.168.101.136 with user root/password neti.
Repository GX4.10.0.2 is residing used.
The web page checks the new release and compares it with installed hardware. All relevant
software and firmware images are retrieved from the repository and installed at appropriate
locations in the node.

After the message ‘Installation completed successfully’, proceed with clicking on the ‘OK’
button. This button takes you to the Maintenance → Software web page. To start the node
with the new software, click on the ‘Bring installed image into service’ button.
Note that the startup on new software may be service disrupting.
The procedure can just as easily be used for downgrades as for upgrades. The only thing
determining what release is installed in the node is the repository, which defines the system
release software version.
It is recommended that caution is used in downgrading GX software as testing is limited
and will continue to be so. If needed to downgrade, contact Net Insight for the availability
of repositories for older releases, or look directly in the Net Insight support portal.
22.2.4 Required intermediate system releases

This procedure described in the previous section can only be used to upgrade to system
release GX.4.1.3.5. For upgrades to higher releases (i.e. newer releases) the upgrade must
be made in multiple steps. After a successful installation of GX4.1.3.5, node install can be
used once more to install a newer system release. In this second step, a new repository must
be used. The procedure may need to be replicated several times, which is described in the
table below. Each time an upgrade is made, the configuration file should be saved and the
node rebooted with the intermediate system release software, before proceeding to the next
system release software in the sequence.
When upgrading to a version, always upgrade to the last available patch, unless there is a
specific reason to the contrary.

Current system Target Required intermediate system
release system releases
release
GX4.1.2.0 - GX4.5.0.2 GX4.1.3.5
GX4.1.2.2 GX4.6.0.3 GX4.3.0.4
GX4.1.3.0 - GX4.7.0.5 GX4.4.0.7
GX4.1.3.4 GX4.8.0.4 GX4.7.0.5
GX4.9.0.2
GX4.10.0.2 GX4.9.0.2
GX4.12.0.0
GX4.1.3.5 GX4.5.0.2 GX4.3.0.4
GX4.1.4.1 GX4.6.0.3 GX4.4.0.7
GX4.1.4.5 GX4.7.0.5
GX4.2.0.1 GX4.8.0.4 GX4.7.0.5
GX4.2.0.2 GX4.9.0.2
GX4.2.0.4 - GX4.10.0.2 GX4.9.0.2
GX4.2.0.7 GX4.12.0.0
GX4.3.0.0
GX4.3.0.1
GX4.3.0.3
GX4.3.0.4 GX4.5.0.2 GX4.4.0.7
GX4.4.0.1 – GX4.6.0.3
GX4.4.0.6 GX4.7.0.5
GX4.8.0.4 GX4.7.0.5
GX4.9.0.2
GX4.10.0.2 GX4.9.0.2
GX4.12.0.0
GX4.4.0.7 - GX4.5.0.2 No intermediate system releases
GX4.7.0.5 GX4.6.0.3 required
GX4.7.0.5
GX4.8.0.4 GX4.7.0.5
GX4.9.0.2
GX4.10.0.2 GX4.9.0.2
GX4.12.0.0
GX4.8.0.3 - GX4.8.0.4 No intermediate system releases
GX4.9.0.2 GX4.9.0.2 required
GX4.10.0.2 GX4.9.0.2
GX4.12.0.0
Figure 448. Table for required intermediate system releases for upgrading.
An upgrade must go through all intermediate releases, stated in the rightmost column. For
example, upgrading from GX4.2.0.6 (between GX4.2.0.4 and GX4.2.0.7) to GX4.12.0.0
must go through GX4.3.0.4, GX4.4.0.7, GX4.7.0.5 and GX4.9.0.2.

Current system Target Required intermediate system
release system releases
release
GX4.1.3.5 GX4.5.0.2 GX4.3.0.4
GX4.1.4.1 GX4.6.0.3 - GX4.4.0.7
GX4.1.4.5 GX4.7.0.5 -
GX4.2.0.1
GX4.2.0.2 GX4.8.0.3 - GX4.7.0.5
GX4.2.0.4 - GX4.9.0.2
GX4.2.0.7 GX4.10.0.2 GX4.9.0.2
GX4.3.0.0 GX4.1
GX4.12.0.0
GX4.3.0.1
GX4.3.0.3
Figure 449. Explanation how to read the previous table; in this case how to upgrade from
version GX4.2.0.6 to GX4.12.0.0.
GX4.1 All the emboldened system releases are
required intermediate system releases.
For upgrades from versions prior to GX4.1.

GX4.1.2 (Nimbra 600 series) or GX3.3.3.0
X3.3.3.0 (Nimbra
One/300 series), this procedure does not work. In case you have such needs, please contact
Net Insight.
22.3 Addition of functional enhancement

22.3.1 General
All functional enhancements described in this section of Element Manager require separate
software licenses.
Note: All
ll functional enhancements described in this section require a
separate software license. This license should be obtained before
the upgrade procedure begins.
Replacement of firmware is most easily done directly from the web interface.
22.3.2 FEC to the 4 x OC

OC-3/STM-1 Trunk Module from CLI
Adding FEC to the 4 x OC
OC-3/STM-1 Trunk Module can be made from the web GUI. An
additional option, --replace
replace, tells the script that it is not a question of system upgrade but
rather an enhancement uupgrade. To indicate what interfaces are to be upgraded, the flag
–d <module #> should be used.
The syntax is (for Nimbra One and 300 nodes):

For an http-server
-d <if #> --replace

replace NSF0011-0001,NPM0006-0155
http://<IP>:<port>/
/<dir>/GX4.11.0.0
and for an ftp-server

-d <if #> --replace
replace NSF0011-0001,NPM0006-0155
ftp://usr:pass@<IP>:<Port>/<dir>/GX4.9.0.2
Example:
Figure 450. Installation of new (FEC) firmware on OC

OC-3/STM-1
1 trunk modules for
Nimbra One/300 series.
22.3.3 Changing fixed trunk interface on Nimbra

310/320/360/380
360/380
Note: This procedure should only be executed with a separate data

network. Using in
in-band DLE causes a loss of contact with the
node upon reboot of the node.
The functionality (supported trunk rate) for the fixed trunks of a Nimbra 310/320/
320/360/380
is easiest changed from the web interface. Note that changing the default setting of 4 x
STM-1/OC-33 trunks requires additional licenses
licenses,, which should be obtained before
upgrading.
Note that if time transfer is added on an IP Trunk, available in GX4.12, only one of the two
time transfer interfaces are available.
To change firmware from the web interface and use different trunk rates,, follow the link
Maintenance → Software
Software. On this page, click on the button ‘Install on-board
board image
image’.

Figure 451. Web page for replacement of the default setting on the fixed interfaces of a
Nimbra 310/320/360/380.
A new web page appears; Maintenance → Software → Install. Here a repository with the
required files is needed; it is possible to install trunk firmware OC-3/STM-1, OC-12/STM-
4, OC-48/STM-16 or IP-Trunk firmware. Installation of IP-trunk firmware requires version
B of Nimbra 360 or Nimbra 310/320/380.
Figure 452. Selection of fixed trunk firmware on a Nimbra 310/320/360/380.
Select the required firmware and click on install. To later activate the new firmware, save
the configuration and go back to Maintenance → Software. This step is needed as the
change of firmware automatically is a change of the configuration. Clicking on ‘Bring
installed image into service’ makes the new firmware with new rates active. Before the
node is restarted, a warning pop-up shows up.

Figure 453. Activation of the new firmware is made by clicking on the ‘Bring installed
image into service’ button.
Figure 454. Warning ppop-up after firmware upgrade of trunks in Nimbra 310/320/
320/360/380.
Observe that in all cases when the firmware has been replaced, the old DTM interfaces
remain with operational status absent. If the user doesn’t intend to go back to previous
interface rates,, these interfaces can (and it is recommended that they) be deleted.
22.3.4 Setting modes for 4 x DS3/E3 Trunk/Access Modules

network. Using in
node uupon reboot of the node.
The 4 x DS3/E3 trunk/access module for Nimbra One/300 can be set to operate either in
trunk or in access configuration. The hardware is common; the difference in the two cases
is the firmware placed on the module. It is fairly easy to reconfigure the module and change
trunk mode operation to the access mode operation and vice verse. Firmware for trunk
mode is called NSF0014
NSF0014-0001 and firmware for access mode is NSF0014-A001 A001.

To install the access mode firmware on a module configured as a trunk module, go to the
web page for Maintenance → Software. As described with earlier firmware upgrades, a
configuration should be saved before the upgrade.
Figure 455. Installation of access firmware on a 4 x DS3/E3 module running trunk

firmware starts with the ‘Install image’.
Figure 456. Installation of new (access) firmware on the 4xDS3/E3 Trunk/Access module.
To change a module in trunk mode to operate in access mode, fill out the field with
-d <slot #> --replace NSF0014-0001,NSF0014-A001 http://<IP>:<Port>/<repos>
To do the reverse:
-d <slot #> --replace NSF0014-A001,NSF0014-0001 http://<IP>:<Port>/<repos>
Of course, both actions can be made from an ftp server rather than an http server.

When the download is finished, save the configuration once more and use the button ‘Bring
installed image into service’. These actions are detailed previously.
Ann Access mode feature license is needed to enable/use a 4 x DS3/E3 Trunk/Access
Module with access functionality if it has been purchased for trunk use, and that a Trunk
mode feature license is needed to enable/use a 4 x DS3/E3 Access/Trunk Module with
trunk functionality if it has been purchased for access use.
22.3.5 Changing firmware on JPEG2000 Video Access

Modules by CLI

network. Using in
node upon reboot of the node.
From GX4.12 and later releases, tthere is one version of JPEG 2000 Video
eo Access Module
v2 for Nimbra 600. The module can run different firmware, giving it different properties
like encoding, decoding and neutral
neutral, i.e without compression. The module is delivered with
neutral firmware, which support uncompressed video streams. If used for JPEG encoding, a
JPEG encoding firmware must be used
used; if used for decoding, a JPEG decoding firmware
must bee used. The available firmware modules are presented in the table below.
Module name Module Firmware Firmware Comment

product type
number
JPEG 2000 Video NPS0074- Neutral NSX0040- Support uncompressed video
Access module v2 6001 E0D0
JPEG 2000 Video NPS0074- JPEG2000 NSX0040- Support JPEG encoding and
Access module v2 6001 Encoder E4D0 uncompressed video
JPEG 2000 Video NPS0074- JPEG2000 NSX0040- Support JPEG decoding and
Access module v2 6001 Decoder E0D4 uncompressed video
Figure 457. Different firmware possible to load on JPEG 2000 Video Access module v2.
The module is inserted in a slot in the Nimbra 600 node. The slots are numbered between
IF1 and IF8 for Nimbra 680 and IF1 and IF16 for Nimbra 688. Slots for NCs are numbered
NCA and NCB, whereas slots for switch modules are numbered SWA and SWB.
The default firmware,, i.e. the firmware that is delivered on the module, is the neutral
firmware (NSX0040-E0D0
E0D0).. To change from the neutral firmware to either the encoding or
the decoding firmware from the web GUI, go to the Maintenance → Software web page.
The structure of the string to enter in the field for new software is
-d <i/f#> --replace
replace <Old FW>,<New FW> http://<IP>:<Port>/<Repos>
The type of server may also in this case be ftp rather than http.

In order to put JPEG encoding firmware on the module with default (neutral) firmware
from a repository residing on an http-server (192.168.234.99/repos), using port 9090,
follow the example below.
-d if4 --replace NSX0040-E0D0,NSX0040-E4D0 http:// 192.168.234.99:9090/repos
Other changes of firmware are made analogously. Note the absence of spaces between the
two NSF product numbers. In this case, the IF must be included before the slot number.
-d if3 --replace NSX0040-E0D0,NSX0040-E4D0 http://192.168.234.99:9090/repos
In order to put JPEG decoding firmware on the module from a repository residing on an ftp
server (iov105/repos) and using port 222, run the script with options defined below.
-d if3 --replace NSX0040-E0D0,NSX0040-E0D4 ftp://user:pass@iov105:222/repos
Changing from encoding to decoding JPEG firmware can be done directly in a similar way.
Here it is illustrated from the http-server.
By extension, changing from JPEG decoder to JPEG encoder the URL field becomes:
Note that it is important that the command is written on one line and that no space in
inserted before or after the comma between the firmware versions.
22.3.5.1 Module restart

In order for the new firmware to become active, the module must be restarted. This can be
done from the web interface, from the Status → Equipment page. Select the module and
toggle the administrative status of the module, i.e. set the administrative status first to
‘Down’ and then to ‘Up’. This procedure causes the module to restart with the new
firmware.

Figure 458. Toggling the administrative status, i.e. setting it first to ‘Down’ and then to
‘Up’ is a simple way to restart a module and run the new firmware.
22.3.5.2 Limitations and licenses

Using either JPEG2000 encoding or decoding firmware requires JPEG2000 feature
licenses. In GX4.12,, one feature license is re
required
quired to encode/decode one stream of SD
SD-
SDI. To encode/decode HD HD-SDI
SDI two licenses are required and to encode/decode 3G-SDI
3G
four licenses are required. Up to eight licenses can be used per module, i.e. at most four
HD-SDI
SDI streams can be compressed on a mo module.
dule. The remaining four interfaces can be
used for uncompressed streams.
This release supports JPEG2000 compressed 3G-SDI,
3G HD-SDI and SD-SDI,
SDI, together with
uncompressed 3G-SDI, SDI, HD-SDI,
HD SD-SDI
SDI or ASI. Stream selection is made per interface,
i.e. different stream types can be encoded or decoded on a single module.
22.3.6 Changing firmware on 8 x ASI/AES Access Module

network. Using in
node upon reboot of tthe node.
8 x ASI/AES Access Module for Nimbra 600 can run on different firmware, giving it
different properties. The module is delivered with ASI firmware, supporting up to eight ASI
video streams. In addition, there is an AES version (supports 8 x AES audio streams) and a
MADI version (supporting a MADI multiplexed audio stream).
The available firmware modules are presented in the table below.

Firmware Firmware Comment
type
ASI NSX0033-A001 Supports up to 8 x ASI video streams

AES NSX0033-E001 Supports up to 8 x AES audio streams
MADI NSX0033-M001 Supports a multiplexed MADI audio stream
Figure 459. Different firmware possible to load on an 8 x ASI/AES Access Module.
The module is inserted in a slot in the Nimbra 600 node. The slots are numbered between
IF1 and IF8 for Nimbra 680 and IF1 and IF16 for Nimbra 688.
The default firmware on the module is the ASI firmware. To change from the ASI firmware
to either AES or MADI firmware from the web GUI, go to the web page Maintenance →
Software and use the button ‘Install image’.
In the field for new software image, write a string to specify what modules should be
affected by the change, what firmware should be removed, what firmware should be
installed and from what repository this should be done.
In order to put AES firmware on the module from a repository residing on an http-server
(192.168.234.99/repos) and using port 9090, add the following string in the URL field.
Note the absence of spaces between the two NSF product numbers.
-d if5 --replace NSX0033-A001,NSX0033-E001 http://192.168.234.99:9090/repos
In order to put MADI firmware on the module from a repository residing on an ftp server
(iov136/repos) and using port 2222, add options defined below.
-d if5 --replace NSX0033-A001,NSX0033-M001 ftp://user:pass@iov136:2222/repo
Changing from AES to MADI firmware is done in a similar way. Here it is illustrated from
the http-server.
-d if5 --replace NSX0033-E001,NSX0033-M001 http://192.168.234.99:9090/repos
By extension, changing from MADI to AES becomes:

-d if5 --replace NSX0033-M001,NSX0033-E001 http://192.168.234.99:9090/repos
22.3.6.1 Licensing requirement for ASI/AES/MADI

The 8 x ASI/AES Access Module must be ordered with firmware and by default the ASI
firmware is loaded. If the user prefers another firmware after the purchase and uses this
procedure to install it, an additional firmware license is required for the installed firmware
module.
22.3.7 Changing firmware on 8 x Gigabit Ethernet Access

Module
In order to load ETS 1+1 firmware on a Gigabit Ethernet Access Module for Nimbra 600
nodes, it is simple to use the web GUI. Go to the Maintenance → Software web page and
click on the ‘Install image’ button.
Figure 460. Replacing regular Gigabit Ethernet Access Module firmware with ETS 1+1.
The firmware to be replaced is NSX0022-0001 and the replacement firmware with ETS
1+1 functionality is NSX0022-ET11. Specifically, if the module is installed in slot number
one, the extended URL becomes (with the same http server, port and repository as in
previous chapter):
-d if1 --replace NSX0022-0001,NSX0022-ET11 http://192.168.234.99:9090/repos
For the reverse process, replacing 1+1 firmware with regular ETS firmware, the order of
the arguments are swapped, i.e
-d if1 --replace NSX0022-ET11,NSX0022-0001 http://192.168.234.99:9090/repos
Usage of ftp, instead of http, is also supported, exactly as described in the other sections in
this chapter.

It is important that the command is written on one line and that no space in inserted before
or after the comma between the firmware versions.
22.3.7.1 License
Note that in order to use ETS 1+1, one or more additional feature licenses must be
purchased, irrespective of the need for firmware swap on the module.
22.3.8 Module restart

In order for the new firmware to become active, the module must be restarted. This can be
done from the web interface, from the Status → Equipment page. Select the module and
toggle the administrative status of the module, i.e. set the administrative status first to
‘Down’ and then to ‘Up’. This procedure causes the module to restart with the new
firmware.
Figure 461. Toggling the administrative status, i.e. setting it first to ‘Down’ and then to
‘Up’ is a way to restart a module and run the new firmware.

23 License information
23.1 General
Some elements of this product include third party software released under open source
licenses.
23.2 GNU General Public license GPLv2

Elements that include GPL source code are released under GPLv2. If you would like a copy
of the source code for those elements for the cost of preparing it, please send a mail to
gpl@netinsight.net.
For GNU General Purpose License, version 2, this is the full license text
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.

51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
Everyone is permitted to copy and distribute verbatim copies of this

license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By
contrast, the GNU General Public License is intended to guarantee your freedom to share and
change free software--to make sure the software is free for all its users. This General Public
License applies to most of the Free Software Foundation's software and to any other program
whose authors commit to using it. (Some other Free Software Foundation software is covered by
the GNU Lesser General Public License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public
Licenses are designed to make sure that you have the freedom to distribute copies of free
software (and charge for this service if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new free programs; and that you
know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or
to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if
you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give
the recipients all the rights that you have. You must make sure that they, too, receive or can get
the source code. And you must show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license
which gives you legal permission to copy, distribute and/or modify the software.
Element Manager User's Manual License information • 416

Also, for each author's protection and ours, we want to make certain that everyone understands
that there is no warranty for this free software. If the software is modified by someone else and
passed on, we want its recipients to know that what they have is not the original, so that any
problems introduced by others will not reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the
danger that redistributors of a free program will individually obtain patent licenses, in effect
making the program proprietary. To prevent this, we have made it clear that any patent must be
licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND

MODIFICATION
0. This License applies to any program or other work which contains a notice placed by the
copyright holder saying it may be distributed under the terms of this General Public License. The
"Program", below, refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law: that is to say, a work
containing the Program or a portion of it, either verbatim or with modifications and/or translated
into another language. (Hereinafter, translation is included without limitation in the term
"modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not covered by this License; they
are outside its scope. The act of running the Program is not restricted, and the output from the
Program is covered only if its contents constitute a work based on the Program (independent of
having been made by running the Program). Whether that is true depends on what the Program
does.
1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in
any medium, provided that you conspicuously and appropriately publish on each copy an
appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to
this License and to the absence of any warranty; and give any other recipients of the Program a
copy of this License along with the Program.
You may charge a fee for the physical act of transferring a copy, and you may at your option
offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion of it, thus forming a work
based on the Program, and copy and distribute such modifications or work under the terms of
Section 1 above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices stating that you changed the files
and the date of any change.
b) You must cause any work that you distribute or publish, that in whole or in part contains or is
derived from the Program or any part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively when run, you must cause it,
when started running for such interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a notice that there is no warranty (or
else, saying that you provide a warranty) and that users may redistribute the program under these
conditions, and telling the user how to view a copy of this License. (Exception: if the Program
itself is interactive but does not normally print such an announcement, your work based on the
Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If identifiable sections of that work
are not derived from the Program, and can be reasonably considered independent and separate
works in themselves, then this License, and its terms, do not apply to those sections when you
distribute them as separate works. But when you distribute the same sections as part of a whole
which is a work based on the Program, the distribution of the whole must be on the terms of this

License, whose permissions for other licensees extend to the entire whole, and thus to each and
every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written
entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or
with a work based on the Program) on a volume of a storage or distribution medium does not
bring the other work under the scope of this License.
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object
code or executable form under the terms of Sections 1 and 2 above provided that you also do one
of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be
distributed under the terms of Sections 1 and 2 above on a medium customarily used for software
interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a
charge no more than your cost of physically performing source distribution, a complete machine-
readable copy of the corresponding source code, to be distributed under the terms of Sections 1
and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding
source code. (This alternative is allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such an offer, in accord with
Subsection b above.)
The source code for a work means the preferred form of the work for making modifications to it.
For an executable work, complete source code means all the source code for all modules it
contains, plus any associated interface definition files, plus the scripts used to control compilation
and installation of the executable. However, as a special exception, the source code distributed
need not include anything that is normally distributed (in either source or binary form) with the
major components (compiler, kernel, and so on) of the operating system on which the executable
runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering access to copy from a designated
place, then offering equivalent access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not compelled to copy the source
along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided
under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program
is void, and will automatically terminate your rights under this License. However, parties who
have received copies, or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
5. You are not required to accept this License, since you have not signed it. However, nothing
else grants you permission to modify or distribute the Program or its derivative works. These
actions are prohibited by law if you do not accept this License. Therefore, by modifying or
distributing the Program (or any work based on the Program), you indicate your acceptance of
this License to do so, and all its terms and conditions for copying, distributing or modifying the
Program or works based on it.
6. Each time you redistribute the Program (or any work based on the Program), the recipient
automatically receives a license from the original licensor to copy, distribute or modify the
Program subject to these terms and conditions. You may not impose any further restrictions on
the recipients' exercise of the rights granted herein. You are not responsible for enforcing
compliance by third parties to this License.
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other
reason (not limited to patent issues), conditions are imposed on you (whether by court order,

agreement or otherwise) that contradict the conditions of this License, they do not excuse you
from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your
obligations under this License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent license would not permit royalty-
free redistribution of the Program by all those who receive copies directly or indirectly through
you, then the only way you could satisfy both it and this License would be to refrain entirely from
distribution of the Program.
If any portion of this section is held invalid or unenforceable under any particular circumstance,
the balance of the section is intended to apply and the section as a whole is intended to apply in
other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right
claims or to contest validity of any such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is implemented by public license
practices. Many people have made generous contributions to the wide range of software
distributed through that system in reliance on consistent application of that system; it is up to the
author/donor to decide if he or she is willing to distribute software through any other system and
a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest
of this License.
8. If the distribution and/or use of the Program is restricted in certain countries either by patents
or by copyrighted interfaces, the original copyright holder who places the Program under this
License may add an explicit geographical distribution limitation excluding those countries, so that
distribution is permitted only in or among countries not thus excluded. In such case, this License
incorporates the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions of the General Public
License from time to time. Such new versions will be similar in spirit to the present version, but
may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number
of this License which applies to it and "any later version", you have the option of following the
terms and conditions either of that version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of this License, you may choose
any version ever published by the Free Software Foundation.
10. If you wish to incorporate parts of the Program into other free programs whose distribution
conditions are different, write to the author to ask for permission. For software which is
copyrighted by the Free Software Foundation, write to the Free Software Foundation; we
sometimes make exceptions for this. Our decision will be guided by the two goals of preserving
the free status of all derivatives of our free software and of promoting the sharing and reuse of
software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO

WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS
AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN

WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY

MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
23.3 Other open source third party software

23.3.1 libarchive
This software is used under BSD license (BSD-3-clause). The full text is
Copyright © 2003-2008, Tim Kientzle
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are
permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions
and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or other materials
provided with the distribution.
Neither the name of the <ORGANIZATION> nor the names of its contributors may be
used to endorse or promote products derived from this software without specific prior
written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
23.3.2 netkit
This package was split from netstd by Herbert Xu herbert@debian.org on Mon, 28 Sep
1998 16:50:43 +1000.
netstd was created by Peter Tobias tobias@et-inf.fho-emden.de on Wed, 20 Jul 1994
17:23:21 +0200.
It was downloaded from ftp://ftp.uk.linux.org/pub/linux/Networking/netkit/.
The license can be found at /usr/share/common-licenses/BSD on the nodes. The full text is

Copyright:
Copyright © 1988, 1993 The Regents of the University of California.
Copyright © 1995 David A. Holland
Copyright © 1994 Peter Tobias (issue.net(5))
Copyright © 1983, 1995 Eric P. Allman (setproctitle.[ch])
Redistribution and use in source and binary forms, with or without modification, are
permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or other materials
provided with the distribution.
3. Neither the name of the University nor the names of its contributors may be used to
endorse or promote products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS

IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
23.3.3 ntp
Copyright (c) David L. Mills 1992-2003

Permission to use, copy, modify, and distribute this software and its documentation for any purpose
and without fee is hereby granted, provided that the above copyright notice appears in all copies and
that both the copyright notice and this permission notice appear in supporting documentation, and that
the name University of Delaware not be used in advertising or publicity pertaining to distribution of
the software without specific, written prior permission. The University of Delaware makes no
representations about the suitability this software for any purpose. It is provided "as is" without
express or implied warranty.
23.3.4 uip
Copyright © 2006, Swedish Institute of Computer Science.
All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the
following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other materials provided with the
distribution.
3. Neither the name of the Institute nor the names of its contributors may be used to endorse or
promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
23.3.5 zlib
Copyright © 1995-2005 Jean-loup Gailly and Mark Adler
This software is provided 'as-is', without any express or implied warranty. In no event will the
authors be held liable for any damages arising from the use of this software.
Permission is granted to anyone to use this software for any purpose, including commercial
applications, and to alter it and redistribute it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim that you wrote the
original software. If you use this software in a product, an acknowledgment in the product
documentation would be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be misrepresented as being
the original software.
3. This notice may not be removed or altered from any source distribution.
Jean-loup Gailly Mark Adler
jloup@gzip.org madler@alumni.caltech.edu

Element Manager Manual PDF

Uploaded by

Copyright:

Available Formats

Element Manager Manual PDF

Uploaded by

Document Information

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

Element Manager Manual PDF

Uploaded by

Copyright:

Available Formats

Element Manager User's Manual

Phone: +46 8 685 04 00

1.1 Overview .......................................................................................................................... 13

1.2 Intended reader ............................................................................................................... 13

1.3 Support and assistance ................................................................................................. 13

1.4 Organization of content ................................................................................................. 13

1.5 Conventions in this manual .......................................................................................... 14

2 GLOSSARY OF TERMS ............................................................................ 16

3 QUICK START GUIDE............................................................................... 21

3.2 Configuration of the IP address .................................................................................... 21

4 KEY CONCEPTS ....................................................................................... 31

5 THE USER INTERFACE ............................................................................ 34

5.2 Connecting to the units ................................................................................................. 34

Element Manager User's Manual About This Manual • 3

©2013 Net Insight AB, All rights reserved

5.4 Web interface .................................................................................................................. 35

5.5 Frequently used terms ................................................................................................... 35

5.6 Default username/password.......................................................................................... 36

5.7 Logging in using the Telnet connection ...................................................................... 36

5.8 Logging in using a web browser .................................................................................. 36

6.1 Overview .......................................................................................................................... 38

6.2 Maintenance system settings ....................................................................................... 39

6.3 Maintenance system syslog .......................................................................................... 43

6.4 Maintenance system restart .......................................................................................... 43

6.5 Maintenance Date and Time .......................................................................................... 44

6.6 Users ................................................................................................................................ 45

6.7 Preferences ..................................................................................................................... 47

6.8 Cooling ............................................................................................................................ 60

6.9 Software program error alarm ....................................................................................... 61

7 STATUS MONITORING ............................................................................. 63

7.1 Overview of status monitoring ...................................................................................... 63

7.2 Alarms and events .......................................................................................................... 64

7.3 Syslog .............................................................................................................................. 66

7.4 Equipment ....................................................................................................................... 69

©2013 Net Insight AB, All rights reserved

7.7 Who (is currently logged in) .......................................................................................... 77

7.8 NTP (Network Time Protocol) ........................................................................................ 78

7.9 Nodeinfo .......................................................................................................................... 79

8 CONTROL NETWORK .............................................................................. 81

8.2 Configuration .................................................................................................................. 83

8.3 Building networks with DLE .......................................................................................... 84

8.4 IP routing ......................................................................................................................... 85

8.5 Control Network main web page ................................................................................... 87

8.6 In-band servers ............................................................................................................... 87

8.7 In-band clients ................................................................................................................ 90

8.8 Bandwidth requirements of DLE ................................................................................... 93

8.9 IP interfaces .................................................................................................................... 95

8.10 IP routing configuration ............................................................................................. 96

8.11 SNMP configuration.................................................................................................... 99

9 DTM CONFIGURATION .......................................................................... 110

©2013 Net Insight AB, All rights reserved

9.2 Interfaces ....................................................................................................................... 111

9.3 Addresses ..................................................................................................................... 114

9.4 Hostnames .................................................................................................................... 116

9.5 Links .............................................................................................................................. 118

9.6 Routing .......................................................................................................................... 119

9.7 Static routing ................................................................................................................ 122

9.8 Dynamic routing ........................................................................................................... 123

10 TRUNKS ............................................................................................... 133

10.2 Editing SDH/SONET Trunk Interfaces ..................................................................... 136