Element Manager Manual PDF

User's Guide
Nimbra 300 series

Nimbra 600 series
GX 5.3
© 1999-2017 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
August, 2017
Stockholm, Sweden
(NID 4954/A13)
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 Conventions in this manual ............................................................................................ 13

1.4.1 Information of specific importance ....................................................................................... 13
1.4.2 Terminal output and keyboard input ..................................................................................... 14
1.4.3 Web interface examples........................................................................................................ 14
2 GLOSSARY OF TERMS .............................................................................. 15
3 QUICK START GUIDE ................................................................................20
3.1 Overview ...................................................................................................................... 20
3.2 Configuration of the IP address ...................................................................................... 20

3.2.1 Initial settings for VT100 terminal emulator .......................................................................... 23
3.2.2 IP settings for Nimbra 300 series ........................................................................................... 23
3.2.3 IP settings for Nimbra 600 series ........................................................................................... 24
3.2.4 Set the Trunk network (DTM) address .................................................................................. 26
3.2.5 Parameter configuration example ......................................................................................... 27
3.2.6 Save the configuration .......................................................................................................... 28
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 ............................................................................................... 32
4.1.5 Isochronous Transport Stream (ITS) ...................................................................................... 33
4.1.6 Ethernet Transport Service (ETS) .......................................................................................... 33
5 THE USER INTERFACE ..............................................................................34
5.1 Overview ...................................................................................................................... 34
5.2 Command Line Interface ................................................................................................ 34
5.3 Web interface ................................................................................................................ 34
User's Guide Contents  3
©2017 Net Insight AB, All rights reserved

5.4 Frequently used terms ................................................................................................... 34
5.5 Default username/password........................................................................................... 35
5.6 Logging in with a telnet or SSH connection ..................................................................... 35

5.6.1 Terminal connection, General for Nimbra nodes ................................................................... 35
5.7 Logging in using a web browser ...................................................................................... 35
6 STATUS WEB PAGE .................................................................................. 37
6.1 Overview of Status ........................................................................................................ 37
6.2 Alarms and events ......................................................................................................... 38

6.2.1 The alarms page ................................................................................................................... 38
6.2.2 Acknowledging an alarm ...................................................................................................... 40
6.3 Syslog........................................................................................................................... 40
6.4 Equipment .................................................................................................................... 42

6.4.1 Setting the administrative status of a module (board) ........................................................... 44
6.4.2 Allocating backplane capacity in Nimbra 600 ........................................................................ 45
6.5 Sensors ......................................................................................................................... 48
6.6 Inventory ...................................................................................................................... 49
6.7 Who (is currently logged in) ............................................................................................ 51
6.8 NTP (Network Time Protocol) ........................................................................................ 51
6.9 Nodeinfo....................................................................................................................... 52
7 MAINTENANCE.........................................................................................54
7.1 Overview ...................................................................................................................... 54
7.2 System - settings ........................................................................................................... 55
7.3 System - syslog ............................................................................................................. 58
7.4 System - restart............................................................................................................. 58
7.5 Date and Time ............................................................................................................... 59
7.6 Users ............................................................................................................................ 60
7.7 Preferences ................................................................................................................... 62
7.8 Configurations .............................................................................................................. 63

7.8.1 Saving the current configuration ........................................................................................... 64
7.8.2 Download of configurations to PC......................................................................................... 65
7.8.3 Upload configurations from PC ............................................................................................. 66
7.8.4 Switching configurations ...................................................................................................... 67

7.8.5 Delete a configuration .......................................................................................................... 67
7.9 Software (maintenance) ................................................................................................ 67
7.10 SSL Certificate .............................................................................................................. 70
7.11 Alarm I/O (configuration) ............................................................................................... 72
7.12 Cooling ......................................................................................................................... 77
7.13 Software program error alarm ........................................................................................ 77
8 CONTROL NETWORK............................................................................... 80
8.1 General about In-band management .............................................................................. 80

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

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

8.7.1 Basic configuration for In-band clients .................................................................................. 91
8.7.2 Statistics for In-band clients .................................................................................................. 93
8.8 Bandwidth requirements of DLE..................................................................................... 93
8.9 IP interfaces .................................................................................................................. 94
8.10 IP routing configuration ................................................................................................. 97

8.10.1 Routes .................................................................................................................................. 97
8.10.2 Firewall ................................................................................................................................. 99
8.11 SNMP configuration .................................................................................................... 100

8.11.1 Basic SNMP configuration .................................................................................................. 100
8.11.2 Access control SNMP configuration .................................................................................... 102
8.11.3 Addition of an SNMP trap receiver(s) .................................................................................. 103
8.11.4 SNMP page internal data .................................................................................................... 104
8.11.5 Format of Access control SNMP configuration .................................................................... 106
8.11.6 Configuration Procedure ..................................................................................................... 106

8.11.7 Defining SNMPv3 Users ...................................................................................................... 107
8.11.8 Defining Community........................................................................................................... 108
8.11.9 Defining MIB Views ............................................................................................................. 108
8.11.10 Defining Groups and Access Rights ................................................................................. 110
8.11.11 Assigning Users ...................................................................................................................111
9 TRUNK NETWORK CONFIGURATION ...................................................... 112
9.1 Overview of Trunk Network ......................................................................................... 112

9.1.1 Trunk Modules, Nimbra 300 Series ...................................................................................... 112
9.1.2 Fixed trunk interfaces for Nimbra 310/320/360/380 ..............................................................113
9.1.3 Trunk Modules, Nimbra 600 .................................................................................................113
9.2 Dynamic Trunk Capacity .............................................................................................. 114
9.3 Configuring the IP/Ethernet trunk interface .................................................................. 115

9.3.1 Protocol stacking ................................................................................................................ 115
9.3.2 Ethernet Interface overview ................................................................................................. 117
9.3.3 Configuration of IP/Ethernet trunks – Ethernet interface .................................................... 118
9.3.4 Ethernet Interface Parameters and Variables ...................................................................... 119
9.3.5 Forward error correction ..................................................................................................... 119
9.3.6 Basic Ethernet Interface Variables and parameters ............................................................. 121
9.3.7 Advanced Ethernet Interface Variables and Parameters ..................................................... 122
9.3.8 Ethernet interfaces - statistics............................................................................................. 124
9.3.9 Ethernet Interface Parameters – Trunk ............................................................................... 128
9.3.10 IP Trunk – Basic (settings) ................................................................................................... 130
9.3.11 IP Trunk - Advanced (settings) .............................................................................................133
9.3.12 IP Trunk - Alarms tab .......................................................................................................... 135
9.3.13 IP trunk interface variables...................................................................................................137
9.3.14 Basic variables .................................................................................................................... 138
9.3.15 Advanced variables ............................................................................................................. 139
9.3.16 Alarms variables ................................................................................................................. 143
9.3.17 Alarms ................................................................................................................................ 144
9.3.18 Ports used by IP trunk ......................................................................................................... 145
9.4 Statistics ..................................................................................................................... 146

9.4.1 General ............................................................................................................................... 146
9.4.2 DPP-IP Trunk level statistics ............................................................................................... 147
9.4.3 Overview (IP) trunk statistics .............................................................................................. 148
9.4.4 Overview Ethernet interface statistics ................................................................................ 149
9.5 Editing SDH/SONET Trunk Interfaces ........................................................................... 150

9.5.1 Asymmetric alarm generation ............................................................................................ 154
9.6 Editing the DS3/E3 Trunk interfaces ............................................................................. 155

9.6.1 Configuration of DS3/E3 mode ............................................................................................ 158
9.7 DTM Interfaces ............................................................................................................ 159
9.8 Links ........................................................................................................................... 161
9.9 Addresses ................................................................................................................... 162

9.9.1 Adding a DTM address ........................................................................................................ 162
9.9.2 Editing or deleting a (DTM) address .................................................................................... 163

9.10 Hostnames and hostname search ................................................................................. 164
9.10.1 Adding a host...................................................................................................................... 164
9.10.2 Hostname search ................................................................................................................ 165
9.10.3 Editing or deleting hostnames ............................................................................................ 166
9.11 Routing....................................................................................................................... 167

9.11.1 General ............................................................................................................................... 167
9.11.2 Static routing ...................................................................................................................... 167
9.11.3 Dynamic routing ................................................................................................................. 169
9.11.4 Area Definition .................................................................................................................... 171
9.11.5 Area Planning ...................................................................................................................... 171
9.11.6 Area Prefix Routes ...............................................................................................................173
9.11.7 Directly Connected Areas ................................................................................................... 174
9.11.8 Indirectly Connected Areas ................................................................................................. 174
9.11.9 Metrics for Area Prefix Routes .............................................................................................175
9.11.10 Configuration ...................................................................................................................175
9.11.11 Addition of a dynamic routing entry .................................................................................... 176
10 SYNCHRONIZATION ............................................................................ 178
10.1 General ....................................................................................................................... 178
10.2 Synchronization selection and DSYP ............................................................................ 178
10.3 Timing source selection ............................................................................................... 179
10.4 Timing source and interface ......................................................................................... 182
10.5 Node synchronization function .................................................................................... 184

10.5.1 Hold-over and free-running properties ................................................................................ 184
10.6 Configuration recommendations .................................................................................. 185
10.7 Time Transfer .............................................................................................................. 187

10.7.1 Time transfer performance requirements ........................................................................... 187
10.8 Configuration of Time (external clocks, synchronization and time transfer) .................... 188
10.8.1 Clock interfaces .................................................................................................................. 188
10.8.2 Nimbra 360,380 and 390 ..................................................................................................... 189
10.8.3 Nimbra 310 and 320 ............................................................................................................ 195
10.8.4 Nimbra 640, 680 and 688 .................................................................................................... 196
10.9 Management of timing sources .................................................................................... 197

10.9.1 Node clock bandwidth ........................................................................................................ 198
10.9.2 Timing source list ................................................................................................................ 198
10.10 Fault Indications – synchronization alarms ................................................................ 199
10.11 DTM and transport layer synchronization .................................................................. 201

10.11.1 Timing modes of SDH/Sonet trunks .................................................................................... 201
10.11.2 IP/Ethernet Trunk ............................................................................................................... 201
10.12 Monitoring synchronization performance .................................................................. 202

10.12.1 Slip Seconds ....................................................................................................................... 202

10.12.2 Pointer Justification Events ............................................................................................. 202
10.13 Time Transfer configuration ..................................................................................... 202

10.13.1 Calibration of Nimbra 300 time transfer interfaces .............................................................. 207
10.13.2 Listing of time transfer channels ..................................................................................... 209
10.13.3 Time transfer on additional interfaces than SDH ................................................................. 209
11 PERFORMANCE MONITORING ............................................................. 210
11.1 Overview .................................................................................................................... 210
11.2 General ....................................................................................................................... 212

11.2.1 Monitored performance values ........................................................................................... 213
11.3 Configuration of PM objects ......................................................................................... 215
11.4 Presentation of PM objects .......................................................................................... 216

11.4.1 Interface PM objects ........................................................................................................... 218
11.4.2 Services .............................................................................................................................. 220
11.4.3 Direction ............................................................................................................................. 220
11.4.4 Error ................................................................................................................................... 221
11.4.5 Admin and Oper Status ....................................................................................................... 221
11.4.6 Reset of counters and setting of admin status on multiple objects ...................................... 221
11.4.7 Particular PM Object web page ........................................................................................... 222
12 ETHERNET TRANSPORT SERVICE (ETS)................................................ 224
12.1 Basic concepts ............................................................................................................. 224

12.1.1 Device................................................................................................................................. 224
12.1.2 Forwarding function (FF) ..................................................................................................... 224
12.1.3 ETH and ETS Interfaces ...................................................................................................... 225
12.1.4 ETS channels ...................................................................................................................... 225
12.1.5 Interface source and sink .................................................................................................... 226
12.1.6 ETS 1 +1 protection ............................................................................................................. 227
12.1.7 Protection type – hitless or standby .................................................................................... 228
12.2 Web configuration of ETS services ................................................................................ 229

12.2.1 Devices (modules)............................................................................................................... 229
12.2.2 Forwarding Function – Basic settings .................................................................................. 230
12.2.3 Forwarding function - Advanced ......................................................................................... 235
12.2.4 Forwarding function – Diffserv configuration ...................................................................... 236
12.2.5 Forwarding function – Spanning tree .................................................................................. 239
12.2.6 Forwarding function – Statistics .......................................................................................... 241
12.2.7 Forwarding function - Nimbra 360 limitations ..................................................................... 242
12.2.8 ETH and ETS interfaces....................................................................................................... 243
12.2.9 Fault management for ETH and ETS interfaces ................................................................... 256
12.2.10 Configuration of Fault management for ETH and ETS interfaces..................................... 257
12.2.11 Destinations configuration for ETS multicast channels ....................................................... 259
12.2.12 Spanning tree configuration for ETH and ETS interfaces ................................................. 260
12.2.13 Statistics overview tab on the ETS configuration page .................................................... 262
12.2.14 Statistics overview tab on the ETH configuration page .................................................... 263
12.2.15 ETS interface groups (ETSG) ........................................................................................... 264
12.2.16 Hitless Protection............................................................................................................ 267

12.3 Configuration examples of ETS services ........................................................................ 268
12.3.1 DTM network as extension cable ........................................................................................ 269
12.3.2 ETS Multicast replication in the DTM layer .......................................................................... 269
12.3.3 ETS 1+1 unicast closed ended configuration ........................................................................ 270
12.3.4 ETS 1+1 multicast closed ended configuration .................................................................... 271
12.3.5 ETS 1+1 open ended configuration ...................................................................................... 272
12.3.6 Ethernet Switching ............................................................................................................. 273
12.3.7 Ethernet switch and VLAN tagging ..................................................................................... 275
13 ISOCHRONOUS TRANSPORT SERVICE (ITS) ......................................... 276
13.1 Overview .................................................................................................................... 276
13.2 Protection ................................................................................................................... 277

13.2.1 Nomenclature ..................................................................................................................... 277
13.2.2 ITS protection cases ............................................................................................................ 278
13.3 Interface settings for Access Modules ........................................................................... 280

13.3.1 Configurable interface parameters ..................................................................................... 281
13.4 Setting up a unicast ITS tunnel ..................................................................................... 287

13.4.1 Terminating Connection ..................................................................................................... 287
13.4.2 Originating Unicast Connection .......................................................................................... 289
13.5 Setting up a multicast ITS tunnel .................................................................................. 291

13.5.1 Considerations for multicast channels ................................................................................. 291
13.5.2 Configuration of a Multicast Connection ............................................................................. 293
13.5.3 Sink TTPs (Termination) ..................................................................................................... 294
13.5.4 Source TTPs ........................................................................................................................ 294
13.6 Advanced settings ....................................................................................................... 297

13.6.1 Embedded ASI in HD-SDI channels ..................................................................................... 298
13.7 Configuration of ASI video stream – an ITS configuration example ................................. 300
13.7.1 Configuration of the Terminating TTP ................................................................................ 300
13.7.2 Configuration of originating TTP for a unicast connection................................................... 302
13.7.3 Configuration of the originating TTP for a multicast service ................................................ 304
13.7.4 Configuration of interfaces ................................................................................................. 306
13.8 Configuration of MADI streams .................................................................................... 308

13.8.1 Configuration process ......................................................................................................... 309
13.8.2 Configuration of interfaces ................................................................................................. 314
13.8.3 Test generator .................................................................................................................... 318
13.8.4 Timing ................................................................................................................................ 318
13.8.5 PM ...................................................................................................................................... 320
13.9 Configuration of AES/EBU streams ............................................................................... 321

13.9.1 Configuration of Terminating TTP ...................................................................................... 322
13.9.2 Configuration of originating TTP for a unicast connection................................................... 325
13.10 Configuration of SDI streams .................................................................................... 329

13.10.1 Configuration of Terminating TTP ...................................................................................... 329
13.10.2 Configuration of originating TTP for a unicast connection ............................................... 332

13.11 Configuration of JPEG 2000 services .......................................................................... 336

13.11.1 Enabling the encoder .......................................................................................................... 336
13.11.2 Sink TTP configuration ........................................................................................................337
13.11.3 Source TTP configuration ................................................................................................... 339
13.11.4 Multicast ............................................................................................................................. 344
13.11.5 Interface configuration ....................................................................................................... 347
13.11.6 Basic interface parameters.................................................................................................. 348
13.11.7 Video interface parameters ................................................................................................. 350
13.11.8 Audio interface parameters ................................................................................................ 351
13.11.9 Ancillary (ANC) interface parameters .................................................................................. 353
13.11.10 Vertical Blanking Interval (VBI) interface parameters ...................................................... 355
13.11.11 Statistics ......................................................................................................................... 356
13.12 Interface Groups and 4K Functionality ....................................................................... 357

13.12.1 Configuring Interface Groups .............................................................................................. 358
13.12.2 Performance Monitoring Interface Groups ...................................................................... 360
13.12.3 Frame Synchronization of Interface Groups ........................................................................ 363
13.13 Configuration of 1+1 protection video services ........................................................... 363

13.13.1 1+1 Seamless protection video services ............................................................................... 363
13.13.2 1+1 Hitless protection video services ................................................................................... 364
13.13.3 Hitless web parameters and variables ................................................................................. 365
13.14 Configuration of interfaces – Test Generator ............................................................. 373

13.14.1 AES......................................................................................................................................373
13.14.2 MADI .............................................................................................................................. 374
13.14.3 ASI ...................................................................................................................................... 374
13.14.4 SDI .................................................................................................................................. 376
13.15 Configuration of Frame Synchronizer and Reference Sources ..................................... 377

13.15.1 Reference sources ............................................................................................................... 378
13.15.2 Configuring Frame synchronizer ......................................................................................... 380
14 CHANNEL PERSISTENCE ...................................................................... 381
14.1 General ....................................................................................................................... 381
14.2 Persistence Configuration ............................................................................................ 381

14.2.1 Link Class Normal ............................................................................................................... 381
14.2.2 Link Class Persistent ........................................................................................................... 382
14.2.3 Link Class Nailed ................................................................................................................. 382
14.2.4 Restart On Error.................................................................................................................. 383
14.2.5 Redundant DLE Servers ...................................................................................................... 383
14.3 Handling an Error Situation .......................................................................................... 383

14.3.1 The Trunk network  Links Page ....................................................................................... 383
14.3.2 Node Status NoControl ....................................................................................................... 384
14.3.3 Restarting a node in NoControl ........................................................................................... 384
14.3.4 Link Errors .......................................................................................................................... 385
14.3.5 Channels with broken control-paths ................................................................................... 385
14.3.6 Channel reestablishment upon link failures ......................................................................... 387
14.3.7 DLE..................................................................................................................................... 388

15 CONNECTION AND CHANNEL LISTS ....................................................389
15.1 Overview .................................................................................................................... 389
16 SOURCE ROUTING ............................................................................... 392
16.1 Loose and strict source-routes...................................................................................... 392

16.1.1 Optional interface specification .......................................................................................... 392
16.1.2 Deleting a source-route ...................................................................................................... 393
16.2 Example of how to define source routes ........................................................................ 393
16.3 Using source routes ..................................................................................................... 397
17 LOOPBACK ..........................................................................................398
17.1 General ....................................................................................................................... 398

17.1.1 Line loopback ..................................................................................................................... 398
17.1.2 DTM Loopback ................................................................................................................... 400
17.2 Behaviorally equivalent configurations ......................................................................... 401

17.2.1 Loopback from the line side in 8 x ASI Transport Module for Nimbra One/300 .................... 401
17.2.2 Loopback from the line side in Video Access Modules for Nimbra 600 ................................ 402
17.2.3 Loopback from the DTM side in Video Access Modules for Nimbra 600 .............................. 402
18 REDUNDANCY FOR NIMBRA 600 .......................................................... 404
18.1 General ....................................................................................................................... 404
18.2 Node Controller redundancy ........................................................................................ 405
18.3 Switch Module redundancy .......................................................................................... 406
19 MODULE INSTALLATION ..................................................................... 407
19.1 General ....................................................................................................................... 407
19.2 Differences Nimbra 360 vs Nimbra 600 ......................................................................... 409
19.3 Addition of new modules to existing nodes ................................................................... 410
20 UP- AND DOWNGRADING ....................................................................416
20.1 General ....................................................................................................................... 416
20.2 Up/downgrading GX version from web GUI ................................................................... 416

20.2.1 Saving the current configuration ......................................................................................... 416
20.2.2 Repository .......................................................................................................................... 417
20.2.3 Up-/downgrading from the web GUI ................................................................................... 419
20.2.4 Required intermediate system releases .............................................................................. 421
20.3 Addition of functional enhancement ............................................................................ 424


20.3.1 General ............................................................................................................................... 424
20.3.2 Changing fixed trunk interface on Nimbra 310/320/360/380 ................................................ 424
20.3.3 Changing trunk interfaces on 3 x IP/Ethernet Trunk Module in Nimbra 300 series................ 426
20.3.4 Setting modes for 4 x DS3/E3 Trunk/Access Modules .......................................................... 428
20.3.5 Changing firmware on JPEG2000 Video Access Modules .................................................... 430
20.3.6 Changing firmware on 8 x ASI/AES Access Module ............................................................. 432
20.3.7 Changing firmware on 8 x Gigabit Ethernet Access Module ................................................ 433
20.3.8 Changing firmware on 10 GE Module .................................................................................. 434
20.3.9 Module restart .................................................................................................................... 435
21 LICENSE INFORMATION ...................................................................... 437
21.1 General ....................................................................................................................... 437
21.2 GNU General Public license GPLv2 ................................................................................ 437

21.2.1 GNU GENERAL PUBLIC LICENSE ....................................................................................... 437
21.3 Other open source third party software ........................................................................ 441

21.3.1 libarchive ............................................................................................................................ 441
21.3.2 netkit .................................................................................................................................. 442
21.3.3 ntp ...................................................................................................................................... 442
21.3.4 uip ...................................................................................................................................... 443
21.3.5 zlib ...................................................................................................................................... 443

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 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 Conventions in this manual

1.4.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.
User's Guide About This Manual  13

1.4.2 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.4.3 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.
User's Guide About This Manual  14

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.
DCP DTM Channel protocol
DCP v2 DTM Channel protocol, version 2
DCP v3 DTM Channel protocol, version 3
DEG Degraded
DID Data Identifier
DLE DTM LAN Emulation allows DTM to be used as a bridge
between different segments of an Ethernet network.
User's Guide Glossary of Terms  15

DLE client DTM LAN Emulation client
DNF DPCP-IP Negotiation Failure
DNU Do Not Use
DRP DTM Routing Protocol
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
FTP File Transfer Protocol

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
HTTPS Hypertext Transport Protocol Secured
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 Data (storage)
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
MSR Media Switch Router
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
RTT Round Trip Time
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).
VAM Video Access Module
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 from the serial interface
Set the Trunk network (DTM) address from the web interface
Save/back-up the configuration
Reboot the node
3.2 Configuration of the IP address

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. Please change the IP settings (IP address, netmask and gateway) from the web
interface. Proceed with saving the configuration and rebooting of the node. Then set the
IP address of the PC/Terminal to fit the LAN or create a route on the PC to connect to the
default IP address of the node. Next, the DTM address is configured. This procedure is
elaborated in chapter 9 Trunk network configuration).
All settings can also be made from the Command Line Interface (CLI) and the serial port.
In order to see what is stored in registry, log in to the node (root/neti) and issue
command: registry list
The FactoryDefault configuration should now appear, as the only configuration.
To see the contents, write resedit get -r -n ipconf
nimbra login: root

Password:
nimbra:/flash/root # registry list
0 FactoryDefault
User's Guide Quick Start Guide  20

nimbra:/flash/root # resedit get -r -n ipconf
.ipconf
.ipconf.if
.ipconf.if.eth
.ipconf.if.eth.0
.ipconf.if.eth.0.name "eth0"
.ipconf.if.eth.0.media
.ipconf.if.eth.0.media.current "autoselect"
.ipconf.if.eth.0.media.supported "autoselect,10baseT half-
duplex,10baseT full-duplex,100baseTX half-duplex,100baseTX full-duplex"
.ipconf.if.eth.0.media.active "100baseTX full-duplex"
.ipconf.if.eth.0.address
.ipconf.if.eth.0.address.0
.ipconf.if.eth.0.address.0.inet "192.168.125.125"
.ipconf.if.eth.0.address.0.netmask "255.255.255.0"
.ipconf.if.eth.0.secZone 0
.ipconf.if.eth.0.mtu 1500
.ipconf.if.eth.0.mac "00:10:5b:11:1f:75"
.ipconf.if.eth.0.adminStatus "up"
.ipconf.if.eth.0.operStatus "up"
.ipconf.if.dle
.ipconf.if.tun
.ipconf.routes
.ipconf.firewall
.ipconf.firewall.secProfile
.ipconf.firewall.secProfile.0
.ipconf.firewall.secProfile.0.purpose "Security profile 0"
.ipconf.firewall.secProfile.0.allowedHosts
.ipconf.firewall.secProfile.0.allowPing "yes"
.ipconf.firewall.secProfile.0.allowedPorts
.ipconf.firewall.secProfile.0.allowedPorts.0
.ipconf.firewall.secProfile.0.allowedPorts.0.purpose "http"
.ipconf.firewall.secProfile.0.allowedPorts.0.enabled "yes"
.ipconf.firewall.secProfile.0.allowedPorts.0.protocol "tcp"
.ipconf.firewall.secProfile.0.allowedPorts.0.portLow 80
.ipconf.firewall.secProfile.0.allowedPorts.0.portHigh 80
.ipconf.firewall.secProfile.0.allowedPorts.1.purpose "https"

.ipconf.firewall.secProfile.0.allowedPorts.2.purpose "snmp"
.ipconf.firewall.secProfile.0.allowedPorts.2.protocol "udp"
.ipconf.firewall.secProfile.0.allowedPorts.4.purpose "ssh"
.ipconf.firewall.secProfile.0.allowedPorts.5.purpose "telnet"
.ipconf.firewall.secProfile.0.allowedPorts.6.purpose "ftp"
.ipconf.firewall.secProfile.0.allowedPorts.7.purpose "ntp"
.ipconf.firewall.secProfile.0.allowedPorts.7.protocol "udp"
.ipconf.firewall.secZone
.ipconf.firewall.secZone.0
.ipconf.firewall.secZone.0.purpose "zone0"
.ipconf.firewall.hostAccess

.ipconf.firewall.hostAccess.0
.ipconf.firewall.hostAccess.0.secProfile "0"
.ipconf.firewall.hostAccess.3.secProfile "block"
nimbra:/flash/root #
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: 38400 bps
Data bits: 8
Parity bit: No
Stop bit: One
Flow control: No
3.2.2 IP settings for 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.eth.0
The system should reply with something like:

nimbra:/flash/root # resedit get -r -n ipconf.if.eth.0
.ipconf.if.eth.0
.ipconf.if.eth.0.name "eth0"
.ipconf.if.eth.0.media.supported "autoselect,10baseT half-duplex,10baseT
full-duplex,100baseTX half-duplex,100baseTX full-duplex"
.ipconf.if.eth.0.mac "00:10:5b:11:1f:75"

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.eth.0.address
resedit set -n ipconf.if.eth.0.address.0.inet -v x.x.x.x
resedit set -n ipconf.if.eth.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.
Create the necessary (default) route, with

resedit create -n ipconf.routes
resedit set -n .ipconf.routes.0.dest -v
0.0.0.0
resedit set -n .ipconf.routes.0.mask -v
0.0.0.0
resedit set -n .ipconf.routes.0.gw –v z.z.z.z
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.if
A typical reply from the node may be):
nimbra login: root

Password:
nimbra:NCB /flash/root # resedit get -r -n ipconf
.ipconf
.ipconf.if
.ipconf.if.eth
.ipconf.if.eth.0
.ipconf.if.eth.0.name "eth-front"

.ipconf.if.eth.0.mac "00:30:d6:01:2c:88"
.ipconf.if.eth.1
.ipconf.if.eth.1.name "eth-aux"
.ipconf.if.eth.1.media.active "10baseT half-duplex"
.ipconf.if.eth.1.mac "00:10:5b:20:1c:b3"
.ipconf.if.eth.1.operStatus "down"
.ipconf.if.dle
.ipconf.if.tun
3.2.3.1 Set 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.eth.0.address

resedit set -n ipconf.if.eth.0.address.1.inet -v x.x.x.x
resedit set -n ipconf.if.eth.0.address.1.netmask -v y.y.y.y
x.x.x.x is the IP address and y.y.y.y the subnet mask.
Create the necessary (default) route, with

resedit create -n ipconf.routes
resedit set -n .ipconf.routes.0.dest -v
0.0.0.0
resedit set -n .ipconf.routes.0.mask -v
0.0.0.0
resedit set -n .ipconf.routes.0.gw –v z.z.z.z
z.z.z.z is the IP address of the default gateway.
Save the configuration with command
registry backup -n basic -c GX5.3.0.0

where the configuration is saved under name ‘basic’ and with comment ‘GX5.3.0.0’.
Check that the configuration is properly saved with
nimbra:NCB /flash/root # registry list

0 basic
1 FactoryDefault
3.2.4 Set the Trunk network (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 by entering the URL to the node in the proper field, login with
root/neti as user/password combination and navigate to the web page Trunk network 
Addresses, and click on the Add Address button.
Figure 1. Login to the node with the web interface
Set the trunk network address of the unit. Make sure that Primary address is set to ‘Yes’.
Click OK.
The Trunk network  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 2. Configuration page of Trunk network (DTM) addresses.

To set a DTM address, write the DTM address in the appropriate field and click on the OK
button.
Figure 3. Addition of trunk network primary address.
Note: A change in the primary trunk network address does not

take effect until after the node has been restarted.
Remember to save the configuration before rebooting.
Figure 4. Listing of the all Trunk network (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 time with maxAlarmRate set to ‘high’ is 100 ms and 1 s.
In CLI, the parameter is set to normal with command
resedit set -n its.maxAlarmRate -v normal
The parameter is set to high with
resedit set -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 5. 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 6. 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 7. 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 8. 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 9. The maintenance – system – settings configuration page
On the syslog tab, the syslog configuration can be made. Default configuration is
presented in the window.
Figure 10. Configuration of the syslog settings, from the Maintenance –

System – Syslog web page.
The parameters are explained in chapter 7.2 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.
In Nimbra 360/380, 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 trunk interfaces are labeled 3:1, 3:2, 3:3 and 3:4.
Finally, the fixed Gigabit Ethernet Access Module Interface is labeled 4:1. In Nimbra 380,
the fixed Gigabit Ethernet ports are labeled 4:1 to 4:8.
Blind Panel
155/622/2488 Mbps (SDH)

1 10/100/1000 Mbps (ETH) 2
Blind Panel
3 - 155/622 Mbps (SDH) - 4
Ports 4:1 to 4:8
Figure 11. 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.
Port 1:1 to 1:x

Blind Panel
1 2
155/622/2488 Mbps (SDH)

10/100/1000 Mbps (ETH)
Power input A Power input B Port 3:1 to 3:8 Port 2:1 and 2:2
Figure 12. Port numbering of Nimbra 320
Nimbra 310 is a Nimbra 320 with trunk interface 2:2 disabled.
User's Guide Key concepts  31

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 13. 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 310/320/380/390 and integrated access features like 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 Service (ETS)

The Ethernet Stream going through the DTM infrastructure from ingress to egress port is
called Ethernet Transport Service (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. In this document, only web browser procedures are described.
5.2 Command Line Interface

A Command Line Interface (CLI) is a set of system commands used for management of
the Nimbra nodes via terminal, SSH or telnet software. CLI can be used when connecting
to the unit via the Serial Control Port (with Terminal software) or when connecting via
telnet (TCP/IP) or ssh over the Ethernet Control Port or over the in-band management
network. Normally the web interface should be used. CLI is intended mainly for initial
configuration operations and troubleshooting.
5.3 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 14. The web based user interface
5.4 Frequently used terms

User's Guide The User Interface  34

The following terms and parameters are frequently used throughout this document:
5.4.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.4.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.5 Default username/password

The default username/password combination is
user: root
pass: neti
5.6 Logging in with a telnet or SSH connection

5.6.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 or SSH 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, 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.7 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 15. 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 16. The start page of the Element Manager.

6 Status web page
6.1 Overview of Status
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 17. 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.
User's Guide Status web page  37

6.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, 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 fault
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.
6.2.1 The alarms page

When clicking on the Status  Alarms link, the following page appears:
Figure 18. 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. Not available for
events.
Figure 19. Description of alarm and event properties. For a full specification of
the alarms, see the appropriate Alarm 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 20. Events page

6.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 21. Acknowledge alarm page
This page shows the same information as the alarm list, with the addition of an editable
Comment field and an Acknowledged drop-down menu.
Enter any desired comment, set the Acknowledged drop-down menu to ‘Yes’ and click
Applyor OK. The alarm now appears with ‘Ack’ (alarm acknowledgement) 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.
6.3 Syslog
The Syslog page lists a log of the node. To access the page, click 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).

Figure 22. The Syslog page for a Nimbra 600 with dual Node Controllers.
Figure 23. The bottom of the Syslog page (latest) for the active node
controller.
Syslog is configured from the syslog tab on the Maintenance  System web page. The
default configuration is
*.*;local1.!=info -/var/log/messages
kern.* -/var/log/kern.log
*.alert /dev/console
This configuration logs 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. The exception is messages from the kernel, which are logged in a
separate file /var/log/kern.log. Furthermore, all critical messages are displayed 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 24. Definition of the syslog file.
6.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 25. 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 26. 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 Tick box The default setting
replacement or 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 01:00:00 1970 Wed, Thu, Fri, Sat,
replaced 1970 Sun) 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
filter shall be 01:00:00 01:00:00 1970 when air filter was last
replaced 1970 replaced’ plus ‘Air filter
(variable) replacement interval’
Figure 27. Air filter replacement parameters and variables.
6.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 28. Board page
In the roll-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 etc.). This is
described more in next chapter.
The status of the card can be verified in the administrative status and operational 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.
6.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-pair fashion. A row-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 is always 10 Gbps, provided a
40 Gbps switch 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 29. Backplane capacity allocation in Nimbra 680/688.
Default is that both IF positions in the row-pair have 5 Gbps allocated. If the left column
interface module should have the whole capacity of the row-pair, the module has to be
configured for that. This is described below.
Note: Note that both slots of a row-pair 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-1 Trunk
4 x OC-12/STM-4 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 30. Edit board page, Nimbra 600 series
Select the Requested capacity, 5 or 10 Gbps and click Applyor OK. Furthermore, on this
page information from the various mounted SFPs is available (Digital Diagnostics). Click
the sfp link, like sfp3:1 and reload the web page.
Figure 31. Pluggable interface page, with information from the particular SFP.

6.5 Sensors
On the sensors web page, various sensors with current values and alarm limits are shown.
Figure 32. The status sensors web page displays information on the various
temperature and other sensors in the node.

6.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 33. 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 34. 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.

6.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 35. 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.
6.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 36. 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 37. Headers on the Status  NTP page
6.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
is rebooted, as a lot of information is lost when the node is rebooted.
Figure 38. 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 39. Nodeinfo page when the file has been generated.

7 Maintenance
7.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 alarm interfaces.
The first maintenance web page is shown below.
Figure 40. 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
SSL Certificate: Handling and generation of self-signed SSL Certificates
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
Applybefore jumping to another tab as clicking directly on another tab removes all
changes on the previous tab.
User's Guide Maintenance  54

Note: Some of the links are further divided in different tabs. It is
important to click on Applybefore jumping to another tab as
clicking directly on another tab removes all changes on the
previous tab.
7.2 System - settings

The maintenance system web page is divided into three different tabs; settings, syslog
and restart. The bulk of the configuration takes place on the settings web page.
Figure 41. Maintenance system settings web page
The system settings web page contains configurable system parameters, which are
described below.
7.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.
7.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.
7.2.1.3 Node 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.
7.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.
7.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.
7.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).

7.2.1.7 NTP Server
Default value: none, i.e. no server is configured
Type: IP address or host name (requires working name server)
Range: 0.0.0.0 – 255.255.255.255, host name of NTP server
Description: The IP address of the NTP (Network Timing Protocol) server.
7.2.1.8 Log these events – Config

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

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

Description: The parameter determines if performance events are logged.
7.2.1.11 Log these events – Debug

Description: The parameter determines if debug events are logged.
7.2.1.12 Log these events – Info

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

Description: The parameter determines if alarm events are logged.

7.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.
7.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. In case it is not
grayed out, the node is in abnormal operation. A click on this button then causes the node
to restart necessary software and resume 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.
7.3 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 chapter of this
document.
Figure 42. Maintenance system syslog web page, with default configuration.
7.4 System - restart

Note: Save the configuration before restarting. Otherwise the
parameter changes will be lost! See chapter 7.8 Configuration
for details.
Navigate to restart tab of the web page Maintenance  System. Click on ‘Restart Node’
to execute a node reboot. Observe that this is traffic affecting and all services originating,
terminating or going through the node are affected. ‘Restart Node’ means that all
processes on all modules in the node are restarted, including the node controller.
Figure 43. 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.
7.5 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 7.2 System
- settings.

Figure 44. 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.
DST: Daylight Savings Time
Time zone: Name of the standard time zone used, which is selectable 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-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 is set by using GMT-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.
7.6 Users
The Maintenance  Users web page lists currently active users. From this page, users
can be added and their privilege level modified.

Figure 45. 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 46. 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:
7.6.1.1 User name

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

7.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.
7.6.1.3 Password/Re-type password

Default value: none
Type: Encrypted string
Range: 1-50 characters long password.
Description: Password for the created user.
To modify the settings for an already created user, go to the user page and edit the user.
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.
7.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 Boolean
different types: performance, config, reset, debug,
info and alarm.
Visible alarms Type of alarms that the user can see. There are five Boolean
different 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 Integer
the user.
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
recommende
d
Figure 47. Configurable parameters, user preferences
Click on the Maintenance  Preferences link. The web page shown below appears.

Figure 48. 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.
7.8 Configurations
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 49. 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-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 50. Maintenance  configuration parameters
Tip: If Valid is set to “Yes” for more than one configuration, the first
configuration with Valid set to “Yes” is used at reboot.
The previously saved 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.
7.8.1 Saving the current configuration

Navigate to the Maintenance  Configurations page according to the previous section.
When the Save Configuration button is clicked, the Save Configurations page appears:
Figure 51. Save configuration
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.
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.
7.8.2 Download of configurations to PC

Note: Changes in a valid configuration occur when 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 Id of the configuration to be modified in the Id column. The ‘Edit
configurations’ page appears. On this page, nothing can be configured in the
configuration itself, but the valid flag can be changed. The configuration can also be
deleted or downloaded to a PC.
Figure 52. Edit, delete or download 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 or removed here is the ‘Valid’
flag. Make the alteration and click on the OK button to save the setting.
Click on the Download File button to download the configuration to the workstation/PC.
A window opens and the user is asked to provide a file name for the configuration (to be
used on the PC).

7.8.3 Upload configurations from PC
To upload a prepared configuration file to the unit, use the following procedure:
Navigate to the Maintenance  Configurations page according to the previous section
and click on the Upload Configuration button. The Upload page appears.
Figure 53. Upload configuration page
Click on the Choose File button. A standard File Open dialogue box appears. Select the
desired file and click the OK button.
The Confirm Upload Configuration page appears.
Figure 54. 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.

7.8.4 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 the previous section. Click
on the name of the configuration to be modified in the 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 the node. The node becomes active
with the configuration file with the lowest Id number that is ‘Valid’.
7.8.5 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 (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.
7.9 Software (maintenance)

New software and firmware is easily installed on the Nimbra switch directly from the web
interface. The newly installed 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, provided that the customer has an active support contract.
It is shown how well the different soft- and firmware modules are aligned to a single GX-
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, vulnerable-weak and none.

The meanings of the different variable values are:
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
strong some running 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
weak running 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
Figure 55. Possible values for the parameter ‘System alignment status’

Figure 56. 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 57. Maintenance, Software, Install page. Installation is supported for
both http and ftp servers.
For a better understanding of what this web page does, consult the Up- and Downgrading
chapter.
7.10 SSL Certificate
Figure 58. SSL Certificate page
SSL Certificates can be obtained as files from reputable certificate issuers (as files) and
installed on the nodes via the Upload button. Alternatively, SSL certificates can be self-
generated from the Generate button.

The present SSL certificate is shown on this page, with common name, organization,
issuer and validity. Certificate details are presented if the Show Details button is
selected.
Figure 59. SSL certificate details
In order to download a certificate, the button Choose File must first be selected. A
window is then opened of the file system and the appropriate file can be selected.
When the file has been selected, the button Upload is no longer grayed out. Clicking on it
will upload and install the new certificate. In case the selected file is not an SSL certificate,
the request is silently ignored.
A new, self-generated certificate is obtained by clicking on the button Generate.

Figure 60. Configuration page for self-generated SSL certificate.
On this page, the common name is displayed as the string entered in the URL field to find
the node in the first place (in our case, this is the IP address). Default issuing organization
is Snakeoil Ltd, default country is SE and default validity is 365 days.
7.11 Alarm I/O (configuration)

In the current release, alarm in- and output signals are supported for Nimbra 310, 320,
380, 390 and all Nimbra 600 series nodes.
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 300
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 300). For
Nimbra 600, pin #7 (of both contacts) is connected to ground and is not configurable.
To configure pins of Nimbra 300, 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 61. Alarm I/O configuration page for Nimbra 390.
A new submenu appears.
Figure 62. Alarm I/O configuration direction page, shown for pin #2.
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 63. 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:
Variable/Parameter Default Possible values

Cause N/A Describes the
cause of the
alarm
Type Equipment Communications
Environmental
Equipment
Processing error
Quality of Service
Severity Warning Warning
Minor
Major
Critical
Object name N/A Name of the pin
under
configuration
Text GPIO port Text string
active
Figure 64. Alarm I/O configuration variables/parameters
Proceed by clicking on the Applyor 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 65. Alarm I/O configuration page for Nimbra 680.
A new submenu appears, when the unused link of a particular pin is clicked.
Figure 66. 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:8 on the main Alarm I/O configuration page).
Figure 67. 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
Applyor OK button.
Figure 68. Alarm I/O configuration page for a specific criterion.
Select ‘Type’, ‘Severity’ and ‘Text’ according to preferences.

Click on the Apply button to make the setting and stay on the configuration page or on
the OK button to make the setting and exit to the previous menu.
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.

For Nimbra360, gpio1:0:2 to gpio1:0:9 pins are shown as absent. They are not
implemented in hardware.
7.12 Cooling
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 69. Drop-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, where staff normally isn't located close to the
nodes.
Balanced This profile is default and a compromise between profiles ‘Silent’ and ‘Cool’.
Suitable for normal operating conditions.
Figure 70. Cooling profiles available in Nimbra 600 series
7.13 Software program error alarm

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 71. 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 72. The nodeinfo file is generated from the Status  Nodeinfo link.

Figure 73. Generation in progress of the nodeinfo file.
Figure 74. 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.

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, SSH, HTTP, HTTPS 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,
SSH 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 (DTM) 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 a regular 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 75. Two separate DLE segments.
Note: Note that the DLE segment is a logical segment. The physical
User's Guide Control Network  80

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 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
IP network.
Routing will load the Control Module CPU of the gateway node. The number of packets
that can be routed will therefore be limited by the capacity of 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
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 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 76. A DLE segment with channels between DLE clients
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.

Critical parameters
Nimbra 300
Nimbra 600
Maximum recommended number of DLE clients for one DLE 16 64
server
When working as gateway: maximum recommended 255 1000
number of nodes to route traffic for
Maximum recommended number of DLE clients on a node 3 3
Figure 77. 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 78. 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 79. 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 80. 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 81. The Control network web page
The sub-sections (links): In-band servers, In-band clients, IP interfaces, IP routing, Firewall
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 82. 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 83. 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).
Note: For compatibility reasons, the DTM Channel Protocol of DLE

servers will always be DCP Version 2.
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: When services must be taken down in a node, in order to be subsequently
re-established, services may be taken down (and re-established) with high or normal
precedence. It is recommended to be restrictive with usage of high precedence.
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 84. Page for configuration of destination to a peering (back-up) DLE
server. Observe that destinations to clients are not set on this page.
With the Force button, it is possible to restrict the route to the back-up DLE server to
first, second or third source route defined for the destination.
Figure 85. Page for configuration of the destination to the back-up DLE server.
Source routes must be defined in the node before they can be used.
Destination DTM node is the DTM address/host name to the back-up server
and Destination DSTI is the back-up DLE server’s DTM Service Type Instance
number.
8.6.4 Statistics for In-band servers

On this web page, no configuration is made but only the traffic statistics to and from the
back-up DLE server is shown.

Figure 86. Control network statistics let the user see traffic stats to and from
back-up DLE servers.
8.7 In-band clients

An In-band clients 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 network  In-band clients link.

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

Default value: Down
Type: Boolean variable (only two states possible)
Range: Down, Up
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: 1 for first defined client on the node, 2 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. Keep default if there is
no back-up 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: 65535
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 Applyor OK.
8.7.2 Statistics for In-band clients

On this web page, no configuration is made but only the traffic statistics to and from the
back-up DLE client is shown.
Figure 88. Control network statistics let the user see traffic stats to and from
the DLE client.
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 89. 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 90. IP interfaces page
eth0 (Nimbra 300) or eth-front (on NC in Nimbra 600)/eth-aux (on GPIO module in
Nimbra 600): The physical address of the Ethernet interface
dlec0, dlec1, dlec2: The logical addresses of In-band clients
Click on the Id of the interface to be changed.
Figure 91. IP interface configuration page for dlec0
On this configuration page, the security zone for the dlec interface is set. Security zone is
explained later under the Firewall heading. After one of the four available zones (zone0,
zone1, zone2 and zone3) have been selected, additional configuration can be made by
clicking on the IP address and set IP address and netmask. Alternatively, click on the Add
address... button in order to add another IP address. Multiple IP addresses are allowed on
the interfaces.

Figure 92. IP address configuration page
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.
Physical interfaces have additional parameters to configure. In addition to security zone,

there is an administrative status (up/down) and an advertised media setting to be made.
Figure 93. IP interface configuration page for eth-front

8.10 IP routing configuration
8.10.1 Routes
In order to enable routing outside an In-band segment, routes have to be configured from
the segment to the wider 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 link to get an overview of the defined IP
routes.
Figure 94. IP routing 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 out” by the routing entry.
The first entry, 127.0.0.0 is for the local host, which always will be there. Three entries
describe that you can reach 192.168.101.0, 192.168.111.0 and 192.168.201.0 directly
without gateway. Also, the first IP entry is shown with a gateway. This entry describes
how to reach all other IP-addresses through the gateway 192.168.101.1.
In order to set up a new route, the tab ‘Configuration’ should be used.

Figure 95. IP route configuration page. Default means all addresses not
otherwise mentioned.
Figure 96. IP route configuration add page. On this page, new routes are
entered with needed netmasks and gateways.
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. Mandatory
netmask 255.255.255.0 (or netmask 0.0.0.0 for the default
route)
Gateway The IP address of a node that is connected to the outside Mandatory
network and that you want all traffic to traverse.
Figure 97. Configurable routing parameters

8.10.2 Firewall
The firewall in the node allows the user to distribute all logical and physical interfaces to
one of four available zones, numbered from zone0 to zone3. The default setting is that all
physical interfaces are allocated to zone0 and all DLEC interfaces to zone2.
By default, zones 0 to 2 all use the predefined ‘Security profile 0’, shown below:
Figure 98. Security profile 0, default for zones 0 to 2, allows for the most
common applications. Anything that is not expressively allowed is prohibited.
There are also two other predefined security profiles: allow all and block all. Furthermore,
additional security profiles can easily be user defined.
To configure the firewall, follow the Control network  Firewall link.

Figure 99. Firewall configuration web page
On this configuration page, different security profiles can be set for different firewall
zones. Also, additional security profiles are easily created by using the Add Profile button
under the security profiles heading. In addition, the different interfaces can have changed
settings directly from the member interface link, under the zone membership heading.
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 100. 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 is the passphrase used for SNMPv3 authentication of the SNMPv3
user. If empty, then the authentication check is disabled, e.g. security level is
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 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 101. 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 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 the
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 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 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 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 102. 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 103. 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 104. 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 control
configurations’ page. This section describes how the equivalent setup on the 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 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 must not be in conflict with each other. In this
case, unpredictable system behavior may happen.
Setting of a Read-only community name with the value public on the Access control
SNMP configuration page is equivalent to:
snmpCommunityEntry ‘1’ public standardReader localSnmpID - - nonVolatile

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

vacmSecurityToGroupEntry snmpv1 standardWriter writers nonVolatile
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 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 - - -
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 105. 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 106. 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 107. 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 Trunk network
configuration
9.1 Overview of Trunk Network
Figure 108. Trunk network main configuration page
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. Trunks are configured both
under Ethernet interfaces and Trunk interfaces.
The trunk interfaces supported are 8B10B, SONET/ SDH, PDH and IP/Ethernet.
IP/Ethernet interfaces are configured under two separate links; Ethernet interfaces and
Trunk interfaces. The other trunk interfaces are configured under Trunk interfaces.
Additional configuration is also made under Trunk network; DTM interfaces, Links, (DTM)
Addresses and Hostnames, Routing and Performance monitoring (Perf. monitor).
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.
9.1.1 Trunk Modules, Nimbra 300 Series

There are several versions of trunk modules, according to the table below.
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
User's Guide Trunk network configuration  112

2 x OC-12/STM-4 Trunk 622 Mbps SDH/SONET
Module
4 x OC-3/STM-1 Trunk Module 155 Mbps SDH/SONET
4 x DS3/E3 Trunk/Access DS3 45 Mbps/E3 34 PDH
Module Mbps
3 x IP/Ethernet Trunk Module 1 000 Mbps IP/Ethernet,
not for Nimbra
390
Figure 109. Available trunk modules for Nimbra 300 series nodes.
9.1.2 Fixed trunk interfaces for Nimbra 310/320/360/380

Nimbra 310/320/360/380 has integrated fixed 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.
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 622 Mbps SDH/SONET
360/380)
OC-3/STM-1 Trunk Interface (2 ports 320; 4 ports 155 Mbps SDH/SONET
360/380)
IP/Ethernet Trunk Interface; requires Nimbra320, Nimbra 1000 Mbps IP/Ethernet
360, HW version B or Nimbra 380 (2 ports)
Figure 110. Fixed trunk interfaces for Nimbra 320/360/380.
Fixed Trunk Interfaces, Nimbra 390 Data rate Category

IP/Ethernet Trunk Interface; 4 ports 1000 Mbps IP/Ethernet
Figure 111. Fixed trunk interfaces for Nimbra 390.
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 112. Fixed trunk interfaces for Nimbra 310.
9.1.3 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 modules for Nimbra 300.

Trunk Modules Data rate Category
OC-192/STM-64 Trunk Module 9 952 Mbps SDH/SONET
4 x OC-48/STM-16 Trunk 2 488 Mbps SDH/SONET
Module
4 x OC-12/STM-4 Trunk 622 Mbps SDH/SONET
Module
4 x OC-3/STM-1 Trunk Module 155 Mbps SDH/SONET
6 x IP/Ethernet Trunk Module Configurable, up to 1000 Mbps IP/Ethernet
per interface
10 GE (Trunk) Module Configurable, up to 10000 Mbps IP/Ethernet
per interface
Figure 113. 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).
9.2 Dynamic Trunk Capacity

Dynamic Trunk Capacity is a new feature in GX4.13. It is available in IP/Ethernet trunks, on
both 1 GE and 10 GE bandwidths on Nimbra 600 series nodes. It is also available on the
build-in, fixed IP/Ethernet trunks in Nimbra 390. The feature makes it possible to only
allocate resources on the IP trunk for the defined channels and not for the unused
capacity. This capacity can then be used for other traffic with lower priority.
On the advanced configuration page, it is possible to choose compression ratio (min
dynamic trunk ratio), between one and 100 percent. With the parameter is set to 100%,
no compression takes place at all. If set to 1 %, the free capacity is compressed to 1 % of
its value without compression.
The channels using the trunk are not directly affected. A change in dynamic trunk
capacity is processed faster than channel establishment of new channels, so the feature
does not add to channel set-up time. What is affected, however, is the delay on the trunk.
Heavy (1 %) compression ratios have a typical delay of about 4 ms, whereas more
moderate ratios (50 %) have a typical delay of about 40 µs. This is the most important
drawback of Dynamic Trunk Compression.

Figure 114. Illustation of Dynamic Trunk Capacity. Minimum DTC is
configurable, but it has to be at least 1% of the full capacity of the IP Trunk.
9.3 Configuring 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. They are described separately from the other trunks as they are
configured on two link; other trunks are configured from the Trunk interface link only.
9.3.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.
Figure 115. The interface structure of the IP trunk.

Configuration of IP/Ethernet trunks starts from the link Trunk network in the left column.
Clicking on this link displays additional links, among others Ethernet Interfaces and
Trunk Interfaces. These two links are used for configuration of the IP/Ethernet interface.
Configuration must be carried out in the order Ethernet Interface and Trunk Interface. In
particular, the IP Trunk interface is not created automatically, but has to be manually
created after the Ethernet interface is configured.
Figure 116. The first configuration page for IP Trunks.
The 10 GE Trunk Module has two SFP+ /SFP ports, which each can transport up to 10
Gbps/1 Gbps. However, the combined capacity for both ports is limited to 10 Gbps, but
the capacity can be arbitrarily divided between the two ports.
SFP+/Multirate modules work at 10 Gbps, when inserted in a 10 GE trunk module.
SFP+/Multirate modules work at 1 Gbps, when inserted in a 6xIP/Ethernet trunk module.
SFP modules operate at 1 Gbps, when inserted in either a 10 GE or 6xIP/Ethernet trunk
module.
The regular 6 x IP/Ethernet Trunk Module use regular SFP ports.

9.3.2 Ethernet Interface overview
The starting web page for Ethernet Interfaces is shown below.
Figure 117. Ethernet Interfaces page, Overview tab
Figure 118. Ethernet Interfaces page, Statistics tab
The table on the overview tab lists the Ethernet Interfaces that are present in the unit. For
each interface, the following is presented: Name (name of the interface), Type (of
interface), Adm (Administrative status of the interface), Oper (Operational status of the
interface), Speed (of the interface) and Purpose (String entered by the user do specify
further the interface). The interface name is written (for trunk interfaces) as “ethtX:Y”,
where X is position of the module in the node and Y position of the port on the module.
The table on the statistics tab lists the Ethernet Interfaces and their packet counters. For
each interface, the following is presented: Name (name of the interface), Rx Accepted
(Number of received packets accepted), Rx dropped (Number of received packets
dropped), Rx Errors (Number of received packets with errors), Tx sent (Number of sent
packets) and Tx Drops (Number of outgoing packets that are dropped and thus not sent).

9.3.3 Configuration of IP/Ethernet trunks – Ethernet interface
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 Trunk Network 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. IP trunks defined on the modules are named according to the
same principle, but as there is no coupling between the physical port and the logical IP
trunk, IP trunk numbering starts in the order the IP trunks are defined in the module. In
other words, etht-7:2 can have ipt-7:1 on top of it. ipt-7:1 rather denotes the first IP-trunk
set up on the IP/Ethernet module placed in slot 7. It is suggested that the IP trunks are
labeled to make them easy to associate with corresponding IP interface. Example of IP
trunk numbering is ipt-2:3, ipt-2:6 and ipt-5:2. Both types of trunk module have the same
nomenclature for the created (IP) trunks.
Module name Interface data rate Number of

(Mbps) interfaces/module
10 GE Trunk Module 10000 2
6 x IP/Ethernet Trunk Module 1000 6
Figure 119. 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-3: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 120. Basic (configuration) page of the Ethernet interface of the
IP/Ethernet trunk etht-3:1, Basic settings.
9.3.4 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
Trunk network  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.
9.3.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 on IP Trunk links connecting nodes that are either part of the
Nimbra 600 family or Nimbra 390. Between Nimbra 600 and other Nimbra 300 nodes, 1D
FEC is possible. Capabilities in the nodes are always displayed in the web interface.
Figure 121. Structure of the FEC matrix for FEC Modes 1D and 2D.
Forward error correction is configured under Trunk network  Trunk interface 

Particular interface basic tab.

9.3.6 Basic Ethernet Interface Variables and parameters
Figure 122. Basic Ethernet Interface Variables.
9.3.6.1 Interface name

Type: Character string (interface name of type etht-x:y)
Description: The name of the Ethernet trunk interface that is configured
9.3.6.2 Administrative Status

Default value: Down
Type: Down, Up
Description: The module can be set to administratively active (Up) or inactive (Down).
9.3.6.3 Operational status

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

Type: Time on format hh:mm:ss
Description: Time stamp of the last change of the configuration.
9.3.6.5 Purpose
Type: text string, up to 255 characters long
Description: A text tag that can be entered by the user for various purposes.
9.3.6.6 Interface type

Type: Type of physical interface

Description: The physical interface is stated, e.g. 10Gbase-SR, 1000Base-T.
9.3.6.7 Active speed

Type: Speed
Description: Speed of the link from the Ethernet interface
9.3.6.8 Active duplex

Type: Duplex
Description: Full/Half Duplex or Simplex used on the interface. Currently only Full Duplex
is supported.
9.3.6.9 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.
9.3.7 Advanced Ethernet Interface Variables and Parameters
Figure 123. Configuration page of the Ethernet interface of the IP/Ethernet

trunk etht-5:1, Advanced settings.


Description: The name of the Ethernet trunk interface that is configured
9.3.7.2 Auto negotiate

Default value: ‘On’
Type: Boolean variable
Range: ‘On, ‘Off’
Description: The variable tells if the autonegotiate feature is enabled or not.
9.3.7.3 Advertised speed

Default value: ’auto’
Type: Drop-down menu with allowed values, 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.
9.3.7.4 Active speed

Type: Speed
Description: Speed of the link from the Ethernet interface
9.3.7.5 Active duplex

Type: Duplex
Description: Full/Half Duplex or Simplex used on the interface. Currently only Full Duplex
is supported.
9.3.7.6 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.
9.3.7.7 Pluggable interface

Type: sfp-x:y
Description: Link to the SFP-interface inserted in port x:y (x=module position in node,
y=interface position on module)
9.3.7.8 Transceiver temperature

Type: Temperature
Description: Measured temperature on the transceiver chip
9.3.7.9 Transceiver laser bias

Type: Current
Description: Laser bias current measured in transceiver chip
9.3.7.10 Transmitter power

Type: Optical power
Description: Optical power transmitted by the transceiver
9.3.7.11 Receive power

Type: Optical power
Description: Optical power received on the transceiver

9.3.8 Ethernet interfaces - statistics
These statistical counters are specified in IETF RFC 1213 or IETF RFC 2819. In the web
interface, they are available from the Trunk network  Ethernet interfaces page. On
this web page, follow the specific interface and the Statistics tab.
Figure 124. Ethernet interface statistics for a particular interface

The counters are standardized. Their meaning is described below.
9.3.8.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.
9.3.8.2 etherStatsCollisions
Description: The best estimate of the total number of collisions on this Ethernet
segment.
9.3.8.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).
9.3.8.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.
9.3.8.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).
9.3.8.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).
9.3.8.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.
9.3.8.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).
9.3.8.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.

9.3.8.10 etherStatsPkts
Description: The total number of packets (including bad packets, broadcast packets,
and multicast packets) received.
9.3.8.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).
9.3.8.13 etherStatsPkts1519ToMaxSizeOctets
between 1519 and the highest allowed frame size.
octets).
octets).
9.3.8.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).
9.3.8.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.
9.3.8.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.

9.3.8.20 ifInErrors
Description: The number of inbound packets that contained errors preventing them
from being deliverable to a higher-layer protocol.
9.3.8.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.
9.3.8.22 ifInOctets
Description: The total number of octets received on the interface, including framing
characters.
9.3.8.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.
9.3.8.24 IfInUnknownProtos
Description: The number of packets received via the interface, which were discarded
because of an unknown or unsupported protocol.
9.3.8.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.
9.3.8.26 IfOutErrors
Description: The number of outbound packets that could not be transmitted because of
errors.
9.3.8.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.
9.3.8.28 IfOutOctets
Description: The total number of octets transmitted out of the interface, including
framing characters.
9.3.8.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.
An overview of Ethernet statistics for all interfaces on a particular module are found under
the Trunk network  Ethernet interface  Statistics tab.

9.3.9 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 tab, to create (and configure) an IP trunk.
A list of all defined trunks is found when this tab is selected.
Figure 125. Ethernet interface configuration – Trunks page, with three IP trunks
defined.
Figure 126. Trunk created with no bandwidth (default)
The trunks are numbered ipt-x:y, where x is the device number and y is a sequential
number at the time of the creation of the particular trunk.
In GX 5.1, creation of multiple trunks on a common physical interface is allowed. The
maximum number of IP trunks on different objects is described below.
Object Number of IP Trunks allowed

10 Gigabit Ethernet Trunk Module 16
10 Gigabit Ethernet Access Module 16
6 x IP/Ethernet Trunk Module 6
Nimbra 390, on all four interfaces 16
Figure 127. Allowed number of IP trunks on different objects.

In the illustration below, an etht interface with multiple IP trunks is shown.
Figure 128. Multiple IP trunks defined on a single etht interface.
To configure the different trunks, click on the particular trunk link (shown below is ipt-
3:1). This link takes you to the basic configuration page of the IP trunk.

9.3.10 IP Trunk – Basic (settings)
Figure 129. Configuration of a new IP trunk, Default basic IP trunk configuration

page
The tabs of the IP Trunk configuration page are seen on the first (basic) configuration
page are Basic, Advanced, Alarms and Statistics.
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.

Default value: Down
Type: Binary
Range: Down, Up
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.
9.3.10.2 Maximum transmission unit

Default value: 1500 (bytes)
Type: integer
Range: 105-1500 (bytes)
Description: IP maximum transmission unit, including IP overhead (64 bytes).
9.3.10.3 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.
9.3.10.4 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.
9.3.10.5 Subnet mask

Range: 0.0.0.0-255.255.255.255
Description: This is the subnet mask of the configured trunk interface.
9.3.10.6 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.
9.3.10.7 Remote IP address


Range: 0.0.0.0-255.255.255.255
Description: This is the IP address of the remote (peer) trunk interface.
9.3.10.8 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 (9.3.5Forward error correction).
9.3.10.9 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.
9.3.10.10 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.

9.3.11 IP Trunk - Advanced (settings)
Figure 130. Default advanced IP trunk configuration page
The parameters that can be configured on this page are described below.

9.3.11.1 Min dynamic trunk ratio
Default value: 100 %
Type: real
Range: 1 – 100 %
Description: The lowest bandwidth that the trunk can use in compressed mode. With the setting
100 %, no trunk compression is made and the feature is disabled.
9.3.11.2 Transmitted frame type

Default value: “untagged”
Type: drop-down menu
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.
9.3.11.3 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.
9.3.11.4 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. As it is
only relevant for these two cases, it is grayed out when transmitted frame type is untagged.
9.3.11.5 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.
9.3.11.6 Time to live

Default value: 30
Type: integer

Range: 0-255
Description: Maximum number of hops allowed between originating interface and terminating IP
interface.
9.3.11.7 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.
In Nimbra 600 nodes, due to a minimum buffering of packets, the jitter tolerance will
always be at least 2 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 1000 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 0,25 ms (2/8000).
In Nimbra 300 nodes, 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.
9.3.12 IP Trunk - Alarms tab

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

Figure 131. Default alarms IP trunk configuration page
9.3.12.1 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.
9.3.12.2 Suppress alarms - RDI

Default value: “yes”, i.e. ticked
Type: binary, checkbox
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.
9.3.12.3 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).
9.3.12.4 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.
9.3.12.5 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.
9.3.13 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 132. Basic IP Trunk configuration page with (configurable) parameters
and (displayed) variables.
9.3.14 Basic variables

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

Description: The name of the underlying physical Ethernet interface. A link is provided
for fast access to the relevant configuration page.
9.3.14.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.
9.3.14.4 Operational status

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

Type: Integer
Description: The highest possible Tx bitrate that can be configured on this interface.
9.3.14.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.
9.3.14.7 Rx bitrate
Type: Real
Description: The variables Rx slots and Rx bitrate are proportional. R
9.3.14.8 Max Rx Bitrate

Type: Integer
Description: The highest possible Rx bitrate that can be received on this interface.
9.3.14.9 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.
9.3.15 Advanced variables

The advanced variables are the variables that are presented on the advanced
configuration page of the IP trunk.

Figure 133. Advanced IP Trunk configuration page with (configurable)
parameters and (displayed) variables.

Description: The name of the IP trunk interface that is configured

9.3.15.2 Physical interface
Description: The name of the IP trunk interface. A link is provided for fast access to the
relevant configuration page.
9.3.15.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.
9.3.15.4 Dynamic trunk delay

Type: Real
Description: The additional delay caused by the use of Dynamic Trunk Capacity.
9.3.15.5 Transported Tx slots

Type: Integer
Description: Number of transmitted Tx slots used currently
9.3.15.6 Transported Rx slots

Type: Integer
Description: Number of received Rx slots currently
9.3.15.7 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.
9.3.15.8 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.
9.3.15.9 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.
9.3.15.10 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

minutes. Sample number 99900 is identified as this value. As soon as one measurement is
finished, another is initiated.
9.3.15.11 Path delay variation (0.1%) (µs)

Type: real number
Description: The 0.1% IP path delay variation value (µs). The value is found from a
minutes. Sample number 100 is identified as this value. As soon as one measurement is
finished, another is initiated.
9.3.15.12 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.
9.3.15.13 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).
9.3.15.14 Peer abilities, Min Receive rows

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

Type: integer
Description: The highest FEC Receive rows that is possible on the interface.
9.3.15.16 Peer abilities, Min Receive columns

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

Type: integer
Description: The highest FEC Receive column that is possible on the interface.
9.3.15.18 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.
9.3.15.19 Time transfer

Type: binary (supported, not supported)
Description: Presents version number of the Time Transfer software module.

9.3.15.20 Dynamic trunk
Type: integer.integer
Description: Presents version number of the software module Dynamic trunk.
9.3.16 Alarms variables

Variables presented on the alarms configuration IP trunk web page are shown below.
Figure 134. Alarms IP Trunk configuration page with (configurable) parameters

and (displayed) variables.
9.3.16.1 Sync signal status

Type: One of ‘normal’, ‘degraded’ or ‘failed’
Description: The status of the sync signal regenerated from the IP trunk.

9.3.17 Alarms
The IP trunk alarms are also presented on the IP trunk alarms configuration page. Below,
the different alarms are described.
Figure 135. 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:
9.3.17.1 Unequipped (UNEQ)

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

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

Description: This alarm is received when the frame on the incoming signal cannot be
properly aligned.
Severity: Critical
9.3.17.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

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

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

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

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

Description: This alarm is received when Rx path between the nodes cannot be
established.
Severity: Critical
9.3.17.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
9.3.18 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 136. UDP port usage by IP/Ethernet trunk protocols

9.4 Statistics
9.4.1 General
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 order to view the different
statistical counters, follow the proper link.
The statistical measures have been divided into DPP-IP counters available from the Trunk
network Trunk Interfaces  Interface name  Statistics link and Ethernet/IP
counters available from the Ethernet Interfaces  Interface name Statistics link
(display of all counters). An overview of Ethernet statistics for the module is found under
the Ethernet Interfaces  Statistics link
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-3:1).
Figure 137. DPP counters
In addition to the nine counters described in next chapter, there are two counters
dppipMaxConsecutiveMissingFrames and dppipOutOfAlignmentCount. These two
counters are not defined from the illustration in chapter 9.4.2 DPP-IP Trunk level
statistics.
9.4.1.1 dppipMaxConsecutiveMissingFrames
Description: This counter is keeping track of the highest number of consecutive missing
frames. Whenever in a sequence two consecutive frames follow each other, counting is
restarting.

9.4.1.2 dppipOutOfAlignmentCount
Description: This counter consists of two different parts; dppipOutOfPointer and
dppipOutOfAlignment.
dppipOutOfPointer is a counter that keeps track of deviations between the observed
pointer and the expected pointer, derived from the previous counter value.
dppipOutOfAlignment is a counter that is increased under special conditions. First, the
frame sequence number of a frame must deviate strongly from the previous frame (i.e. by
more than 32767). If this happens, the frame is dropped and next frame is considered. This
is called an Out-Of-Sequence event. If there are sixteen consecutive Out-Of-Sequence
events, the dppipOutOfAlignment counter is increased by one and state Out Of
Alignment is reached. To exit this state, three consecutive dpp counters with sequential
frame numbers are needed.
9.4.2 DPP-IP Trunk level statistics
Figure 138. Relationship between the various DPP-IP counters
9.4.2.1 dppipDeliveredFrames
Description: The total number of DPP-IP frames that have been received and delivered to
the DTM interface.
9.4.2.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.
9.4.2.3 dppipDuplicateFrames
Description: The number of DPP-IP frames that were received with a sequence number
of an already processed DPP-IP frame.

9.4.2.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.
9.4.2.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.
9.4.2.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.
9.4.2.7 dppipRecoveredFrames
Description: The number of missing DPP-IP data frames that were recovered by the FEC
procedure. dppipRecoveredFrames only counts data frames.
9.4.2.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.
9.4.2.9 dppipSentFrames
Description: The number of DPP-IP frames that were sent on the DTM interface.
9.4.3 Overview (IP) trunk 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 Trunk network  Trunk Interfaces link. On this
page, the Statistics tab should be followed.
Figure 139. Overview trunk interface statistics
9.4.3.1 Rx Delivered
Description: The number of received packets delivered to higher level (DTM) protocols.

9.4.3.2 Rx Lost
Description: The number received packets lost before delivery to higher level (DTM)
protocols.
9.4.3.3 Rx Corrected
Description: The number of received packets corrected and delivered to higher level
(DTM) protocols.
9.4.3.4 Tx Sent
Description: The number transmitted packets sent towards the Ethernet interface
9.4.4 Overview Ethernet interface statistics
Figure 140. Overview of Ethernet statistics on a module
9.4.4.1 Rx Accepted
Description: Number of received packets accepted by the Ethernet interface.
9.4.4.2 Rx Drops
Description: Number received packets dropped and not sent to the Ethernet interface.
9.4.4.3 Rx Errors
Description: Number of received packets with errors that are corrected and sent to the
Ethernet interface.
9.4.4.4 Tx Sent
Description: Number of packets sent towards the line and the remote Ethernet interface.
9.4.4.5 Tx Drops
Description: Number of packets dropped and not sent towards the line and the remote
Ethernet interface.

9.5 Editing SDH/SONET Trunk Interfaces
The basic structure of the configuration page is kept constant for the various interfaces in
all Nimbra nodes.
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 The operational status of the board
status
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 141. 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 142. 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 143. Configurable parameters for common interfaces
The configurable Advanced parameters for SDH/SONET trunk modules are:

Parameter Description Comment
Transmit Define the sync source for the transmitting (Tx) Not used for OC-
sync source interface. The parameter can have two values, 48/STM-16 X-ADM
‘interface’ and ‘loop’. The default setting is Trunk Module or
‘interface’, which uses the node sync source as Nimbra 600 OC-
source for the outgoing Tx interface. ‘loop’ means 48/STM-16 Trunk
that the incoming Rx signal is reused on the Tx modules
interface. This setting should not be used at both
ends of 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 Path overhead Used on 4 x OC-
byte The C2 byte in the path overhead specifies what 3/STM-1 Trunk
type of network is used. ITU-T has not yet assigned Module and OC-
a C2 value for DTM networks, so for DTM networks 48/STM-16 X-ADM
use ‘05’ as the ITU-T ‘experimental’ value. Module
Signal Delay time for 1+1. The time that the nodes waits for
failure filter the underlying network (SDH/SONET/WDM) to re-
period 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 according to ITU G.806 for the interface. 48/STM-16 X-ADM
(DEG) Period, default 5 sec. Trunk Module or
period OC-3/STM-1 (DTM
150) Trunk Module
Degraded Configuration parameters for the “Degraded” alarm, Not used for OC-
defect according to ITU G.806 for the interface. 48/STM-16 X-ADM
(DEG) Number of background block errors. Default 1200. Trunk Module or
threshold OC-3/STM-1 (DTM
150) Trunk Module
Figure 144. 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 145. 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 Alarm indication signal, line or defect detected by upstream
signal, line (AIS-L) SONET/SDH network interface.
Alarm indication Alarm indication signal, path or defect detected by upstream
signal, path (AIS-P) SONET/SDH network interface.
Remote defect Remote defect indication, line or defect detected by
indication, line (RDI-L) downstream SONET/SDH network interface.
Remote defect Remote defect indication, path, RDI-P or defect detected by
indication, path (RDI- downstream SONET/SDH network interface.
P)
Payload mismatch Payload mismatch.
(PLM)
Degraded signal Degraded signal
(DEG)
Loopback Loopback alarm, NA
Figure 146. Alarms parameters
As an example, configuration of one interface on the OC-192/STM-64 Trunk Module is

given.

Figure 147. Configuration page of the OC-192/STM-64 module, basic tab.

Figure 148. Configuration page of the OC-192/STM-64 module, alarms tab. This
page displays the status of possible trunk alarms, but no configuration is made
from here.
9.5.1 Asymmetric alarm generation

When the DTM link is taken down between a Nimbra 680/688 and a Nimbra 300 series
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 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.

RDI-P in iov101 (Nimbra 360) UNEQ in iov101 (Nimbra 360)
UNEQ in iov136 (Nimbra 680) No alarm in iov136 (Nimbra 680)
iov101 iov101
ASI (8p) DS3/E3 (4p) ASI (8p) DS3/E3 (4p)
STM-1 (4p) GbE (1p) STM-1 (4p) GbE (1p)
360 360
3:1 3:1
3:2 3:2
JPEG2k (8p) JPEG2k (8p)
Video (8p) Video (8p)
GigE (8p) ASI/AES (8p) GigE (8p) ASI/AES (8p)
STM-16 (4p) STM-16 (4p)
40 Gbps SWA 40 Gbps SWB 40 Gbps SWA 40 Gbps SWB
NCA NCB NCA NCB
680 680
iov136 iov136
Figure 149. 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.
9.6 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
name in the 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
interface for the 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 150. 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.
All: When marked, all alarms are suppressed.
AIS: Alarm Indication Signal.
RDI/RAI: Remote Defect Indicator/Remote Alarm
Indication
Figure 151. Configurable parameters of the DS3/E3 Trunk Interface

The Advanced parameters are:
Line build out (E3 For operation with physical cable lengths over 68 m (225 feet), the
mode only) ‘Line build-out’ variable must be selected. With the selection,
operation up to 137 m (450 feet) is feasible. The feature
compensates the frequency content to accommodate for frequency
dependent attenuation and propagation properties of the cable.
SSM/TM code (E3 Synchronization Status Message/Timing Marker code. Can assume
only) values 0-15 or auto. Auto is recommended.
Receive sync Select receive DTM sync source. Either the recovered bit clock
(RX_FSYNC) (Line) or the recovered DTM Start of Frame signal (FSP). Normally
source set to Line, but if 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 Delay time for 1+1. The time that the nodes waits for the underlying
filter period network (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,
(DEG) period according to ITU 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,
(DEG) threshold according to ITU 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
information page); 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 152. 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
(UNEQ/IDLE) that the 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 Alarm indication signal, line or defect detected by upstream
signal, line (AIS) network interface.
Remote defect Remote defect indication or defect detected by downstream
indication, line network interface.
(RDI/RAI)
Payload mismatch Payload signal label mismatch.
(PLM)
Degraded signal Degraded signal.
(DEG)
Figure 153. 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 154. Edit the Trunk parameters on a DS3/E3 Trunk Interface, here shown
for E3.

Figure 155. Alarms of a DS3/E3 Trunk Interface, presented on the alarms tab.
9.6.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.

9.7 DTM Interfaces
DTM interfaces are listed under Trunk network  DTM Interfaces.
Figure 156. Listing of DTM interfaces in a node
In order to configure a particular interface, click on the link in the listing. In the text,
interface dtm1:1 is configured.

Figure 157. Configuration of a DTM interface
The configurable parameters for the DTM Interface are:
Administrative Status Down (disabled)
Up (enabled)
Purpose A text field where a descriptive name name can ble
given.
Link class Link class is a property of the link. It tells how a faulty
DTM link is handled and can have three different values:
normal, persistent or nailed. It is described in chapter 14
Channel Persistence.
Control channel capacity There is always a control channel using one slot per
DTM frame, which is the default. It is configured in the
web as 0 slots, so the number entered in this box is
really the control channel capacity minus one
(expressed in slots).

Enable dynamic routing This checkbox is by default ticked, i.e. dynamic routing
is selected. If not ticked, static routes must be
configured for the interface. DTM routing is described in
chapter 9.11Routing.
Metric for dynamic routing The “cost” of using the interface in DTM routing. The
selected route is determined when a service is set up.
Among possible routes, the route with least “cost” is
selected.
Figure 158. Configurable parameters of the DTM Interface
9.8 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 established. For each link id
there should be two addresses; the node address and the address to the remote node.
The link-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 the node
that the interface is located in.
Each link starts with an Id, which is equal to the Id 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 Trunk networks  Links link. The Links page appears.
Figure 159. 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.9 Addresses
This chapter describes how to configure the (DTM) addresses of the unit. The address
must be configured before any configuration of service can be made.
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 Trunk network link; then click on Addresses. The addresses’ configuration
page appears.
Figure 160. Addresses’ page
The table shows information of the configured addresses as follows:

Type of DTM address: The configured (primary) 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.9.1 Adding a DTM address

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

Figure 161. Add DTM address page
Enter the DTM address and whether the address is Primary or not and then click OK. The
(DTM) addresses’ page will reappear with the new address listed in the table.
Back up the configuration changes and restart the node. This configuration change,
different from all other configuration changes, needs a restart of the node to become
active.
9.9.2 Editing or deleting a (DTM) address

Go to the addresses page from the previous chapter and click on the address that is to be
revised or deleted. The following page appears:
Figure 162. Edit or delete DTM address web 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.10 Hostnames and hostname search

Nodes in a DTM network can be assigned names with the hostnames function.
Hostnames are configured locally in each node and used as aliases for DTM addresses.
To configure hostnames, click on the link Trunk network  Hostnames. The following
page appears.
Figure 163. 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 in the network; all the nodes
in the network must know all the hostnames!
9.10.1 Adding a host

Go to the hostnames page and click on the Add host button. The following page appears:

Figure 164. 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 hostnames. The names can consist of letters, numbers
and characters dot ‘.’ and dash ‘-‘, but they 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.
9.10.2 Hostname search

A list of hostname suffixes may be defined in the web interface, under the hostname
search tab. The implemented completion function searches for a match, starting with the
top suffix defined in the list.
Figure 165. Editing DTM hostname search suffixes is done from the Search tab
under the Trunk network  Hostnames link. This example with lab,
academy.se, netinsight.net makes it possible, for example, to name the

node node10.academy.se but still only use node10 as hostname for
configurations.
Hostname search entry(suffix) Full name Short name

lab iov101.lab iov101
academy.se node5.academy.se node5
netinsight.net iov072.netinsight.net iov072
netinsight.net cus033.netinsight.net cus033
Figure 166. 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.10.3 Editing or deleting hostnames

Navigate to the Hostnames web page and click on the address for the host to be edited or
deleted. The Edit Hostnames page appears.
Figure 167. Editing or deleting DTM hostnames
Change the parameters and click Applyor ‘OK.

To delete a host, click the Delete button. The DTM hostnames page reappears with the
host removed from the table.
Note: Changes to a hostname do not affect channels that have

already been established. The hostname table is only
consulted when a new channel is established.

9.11 Routing
9.11.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 One nexthop per All possible nexthops to
to reach a destination? destination the destination.
Address type IP address DTM address
Figure 168. Differences between routing in an IP network and a DTM network
This section describes how to configure DTM routing. There are two different ways to do
this:
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.11.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 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 nodes
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 on the
Trunk network  Routing page. The routing table consists of a number of routing
entries. To set a new entry, click on the Add Source button.

Figure 169. Routing
Click on ‘Add source’ or the specific link that is to be edited or deleted; the configuration
page for a static route appears. To edit or delete an already existing static route, click on
the DTM address of the route (underlined).
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 Applyor 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; to remove the route, the Delete button
should be used in the second step.
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 can use to reach the 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.
9.11.3 Dynamic routing

Instead of configuring the routing tables manually in each node; a routing protocol can be
used to route automatically. This is called dynamic routing and the used routing protocol
in DTM networks is called DRP (Dynamic Routing Protocol).
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
No entry errors
The DRP Protocol is a routing protocol that is very similar to OSPF, but it has been
adapted to the unique characteristics of DTM. 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/interfaces 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.
To set the dynamic routing parameters, click on the Dynamic Routing tab on the Trunk
network  Routing web page.
Figure 170. Dynamic routing


The goal of DRP is to find the 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 outgoing
interfaces to 1 and the cost for passing through all nodes to 0 (i.e. to use the default
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, with default value 0.
Interface metric: The cost of setting up an outgoing channel via this interface, with
default value 1.
Enable: Allows the node to communicate and exchange routing information with
neighboring nodes via this interface? 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. 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-point 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 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.
Detect default gateway: Ticking this box forces the node to automatically find its
gateway. This is only relevant for end-nodes. For switches, the box is grayed out (default).
Detect from neighbors: This box is only visible when the user selects area number ‘Select
from neighbors’. Whenever it is visible, it is by default 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 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 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 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-information distributed between two
different operators.
9.11.4 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 171. 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.11.5 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 172. 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.

1
2 3 5
Figure 173. 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.11.6 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 171/Figure 174 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.11.7 Directly Connected Areas
Area A1 Area A2
X.17.01.3A X.17.02.21
Figure 174. 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.11.8 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 175. 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.11.9 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.11.10 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.11.11 Addition of a dynamic routing entry

To add a dynamic route, follow the Trunk network  Routing link. Click on the Add
source button. The static routing web page appears.
Figure 176. Dynamic routing is made by changing the Type parameter from
Static to Link prefix or Area prefix.
Figure 177. Dynamic routing, with available Type selections.
For dynamic routes (i.e. not static), the type could be set to:
9.11.11.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
the Dynamic routing tab of the Trunk network  Routing link) and adding a link-prefix
route in node s1.

X.17.01 n1
X.17.02 n2 s1
X.17.03 n3
Figure 178. 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.11.11.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.

10 Synchronization
10.1 General
This chapter describes synchronization principles of DTM networks (ETSI ES 201 803) and
the specific DTM feature time transfer. While many aspects of network synchronization
principles are 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 can be transported over
SDH/SONET as well as over PDH (DS3/E3) or 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. In addition, the optional time transfer feature of DTM networks
allow for phase and time alignment of nodes and services.
10.2 Synchronization selection and DSYP

The overall goal of the synchronization selection and DTM Synchronization Protocol
(DSYP) is to select a common Timing Reference (TR) throughout the full network, in order
to ensure that there are no frequency errors, as these cause data-loss, as well as provide
stable signal over the various service interfaces. DSYP steers the synchronization
distribution through-out the network, but does not itself transport the synchronization
signal. The synchronization signal is transported by synchronization interfaces and trunk
interfaces. The goal of the synchronization routing is that all nodes in a network are
synchronized to one reference in a master-slave scheme.
All clocks that can provide timing to the network are referred to as a Timing References
(TR), and configuration at each timing reference then provides administrative input to the
automatic selection process.
Each node has a number of timing sources consisting of external clock signals, internal
clocks and trunk interfaces. Each timing source represents a timing reference as supplied
somewhere in the network, where it enters in form of an external clock signal or internal
clock timing reference. The node has a timing source selection process which selects the
best available timing source, based on the info of the timing reference it represents, and
then steers the node clock to use that timing source. The selection is then shared with
other nodes over the trunk interface, to let them know which timing reference the node
represents, using DSYP messages. In practice the DSYP message handling and timing
selection process is referred to as DSYP.
The DSYP message is referred to as a Timing Reference Announcement (TRA), holding all
the necessary values for the neighbor node, over a DTM trunk. The TRA contains
information about the selected timing reference (Node ID and priority level of the timing
User's Guide Synchronization  178

reference, number of nodes traversed and Node ID of up to two previous nodes in the
path to the timing reference).
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 timing
reference with highest preference through the shortest available path.
The synchronization selection and DSYP includes a number of methods to ensure
convergence of solution throughout the network as well as to ensure stable behavior and
handling of a number of error-cases.
In the case a timing references comes and goes, the choice of the network may change.
Also, if the network splits into two islands, each island needs to coordinate its
synchronization to a common timing reference. When two such islands are joined, the
combined network needs to agree on a common timing reference. DSYP is designed to
manage this automatically with minimal manual intervention.
If a timing reference fails, affected nodes enter hold-over mode (see 10.5) until a new
spanning tree has been calculated for back-up timing reference. This takes at most a
couple of seconds. In hold-over mode, phase and frequency continuity is maintained, in
order to not affect the quality of transmission.
Furthermore, synchronization loops are eliminated in such topology.
A synchronization loop is when nodes selects synchronization signal from another node in
such a way that it ends up listening to itself. This is a highly unstable system state which
will cause much loss of data so this situation must be avoided. The loop situation also
breaks the basic assumption of being operated by a clock. DSYP includes multiple
methods to detect possible loops or avoiding them.
No manual configuration is needed to avoid loops. DSYP is responsible for dynamically
resolving the loop problem. Alternative paths shall not be disabled to steer the tree
except for very rare conditions, but the operator shall let DSYP use these alternative
paths to achieve the best synchronization distribution the current situation enables.
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 timing reference as network grows beyond 10
nodes.
10.3 Timing source selection

The primary task is to select the best (most preferred) timing reference to the network,
and when agreeing on that, the best (most preferred) path to this source. The operator
configures preference amongst clocks using the timing reference priority value. A low
priority value reflects a high preference while a high value reflects a low preference.
Priority values also have some implied clock quality assigned to them. The value range of
0-11 reflects the SDH G.811 PRC quality, essentially the stability of GPS/GNSS receivers
and Cesium clocks supplied to the network as external clock. The value 12 reflects G.812
SSUA while the value 13 reflects G.812 SSU, thus the SSU/SASE/BITS type of station clock
stability which can either be externally supplied or most often be that of internal clocks.
The value 14 reflects the G.813 SEC type of clock, which is what the majority of nodes
have as their internal clock. The value 15 reflects the Do Not Use (DNU) which is a way to
indicate that this clock is unsuited for any use.
Every DTM node has its own clock or synchronization source. 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 14.

The default clock priority is 14 for all Nimbra nodes.
The typical user configuration is only expected to supply external clocks and assign values
in the 1-11. The value 0 has a special meaning in that not only is the clocks of PRC quality,
but also coordinated and thus behaves as the same clock. This allows for the network to
not attempt to select a single timing source, as it does for all other cases, but to use
multiple timing sources and thus be able to focus on achieving the shortest distance to
any of them. The operator needs to ensure that the multiple source acts as the same
source prior to configure them as priority 0. Figure 181 illustrates this use of priority 0.
Internal clocks have default priority values that reflects their clock stability. In a typical
configuration, they shall never be changed, as they let the clock quality steer selection.
For network not having an external clock, it may be required to steer selection to a node
of a more central position such that short and stable paths can be ensured. This can also
be used as a temporary fix, but this is not expected to be needed in most cases.
After finding the clocks of lowest priority, for those of priority higher than 0, multiple
timing sources can have the same priority and yet the network shall converge to only one.
The Node-ID (MAC) is used as a tie-breaker, and the lowest Node-ID is preferred. For
priority 0, which is used with common clocks, the tie-breaker is not used to select a
unique timing source.
Once the most preferred timing source have been identified, the most preferred path to
that source is selected. The hop-count, that is the number of nodes from the actual timing
source, should be as low as possible. For priority 0 sources the Node-ID preference is used
as a tie-breaker if there is multiple selection of equal length. Figure 179 exemplifies how
priority 0 and 1 are routed throughout a network. Figure 180 exemplifies how this
spanning tree routing works around a broken link in the network.
There is no default preference among different interfaces, but a path preference may be
configured. The default value is 65535, but lower values may be configured for higher
preference.
When operating time-transfer (TT) in the network, interfaces being capable of directly
providing time-transfer tracking has a strictly higher preference over interfaces not
providing tracking. This preference is stronger than the timing source priority.
In general, the timing interface selection is non-revertive, such that a timing interface
needs to have higher overall preference of the current selected interface, whereas
equivalent or lower preferences does not affect the selection. This is to reduce the impact
of dynamics and errors.
Interfaces for which there is any of a number of fault conditions are not considered for
selection, and are only available once they moved out of the fault conditions (including
WTR, see 10.4 Timing source and interface).

Figure 179. 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 180. 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.

Figure 181. 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.
10.4 Timing source and interface

The timing as derived from any timing capable interface on a node, i.e. that of DTM trunk,
external clock or internal clock, is referred to as a timing source. Each timing source can
represent a timing reference, local or remote. It may also lack a signal or have error
conditions. Figure 182 illustrates the view of interfaces.
The timing reference a timing source represents is either set through manual
configuration or remotely through signaling (i.e. DSYP).
Each timing source thus have a Timing Reference priority, Node ID and in the case of
DTM trunk/DSYP interface also previous nodes and hop-count from the timing reference.
In addition, locally, each node has TT-preference state, a timing source priority
configuration, a lockout (Selectable) configuration and an interface status field.
The Timing Reference priority, Node ID and hop-count have been described in the Timing
source selection chapter. For local clocks or external clock interfaces, the Node-ID is given
by the node and only the Timing Reference can be configured.
A Timing Source can be selected as a source if the interface status field is “OK”. For other
interface status field values, the timing source cannot be selected right now.
The Wait To Restore (WTR) feature helps to keep unstable interfaces from being selected
during the periods of instability. The benefit of this approach is that during periods of
stability, the links provide a path for synchronization while the configuration would
remove them completely.
If there is no signal available or other input error in the underlying interface, the interface
status is Trail Signal Fail (TSF). After the underlying problem clears, the interface enters
the Wait To Restore (WTR) state, and the interface must remain in this state without
errors for a default of 40 s before leaving the WTR state and enter the “OK” state. The

interface status field will be “WTR” when the interface is in WTR state. Any underlying
error in the WTR state will force the interface to the TSF state.
If an interface has just been initiated, it will be in the INIT state, with the interface status
field being “INIT”. This is rarely seen by a normal user. After it has been taken up, it will be
in the HOLDDOWN state for 10 s and only if being there without error it will reach the
“OK” state. If underlying error occurs, the interface will directly reach the “TSF” state.
An interface for which no Timing Reference Announcement (TRA) has been received will
be in the NOTRA state, as reflected by the interface status field to be “NOTRA”. Lacking
TRA there is no data to compare it against others, and thus it cannot be selected.
In order to lockout interfaces, the Selectable configuration can be de-selected, and this
will prohibit the interface to be used for selection, regardless of its state in general. The
interface status field will reflect the lockout. Timing sources should not be locked out
without considering how the WTR mechanism prohibits the selection of unstable links
already, while periods of stability provide a transport path which would be lost by the
lockout.
Figure 182. By un-ticking the ‘Selectable’ checkbox in the table, the clock sync
signal will not be distributed further in the DTM network.
When an interface should not be used, a Do Not Use (DNU) signal can be generated, and
when the interface detects this it will enter the DNU state which is reflected by the
interface status field being “DNU”. When in DNU state, the interface cannot be selected
as selected timing source.
For TRA messages received which have traversed a too long path, there is a limit to the
trace length. This also acts as a transient loop cut-off mechanism. When the TRA has a
trace-length above the trace-length limit (64 nodes), it enters the TRACELENGTH state
which is reflected by the interface status message “TraceLen”. The time source is not
selectable when in the TRACELENGTH state.
When a TRA is received on an interface which the current TRA is degraded, then all timing
sources having a matching TRA from the same source are marked as black-listed. This
black-listing is lifted after two valid messages have been received. The black-listing
mechanism aims to remove potentially dangerous misinformation about potential paths
and hugely improve convergence time as proper alternative paths will be accepted within

3 s. When in the black-listed state, the interface status field reflect this with “BlackLst”.
The timing source is not selectable when in the black-listed state.
When a TRA is received from a neighbor node and it find itself in the trace of that TRA,
then the TRA must be disqualified as selecting it would create a loop, so the interface
enters the loop-state as reflected by the time source status field being “Loop”. During the
loop state the interface is not selectable.
When a TRA is received and there is reason to believe that a dynamic loop has been
activated, the time source enters the dynloop-state as reflected by the time source status
field being “DynLoop”. During the dynloop state the interface is not selectable.
Disqualified timing sources may contain more information beyond the timing source
status field, but it usually provides the best insight into the problem.
10.5 Node synchronization function

The node synchronization function coordinates all synchronization tasks that are local to
the node. Among these are:
 Selection of synchronization source (as ordered by DSYP) for the node
 Smoothing of the synchronization signal
 Distribution of the smoothed signal to all outgoing trunk interfaces
 Providing a hold-over capability in case of lost synchronization source
 Ensuring phase continuity when changing sync source
 Supervision of available sync sources
Smoothing of the sync signal is done with a digital phase-locked loop (PLL) that smooths
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.
10.5.1 Hold-over and free-running properties

A Nimbra switch is normally 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 typically

about 0.01 ppm (10 ppb or 10 ns/s) 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. ITU-T Rec. G.813 specifies this to be within +/- 1 s for 20 s holdover, which is
achieved with margin.
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.
10.6 Configuration recommendations

A strong general recommendation is to use an external reference clock with high accuracy
and stability. Such source includes SSU/SASE/BITS equipment, high stability oven
oscillators, rubidium or cesium clocks as well as GPS/GNSS steered clocks. Some
networks work perfectly well without an external reference clock while other networks
may function but with lower service quality.
The general recommendation is that for networks having 10 or more nodes, it is strongly
recommended to have an external clock source to the network, to make sure that the
network has a good stable source.
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, SDI Video service This service has a very hard requirement on drift
preferred rate that 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 183. External clock recommendations.
The requirements on the external reference clock are:

High stability (preferably ITU-T G.811 PRC/Stratum 1, which could be obtained from
cesium clocks or GPS).
2.048 MHz signal, according to ITU-T G.703.13, sine or square wave1. Square wave signal
is recommended.
Alternatively, a 1.544 MHz, a 5 MHz or a 10 MHz signal with the same electrical properties
as the 2.048 MHz clock described above may be used.
1
Note that 10/5/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 10, 5, 2.048 or 1.544 MHz clock is attached.

Note: Please note, D4, SF or ESF formatted T1, 1.544 Mb/s and 2.048
Mb/s timing signals cannot be used as synchronization source.
Nimbra 310, 320, 360, 380, 390, 640, 680 and 688 (only with a 160 Gbps Switch Board or
with an 80 Gbps Switch Board, revision A6 or higher) 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-slip in the transition process. These excellent sources may be
configured as external sources with priority 0, to use synchronization network
segmentation.
All sources shall be able to turn off, squelch, their output upon failure. This allows DSYP
to choose alternative sources to the network without manual intervention and with
significantly reduced effect on network and transported services. Some clocks are unable
to squelch their output on failure, and those should be avoided. Some clocks have the
ability to squelch their output on failure, but need to be configured to achieve that. Users
is strongly recommended to verify that all their sources have this ability.
In networks for which no external synchronization signal is applied, voting is done among
the nodes to select the node according to default priority and node identifier. Since node
identifiers are not configurable, the node identifier being most preferable might be in a
distant node, making the service of the network dependent on this node and the links
from it. Experience shows that this can cause problems, so as networks grow beyond 10
nodes or so, it is strongly recommended to have at least one node being fed an external
clock both to provide a stable reference and a suitable insertion point for the network.
It is recommended 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. For larger networks, it is
recommended to have multiple synchronization sources with geographical separation
such that common problems do not affect all sources. This also helps to handle larger
network failures that cause it to break into pieces, as it increases likelihood of feeding
both sides of the break.
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 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: Proper grounding of equipment and use of squarewave signal

have proven a good strategy to ensure good sync into external
interface.

10.7 Time Transfer
Time transfer is an optional software feature available on Nimbra 300 and the Nimbra 600
series. It requires Nimbra 300 nodes with PPS + 10 MHz input/output interfaces.
Time transfer is based on node clocks and network synchronization available in all DTM
networks. Time Transfer 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 nodes, which allow the nodes to calculate
absolute time with great accuracy.
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 (SFN) 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 for SDH and PDH based trunks. These channels are listed in the
web interface, from the link All connections Channels or from Nimbra Vision. For IP-
based trunks the time transfer specific information is sent in a separate packet stream,
requiring no channels to be setup.
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 s for ten consecutive node hops.
10.7.1 Time transfer performance requirements

In order to achieve an accuracy better than  1 s for ten consecutive node hops, it puts
requirements on the underlying infrastructure.
The delay between box A and B needs to be near the same in both directions, thus the
delay from A to B needs to be near the delay from B to A. When they delay is the same,
we say that there is a symmetric delay, but the difference in delay we say causes
asymmetric delay.
Asymmetric delays in the transmission path between two systems is very hard to discover
and conclusively eliminate without external aiding.
Avoiding SDH or WDM systems that provide protection paths to let the two directions to
go different geographical paths is a first means to achieving the necessary performance.
Further, underlying infrastructure such as microwave link systems should be checked for
their symmetric delay.
In order to achieve  1 s for ten consecutive node hops, a worst-case analysis would
reduce the limit to an error of  100 ns for each node hop. However, many times the
errors do not orient in the same direction, so a division by square root 10 is more
appropriate. A rule of thumb is that if continuous testing gives within  100 ns, there is no
cause to worry, similarly errors within  300 ns might be OK if there is no tendency to go
outside of those limits or mostly within the tighter limit.

Fixed asymmetric delays can be compensated for using the calibration method, but if the
asymmetric delay varies, it becomes harder to achieve a guaranteed stable
compensation.
In order to facilitate calibration an external reference can be connected, and
measurements compensated with this as reference. Using such method, a network can be
calibrated, assuming the previous node has calibrated time.
10.8 Configuration of Time (external clocks,

synchronization and time transfer)
10.8.1 Clock interfaces
Clock interfaces are denoted sqc-1, sqc-2 etc. and available clock interfaces are listed in
the Time  Clock interfaces list.
Each interface can then be configured Administrative up or down. For input interfaces,
the signal is only available to the system when configured as Administrative up and it has
no faults. For output interfaces, the signal is only sent out when set as Administrative up.
Figure 184. Configuration of time for a sync interface, sqc-b:1 in Nimbra 600
10.8.1.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.
10.8.1.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’.

10.8.2 Nimbra 360,380 and 390
In Nimbra 360, 380 and 390 nodes, there are two external clock interfaces, sqc-1 and sqc-
2. On the physical node, they can be found at the lower right side, with notations TSI-1
(sqc-1) to the left and TSI-2 (sqc-2) to the right.
Figure 185. Nimbra 360 front. The sync interfaces are found at the lower right
side. Nimbra 380 and 390 are identical to Nimbra 360 with respect to TSI-
1/TSI-2 (sqc-1/sqc-2).
Configuration of TSI-1/sqc-1 includes one parameter, time dual frequency mode, with
possible values ‘None’ or ‘PPS + 10 MHz’. With the parameter set to none, the port is a
regular external clock interface that accepts and distributes a synchronization signal.
With the parameter set to PPS + 10 MHz, the interface is set up to accept (or deliver) a
time transfer signal.
Figure 186. Nimbra 360 with TSI-1/sqc-1 configured with Time Dual Frequency
Mode equal to ‘None’, i.e. the two ports of the interface are used as regular
sync in and sync out ports. Observe that sync in is the leftmost connector of
the pair.
In order to configure this interface from the web interface, follow link Time  Clock
interfaces. The available clock interfaces are shown on this web page.

Figure 187. Configuration of external clock interfaces. Click on sqc-1 to
configure the sqc-1/TSI-1 interface of Nimbra 360/380/390.
Figure 188. Configuration of sqc-1, with time dual frequency set to ‘None’.
When Time Dual Frequency Mode is set to ‘None’, the parameters to configure are
direction and Output frequency (if applicable). The parameter ‘Time input offset’ is
irrelevant when 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/390 node (from its source), but it is only relevant for Time
Dual Frequency Mode set to PPS + 10 MHz, described in next section. Square wave input
sync signals of 1.544 MHz, 2.048 MHz, 5 MHz or 10 MHz are automatically recognized by
the node (according to ITU-T G.703-13).

Figure 189. Configuration of sqc-1, with time dual frequency set to PPS + 10
MHz.
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 and can be used by external equipment.
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 Time  Clock
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+10 MHz OK Both PPS+10 Mhz are OK
Figure 190. 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, see Figure 191.
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/390 of the PPS
signal.
The other interface on Nimbra 360/380/390, TSI-2/sqc-2 can only be used as an output
interface. In this case, some additional parameters can also be configured.
Note: Actually common to sqc-1, when sqc-1 is used as an output.

This interface is absent on Nimbra 310/320 and the extra fields
are placed on the sqc-1 page.
Figure 191. Defect presented on the sqc-1 web page.

Figure 192. Configuration of sqc-1/TSI-1 of Nimbra 310/320/360/380/390 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.

Figure 193. Configuration of sqc-2/TSI-2 of Nimbra 360/380/390 with Time dual
frequency mode set to PPS+10 MHz.
The parameters to configure, in addition to time dual frequency mode, are:
10.8.2.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. When time dual frequency is set to time dual
frequency mode equal to PPS + 10 MHz, this parameter becomes irrelevant and is grayed
out.
10.8.2.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/390 to the destination of the sync
signal. The parameter cannot be set independently on both configurable ports.

10.8.2.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.
10.8.2.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.
10.8.2.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.
10.8.3 Nimbra 310 and 320

Nimbra 310 and 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 390 and it accepts the same 1.544, 2.048, 5 and 10 MHz sync signals. Nimbra
310 or 320 can also be used as an entry point for time transfer, the same way as Nimbra
360, 380 or 390. 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.
Blind Panel
1 2
155/622/2488 Mbps (SDH)

10/100/1000 Mbps (ETH)
Sync Out In
Time transfer in PPS In 10 MHz In
Time transfer out PPS Out 10 MHz Out
Figure 194. Nimbra 320 configurable TSI-1 interface

10.8.4 Nimbra 640, 680 and 688
Nimbra 640, 680 and 688 accept 1.544 MHz, 2.048 MHz, 5 MHz and 10 MHz
synchronization signals (SWB40 and older SWB80 do not support 5 and 10 MHz clock
signals, they will simply not be identified and accepted). 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
Ohmand 50 Ohm. The interface is designed to interface both impedances. 5 and 10 MHz
are typically supplied as 50 Ohm signals, whereas 1.544 and 2.048 MHz are typically
supplied as 75 Ohm signals. Use cabling consistent with the source impedance.
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.
The synchronization interface of SWA and SWB is handled as independent
synchronization sources and can be independently configured. The external clock
interface located on the switch board in redundancy state standby is routed over to the
active switch board, which has the node clock master. The standby switch board will
always follow the active switch board in phase, regardless if the synchronization source is
local or not.
Figure 195. Configuration of external clock interface on Nimbra 600 systems.
The parameters to configure are:
10.8.4.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 generates 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.

10.8.4.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’.
10.9 Management of timing sources

The external reference clock is configured on two separate web pages. They are found on
web pages Time  Sync and Time  Clock interfaces. The latter step has already been
discussed. The link Time  Sync shows the following configuration page:
Figure 196. The Sync page, where internal and external clock priority are
configured and Node clock bandwidth.
The parameters to configure are:

10.9.1 Node clock bandwidth
Default value: Narrow
Type: binary
Range: ‘Narrow’ or ‘Wide’
Description: The node clock recovers synchronization from the selected source. It uses a
Phase Locked Loop (PLL). In order to handle imperfections on the transport layer,
typically and historically due to pointer adjustments in the SDH layer, the bandwidth of
the PLL has been chosen to be very narrow in order to suppress incoming jitter/wander
very well.
If the infrastructure is known to be "clean" from pointer justifications or similar
imperfections (for example transmission over dark fiber, dedicated wavelength or a
properly synchronized SDH network), the "Wide" setting may be advantageous in order
to provide highest possible frequency stability.
The differences are subtle and important only for the absolute most demanding
applications. The "Narrow" setting is the default and corresponds to the historical setting,
while the "Wide" setting is suggested when the infrastructure is "clean" from
imperfections, to get higher frequency stability.
10.9.2 Timing source list

The Internal and External Clock Priority are displayed in the last rows of the table. They
are the only items where you can define a priority, all items above them displaying
incoming information on priority. Also, the Internal Clock doesn’t have a Selectable
checkbox.
The column variables presented in the table 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, which is shown in the alarms list
Type Internal Node clock
External External, attached clock
Interface Clock extracted from DTM link
Name 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
Status ‘OK’ No fault
‘Init’ Interface initiated
‘NoTRA’ No Timing Reference Announcement (TRA) message
‘Lockout’ Interface lockout, not selectable
‘TSF’ Trail Signal Fail, underlying interface in error

Variable Value Meaning
‘DNU’ Do Not Use
‘HoldDown’ Interface remains in Hold-down after TSF clear on
interface leaving Init state.
‘WTR’ Interface remains in Wait To Restore after TSF clear
on interface having been OK.
‘TraceLen’ The length of the sync trace was too long.
‘BlackLst’ The interface has been blacklisted to avoid
synchronization loops.
‘Loop’ The TRA message would form a loop.
‘DynLoop’ The TRA message likely formed a dynamic loop.
TR Prio 0-15 Clock source priority; lower number means higher
priority. Zero (0) is the highest priority.
If an item is listed with a priority of 15, it indicates that
no priority information has been detected.
Selectable Ticking this check-box allows the node to use the
extracted sync signal from the link as a
synchronization source. This is the default setting.
Un-ticking this check-box forces the node to select
another sync source.
If the external clock Selectable status is ticked, it is
available to the network. If it is un-ticked, the clock
cannot be used by the network.
Figure 197. Variables presented on the Time  Sync web page.
10.10 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 the following way. Input faults,
i.e. a lack of, or poor quality input synchronization input, generates a ‘No external sync
source available’ alarm. More details can be viewed from the sqc interface web page.
Output faults of the time transfer signal (PPS+10 MHz) 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, 380 and 390, 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 198. The LEDs on the two interfaces TSI-1/sqc-1 and TSI-2/sqc-2 on
Nimbra 360/380/390. 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 199. 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 Time  Clock
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.
Signal Frequency Mismatch Input frequency does not match
(SFM) requirements of operational mode (e.g.
2048kHz in PPS+10Mhz operational
mode).
Excessive Phase Deviation Output realignment limit has been
(EPD) exceeded.
Loss Of Alignment (LOA) Output reassignment limit has been
exceeded.
Ok No defect detected
Figure 200. Details of Defects of the squelchable clocks described above.

On Nimbra 310 and 320, the TSI-2 interface described for Nimbra 360,380 and 390 is
absent, but the TSI-1 interface is present and has the same functionality.
10.11 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.
10.11.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.
Network timing: The line rate is synchronized to the DTM network frequency. This applies
to all new Nimbra 300 trunks, 4 x DS3/E3 and all Nimbra 600 series trunks.
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. Intermediate SDH/SONET nodes may introduce
pointer justification when the SDH/SONET nodes or network is not synchronized to the
same source as the DTM network, or when either of the network is experience wander.
Since interfaces 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.
10.11.2 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, 0.1% percentile,
99.9% percentile packet delay variation and RMS packet jitter.

Time transfer is now available over most IP Trunk links. This is described in 10.7 Time
Transfer.
10.12 Monitoring synchronization performance

10.12.1 Slip Seconds
A useful 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  Data. Set (interface) to ‘Trunk’ and click on the Show button.
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.
10.12.2 Pointer Justification Events

Pointer Justification Events (PJE) at SDH/SONET interfaces are available for monitoring.
On the Trunk network  Trunk interfaces web page, select the actual interface. There
are counters for:
RXPJE +
RXPJE -
TXPJE +
TXPJE -
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. In the RX direction, an intermediate SDH/SONET network could
introduce pointer justifications also when in Network timing mode.
10.13 Time Transfer configuration

To configure time transfer, the PPS + 10 MHz input node must also be used as an external
synchronization source. Start from the Time  Sync web page.

Figure 201. Configuration of the external clock priority in the node that is the
source for time transfer or has an external clock that is.
Continue with the Time  Clock interfaces web page.
Figure 202. Configuration of the external clock admin status in the node that is
the source for time transfer or has an external clock that is.
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 Time  Time transfer web page.

Figure 203. Time transfer configuration web page for node with 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. The easiest way is to set it to Up for all links in
all nodes. While in operation, links not used for distribution of time transfer signal may be
removed later.
Operational status is Up when time transfer is active and sync is taken from the 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 above;
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 current operating mode. It can take on three 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 has a degenerated time offset from neighbor nodes
(being 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 may not be used for precision timekeeping. When the time scale of the node has
been initiated to TAI/UTC, it is compensated and can be used for time keeping.
Calibration reference is the reference clock, which is compared to the time transfer
(reference) clock distributed in the network. It can be set to any of the interfaces, an
external clock or the node itself (sync/osc).
To configure a particular interface, click on the link to the interface in the Time sources
column.

On this page, the administrative status can be set. The default setting is Down for all
trunks. In order to let the system handle selection of a suitable synchronization source, it
is strongly recommended to set the administrative status on all trunk interfaces to Up if
time transfer is used. Time transfer channels are then established exactly where they are
needed, automatically. If it is known where the sync/time transfer signal passes, not used
links could have administrative status down.
Figure 204. Time transfer configuration web page for a specific interface in a
node.
Note: Setting the administrative status to Down on an interface with

operational status Up forces the operational status to state Down and
disables the time transfer function.
No warning is given to nodes further down in the synchronization chain,
but an event is generated in the event log.
This setting is strongly discouraged.
Figure 205. Definition of delay remote-local and delay local-remote as well as

calibration factor.
The calibration clocks, comprising of one PPS and one 10 MHz oscillator, is used for
reference and to determine the time difference between different interfaces. In the

illustration above and as seen from node A, the delay remote-local is 9.9 ms and delay
local-remote is 10.1 ms. The Round trip time is the sum of the two delays, i.e. 20 ms, and
assuming a symmetrical delay (i.e. calibration factor of 0), the estimated delay each way
is 10 ms.
The calibration time error, i.e. the error of the estimated time relative the calibration
clock, is measured. In this case, it will be -0.1 ms. The calibration factor error is a measure
of the asymmetry of the link, and is expressed in ppm of the round trip time. In our case, it
is
-0.1/20 * 1000000 = -5000 ppm.
The current calibration factor error can be fed back to the system to improve the time
estimation at the interface. The new calibration factor value to be entered on the web
page is the previous calibration factor subtracted by the current calibration factor error.
This procedure may be repeated to fine tune the calibration.
Note that for short distances, with low RTT, the time error variations get scale up, and
causes large calibration factor error variations. These can safely be ignored since the
actual contribution of calibrating such low RTT ranges is very low.
Variables and parameters presented on the web configuration page are:
Variable/Parameter Type Range Comment

Calibration factor Integer -500000 to Deviation from the symmetrical
500000 case, delay remote-local to round
trip time ratio (ppm).
Operational status Up Current state for the time transfer
Down signal
Dormant
Lower layer
down
Delay remote-local Real See illustration above (µs).
Delay local-remote Real See illustration above (µs).
Round trip time Real Round trip time to the destination
(RTT) interface and back (µs). Delay
remote-local plus delay local-remote
(µs).
Interface time error Real A measure of the difference
between the actual node time and
the remote node time measured on
that particular interface. Should be
very close to zero if the chosen
interface is the synchronization
interface (ns).
Calibration time Real Difference between the calibration
error time and the time transfer time for a
particular interface (ns).
Calibration factor Real Calibration time error divided with
error the round trip time (ppm)
Figure 206. Variables shown on a specific interface time transfer configuration
web page.

10.13.1 Calibration of Nimbra 300 time transfer interfaces
Time transfer interfaces can be calibrated, to remove asymmetries between one way
transit times between nodes. This is a fairly straightforward process, but it requires a
reference standard.
Attach the reference PPS + 10 MHz signal to the TSI-1/sqc-1 interface of the Nimbra 300
node to be calibrated.
Select Sync/External Clock in the drop down menu for one way time reference, on web
page Time  Time transfer.
Figure 207. Selection of calibration reference.
Go to the web page for the interface to be calibrated (Time  Time transfer  Specific
interface like sync/dtm3:2).
Find a good average of one way (delay deviation) to round trip time error ratio. This is
what is read from the (negative of the) value of Calibration factor error seen at the
bottom of the web page.
Input this number with a negative sign as calibration factor in the available entry field.
Make sure admin status is down, when setting the calibration factor.

Figure 208. Configuration of a calibration factor, which is the (estimated)
average of the negative value of the calibration factor error. In this example,
we pick 10000 ppm after inspection of how the calibration factor error varies
over time.
Figure 209. Inspection of the web page. Once calibration and interface time
error are small values, the calibration is as good as it gets.
Watch the interface and calibration time error on the page. If their time average is close
to zero, the calibration is fine. Otherwise, add the new calibration factor with negative
sign to the value already entered previously.
Iterate the calibration step, if needed.

10.13.2 Listing of time transfer channels
The time transfer channels are seen under All connections  Channels. They are listed
as Time Transfer services.
Figure 210. All Channels listed, including all Time Transfer channels.
10.13.3 Time transfer on additional interfaces than SDH

Time transfer was first introduced and only available on SDH interfaces. Currently time
transfer is also supported from IP Trunk interfaces.
Inclusion of time transfer on either interfaces on the built-in IP trunk or the IP trunk
module in Nimbra 300 nodes (not including the built-in trunk on a Nimbra 390) requires
supporting firmware, which needs to be downloaded to the built-in trunk or trunk
module. Instructions how to download the required files are given in 20 Up- and
Downgrading.

11 Performance Monitoring
11.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
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.
Interface A Source TTP A1 Route One Sink TTP B1
PM
Node A
Nimbra network
Interface B
Interface C Source TTP C1
PM
Route Two Sink TTP B2

Node C Node B
Figure 211. Open ended protection with performance monitoring on both

streams on (separate) sink TTPs.
User's Guide Performance Monitoring  210

Source TTP A1 Route One Sink TTP B1
PM
Nimbra network
Interface A Interface B
PM
Source TTP A2 Route Two Sink TTP B2
Node A Node B
Figure 212. 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.
Figure 213. 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.
11.2 General
In the web interface, Performance monitoring is found under the Perf. monitor link.
Figure 214. 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 215. Performance Monitoring configuration menu
The configurable parameters on this page are described in the table below:

Parameter Type Range Default Description
Administrativ Binary Up, Down Up The administrative status of all
e status performance monitoring in the node.
Setting it to Up enables performance
monitoring while setting it to Down
disables performance monitoring in
the node.
Max number Integer 0- 128 Consist of 15 PM report entries of 15
of Small 4294967295 minute and one entry of 24 hrs.
history log (232-1) Allocated system resources for the
small history log.
Max number Integer 0- 4 Consist of 96 PM report entries of 15
of Large 4294967295 minute and 30 entries of 24 hrs.
history log (232-1) Allocated system resources for the
large history log.
Figure 216. 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.'
11.2.1 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 217. 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 218. Block size for different trunks, accesses and service

11.3 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 219. 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:

Administrativ Binary Up, Up This parameter enables (Up) or disables
e status Down (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.
crossing alarm One of 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’)
suppression zero 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 Binary On, Off Off This parameter enables (‘On’) or disables (‘Off’)
periodic periodic history reports to be generated as
history events and thus subsequently sent as SNMP
reports traps to SNMP managers like Nimbra Vision.
History log Drop None, Small None: No history log is used.
size 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
threshold special meaning of disabling the threshold.
15m SES Integer 0-900 1 Value for 15m SES threshold, where zero has a
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
24h ES Integer 0- 10 Value for 24h ES threshold, where zero has a
threshold 86400 special meaning of disabling the threshold.
24h SES Integer 0- 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- 1 Value for 24hm SS threshold, where zero has a
Figure 220. Configurable parameters for PM objects.
11.4 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 221. 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 222. 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 223. 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 224. 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 225. Possible values for the parameter (errors) are ‘15m errors’ and ‘24h
errors’.
Figure 226. Possible values for the parameter (admin status) are ‘Admin up’ and
‘Admin down’.
Figure 227. 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.
11.4.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.

Figure 228. 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 229. 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.
Figure 230. 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 231. 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 232. PM implementation on access modules for Nimbra 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).
Figure 233. 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.
11.4.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.
11.4.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).

11.4.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.
11.4.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.
11.4.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 234. 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.

11.4.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 235. Details of trunk sonet/sdh-3:4 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 236. Graph and history details for sonet/sdh-3:4

12 Ethernet Transport Service
(ETS)
The Ethernet Transport Service (ETS) provides a flexible transport service for Ethernet
packets. The ETS service provides bandwidth configurable, point-to-point or point-to-
multipoint channels with very low packet jitter and high Quality Of Service. Ethernet
ports on the Access Modules allow customer traffic to be transported on the ETS
channels over the Nimbra Network to it's destinations.
12.1 Basic concepts

12.1.1 Device
An Ethernet device represents a physical Ethernet board. The device number presents the
device/board position in the node. The node type determines the maximum number of
Ethernet devices.
12.1.2 Forwarding function (FF)

The forwarding function is a Virtual Ethernet Switch. The FFs are used to separate traffic
from each other. The Ethernet traffic can only reach ports belonging to the same FF and
each port can only belong to one FF. The properties of the FF are used by all ports that are
added to the FF. The feature/property set of the FF varies by the type of board; especially
the old board types have a limited FF feature set. Most of the boards support eight
forwarding functions. The main parameter of the FF controls Ethernet switching, VLAN
mode and Spanning tree.
User's Guide Ethernet Transport Service (ETS)  224

Figure 237. Illustration of the two types of interfaces, connected with each other
through a forwarding function.
12.1.3 ETH and ETS Interfaces

Ethernet switching has two separate interface types that in most aspects are configured
the same way. They are physical interfaces (Eth) and virtual Ethernet Transport Service
(ETS) interfaces. In the illustration below, the two types of interfaces are tied together
with a forwarding function.
The physical Ethernet interface on the device is labeled after the device number in the
node and the interface number on the device. An example is eth3:6, for physical interface
number six (from the left) on device number three. The number of physical ports depends
on device type.
Numbering of ETS interfaces is made automatically when unicast or multicast services
are defined. All physical interfaces gets the lowest interface numbers. The first ETS
interface created gets the lowest number available after the physical interfaces have been
numbered. If the board supports eight physical ports the first ets port number is nine, an
example is ets3:9.
An ETH/ETS interface must belong to an FF in order to send and receive traffic.
12.1.4 ETS channels

Ethernet Transport Service channels transport Ethernet traffic through an underlying
Nimbra (DTM) network. The channels are set up from ETS source interfaces to 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.
12.1.4.1 Ethernet Transport Service interface (ETS)

The 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. Multicast can be set up as a unidirectional
service.
12.1.4.2 ETS unicast connection

A schematic picture of an ETS unicast connection is shown below. It consists of two
unidirectional channels, one in each direction. These channels are used to send packets
through the DTM network from the ETS interface in node A to the ETS interface in node B
and vice versa. The bandwidth doesn’t need to be symmetrical.
In Figure 238 below, the DTM network acts like an extension cord between two Ethernet
interfaces of the nodes.
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.

Figure 238. An ETS channel can be defined between two ETS interfaces. The
physical interfaces (ETH) are tied to the ETS interface via the Forwarding
Function.
12.1.4.3 ETS multicast connection

ETS multicast provides a point to multipoint service. An ETS multicast connection can
connect several ETS-sinks to one ETS-source. Zero, one or several ETS-sources can be
connected to one ETS-sink. Multicast connections can be defined with any number of
destinations (including zero). Both source and destination must be defined as ETS
multicast interfaces.
Figure 239. A multicast ETS connection, with a source (node A) and two
destinations (node B and node C).
Note: 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.
12.1.5 Interface source and sink

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 (11 Performance Monitoring)

Figure 240. Illustration of the objects eth-source, eth-sink, ets-source and ets-
sink.
12.1.6 ETS 1 +1 protection

Different types of protection are available both for ETS and ITS (video/audio) services.
The fundamental concepts are elaborated in chapter 13.2 Protection.
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 sequence
numbers and not be part of an interface group 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).
Note: 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 20 Up- and Downgrading.

12.1.6.1 ETS interface groups
ETS interface groups are objects that are 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. This type of protection
is called hitless protection.
An interface group is empty when created. When the first ETS interface is associated with
the interface group; most properties of the interface are copied to the interface group.
Furthermore, most properties can now only be changed on the interface group level and
not on the ETS interface level with a few exceptions. 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 parameters that are set only on the individual ETS interfaces or
interface group.
Figure 241. Example of unicast hitless setup of ETS 1+1 protection with one
destination. Observe that the primary and secondary routes through the
network must be different, in order to ensure a working protection
mechanism.
12.1.7 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.
12.1.7.1 Hitless protection

Hitless protection means that one stream is split at the ETS-source and the two resulting
streams (with identical content) traverse the network through different paths. In the sink
node, the two streams are combined in the play-out buffer and one stream is passed on
for further distribution. The egress stream is composed of packets from both streams.
To get proper protection, the streams have to go through the Nimbra network along two
different routes.

12.1.7.2 Standby protection
Standby protection means that one of two streams is selected to generate the resulting
stream; the other stream is in standby mode. Selection of primary channel and standby
channel is based on alarm indications such as LOS, AIS, DEG or RBR. The selection is
made at the sink 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.
12.2 Web 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.
12.2.1 Devices (modules)
Figure 242. The first configuration page for Ethernet.
Figure 243. The configuration page obtained by clicking on the Devices link.
Click on the corresponding device link to manage a specific device. To be able to

configure a device the board must either be present or an old configuration of an Ethernet
board must exist.

Figure 244. The configuration page for a particular Ethernet device (i.e. module)
is found in this example when the link (name) eth5 is used.
The starting point for configuration of Forwarding Functions, ETS or interface groups is
found by clicking on the name of the particular object to be configured or use the Create
buttons.
Click on the statistics tab to get an overview of the statistics counters of all the interfaces
belonging to the device.
If an Ethernet device is in status absent a button that says Delete Device will appear. This
is the case when the module has been removed from the node. If the button is clicked, the
device is removed from the web interface.
12.2.2 Forwarding Function – Basic settings

The FF is created and deleted by the user. An Ethernet Access Module without a
configuration has no FFs. To create an FF, select Ethernet  Devices, click on the link to
the desired device (like eth1) and the button Create Forwarding Function.
The forwarding function in a Nimbra node must be associated with a device.
When a forwarding function is deleted, a confirmation window is opened. The deletion is
confirmed with the OK button.
The forwarding function can also be managed through Ethernet  Forward. Functions.
In this case you will see the screen depicted in Figure 245below, select the device then
click OK.

Figure 245. 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.
Figure 246. 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 two Mac
modes see Figure 247 below. When Mac mode is set to auto; nomac switching mode is
selected if only two ports are connected to the FF and mac switching mode in all other
cases.

Mac Mode  nomac Mac
VLAN Mode↓
Transparent Forwards incoming packets to all Bridged MAC mode

ports belonging to the same FF. VLAN transparent
Switching mode
IEEE802.1D
Customer Forwarding based on customer Bridged VLAN/Mac

VLAN only. Forwards incoming mode
packets to the interfaces VLAN aware Switching
belonging to the same FF and mode
(customer) VLAN.
IEEE802.1Q
Only mode supported in Nimbra
360 products
Figure 247. VLAN and Mac Mode settings of Forwarding Functions
There are five tabs to configure in a Forwarding Function; Basic settings, Advanced
(settings), Diffserv, Spanning Tree and Statistics (see Figure 246 above). Note that you
have to use the Apply or OK button on each page before moving on to the next tab to
save the configuration.
12.2.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
12.2.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
12.2.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.
12.2.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).
12.2.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.
12.2.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’
3
.In the table below, it is outlined what actions are taken depending on the values of the
spanning tree parameter.
3
Nimbra 360 only supports ’Auto’ and ’Forward’

Spanning Tree VLAN mode Action
Auto Transparent Running mode Process, see
below
Auto Customer Running mode Drop, see below
Forward All All BPDU packets are
forwarded by the forwarding
function
Drop All Drop; All BPDU packets are
dropped by the forwarding
function
Process All Process; BPDU packets are
processed by the spanning tree
algorithm
Nimbra 360 supported feature set
Spanning Tree VLAN mode Action
Auto/forward Customer Forward; All BPDU packets are
forwarded by the forwarding
function
Figure 248. Spanning tree settings in different nodes, with actions taken.
12.2.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, augmenting the maximum MTU size.
In case the parameter is set to On, 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 for Forwarding Functions with VLAN mode customer and 1518 bytes for
Forwarding Functions with VLAN mode transparent. The default setting of the parameter
is On.
This feature is not supported on Nimbra 360.
12.2.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 supported on Nimbra 360.
12.2.3 Forwarding function - Advanced

The reserved MAC addresses group, 01-80-C2-00-00-0X/01-80-C2-00-00-2X defined by
IEEE 802.1D and 1Q can be configured to forward or drop on this tab.
This feature is not supported on Nimbra 360.
Figure 249. Configuration of advanced settings of a forwarding function, top.

Figure 250. Configuration of advanced settings of a forwarding function,
bottom.
12.2.3.1 Advanced – MRP address 01-80-C2-00-00-2X (X = 0, …, F)

Default value: forward
Type: binary, selectable from a drop-down menu
Range: drop, forward
Description: This is a defined behavior for traffic to the Multiple Registration Protocol
addresses. By default all traffic is forwarded, but traffic to any of the sixteen addresses
can be disabled individually by setting the traffic to drop for the particular address.
12.2.3.2 Advanced – Reserved address 01-80-C2-00-00-0X (X = 2, …, F)

Default value: drop
Type: binary, selectable from a drop-down menu
Range: drop, forward
Description: This is a reserved address. Packets to this address are dropped according to
the IEEE 802.1D standard, but the standard can be overridden by setting this parameter
to forward.
12.2.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) mapping. This
setting is made on the forwarding function, under the link Diffserv.
The mapping of flow group to priority is made on the Ethernet/ETS interface basic
configuration page.
Figure 251. Traffic class and drop precedence assignment.
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 (Traffic priority  Priority mode (Ethernet
or Diffserv)
Figure 252. Default priority mode is defined for all packets reaching the
forwarding function under the ETH or ETS interface advanced configuration
web page.
Furthermore, on the Ethernet/ETS advanced interface configuration pages, there is a

mapping of the eight Flow Groups numbered 0 to 7 into Traffic Classes (numbered TC0 or
TC1) and Drop Precedence Classes (DP0, DP1 or DP2). 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 main queues are used. Within each Traffic Class,

three different Drop Precedence levels are added. This gives another priority level. The
Drop Precedence levels are configured per interface, on the advanced interface
configuration web page. The relative priority of the Drop Precedence level is not defined
by the system, but left for the user to set. By default, all packets are configured with Drop
Precedence.
Outgoing from the Forwarding Function, the two buffers for the different traffic classes
are combined on a strict priority basis (TC1 goes before TC0). The different drop
precedence classes in TC0 have different levels for packet drop set in the buffer.
Figure 253. Traffic class and drop precedence illustration. All TC1 traffic is
handled before TC0 traffic (strict-priority).
Figure 254. Mapping of flow groups into traffic class/drop precedence is made
on the advanced ETH/ETS configuration page.
DSCP or Diffserv configuration is made per forwarding function, under the Diffserv link on
the forwarding function configuration page.

Figure 255. 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 class and drop precedence
on the ETS/ETH interfaces.
12.2.5 Forwarding function – Spanning tree

The Spanning tree protocol is used to avoid traffic loops in an Ethernet network.
The basic setting ‘Spanning Tree’ of a forwarding function is described in chapter 12.2.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.
The configuration on the spanning tree tab is used when the running mode is in process.

Figure 256. Spanning tree configuration for spanning tree mode process
The Spanning Tree Protocol (STP) and the Rapid Spanning Tree Protocol (RSTP) are
supported by most Nimbra Ethernet devices. The selection of type of spanning tree
protocol to use is made per forwarding function, on the “Spanning tree” web page.
12.2.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.

12.2.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.
12.2.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.
12.2.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
12.2.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
12.2.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.
12.2.6 Forwarding function – Statistics

From the Statistics tab, 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 257. 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
exceeding the Q threshold,
causing congestion in the
network.
Figure 258. Interface statistics, headings
12.2.7 Forwarding function - Nimbra 360 limitations

The product Nimbra 360 all has hardware restrictions for some of the configuration
parameters of the forwarding function.

As an example, configuration of a Nimbra 360, is shown below:
Figure 259. Configuration of a forwarding function in Nimbra 360
In the table below, the basic settings for of these products are shown below:
Property Possible values in Nimbra 360

Customer ID No restrictions
Purpose No restrictions
VLAN mode Customer
Mac mode Only nomac is possible (auto means nomac)
Spanning tree Only forward is possible (auto means forward)
Figure 260. Presented capabilities for Nimbra 360
As can be seen in the web GUI for Nimbra 360, two links from Nimbra 600 are missing
(Advanced and Spanning Tree).
12.2.8 ETH and ETS interfaces

12.2.8.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.
To manage a Physical Ethernet interface select Ethernet  Devices, click on the link to
the desired device (for example eth1). In the overview tab click on the desired Ethernet
interface (eth1:1). See Figure 261 below.

Figure 261. Configuration of Ethernet basic interface settings.
To manage an ETS interface select Ethernet  Devices, click on the link to the desired
device (like eth1). In the overview tab click on the desired ETS interface (ets1:9) or create
new ETS interface by clicking on the button Create Unicast i/f. See Figure 262 below:

Figure 262. Configuration of ETS basic interface settings
The common interface parameters are:
Parameter Type Default Range

Administrative Binary Down Down (disabled)
status Up (enabled)
(Admin status)
Interface group Enumerable None None plus all defined ETS
list/drop-down interface groups.The ETS
menu interface group is used for
ETS 1+1 protection.
Forwarding Enumerable None None (disables switching), All
function list/drop-down defined forwarding functions
menu
Customer ID Integer 0 0-4294967295 (232 – 1)
Purpose Text string Empty text Text string of 255 or less

string characters

Local DSTI (DTM Integer Lowest Integers between 0 and
Service Type unused 32767. Must be unique in the
Instance) integer, node in order to identify an
starting object during connection
with 0 setup.
Figure 263. Common basic Ethernet/ETS/ETS 1+1 interface parameters for a
forwarding function in transparent mode.
12.2.8.2 Originating Channel and Spare Capacity Utilization

Some additional parameters are needed for ETS interfaces, in order to define channels to
other ETS interfaces in other nodes. See Figure 262 “Configuration of ETS basic interface
settings” above.
Spare Capacity Utilization (SCU) enables seamless integration of bulk lower priority data
services. It provides dynamic utilization of the link capacity while still presenting a single,
well-behaved IP stream. The SCU-ETS channel is an ordinary ETS channel, but assigned a
lower priority than all other channels.
The SCU-ETS channel automatically makes use of available bandwidth not used by other
ITS/ETS services. The SCU-ETS will at all times allocate the trunk link capacity that is not
used by the “normal” ITS or ETS services. It has the scope of one trunk link, i.e. it
originates and terminates in Forwarding Functions on each side of the link.
Figure 264. The Originating Channel Parameters section
An SCU license is required on each terminating node. Only one SCU-ETS channel can be
setup per trunk link. That is, the SCU-ETS must be terminated in a Forwarding Function
(FF) on the nodes that terminates the trunk link. The same FF can be used to terminate
several SCU-ETS, as well as ordinary ETS channels, creating a network with dynamic, as
well as fixed capacity channels.
The Originating Channel Parameters are:

Destination DTM Text string DTM Text string of 255 or less
node address or characters.
Hostname
Destination DSTI Integer Integers Must match the local DSTI of
between 0 the ETS unicast or multicast
and 32767 interface defined in the
destination node.
Requested channel Enumerable Auto Auto,
version list/drop-down DCP version 2,
menu
DCP version 3.
This list is only visible if SCU-
ETS is set to ‘No’ Selection of
DTM Channel Protocol. Auto
means that DCP v3 is tried
first, but if not supported the
entire way, the channel is
established with DCP v2.
Committed Integer 1000 Mbps The CIR rate is the fixed
information rate capacity. A value between 0
and the trunk capacity.
Excessive Integer 1000 Mbps The EIR rate is the maximum
information rate dynamic capacity. A value
between 0 and the trunk
capacity. This field is only
displayed when SCU-ETS is
set to ‘Yes’.
SCU-ETS Binary No No (disables SCU-ETS)
Yes
Source routes (Up Enumerable None All defined source routes in
to three) list/drop-down the node.
menu Used if the defined ETS
channel is source routed.
Use source route Enumerable Auto Override of source route
list/drop-down priority. Auto means that the
menu function is disabled.
Primary source Checkbox Enabled Enabled (Suppressed)
route alarm Disabled
Figure 265. Originating Channel Parameters.
12.2.8.3 Additional common configurable basic interface parameters, VLAN mode

customer
When the interface is connected to an FF set to VLAN mode customer, there are some
additional parameters to configure, VLAN tagging and VLAN membership.

Figure 266. Basic interface VLAN configuration.
Parameter Default Possible Explanation

values
Acceptable all all All frames are accepted
frame type vlantagged Only VLAN tagged frames are accepted
4
untagged Only untagged and priority tagged
frames are accepted
Default 1 1-4094 If no VLAN tag is attached to a packet,
VLAN the default VLAN tag is added where
appropriate. The default VLAN tag is
interpreted as an IEEE 802.1Q VLAN
tag.
Default 0 0-7 Assigned on the ingress interface for
Ethernet untagged packets. Used on the egress
Priority interface if the outgoing packet is
tagged.
Note! This parameter is not used for
priority classification
Transmitted vlantagged vlantagged, Describes if tagging is used on flows
frame type untagged, leaving the interface, i.e. for the
legacy5 Ethernet interface in the 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.
4
Not supported by Nimbra360
5
Only supported and the only mode in Nimbra 360 for ETS.

Figure 267. Common basic Ethernet/ETS interface parameters for a forwarding
function in VLAN mode customer.
For definition of VLAN tagging see IEEE 802.1Q.

VLAN membership is defined both on the ETH and ETS interfaces. Only packets with
VLAN tags included in the list are accepted by the interface.
12.2.8.4 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 268. VLAN membership configuration on the ETH/ETS interface.:
Parameter Default Possible values Explanation

VLAN set Empty Comma separated list of Allowed VLAN(s);
Integer(s) or list of Example: 1,3-18,47,62-68, 4092-
integers in the range 1- 4094
4094
Customer ID 0 0 – 4294967295 (232 – 1) Integer identifier
Purpose Empty Text string, 0-255 Text string identifier, to the
string characters user’s disposal
Figure 269. Configurable parameters for VLAN settings
Note: If ‘VLAN Mode’ of the FF is set to transparent, then VLAN tags are
ignored.
12.2.8.5 Common configurable advanced interface parameters

The web pages to configure advanced settings for Ethernet and ETS interfaces are shown
below. The “Force VLANs Tagged/Force VLANs Untagged” fields are only present on
physical ports, see section 12.2.8.7 “Specific Advanced Ethernet (ETH) interface
parameters”.

Figure 270. Configuration of Ethernet advanced interface settings, part one. On
the top part of the web page, all configurations are made on inbound packets
to the interface.
These settings are made on the incoming packets to the forwarding function.

Figure 271. Configuration of Ethernet advanced interface settings, part two.
These settings are used for the egress from the forwarding function.
For ETH interfaces the additional section used to manage autonegotiate is shown on the
advanced tab, see 12.2.8.7 Specific Advanced Ethernet (ETH) interface parameters. For
ETs interfaces the additional section used to manage connection re-establishment is
shown on the advanced tab, see 12.2.8.8 Advanced ETS specific interface configuration
parameters.

MAC Learning On On Decides if Ethernet MAC
learning should be enabled on
this interface. This property is
ignored and learning is set to
off if the currentMACMode of
the forwarding function is
nomac.
Off MAC Learning disabled (Off)
Priority mode Ethernet Ethernet Priority according to Ethernet

Diffserv Priority according to Diffserv
Default traffic 0 0 All packets, lacking prioritizing
class (TC) information, have lowest
1 priority
All packets, lacking prioritizing
information, have highest
priority
Default Drop 0 0 Drop precedence are
Precedence 1 configured from 0 to 2. Packets
(DP) 2 within a traffic class can belong
to different DP and can be
configured to have different
priority in the forwarding
function.
Flow Group to 0 0 All packets in the flow group
Traffic Class have lowest priority (traffic
mapping, flow 1 class 0)
groups 0 to 7 All packets in the flow group
have highest priority (traffic
class 1)
Figure 272. Common advanced Ethernet/ETS interface parameters, exclusive of
TC/DP settings
12.2.8.6 Configuration of Traffic Class/Drop Precedence

Configuration of Drop Precedence per Traffic Class makes it possible to tailor how the
output/source interface handles an overload situation. The classification is made on
packets received on an input/sink interface and is prioritized on the output/source
interfaces.

Figure 273. Illustration of how Traffic Class and Drop Precedence works inside a
forwarding function. Traffic of both classes are sent to different queues, where
the drop precedence decides when to drop packets of a certain traffic class.
TC1 is always prioritized over TC0 on the output side (in C).
In the table below, configuration of the Drop Precedence parameters are shown. Both
Traffic Class 0 and Traffic Class 1 have their independent parameter set.

Max bytes (in the Auto Auto Packets are dropped if the queue in
queue) bytes exceeds the Max bytes drop
threshold. Used to set maximum
queue latency.
The Auto value is calculated to give a
Manual;
maximum queue latency of 1 s. This
(1 - 4194288)
setting is relevant for interfaces with
bandwidth less than 10 Mbps which
could build up a queue that could give
a latency of several seconds.
Drop Precedence Auto Auto Available buffers are evenly shared
0 (or 1 or 2) between all enabled TCs/queues on
Frame threshold the device.
Disable All packets belonging to the traffic
class and drop precedence are
dropped.
Manual Number of packets in this queue
Drop Precedence Taildrop Taildrop The packets are dropped if the queue
0 (or 1 or 2) threshold is exceeded.
Drop Function Wred Weighted random early drop is an
algorithm to drop packets. Used
together with traffic flows that
throttle the bandwidth based on
packet drops (TCP/IP) .
Figure 274. Configuration parameters for Traffic Class/Drop Precedence

12.2.8.7 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. The ‘Force VLANs tagged’/‘Force VLANs
untagged’ fields are not shown when the interface belongs to a FF set to transparent
mode.

‘Force None Comma VLANs included in this field are tagged,
VLANs separated list of despite the general setting of
tagged’ integer(s) or list Transmitted frame type ‘Untagged’
of integers in the Example: 1,2,5-8,16 tags VLAN 1,2,5 to
range 1-4094. 8 and 16 on egress traffic.
This field is only available if Transmitted
frame type of the interface is
‘Untagged’
‘Force None Comma VLANs included in this field are not
VLANs separated list of tagged, despite the general setting of
untagged’ integer(s) or list Transmitted frame type ‘Tagged’
of integers in the Example: 1,2,5-8,16 untags VLAN 1,2,5
range 1-4094. to 8 and 16 on egress traffic.
This field is only available if Transmitted
frame type of the interface is ‘Tagged’
Figure 275. 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 276. Autonegotiation of an Ethernet interface

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

values
Auto Auto Auto Auto – The autoneg.feature is turned on/off
negotiate On depending of interface type and settings
below.
Off
On - The autonegotiate feature is enabled
Off - The autonegotiate feature is disabled
The selected value is shown within
parenthesis
Advertised Auto Auto All HW supported speeds (by module and
speed SFP) are 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
10G Only 10Gbps are supported
Advertised Auto Auto All supported duplex forms are advertised.
duplex Recommended
Full Only full duplex is advertised
6
Half Only half duplex is advertised
Advertised Auto Auto All supported flow-control forms are

flow-control PAUSE 7 advertised.
ASM_DIR PAUSE flow-control is advertised
PAUSE, ASM_DIR flow-control is advertised
ASM_DIR PAUSE and ASM_DIR are advertised. For a
None description, see IEEE802.3-2005 Section
Two.
No flow control is advertised.
Figure 277. Auto negotiation parameters for Ethernet interfaces. The available
parameter values are always presented in the web interface, but could vary
depending on the interface type.
6
Only supported by Nimbra 360.
7
The only supported mode in Nimbra 360.

12.2.8.8 Advanced ETS specific interface configuration parameters
Figure 278. Configuration of Ethernet advanced interface settings, connection

re-establishment for virtual interfaces.
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.
12.2.9 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
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.
12.2.10 Configuration of Fault management for ETH and ETS

interfaces
Figure 279. 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:
12.2.10.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.

12.2.10.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.
12.2.10.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.
12.2.10.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.
12.2.10.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.
12.2.10.6 Generate AIS on Major 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.
12.2.10.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.
12.2.10.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.
12.2.11 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 interface configuration page, see Figure 280 below.

Figure 280. 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 281. Configuration parameters for Ethernet/ETS destinations for
multicast connections.
Figure 282. Add destination configuration web page.
12.2.12 Spanning tree configuration for ETH and ETS interfaces

The Spanning tree protocol is used to avoid traffic loops in an Ethernet network. The
configuration on the spanning for the interface is used when the interface belongs to a FF
with Spanning Tree mode is process. The basic setting ‘Spanning Tree’ of a forwarding
function is described in chapter 12.2.2.6 Basic setting – Spanning tree and chapter
12.2.5Forwarding function – Spanning tree
The parameters that can be managed on the interface are shown in the Spanning Tree
tab see Figure 283 below.

Figure 283. Detailed spanning tree configuration on the ETH/ETS interface for
spanning tree mode process
Spanning tree is specified in IEEE 802.1D. 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
cost 200000000) (manual) input 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 284. 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 port identity 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.

12.2.13 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 285. 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 286. ETS statistics for all ETS interfaces in a particular node.
12.2.14 Statistics overview tab on the ETH configuration page

The statistics for eth interface are presented according to standard MIB-II (RFC1213) and
RMON group 1 statistics (RFC 1757).

Figure 287. Ethernet statistics
12.2.15 ETS interface groups (ETSG)

ETS interface groups (ETSG) are used to set up ETS 1+1 protection. Start with setting up a
channel between two ETS interfaces in two different nodes. Place the ETS interfaces in an
ETS group (one ETSG in each node).
The ETSG inherits properties from the first ETS interface added to the ETSG. Most
parameters are now configured on the ETSG level. The second ETS interface added to the
ETSG inherits the properties from the ETSG, except for channel specific properties. Note!
The ‘admin status’ must be configured on all levels (ETSG and ETS).
Below is shown parts of the configuration web page of an ETSG:

Figure 288. Configuration page for an ETS interface group (ETSG).
The configurable general ETSG parameters are:

Administrative Binary Down Down (disabled)
status Up (enabled)
(Admin status)
Forwarding Enumerable list/ None None (disables switching), All
function Drop-down menu defined forwarding functions
Customer ID Integer 0 0-4294967295 (232 – 1)
Purpose Text string Empty Text string of 255 or less characters

string
Figure 289. Basic configurable general ETSG parameters

The configurable protection parameters are specific for ETSG and are not defined on ETS
interfaces. The VLAN parameters are set on the individual ETS interfaces, if the interfaces
are not part of an ETS group. When they are part of an ETSG, the VLAN parameters are
configured on the ETSG level.
12.2.15.1 Protection – Member interfaces

Default value: None
Type: Set of two or fewer ets interfaces
Range: Not applicable
Defined on object: etsg
Description: Member interfaces of an ETSG are associated with the ETSG on the
configuration page for basic configuration of ETS interfaces.
12.2.15.2 Protection – Protection type

Default value: Standby
Type: Binary
Range: Standby, Hitless
Description: There are two possible protection types available. The protection types are
common for protected ITS and ETS services. For a general description, see chapter 13.2
Protection.
12.2.15.3 Protection – Status

Default value: N/A
Type: Unavailable, Unprotected, Standby protected, Hitless measure, Hitless capable,
Hitless protected
Description: Current protection status
Unavailable: Both channels down.
Unprotected: Only one channel is up.
Standby protected: Both channels are up and protection type is set to stand by.
Hitless measure: Both channels are up and protection type is set to hitless. (The buffer is
not yet in use).
Hitless Capable: Both channels are up and protection type is set to hitless (the buffer is in
use but one of the flows is outside the buffer window).
Hitless Protected: Both channels are up and protection type is set to hitless (the buffer is
in use and the service is fully protected.
12.2.15.4 Protection – Expected status

Default value: Unavailable
Type: Enumerable list/drop-down menu
Range: Unavailable, Unprotected, Standby protected, Hitless capable, Hitless protected
Description: This is a value that can be set as a flag for loss of protection. Five possible
states are selectable and if the current status of protection is “below” that status, an

alarm with severity warning is generated. The lowest status in this rank is ‘unavailable’
and the highest ‘Hitless protected’. The order is the order given above in the range
definition.
12.2.15.5 Protection – Enter hitless

Default value: Always
Range: Always, On startup, On action
Description: This value describes when an attempt to enter the hitless state shall be
made (valid in protection type hitless).
‘Always’ means that an attempt to reach the hitless state is made as soon as all
prerequisites to enter hitless is met.
‘On startup’ means that an attempt is made when the service is started and all
prerequisites to enter hitless is met within 20 s.
‘On action’ means that an attempt is made when the Realign Buffer button is clicked.
12.2.15.6 Protection – Active interface

Default value: None
Type: ETS interface
Range: Member of the ETS group
Description: The active interface is the interface that delivers packets to the outgoing
buffer first, of the two interfaces in the group.
12.2.16 Hitless Protection

When protection type hitless is chosen the additional status and configuration fields are
shown; see figure below.
Figure 290. Explanation of the different buffer levels in an ETSG with two
streams that define a hitless connection.

The Realign Buffer button can be used when the buffer becomes misaligned and needs
to be corrected. Another use for the Realign Buffer button is to enter hitless state when
‘enter hitless’ mode is set to on action/on startup. The service will then enter hitless state
if the following criteria are met: Both flows are present and OK, the differential delay
must be low enough for the flows to fit in the buffer.
Note! If there are packets in the buffer a click on the Realign Buffer button will cause a
packet drop(flush of buffer) and then a realignment attempt.
12.2.16.1 Protection – Differential delay

Description: The measured difference in delay between the channels in the interface
group (reported in number of packets and µs).
12.2.16.2 Protection – Avarage packet rate

Description: Average packet rate in packets per seconds.
12.2.16.3 Protection – Buffer size

Default value: Depends on board type (256 or 1024).
Description: The amount of buffers allocated for the etsg. On each device there is a
limited amount of buffers shared between the ETS groups.
12.2.16.4 Protection – Alignment offset

Default value: 0
Type: integer
Range: 0-1000000 (microseconds)
Description: Extra alignment delay in microseconds. Used when a large latency increase
may occur due to a re-route or queue buildup.
12.2.16.5 VLAN Tagging – configuration

See section 12.2.8.3 “Additional common configurable basic interface parameters, VLAN
mode customer” above.
12.3 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.
12.3.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.
Figure 291. A unicast connection between two Ethernet interfaces.
12.3.1.1 Configuration procedure

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
Spanning Tree Forward is recommended
Jumbo Frames On (default) is recommended
Fault propagation On 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.
12.3.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.

Figure 292. 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.
12.3.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.
Figure 293. ETS 1+1 protection in a point to point case.

Create two forwarding functions in the sink and source module. If we intend to use VLAN
tagged traffic, we can choose to set VLAN mode to customer for the forwarding
functions.
Create an ETS per forwarding function. Combine the ETS interfaces 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.
12.3.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.
Figure 294. 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.

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 ETS interfaces 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 ETS interfaces.
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.
12.3.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.
Figure 295. 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.
12.3.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’.

Figure 296. Ethernet switching with one switch and three more nodes.

12.3.7 Ethernet switch and VLAN tagging
Figure 297. 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.

13 Isochronous Transport
Service (ITS)
13.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 298. Video traffic through a unicast DTM channel.
Interface Originating
Connection Terminating Interface
asi-2:1
Connection asi-1:2
itso-1
TTP Source itsi-2
TTP Sinc
Figure 299. ASI,TTP connection, unicast
User's Guide Isochronous Transport Service (ITS)  276

HD-SDI HD-SDI
Terminating Terminating
DTM node DTM node
DTM
Originating
DTM
node
HD-SDI
Figure 300. HD-SDI video transported with a DTM multicast channel to two
destinations
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.
Interfaces: Configuration and editing of the interfaces.
Perf. monitor: Shortcut to the Performance monitoring menu, which is described in
chapter 11 Performance Monitoring.
To configure ITS services, it is best to start with creating TTPs at the destination(s).
Continue with creating a matching TTP at the ITS source. After finishing the
configuration, all ITS channels should be set up if the required bandwidth is available.
13.2 Protection
13.2.1 Nomenclature
13.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.
13.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.
13.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.
13.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 outgoing
stream.
13.2.2 ITS protection cases

13.2.2.1 Type 1 protection
Source TTP A1
Route One
DTM
Interface A Route Two Interface B
Sink TTP B2
Figure 301. 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.

13.2.2.2 Type 2 protection - open ended
DTM
Interface A1 Interface B
Route Two
Interface A2
Source TTP A2
Figure 302. Open ended type 2 protection of ITS streams. This protection type
supports standby protection with uni- or multicast streams.
13.2.2.3 Type 2 protection – closed ended

DTM
Interface A Route Two Interface B
Source TTP A2
Figure 303. 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).

13.2.2.4 Type 3 protection – open ended
DTM
Interface A1 Interface B
Sink TTP B2
Route Two
Interface A2
Source TTP A2
Figure 304. Type 3 protection, open ended case, of ASI and JPEG2000 streams.
This protection type supports standby protection with uni- or multicast
streams.
13.2.2.5 Type 3 protection – closed ended
DTM
Figure 305. 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.
13.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.
13.3.1 Configurable interface parameters

13.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.
13.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.
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
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
otherwise.
SDI, JPEG Repeat of last frame or black picture (in case no frame has been
compressed received) if the channel is up. If the channel is down, a black picture
is generated.
Figure 306. Actions taken on the output access interface for the parameter
‘Output action on signal fail’ having value ‘None’.

13.3.1.3 TS-packet sync errors
Default value: Unchecked (Do not ignore)
Type: Binary
Range: Checked, Unchecked (Ignore, Do not ignore)
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. This parameter is only available on Nimbra
600 nodes.
13.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.
13.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.
13.3.1.6 Transport format

Default value: Standard
Type: Drop-down menu
Range: Standard, CASI
Description: Describes the format used for the stream. This parameter is so far only used
for ASI streams on 8 x ASI Transport Access Module. CASI is compressed ASI, where null
packets are stripped from the outgoing stream and regenerated on the receiving side.
Usage of the CASI setting is only recommended for the experienced user and very specific
applications. No check is made if the configured bandwidth is enough for the stream, so
the configured bandwidth must be sufficient at all times. Only available in Nimbra 300
nodes.

13.3.1.7 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.
13.3.1.8 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.
13.3.1.9 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.
13.3.1.10 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.
13.3.1.11 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.
13.3.1.12 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)
13.3.1.13 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.
13.3.1.14 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.
13.3.1.15 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.
13.3.1.16 Interface direction to monitor

Default value: In
Type: Binary
Range: In, Out
Description: This parameter describes which direction is monitored for the selected
interface.
13.3.1.17 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.

13.3.1.18 PDH framing
Default value: g751
Type: Enumerated list in drop-down menu
Range: None, g751, g832
Description: PDH framing type used
In the cross-reference table below, it is shown on which modules/fixed interfaces the
different configurable parameters are found.
Configurable parameter
8 x ASI Transport Access Module

4 x OC-3/STM-1 Access Module
8 x SDI Video Access Module
8 x AES/EBU Access Module

4 x DS3/E3 Access Module
E1/T1 Access Module
Enable signal speed

autosensing
Output action on signal x x x x x
fail
Transport format x
Output mode x
TS-packet sync errors
Suppress alarms x x x x x x
Loopback 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 M M M
selection button
PDH signal to transport x

PDH Framing x
Figure 307. Cross-table Configuration parameters vs. Access Module for Nimbra
300. M designates monitor interface.
Configurable parameter
8 x or 8 x 3Gbps VAM, HD/SD or 3G –SDI
8 x ASI/AES Access Module, AES/MADI

8 x ASI/AES Access Module, 8 x or 8 x
3Gbps VAM, ASI configured interface
JPEG2k VAM v2, HD/SD or 3G –SDI
JPEG2k VAM v2, JPEG encoding
JPEG2k VAM v2, JPEG decoding

configured interfaces
configured interface
configured interface
Enable signal speed x x x
autosensing x
Output action on signal x x x x
fail x x
Transport format
Output mode x
TS-packet sync 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
PDH Framing

Figure 308. Cross-table ITS Configuration parameters vs. Access Module for
Nimbra 600. M designates monitor interface.
13.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 50 ms. This tip only works for unicast
connections.
13.4.1 Terminating Connection

Follow the ITS  Sink TTPs link; a page appears like the page below.
Figure 309. ITS setup sink TTPs main terminating page
Click on Add TTP to configure the Termination; see figure below.
Figure 310. 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 311. Configuration of terminating TTP of an ITS unicast channel.
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. Local DSTI is the DTM Service Type Instance, a unique number per service type,
direction and node. A default DSTI is selected by the system (lowest available number)
but it can be user modified. The DSTIs don’t have to be consecutive.
With the Connection protection parameter, it is possible to configure the sink TTP for
1+1 protection (parameter value on) or without it (parameter off). Note that when
protection is used, there are two terminating connections connected to a single TTP.
Protection is more described in chapter Source Routing.
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.
Degraded threshold and Degraded period are two parameters that together define the
conditions for raising the Degraded alarm. The alarm is raised if (and only if) the degraded
threshold has been reached or surpassed for each second during the degraded period.
When finished with the configuration, click OK or ‘Apply’.

13.4.2 Originating Unicast Connection
Follow the ITS  Source TTPs link; a page appears like the page below:
Figure 312. Definition of the ITS Source TTP.
Click on Add TTP … to enter the setup page. A page similar to the page below will appear.
Figure 313. Addition of an ITS source TTP.
In the web page, the same settings as for the terminating TTP can be made.
Make the settings required (Originating/Unicast), use the drop-down menu to set the
local interface and click on the Add button.

Figure 314. 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 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.
13.5 Setting up a multicast ITS tunnel

13.5.1 Considerations for multicast channels
There are two things that must be considered when a combination of source-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.
node1 node4
3:1 7:2
itso-0 itsi-0
360 sr A
3:2
1:1
1:2
680
7:1
sr B
3:2
3:1
1:1 1:1
sr C
itsi-0 itsi-0
1:2 1:2
360 380
node2 node3
Figure 315. Example of source routes used for multiple destinations.
In the figure above, let sr C from node1 to node2 via node4 and node3 be defined by
Group A SDH/SONET STM-16 Group B SDH/SONET STM-16
IP/Ethernet IP/Ethernet
Figure 316. Definition of sr C in node1.

The source routes to node3 (sr B) and node4 (sr A) must then be defined as:
Figure 317. Definition of sr B in node1, a subset of sr C.
Figure 318. 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!
node1 node4
3:1 7:2
itso-0 itsi-0
360
3:2
1:1
1:2
680
7:1
sr D
3:2
3:1
1:1 1:1
sr C
itsi-0 itsi-0
1:2 1:2
360 380
node2 node3
Figure 319. 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
GroupisAnot considered. SDH/SONET STM-16
In other words, Groupmay
bandwidth allocation B not be optimal.SDH/SONET STM-16
IP/Ethernet IP/Ethernet
13.5.2 Configuration of a Multicast Connection
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 ASI channel is set up between iov072 and iov137. The channel is
terminated on several interfaces in iov137.
Figure 320. Setup of Multicast Channel.
The sequence for fast completion of the circuit is to set up the sink TTPs first and then to
set up the source TTP.

13.5.3 Sink TTPs (Termination)
Follow the ITS  Sink TTPs link and the button Add TTP; a page appears like the page
below:
Figure 321. ITS TTPs create Multicast page
Select the type to Terminating and use the pull-down menu to set the local interface.
Note that as soon as Type is set to Terminating, Mode cannot be set.
Click on the Add button. Repeat for all destinations.
13.5.4 Source TTPs

Follow the Source ITS  TTPs link and the Add TTP button; a page appears like the page
below:
Figure 322. ITS basic setup for source TTP and multicast service.
Chose the type of interface (originating) and type of mode (multicast in our example), 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 323. 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 324. 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 325. Destinations to a source ITS TTPs are defined.
Set Administrative status to Up, Destination DTM to iov137 and destination DSTI to 2 and
3 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.
Figure 326. Destinations defined in the originating TTP.

For every destination, three source routes can be associated (1st, 2nd and 3rd). If ‘use source
route’ is set to auto, the defined source routes are selected in order. If automatic selection
of “best route” (i.e. DRP) is to be used, either no source routes can be defined or one
defined source route must be the “empty route”, i.e. a loose source route without
interfaces or nodes in its definition.
If any of the three choices mentioned above is selected, all destinations will have their
respective source-routes changed at the same time. If ‘first’ is selected and the Force
button is clicked, all destinations will be using respective first source route.
If multiple destinations have defined source routes, there is no way to change this
behavior.
13.6 Advanced settings
Note: Before changing the max and min settings in a production

network please consult Net Insight support services 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 327. Edit ITS Source TTP Advanced Configuration
From this menu a variety of parameters are set: DCP version to be tried, suppression of
primary source route alarm and the parameters of the exponential back-off algorithm.

Requested channel version: This is where the requested version of the DTM channel
Protocol is set. The available versions are two and three. Auto means that version three is
tried first. If version tree is not supported in all nodes along the entire route, version two is
used instead.
Suppress primary source route alarm: This tick box is selected by default. In case it is not
selected, an alarm with severity warning is raised when the primary source 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-establish the connection immediately. If
unsuccessful, after a wait of 10 ms a second attempt is made. A third attempt is made
after a longer time according to the algorithm.
Maximum interval: 50000 ms. The end value of the algorithm. The re-establish
mechanism will wait not longer than 50000 ms to re-establish a channel.
Precedence: This drop-down menu determines if the connection has precedence or not,
i.e. if it is torn down fast (and is re-established fast). Maximum five are recommended per
node.
If required, back up the configuration changes; see chapter Maintenance, section
Configuration handling for details.
13.6.1 Embedded ASI in HD-SDI channels

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 328. 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  interfaces web page of the source interface then shows
the bandwidth used by the ASI stream.

Figure 329. ITS  Interfaces web page of the inserted ASI stream.
13.7 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.
When 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 iov137 to interface asi-6:1 in iov072 is used as
example. It is also shown, how to set up an ASI multicast stream from interface asi-2:1 in
iov137 to multiple interfaces in iov132.
13.7.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 ITS  Sink TTPs web page and click on the Add
TTP button. Select the interface on which the incoming stream is expected.
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
and this choice is irrelevant.
Figure 330. ASI Configuration example

Figure 331. The Add TTP configuration page for ITS. In this example, a
terminating TTP on local interface asi-6:1 in iov072 is set up.
Clicking on ‘Add’ takes the user to the configuration page of the sink TTP.
Figure 332. Configuration parameters for the terminating TTP.

Parameter Type Possible values Default Comment
Administrative Drop-down Up/Down Down
status
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 when two channels ends at the
protected TTP. Disabled w/o dual
channels.
Figure 333. Configuration parameters for terminating TTP
13.7.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 334. When the Add button is clicked, the configuration page of the originating
TTP is presented (Figure 335).
Figure 334. The Add TTP Configuration page for ITS. In this example, a source
TTP on local interface asi-2:1 is set up.

Configuring the originating TTP is made from the following web page:
Figure 335. 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 DTM String Defined hostname or None
node DTM address
Destination DSTI Integer 0-32767 (215-1) 0 Number unique
per service type,
direction and
node
Requested Real 0.8-212 Mbps 2 Mbps Capacity
capacity (Mbps) number dedicated 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. routes possible to
Route Three routes are select (in priority
available per channel. order) per channel
Use Source Drop- (auto), first, second, (auto) A parameter that
Route down third when set changes
the order of
source route
usage.
Figure 336. Configuration parameters for originating TTP
13.7.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 337. Configuration of a multicast originating TTP. Destinations are
defined under the Destinations tab on the source TTP web page.
Figure 338. 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 336).

13.7.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 339. Interface configuration

Parameter Type Value range Default Comment
Output action Drop-down None, Mute None If set to ‘Mute’, the failed signal
on 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, None Should alarms be disabled on

all 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 ticked

errors
Output mode Drop-down Auto, Spread, Auto How should the outgoing ASI
Burst stream be sent, in spread or
burst mode?
Type Drop-down Standby, Hitless Standby What type of protection does

the interface have?
Expected status Drop-down Unavailable Unavailable

Unprotected
Standby
Hitless ready
Hitless protected
Figure 340. Interface configuration parameters
Table for ‘Output action on signal fail’ and possible services.

otherwise.
otherwise.
is generated.
13.8 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. The MADI stream uses 245 slots in
the DTM frame and is displayed with speed 125 Mbps in the web interface.
It requires the 8 x ASI/AES module for Nimbra 600 with MADI firmware running on the
module. This firmware only supports MADI signals; it neither supports regular AES/EBU
streams, nor DVB-ASI video streams. To install MADI firmware, look in the Up- and
Downgrading chapter (chapter 20) and follow the procedure described.
48 kHz 48 kHz
MADI Nimbra DTM Nimbra MADI
Figure 342. 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. Alternatively, the node clock can be
used as a clock source for extracting an egress MADI signal.
Please note that MADI does not use the through-timing of all other services. Instead,
there are a number of possible ways to synchronize the stream. The typical setup uses the
word clock of the egress interface to synchronize the egress traffic. It is possible,

however, to synchronize using any external MADI reference signal. Consequently, it’s
possible to setup any MADI board as a MADI generator for external equipment
13.8.1 Configuration process

Configuration starts on the terminating TTP, whether the service is uni- or multicast.
After having previously defined all terminating TTPs for the service, the originating TTP
should be defined. After all TTPs are defined and the channel is established, some
parameters on the interfaces can be set. These 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 an example. It shows how to set up a MADI multicast stream from
interface aes/ebu-8: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.
13.8.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 link of the TTP and click on the Add TTP button.
Select the interface on which the outgoing stream is wanted.
Pleas note that, once Terminating Type is selected, mode selection will be grayed out.
This is because, for the terminating TTP, configuration is identical for uni- and multicast
services.
DTM
aes/ebu-8:1
Nimbra 680
Nimbra 680 Node iov018
Node iov044
TTP
TTP aes/ebu-6:1
Figure 343. Configuration example with a MADI stream between interface

aes/ebu-8:1 in iov044 and aes/ebu-6:1 in iov018.

terminating TTP on local interface aes/ebu-6:1 in iov018 is set up.
Clicking the ‘Add’ button opens the configuration page of the terminating TTP.
The configurable parameters are defined in the table below:


Administrative Drop- Up/Down Down
status down
(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
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.
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
Degraded Integer 1-1000 10 If the degraded threshold is equal
threshold to or passed (by number of block
errors) during each second of the
degraded period, the Degraded
alarm is raised.
Degraded Drop- 2, 3, 4, 5, 6, 7, 8, 9, 2 See above
period down 10
13.8.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 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.

on the page. Select originating type (unicast mode) and local interface (in the example
aes/ebu-8:1), according to Figure 347. When the Add button is clicked, the configuration
page of the originating TTP is presented (Figure 348).
Figure 347. The Add TTP configuration page for ITS. In this example, an
originating TTP on local interface aes/ebu-8:1 is set up.
Configuration of the originating TTP is made from the following web page:
Figure 348. Configuration parameters for a unicast MADI stream on the

originating TTP

Parameter Type Range Default Comment

status down
(232-1)
Purpose String Character string Empty string Identifier
(Local) DSTI Integer 0-32767 (215-1) Lowest Unique per service type and
available node
Destination DTM String Defined hostname None
node or DTM address
Destination DSTI Integer 0-32767 (215-1) 0 Number unique per service
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
Channel Source down routes in a node. possible to select (in
Route Three routes are priority order) per channel.
available per If no source route is
channel. selected, DRP routes the
channel(s). For 1+1
protection, source routes
are strongly recommended.
Figure 349. Configuration parameters for a unicast, originating TTP. The
bandwidth is not configured as it is always 125 Mbps.
13.8.1.3 Configuration of the originating TTP for a multicast service

the multicast case.

defined thorough the Destinations tab on the configuration page.
Figure 351. 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 336).
13.8.2 Configuration of interfaces

13.8.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 352. Basic interface settings configuration
This interface has some parameters to configure; ‘Output action on signal fail’, ‘Suppress
alarms’; ‘Loopback’; ‘Type’ (can only have one value – Standby); ‘Expected Status’ and
‘Active interface’. 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.

Output action Drop-down None, Mute None If set to ‘Mute’, the failed signal muted
on signal fail Freeze (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 (see below).
If set to ‘Freeze’, the last good frame is
repeated forever.
Suppress alarm Drop-down None, None Suppression of alarms on the
warning, all terminating TTP is possible. The options
are:
None No suppression is made
Warning Suppression of alarms with
severity Warning is made
All All alarms are suppressed
Loopback Drop-down None, DTM None The physical port can be used for both
ingress and egress traffic (DTM
Loopback) or this possibility can be
disabled (None)
Type Standby Standby Standby Parameter that cannot be set for MADI
streams.
Expected If ‘status’ is Unavailable Unavailable Expected status
status “lower” than Unprotected
‘expected Standby
status’ in the protected
Hitless/standby Hitless
state machine, capable
a major alarm Hitless
with text protected
‘Protection
status lower
than expected’
is generated.
Active Answers the e.g. The first ITS One of the two ITS services connected to
interface question itsi-1, service to the physical interface.
“What itsi-2 be
interface is associated
passed on to with the
the output physical
interface?”. interface
Only relevant
for standby
protection.
Figure 353. Interface configuration parameters

Table for ‘output action on signal fail’:

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 error. ‘Mute’ action otherwise.
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 channel is up and there is an error. ‘Mute’ action otherwise.
compressed received) if the channel is up. If the channel is down, a black picture is
generated.
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

Interface Name of the interface
name
Source TTP Name of the TTP, if the TTP is a source TTP; otherwise
none
Sink TTP Name of the TTP, if the TTP is a sink TTP; otherwise
none
Operational Up, Down
status
Description Interface A description of the interface
description
Speed Positive value The currently used bandwidth over the interface.
Purpose String with 0-255 User defined field. Default value is the empty string.
characters
Errored Zero or positive This counter registers the number of errored blocks
blocks value since 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 355. Variables presented on the interface configuration page.

13.8.3 Test generator
There are two mutually excluding signals that can be launched from the interface test
generator configuration page.
Figure 356. Configuration page for built-in test generator for MADI.
On this page, you can enable the test generator for MADI or a World clock by choosing it
in the Output Signal drop down menu and ticking the enable box.
The MADI signal is an AES10 signal, with 64 audio channels, sampled at a 48 kHz rate.
The word clock is a 48 kHz, square-wave clock, with an average output voltage of 0 V and
a 1 V peak-to-peak value.
13.8.4 Timing
MADI timing is defined under the tab ITS  Interfaces  Timing.
Figure 357. Timing definition for an interface. There are two parameters to
define, ‘Operating mode’ and ‘Output reference’.

Figure 358. Selecting Word clock timing source as ‘Operating mode’ will disable
‘Output reference’ and display the ‘Output delay’ input field.
The parameters ‘Operating mode’ and ‘Output reference’ exist both on the source (input)
and sink (output) interfaces. On the source interface, ‘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
Operating Drop- Audio transport Audio transport Audio transport forwards a MADI
mode down Word clock stream and should be used for an
timing source output interface.
Word clock timing source is used for
timing source input. Selecting this
item in the dropdown list will
disable the Output reference list
and display the Output delay input
field.
Output Drop- node sync, aes/ebu-x:8 The output reference to which the
reference down aes/ebu-x:1 to signal is aligned.
aes/ebu-x:8 The interface has to have a word
(excluding the clock timing source attached if
interface under aes/ebu-x:1 to aes/ebu-x:8 is used.
configuration)
‘node sync’ means that the node
clock is used for synchronization of
the output signal (i.e. through-
timing is used).
Output delay field ± 20000000 ns 0 (zero) ns Offset in relation to the output

(± 20 ms) reference for the start of new
frames.
This input field is only displayed
when ‘Operating mode’ is set to
‘Word clock timing source’.
Figure 359. Interface configuration parameters. They exist both for source and
sink interfaces, but are irrelevant for source interfaces.

13.8.5 PM
Figure 360. Performance measurement over the interface. Configuration of PM

related parameters is made from the web page found under the configuration
link.

Figure 361. Configuration of performance monitoring web page.
A guide how to configure the PM parameters is given in chapter 11 Performance

Monitoring.
13.9 Configuration of AES/EBU streams

Configuration starts on the terminating TTP, whether the service is uni- or multicast, 1+1
protected or not. Having defined all terminating TTPs for the service, the originating TTP
can be defined. After all TTPs are defined and the channel(s) is/are established, some
parameters on the interfaces can be set. The parameters can also be configured during
the setup process.
In this text, different examples of an AES/EBU streams are given, from iov137 to iov136.

The simplest stream is a unicast stream from port aes/ebu-6:1 in iov137 to port aes/ebu-
5:1 in iov136. The second case is a multicast stream from port aes/ebu-6:1 to ports
aes/ebu-5:1 and aes/ebu-5:2. In addition, it is shown how to do configurations with a
protective stream in both cases.
13.9.1 Configuration of Terminating TTP

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. Once Terminating Type is selected,
the mode selection option is grayed out. This is because, for the terminating TTP,
configuration is identical for uni- and multicast services.
terminating TTP on local interface aes/ebu-5:1 in iov136 is set up.
Clicking on ‘Add’ takes the user to the configuration page of the terminating TTP.

The configurable parameters are defined in the table below. To activate the terminating
TTP, make sure that the administrative status is set to Up,


status down

(232-1)

string

Local DSTI Integer 0-32767 (215-1) Lowest Unique per service type and node
available
backup.
parameter.

options are:
None No alarm suppression
is made
with severity Warning is made
All All alarms are
suppressed

alarm is raised.

period down 10

The originating TTP is where you configure if the channel is uni- or multicast.
Configuration of protection is made both on the originating and the terminating side of
the connection.
If you define the channel as multicast, the different destinations are entered under a 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.
aes/ebu-2:1), according to Figure 365. When the Add button is clicked, the configuration
page of the originating TTP is presented (Figure 366).
Figure 365. 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 web page obtained by clicking on the
Add button.

Figure 366. Configuration parameters for a unicast AES/EBU stream on the
originating TTP


status down

(232-1)

available node

node or DTM address

type and node
Requested Drop- 32.0, 44.1, 48.0, 48.0 kHz Enumerated list

capacity down 88.2, 96.0, 176.4,
192.0

with one common
destination TTP.

channel(s). For 1+1
Figure 367. Configuration parameters for AES/EBU and the originating TTP.
Set both administrative statuses to up and make sure there is bandwidth available
between the nodes. The channel should now be established.
Once a channel has been set up, it is very simple to set up a protected channel between
the two nodes. All it takes is define a second source TTP to the same destination TTP (i.e.
the destination DSTI). Connection protection to off for both the originating source TTP
and on for the terminating TTP (allows for the receiving TTP to handle two different
streams).
When this is done, both channels should be up and the same information sent two
separate ways through the network. See chapter 13.2.2.3 Type 2 protection – closed
ended for more details.

the multicast case.
Terminating TTPs are defined the same way as they are for a unicast service.

Figure 369. 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 are
used in the unicast case (Figure 336).

13.10 Configuration of SDI streams
Configuration starts on the terminating TTP, whether the service is uni- or multicast, 1+1
protected or not. Having defined all terminating TTPs for the service, the originating TTP
can be defined. After all TTPs are defined and the channel(s) is/are established, some
parameters on the interfaces can be set. The parameters can also be configured during
the setup process.
In this text, different examples of an SDI streams are given, from iov137 to iov136.
The simplest stream is a unicast stream from port sdi-8:1 in iov137 to port sdi-6:1 in
iov136. The second case is a multicast stream from port sdi-8:1 to ports sdi-6:1 and sdi-
6:2. In addition, it is shown how to do configurations with a protective stream in both
cases.
13.10.1 Configuration of Terminating TTP

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. When Terminating Type is selected,
the mode selection option is grayed out. This is because, for the terminating TTP,
configuration is identical for uni- and multicast services.
terminating TTP on local interface sdi-6:1 in iov136 is set up.
Clicking on the Add button takes the user to the configuration page of the terminating
TTP.

The configurable parameters are defined in the table below. To activate the terminating
TTP, make sure that the administrative status is set to Up,


status down

(232-1)

string

Local DSTI Integer 0-32767 (215-1) Lowest Unique per service type and node
available
backup.
parameter.

options are:
None No alarm suppression
is made
with severity Warning is made
All All alarms are
suppressed

alarm is raised.

period down 10

The originating TTP is where you configure if the channel is uni- or multicast.
Configuration of protection is made both on the originating and the terminating side of
the connection.
If you define the channel as multicast, the different destinations are entered under a 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.
sdi-8:1), according to Figure 365. When the ‘Add’ button is clicked, the configuration page
of the originating TTP is presented (Figure 366).
Figure 373. The Add Source TTP configuration page for ITS. In this example, an
originating TTP on local interface sdi-8:1 is set up.
Configuration of the originating TTP is made from the web page obtained by clicking on
the Add button.

Figure 374. Configuration parameters for a unicast SDI stream on the
originating TTP


status down

(232-1)

available node

node or DTM address

type and node
Requested Drop- 32.0, 44.1, 48.0, 48.0 kHz Enumerated list

capacity down 88.2, 96.0, 176.4,
192.0

with one common
destination TTP.

channel(s). For 1+1
Use source route Drop- Auto, 1st, 2nd, 3rd Auto Override of the defined
down source route order. Auto
means that the source
routes are attempted in
order. 1st means that the
first route is tried first, 2nd
that the second route is
tried first and 3rd that the
third route is tried first.
Figure 375. Configuration parameters for SDI and the originating TTP.
Set both administrative statuses to up and make sure there is bandwidth available
between the nodes. The channel should now be established.

Once a channel has been set up, it is very simple to set up a protected channel between
the two nodes. All it takes is to define a second source TTP to the same destination TTP
(i.e. the destination DSTI), but associated with the same interface as the first TTP. Set
connection protection to off for both originating source TTPs and on for the terminating
TTP (this allows for the receiving TTP to handle two different streams).
When this is done, both channels should be up and the same information sent two
separate ways through the network. See chapter 13.2.2.3 Type 2 protection – closed
ended for more details.

the multicast case.
Terminating TTPs are defined the same way as they are for a unicast service.


Figure 377. 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 are
used in the unicast case (Figure 336).
13.11 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
TTP/interface. This is the way the setup is described.
13.11.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 2000 encoded stream, the encoder has to be
enabled. The setting is made on the encoder interface web page.

Figure 378. JPEG 2000 encoding must be enabled in the ‘JPEG 2000 encoding
enable’ check box on the basic interface configuration page.
13.11.2 Sink TTP configuration
Figure 379. Creation of the terminating TTP in a unicast HD-SDI or SD-SDI

JPEG2000 channel. Observe that this 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 380. 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 381. Configuration of the terminating interface
13.11.3 Source TTP configuration

After finishing the configuration of the sink side, proceed with the source side. In this
example, interface 2:1 in iov058 is used as source interface.

Figure 382. 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 2000 is enabled on the interface, only uncompressed configurations will
work.

Figure 383. 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 384. Available settings for ‘Requested capacity’, with the default SDI
uncompressed 270 Mbps setting.
Figure 385. The setting User defined 270 Mbps is treated exactly the same way
as uncompressed SDI 270 Mbps.
JPEG 2000 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 386. 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.
The audio part of the compressed stream is a constant per audio stream. For SD-SDI
streams, the bandwidth requirement is depending on the SD audio mode (20 or 24 bit).
This is described in the table below.
Type of stream Required bandwidth

(Mbps)
per audio group
SD-SDI, 20 bit audio mode 7.3
SD-SDI, 24 bit audio mode 9.7
HD-SDI, 3G-SDI 17
Figure 387. Required audio bandwidth for different types of JPEG 2000
compressed streams.

ANC data varies with exactly what data is transported with the compressed stream. In the
table below, the values are presented for a typical case of 30 frames per second,
interlaced. The total required bandwidth is 3.29 Mbps.
Service Standard Bandwidth (kb/s)

AFD SMPTE 2016-3 12
OP-47 SDP RDD-8 680
OP-47 VANC multipacket RDD-8 850
WSS RDD-8 15
ATC Ancillary Timecode SMPTE 1200-2 17
Caption Distribution Packet (CEA-708) SMPTE 334-1 110
CEA-608 Data SMPTE 334-1 7.7
VPID SMPTE 352 9.6
ANSI/SCTE104 Messages SMPTE 2010 680
Audio Metadata Ch1-16 SMPTE 2020 340*n; n is an integer
between 1 and 9
DVB/SCTE VBI Data SMPTE 2031 580
Sum (rounded) 3290 + (n-1)*340
Figure 388. Bandwidth requirements of different ANC services
VBI can only be sent over compressed SD-SDI signals. The required bandwidth per line is
a constant, but different for PAL and NTSC because they are of different length.
Type BW requirement/line Max number of Max BW requirement

(Mbps) lines (Mbps)
PAL 0.40 35 14
NTSC 0.48 21 10
Figure 389. Bandwidth requirement for VBI data
In addition to Basic settings, also Advanced settings can be configured.

Figure 390. Configuration of the originating TTP, advanced settings.
13.11.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 391. Configuration of a multicast channel, in this case uncompressed.
Figure 392. Add destinations to a multicast channel. To get to this web page,
click on the Destinations tab in the previous picture.

Figure 393. Addition of a new destination to an originating multicast TTP.

13.11.5 Interface configuration
Figure 394. 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.

13.11.6 Basic interface parameters
13.11.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.

otherwise.
otherwise.
is generated.
13.11.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.
13.11.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 396. DTM loopback mode.
13.11.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. To change the value of this
parameter, the administrative status must be down on the TTP.
13.11.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.
13.11.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.

13.11.7 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 397. Video configuration on an SDI interface. The page is only available
on the encoding side.
13.11.7.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.
13.11.7.2 Cb weight (%)

Default value: 5
Type: real number
Range: 2-15
Description: Weight of the Cb or blue difference component of the video.
13.11.7.3 Cr weight (%)

Default value: 5
Type: real number
Range: 2-15
Description: Weight of the Cr or red difference component of the video.

13.11.8 Audio interface parameters
Figure 398. Audio configuration on the encoding side. Audio groups five to eight
are only available for 3G-SDI speeds.
13.11.8.1 Audio group enable (for groups one to eight)

Default value: Selected
Type: Check 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.
13.11.8.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.
and ancillary (ANC) data.

13.11.8.3 SD Audio Mode (for SD-SDI compressed streams only)
Default value: 20-bit
Type: Drop-down, 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.
and ancillary (ANC)/vertical blanking interval (VBI) data.
13.11.8.4 Reduced audio transport bitrate

Default value: No
Type: Binary
Range: Yes, No
Description: Selects if the audio stream is transported “as is” or with a reduced transport
stream header. Selecting reduced audio transport does not compress the audio stream in
any way.

13.11.9 Ancillary (ANC) interface parameters
Figure 399. ANC parameter configuration on the encoding side. The web page
makes it possible to transport only some of the ANC services. Default is that
all ANC data is transported.
On the encoding interface, ancillary (ANC) data 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
ANSI/SCTE 104 Messages 0x41 0x07
ATC Ancillary Timecode 0x60 0x60 Ancillary Time Code
Audio Metadata (Single Program) 0x45 0x01
Audio Metadata Ch 01/02 0x45 0x02
Caption Distribution Packet 0x61 0x01

(CEA-708)
CEA-608 Data 0x61 0x02 Only usable in 30/60 frames per

second systems
DVB/SCTE VBI Data 0x41 0x08
OP-47 SDP 0x43 0x02 Subtitling Distribution Packet
OP-47 VANC multipacket 0x43 0x03 Vertical ANC Packets
User specified 0x50 0x30 User specific Ancillary data

defined by DID and SDID
User specified 0x53 0x49 User specific Ancillary data

defined by DID and SDID
VPID 0x41 0x01
WSS 0x50 0x01 Wide Screen Signaling
Figure 400. 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.

13.11.10 Vertical Blanking Interval (VBI) interface parameters
Figure 401. Configurable VBI parameters for JPEG 2000 SD-SDI compressed
signals with PAL or NTSC 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 or NTSC button. To select all or no lines, use the All or None
button.

13.11.11 Statistics
Figure 402. 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
rate through the interface
Total maximum Highest possible value of the previous counter

bit rate
Figure 403. Variables shown on the Interface Statistics web page.
13.12 Interface Groups and 4K Functionality

Interface Groups are used to collect and synchronize separate streams that, when put
together, make up a 4K stream. Both Level A and Level B standards are supported.
Interface Groups enable the collection of four streams, each one carrying part of a single
4K, JPEG2000 compressed multi- stream. Interface Groups are only available on port 1 to
4 on the video boards.
Due to the demands placed on the hardware, it will be necessary to use two (2) video
boards on each side of the stream. That means that a true 4K stream will require 4 video
boards. Two video boards on the Source side, and two video boards on the Sink side.
Each switch will have to use ports 1 and 2 for the streams, while annexing the hardware
resources of port 3 and 4 as well for extra elbow room.

Note: If the 4K stream is according to the Level A standard, it might be
possible to use ports 3 and 4 on the participating video boards for non-
4K streams. This is due to a better fit of the Level A standard with
regards to the video board hardware capabilities.
Please keep in mind that even with a Level A compliant stream, you will
still need 2 video boards on each side, using port 1 and 2, for the 4K
stream. Also, using ports 3 and 4 while streaming 4K media on ports 1
and 2 is to risk creating a bottleneck in the flow and is not Best Practice.
13.12.1 Configuring Interface Groups

As explained in the previous chapter, you will need to use ports 1 and 2 on two video
boards at the Source end, and a similar setup on the Sink end, to establish the 4K media
stream. The streams are decoded and collected into a single 4K stream at the Sink by
assigning them to an Interface Group.
Interface Groups are collections of media streams, typically 4 FHD streams that make up
a single 4K media stream when put together in an Interface Group. Only interfaces on
ports 1 to 4 can be assigned to Interface Groups.
4K streams are usually split up into four streams, each covering a quarter of the image
transmitted. The separate streams are then sent from the Source to the Sink, where they
are put together into a single 4K stream again.
Figure 404. 4K is transmitted in 4 separate streams, each containing a quarter of

the image.
Interfaces can be assigned to Interface Groups in their respective settings. Go to ITS 

Interfaces  [Interface object]  Basic tab. If the Interface in question is on port 1 to 4,
an Interface Group dropdown list will be present in the top section of the tab.
The dropdown list will always contain the options “None” and “New Group”. Already
existing Interface Groups will also be present. If the list alternative “New Group” is
chosen, a new Interface Group will be generated.

Interface Groups are automatically created when an interface is added, and automatically
deleted when the last interface object is removed from it. Interface Groups are assigned a
name. You can’t choose or alter the name. But you can specify a descriptive Purpose for
the Interface Group on the Basic tab of its properties.
Figure 405. Adding an Interface to an Interface Group

Interface Groups and their assigned interfaces are listed on the ITS Interface Groups
web page. If you click on the group name, or the name of any of its members, you will
open their respective properties web page.
Figure 406. The Interface Group web page.
Figure 407. The Basic tab of an Interface Group.
The properties of an Interface Group will have a Basic tab and a PM tab.On the Basic tab
you can specify a descriptive Purpose or click on the links to the Members. The PM tab is
where Performance Monitoring for the Interface Group is handled. The PM functionality
is described in the next chapter.
13.12.2 Performance Monitoring Interface Groups

The Performance Monitor settings of Members of an Interface Group doesn’t have to be
identical. Each member interface of an Interface Group can have individual monitoring
settings for performance issue alarms. Settings for individual Interfaces are available in
the ITS  Interfaces  [interface object] PM tab. For more in-depth information
regarding PM settings, see the chapter on Performance Monitoring.

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 408. Performance Monitoring, monitored parameters
In the web interface, Performance Monitoring is found under the Perf. monitor link. The
general configuration settings for all performance measurement points in a node are set
on the Perf. Monitor  Configuration web page. The PM information for all interfaces
and Interface Groups are collected and listed in a table on the ITS  Perf. Monitor web
page.
Performance Monitoring of a 4K stream will be an aggregate of all the partaking streams
in the Interface Group. The details of the aggregated PM will be dependent on the PM
settings of the individual Interfaces. For an error to be reported in the group, the
individual PM object where the error occurs must have Performance Monitoring activated
for that particular parameter.
The configurable parameters are:

Administrative Binary Up, Up This parameter enables (Up) or disables
status Down (Down) PM on the PM object.
Enable UAT Binary On, Off Off This parameter enables (‘On’) or disables
alarms (‘Off’) 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
threshold (‘Off’) threshold crossing alarms on the PM
crossing alarm object. One of 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
suppression (‘Off’) zero 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
history reports (‘Off’) 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
15m SES Integer 0-900 1 Value for 15m SES threshold, where zero has
threshold a special meaning of disabling the threshold.
15m BBE Integer 0- 2 Value for 15m BBE threshold, where zero has
15m SS Integer 0-900 1 Value for 15m SS threshold, where zero has a
24h ES Integer 0- 10 Value for 24h ES threshold, where zero has a
24h SES Integer 0- 1 Value for 24h SES threshold, where zero has
threshold 86400 a special meaning of disabling the threshold.
24h BBE Integer 0- 10 Value for 24h BBE threshold, where zero has
24h SS Integer 0- 1 Value for 24hm SS threshold, where zero has
threshold 86400 a special meaning of disabling the threshold.
Figure 409. Configurable parameters for PM objects.

13.12.3 Frame Synchronization of Interface Groups
From the point of view of setup and usage, there is no difference between Frame
Synchronizing an Interface Group and Frame Synchronizing an “ordinary” Interface. The
procedure and functionality is the same regardless. See the chapter on Frame
Synchronizer for more information.
Both analogue and digital sync reference signals are supported. The sync reference
source can be configured per media stream. That means one sync reference is used for
the entire 4K multi-stream. It is possible to adjust delay offset to the sync reference on a
per port basis. That means that every “part-stream” of the 4K multi-stream can have a
unique offset from the sync reference source.
If analog blackburst synchronization is used, it must be input (and output) through port 8.
Digital synchronization reference can use any port.
One of the streams in the 4K multi-stream can be assigned to act as the sync reference. In
that case, local synchronization reference is not needed.
13.13 Configuration of 1+1 protection video services

In general terms, 1+1 protection video services is a collection of techniques for failover
switching on defective frames. The aim is to, as far as possible, secure an uninterrupted
flow. Hitless Protection minimizes defective frames by aligning and merging two identical
packet streams. The downside is added end-to-end latency. Seamless Protection repeats
the previous frame on detected faults, limiting the added latency but not protecting
against, for instance, random packet loss.
13.13.1 1+1 Seamless protection video services

Uncompressed SDI frames has a built-in fault protection, enabled by the Frame
Synchronizer function in conjunction with Standby 1+1. One leg will be active and the
other standby. If a fault is detected on the active leg a synchronous switch is performed to
the standby leg. The defective frame will be dropped and the previous frame repeated to
minimize visible impact. That way, the frame delivery proceeds with preserved phase and
frequency.

Figure 410. Defective frames are dropped and the previous frame repeated.
13.13.2 1+1 Hitless protection video services

Hitless 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.

Figure 411. Hitless Video 1+1 Protection switching merges two identical packet
streams to eliminate loss of data.
Hitless Video 1+1 Protection is available for Nimbra 600 nodes on the following Access
Modules:
JPEG2000 Video Access Module v2 (NPS0074-6001)
SFP Video Access Module (NPS0054-6001)
Video Access Module v2 (NPS0052-6001)
Nimbra network
Node A Node B
Figure 412. 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.
13.13.3 Hitless web parameters and variables

There are three configurable web parameters in the hitless video 1+1 protection release.
They appear at the bottom on the outgoing sink interface web page.

Figure 413. New parameters to configure in Hitless Video 1+1 Protection.
In the table, parameters and their possible values are detailed. Non-configurable variables
are also listed.
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 and 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.

Parameter/Variable Description
Max differential delay Can be set to “auto” (default) or “manual”. If set to “manual”, an
upper limit to the differential delay can be specified in the
adjacent field. The span is from 0 to 10 000 ms.
The mode “auto” is not applicable to ASI transport. It works only
for SDI. If “auto” is configured, the hitless buffer will be set to
the maximum buffer. For example, it will be 1 s at 20 Mbps.
Please remember that regardless of the manual setting, the
actual differential delay will always be limited by what is
practically achievable by the hardware.
Figure 414. New parameters and variables on the sink interface in Hitless video
1+1 protection.
13.13.3.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 415. Addition of a sink TTP in the destination node.

Figure 416. Configuration of a sink TTP (itsi-3 or Sink TTP B1 in the previous
illustration). 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 417. Addition of the second sink TTP in the destination node.

Figure 418. 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 419. Created sink TTPs.
13.13.3.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 Add TTP button.
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 420. Configuration of first source TTP (itso-7 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 421. Configuration of second source TTP. (itso-8 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 C
13.13.3.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 422. Type of protection is selected in the Type drop-down menu. Hitless
is available only if there are two sink TTPs (Member interfaces; itsi-3 and itsi-4)
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.

13.14 Configuration of interfaces – Test Generator
Test generators for MADI, AES, ASI and all SDI versions (SD-SDI, HD-SDI and 3G-SDI) are
available on the video ports. 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.
An enabled test generator is active both on the TX and RX side of the port, i.e. the signal
can be used as an input signal to another port via a BNC cable or it can be set up as a
source TTP and distributed in the network as a unicast or multicast ITS channel. In fact, it
can be used in both fashions simultaneously.
In order to access all these test generators, go to the link ITS  Interfaces  Test
Generator.
13.14.1 AES
Under the Interface link to the specific AES interface, a Test generator link is available.
Figure 423. 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

Parameter Type Default Range Explanation
Sample Drop- 48.0 kHz 32.0 kHz Sample rate for the (non-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 424. Configurable AES interface test generator parameters.
13.14.2 MADI
The MADI test generator can be set to either MADI signal or Word clock signal.
There is only one parameter to configure and that is to enable or disable the test
generator itself.
Figure 425. Configuration of MADI test generator
If set to MADI, 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.
The Word clock Output signal is for when the MADI board is used as a MADI generator for
external equipment.
13.14.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 v2, 8 x ASI/EBU Video Access module
and JPEG2000 Video Access Modules v2.

Figure 426. 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
(MFN) set to 0xb8. All other sync bytes are set to 0x47.

Figure 427. Configurable ASI interface test generator parameters.
13.14.4 SDI
Under the Interface link to the specific SDI interface, a Test generator link is available.
Figure 428. Test generator configuration for an SDI interface.
The configurable test generator parameters are described in the table below:
Parameter Type Default Possible values Comment
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

Parameter Type Default Possible values Comment
Pattern Drop- matrix black ‘black’ means a digital black pattern;

down matrix ‘matrix’ means pathological
color75 equalizer and PLL pattern; ‘color75’
means 75 % color bar pattern.
Pattern is increasing with one per
packet.
Figure 429. Configurable Test generator on an SDI interface.
13.15 Configuration of Frame Synchronizer and

Reference Sources
Frame synchronizer can be used to achieve inter-studio synchronization by establishing a
common studio clock for timing of frames. Frame synchronization is automatically used
when transmitting a 4K media stream. It is necessary, because the stream is transported
as 4 separate streams from the Source to the Sink, where it is assembled again.
It is possible to configure how SDI or JPEG 2000 encoded video streams are synchronized.
Individual streams on the same video boards can use either the node clock or another
relevant video stream on the same module. The synchronization information is
distributed within the video transport infrastructure, so no additional equipment is
needed.
Figure 430. Frame Synchronizing.
On our current JPEG decoder modules, only ports one to four support JPEG2000
decoding and those are the only ports with automatic frame alignment implemented.
Ports five to eight can be used as reference source. On our current Video Access Module
v2, all eight ports can have frame alignment activated.
Figure 431. Digital sync reference can be input on any port, analog blackburst
can only be input on port 8.

Figure 432. One stream acts as master reference. In this setup, no local sync
reference input is needed.
Note: The E0D0 and E0D4 Video Access Applications both support
Frame Synchronsation. It is supported for both encrypted and
unencrypted streams.
The E4D0 Video Access Application doesn’t support Frame
Synchronization.
13.15.1 Reference sources

Ports used as reference source has to be configured accordingly. In order to have access
to the timing parameters, the administrative status of all TTPs defined on the interface
has to be down. The web page for interface objects supporting timing parameters is
shown below.
Figure 433. Timing configuration on an SDI interface. This is available on ports

one to four on a JPEG 2000 decoder module and all ports on a regular Video
Access Module v2.
13.15.1.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 primarily used by the system as a
signal to be transported and secondly as timing source. If the transport channel goes
down, the signal is also lost as timing reference. If the signal is configured as ‘Digital
timing source’, the signal is primarily used as a digital timing source and secondly as a
signal source. In this case, if the transport channel is lost, the signal is still used as timing
source. ‘Analog timing source’ (available on port eight for J2K Video Access Module, all
ports on the Video Access Module v2 and on all ports on the SFP Video Access Module
with suitable SFP module) is used for an analog timing source input signal.
13.15.1.2 Output reference

Default value: sdi-x:y, the interface itself. This setting means that no alignment is made
and the node is operating in through-timing mode.
Range: Node sync, sdi-x:1, sdi-x:2,…, sdi-x:n, where n is number of interfaces on the node
in question. The interface itself as output reference means that we are operating in
through-timing mode.
Description: Reference is the outgoing timing signal used to clock out the signal from the
interface being configured.
13.15.1.3 Output delay (ns)

Default value: 0
Type: integer
Range: Plus or minus half a frame, expressed in ns. For example, with frame rate 25
frames per second one full frame is 40 ms. In this case, the range is ± 20 ms or ± 20000000
ns.
Description: Offset in relation to the output reference for the start of new frames.
Figure 434. Timing configuration on a JPEG 2000 Decoder SDI interface (five to
eight). Note that if an interface is to be used as a timing source, it has to be
configured as a digital timing source first. On port eight, an analog timing
source can also be attached and configured as such (not shown).

13.15.2 Configuring Frame synchronizer
Frame synchronizing is enabled by default if JPEG 2000 encoding is enabled. It has to be
manually enabled for other types of encoding. To turn Frame synchronizing on for an
interface, the "Output action on signal fail" must be set to "Freeze".
To set the "Output action on signal fail", go to ITS  Interfaces  [interface object].
The "Output action on signal fail" is defined in a dropdown list in the third section of the
Basic tab of the Interface. The available options are "None", "mute" and "freeze". Choose
the “Freeze” option to enable Frame Synchronizing.
Figure 435. The “Output action on signal fail” must be set to “Freeze” for Frame
Synchronization to be enabled.

14 Channel Persistence
14.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.
14.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.
14.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.
User's Guide Channel Persistence  381

14.2.2 Link Class Persistent
Note: 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 enter a NoControl mode if the
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. 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 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 condition), it will
tear down all channels over that link.
Persistent links are useful to protect end-nodes that are single points of failure for a
service. An interface configured with link-class Persistent will never have status
DownKeep, it will go to status Down instead.
14.2.3 Link Class Nailed
Note: 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 that the channels cannot forward any data since there is a loss-of-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 restarts. In the NoControl mode, the node will not run the normal DTM
protocol stack and instead leave the hardware configured as-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 channels.
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.

14.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.
14.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.
14.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.
14.3.1 The Trunk network  Links Page

The Trunk network  Links web page displays the status of communication with all
neighboring nodes. 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.
14.3.2 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.
14.3.3 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

14.3.3.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”.
14.3.3.2 Restarting via Serial Console

To restart the node via serial console, use the CLI-command “node-restart local”.
14.3.3.3 Restarting from a Neighboring Node

To restart a neighboring node, look at the Trunk network  Links page. It will show the
operational 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.
14.3.4 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.
14.3.5 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.
14.3.5.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.
14.3.5.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
Re-connect Channel button.
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 Delete button to tear down the channel from the terminating side as well.
14.3.5.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 Re-connect Checked
button. 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.
14.3.6 Channel reestablishment upon link failures

14.3.6.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 436. 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 437. 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.
14.3.6.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.
14.3.7 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.

15 Connection and channel
lists
15.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 438. List of originating connections
User's Guide Connection and channel lists  389

Figure 439. List of terminating connections
Figure 440. List of channels to, from and via the node

Figure 441. 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 442. List of error statistics

16 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.
16.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.
16.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.
User's Guide Source Routing  392

Figure 443. A source-route with explicit interface specifications
16.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.
16.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 444. 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 445. Specification of the first source route

Figure 446. 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 447. 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, Applyor ’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 448. Definition of a loose-far-route-to-iov101.
In the same way, a loose version of Close-route-to-iov101 can be defined.
Figure 449. Definition of a loose version of close-route-to-iov101.

16.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.

17 Loopback
17.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.
17.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 450. 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:
User's Guide Loopback  398

Figure 451. 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 Applyor 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:
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 error. ‘Mute’ action otherwise.
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, ‘Mute’ action, possibly involving some extra noise from short cables, if
MADI 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 channel is up and there is an error. ‘Mute’ action otherwise.
compressed received) if the channel is up. If the channel is down, a black picture is
generated.

17.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 453. DTM loopback mode. The signal is copied to the Rx port on the
same interface before being sent out on the Tx port.
Figure 454. Configuration of DTM loopback on a fixed interface in Nimbra 340.

17.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.
17.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 455. 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.
17.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 Applyand the configuration is made.
Figure 456. 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.
17.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 457. 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. The second ITS service is configured as a regular ITS service, with
source TTP tied to the interface set to DTM loopback mode.
Figure 458. 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’.

18 Redundancy for Nimbra 600
18.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 459. 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 complete the reset, nodeStatus has to be set to Up by the user. At this point,
traffic disturbance follows on the persistent channels.
User's Guide Redundancy for Nimbra 600  404

18.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. Replication takes place directly after the
configuration is saved.
Note: It is essential to save any altered configuration on the active

Node Controller. If this not is done, the standby Node
Controller is not properly updated and a potential reboot is
made on a different configuration than the one currently
running.
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 460. 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.
18.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.

19 Module installation
19.1 General
There are a few things to consider when a new or replacement module is added to a node
installed in a network in full operation. It is critical to have complete nodes aligned to
specific system release software. New modules delivered from the shelf typically have
different system release software than the node and even if they do happen to share a
common software base, they must be treated as if they do not.
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:
c:\Users\dummy\Repos\GX5.1.0.2>dir
Volume in drive C is Win7Pro
Volume Serial Number is CCB0-0888
Directory of c:\Users\dummy\Repos\GX5.1.0.2
2015-05-06 11:16 <DIR> .

2015-05-06 11:16 <DIR> ..
2015-02-18 16:01 66 740 AP_install
2015-02-18 16:01 5 929 fingerprints
2015-02-18 16:02 3 408 md5sums
2015-02-11 13:06 511 152 NPM0006-0155_B3.flow
2015-02-18 16:00 13 521 676 NPM0013-N301_AM2.flow
2015-02-11 13:06 303 060 NSF0010-0141_B9.flow
2015-02-11 13:06 325 844 NSF0010-0441_B9.flow
2015-02-11 13:06 314 260 NSF0010-1621_B9.flow
2015-02-11 13:06 511 152 NSF0011-0001_A36.flow
2015-02-11 13:06 511 152 NSF0012-0001_B8.flow
2015-02-11 13:06 1 027 760 NSF0013-0001_C6.flow
2015-02-11 13:06 1 027 760 NSF0013-0141_C6.flow
2015-02-11 13:06 1 027 760 NSF0013-0421_C6.flow
User's Guide Module installation  407

2015-02-11 13:06 580 016 NSF0014-0001_B3.flow
2015-02-11 13:06 580 016 NSF0014-A001_A9.flow
2015-02-11 13:06 1 834 436 NSF0020-0001_A24.flow
2015-02-11 13:06 1 852 876 NSF0020-AEB1_A22.flow
2015-02-11 13:06 2 147 596 NSF0020-SD01_A13.flow
2015-02-11 13:06 388 772 NSF0021-0360_E9.flow
2015-02-11 13:06 561 256 NSF0032-0380_B11.flow
2015-02-11 13:06 692 772 NSF0040-0390_A20.flow
2013-01-28 10:08 88 292 NSS0004-0001_1.2.2.flash
2013-09-26 13:47 849 172 NSS0006-X001_G1.flow
2015-02-18 16:00 3 388 000 NSS0011-0001_AJ2.flow
2014-10-17 14:27 46 068 NSS0012-0001_B2.flow
2014-10-17 14:27 46 324 NSS0012-0002_B2.flow
2015-02-18 16:00 17 374 684 NSS0013-0001_AR2.flow
2012-04-13 08:50 335 408 NSS0014-0001_A6.flow
2014-10-10 09:32 13 744 NSS0019-APP1_H4.flow
2013-11-27 11:56 73 940 NSS0024-3001_B1.flow
2014-09-19 10:38 90 268 NSS0024-3901_D1.flow
2015-02-18 16:00 1 165 900 NSX0011-0001_AF6.flow
2014-10-17 14:27 994 248 NSX0012-0001_AF2.flow
2014-10-17 14:27 933 344 NSX0018-0002_AF2.flow
2014-10-17 14:27 945 100 NSX0020-0001_AF2.flow
2014-10-17 14:27 942 448 NSX0021-0001_AF2.flow
2014-11-24 10:17 1 846 060 NSX0022-0001_AH1.flow
2014-11-24 10:17 1 886 924 NSX0022-ET11_P1.flow
2015-02-18 16:00 1 456 924 NSX0025-0001_AF6.flow
2014-11-24 10:17 2 229 436 NSX0027-0001_AM1.flow
2014-11-24 10:17 3 626 536 NSX0030-E0D0_AA1.flow
2014-10-17 14:27 656 228 NSX0031-3602_S5.flow
2014-10-17 14:27 587 716 NSX0031-36T1_G5.flow
2014-10-17 14:28 3 976 028 NSX0031-N013_S5.flow
2014-10-17 14:28 3 603 100 NSX0031-NT12_G5.flow
2014-11-24 10:17 1 461 032 NSX0033-A001_W1.flow
2014-11-24 10:17 1 462 216 NSX0033-E001_AA1.flow
2014-11-24 10:17 1 420 584 NSX0033-M001_Y1.flow
2014-10-17 14:28 2 543 656 NSX0034-E601_X5.flow
2015-01-23 14:41 1 586 492 NSX0036-0002_U1.flow
2015-01-23 14:41 1 600 204 NSX0036-3902_G1.flow
2014-10-17 14:28 4 964 968 NSX0037-0001_Q5.flow
2014-11-24 10:17 4 765 672 NSX0037-A002_I1.flow
2015-02-18 16:00 7 014 184 NSX0039-00A4_N2.flow

2014-11-24 10:17 3 831 764 NSX0040-E0D0_W1.flow
2014-11-24 10:17 5 350 804 NSX0040-E0D4_W1.flow
2014-11-24 10:17 5 559 412 NSX0040-E4D0_W1.flow
2014-11-24 10:17 5 134 092 NSX0042-ET04_E1.flow
2013-11-27 11:57 19 324 NTS0016-3001_A1.flow
2014-03-10 08:45 21 564 NTS0016-3901_B1.flow
2013-11-27 11:57 22 972 NTS0017-N300_A1.flow
2014-03-10 08:45 21 020 NTS0017-N390_B1.flow
2015-02-18 16:01 12 645 Packages.list
63 File(s) 121 743 890 bytes
2 Dir(s) 10 167 488 512 bytes free
19.2 Differences Nimbra 360 vs Nimbra 600

Implementation of administrative status is different on Nimbra 360 and Nimbra 600. If a
module has administrative status set to Down on a Nimbra 360 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 360 must be made with
admin status Up. With this exception, 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

19.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 Status
 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 461. Status equipment page, with administrative status of all present
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 462. Status equipment page, with administrative status of all present
modules set to up. The new module is intended for IF8, which has admin
status down.
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 463. 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 464. 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 Install image button. The page below appears on the screen.

Figure 465. 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 466. Example of an http server. The repository of system release

software GX5.1.0.2 is found under directory official/ GX5.1.0.2 / GX5.1.0.2 / of
the http server.

Figure 467. Example of an ftp server. The repository of system release software
GX5.1.0.1 is found under directory official/ GX5.1.0.1 / GX5.1.0.1 / 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 468. Progress report of installation.
When the installation is complete, the web interface communicates this.

Figure 469. 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 restart IPMC, the command
swap restart -d <slot> -i management
can be used. Slot is the module position i.e. if1-if8, nca, ncb, swa or swb.
After this step is completed, just set the administrative status to Up and the module is
operational and the node is fully aligned. Now, payload is started and the module is fully
operational on the correct software version.

20 Up- and Downgrading
20.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.
20.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.
20.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
User's Guide Up- and Downgrading  416

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).
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
GX4.13 6
GX5.0 7
GX5.1 7
GX5.2 10
GX5.3 12
Figure 470. 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 471. Header for configuration file BasicConfigGX47
20.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.10.0.2 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
20.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 Save Configuration
button.
Figure 472. Save configuration web page.

After this step is taken, continue with web page Maintenance  Software. The Install
Image button 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 473. Install system release software web page.
In case an ftp server is used instead of an http server, 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 474. Installation from http server 10.100.0.82. Repository GX5.1.0.2 is
residing on directory /official/GX5.1.0.2.
Figure 475. Installation from ftp server 10.100.1.144 with user luser and
password neti.
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 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 of new software is most likely service disrupting.
The described 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.
It is crucial that downgrade is made on a configuration file with proper version number
(i.e. the same as expected by the software) discussed earlier (Figure 470. System release
software and configuration version numbers).
20.2.4 Required intermediate system releases

Note that in case you do not require a previous configuration, it is not needed to upgrade
in steps as described in this procedure. It is sufficient to remove (delete) all previous
configuration files and upgrade directly to the chosen release. The unit will revert to
system default settings, including IP address 192.168.125.125. All settings will have to be
reconfigured.
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 releases

release system
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.3 GX4.9.0.2
GX4.13.0.0
GX5.0 GX4.13.0.1
GX5.3
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.2.0.7 GX4.10.0.3 GX4.9.0.2
GX4.3.0.0 GX4.13.0.0
GX4.3.0.1
GX4.3.0.3 GX5.0 GX4.13.0.1
GX5.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.3 GX4.9.0.2
GX4.13.0.0
GX5.0 GX4.13.0.1
GX5.3
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.3 GX4.9.0.2
GX4.13.0.0
GX5.0 GX4.13.0.1
GX5.3
GX4.8.0.3 - GX4.8.0.4 No intermediate system releases
GX4.9.0.2 GX4.9.0.2 required
GX4.10.0.3 GX4.9.0.2
GX4.13.0.0
GX5.0 GX4.13.0.1
GX5.2
GX4.10.0.2 GX5.0 GX4.13.0.1
GX4.13.0.1 GX5.3
Figure 476. 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 GX5.3.0.0
must go through GX4.3.0.4, GX4.4.0.7, GX4.7.0.5, GX4.9.0.2 and GX4.13.0.1.
Current system Target Required intermediate system releases

release system
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.3.0.0 GX4.10.0.3 GX4.9.0.2
GX4.3.0.1 GX4.13.0.0
GX4.3.0.3
GX5.0 GX4.13.0.1
GX5.3
Figure 477. Explanation how to read the previous table; in this case how to
upgrade from version GX4.2.0.6 to GX5.3. All the emboldened system releases
are required intermediate system releases.
For upgrades from versions prior to GX4.1.2 (Nimbra 600 series), this procedure may not
work. In case you have such needs, please contact Net Insight.

20.3 Addition of functional enhancement
20.3.1 General
All functional enhancements described in this section of Element Manager require
separate software licenses.
Note: All 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.
20.3.2 Changing fixed trunk interface on Nimbra 310/320/360/380
Note: This procedure should only be executed with a separate

data network. Using 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/360/380
is easiest changed from the web interface.
Note: Changing the default setting of 4 x STM-1/OC-3 trunks

requires additional 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 and configure. On this page, click on the Install On-board
Image button.

Figure 478. 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 479. 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 480. Activation of the new firmware is made by clicking on the Bring
Installed Image Into Service button.
Figure 481. Warning pop-up after firmware upgrade of trunks in Nimbra

310/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.
20.3.3 Changing trunk interfaces on 3 x IP/Ethernet Trunk Module in

Nimbra 300 series

The functionality of the plug-in 3 x IP/Ethernet Trunk Module (NPS0053-3001) is to

transport three different IP trunks. This module is by default equipped with firmware
NSX0031-N013 (3 x IP/Ethernet Trunk Application), but it can also be equipped with
firmware NSX0031-NT12 (2 x IP/Ethernet + TT Trunk Application). This firmware supports
only two interfaces, but they can be used for time transfer signals as well.

Note that changing firmware requires additional licenses, which should be obtained
before upgrading.
To change firmware from the web interface, follow the link Maintenance  Software.
On this page, click on the Install Image button.
Figure 482. Web page for replacement of firmware on a 3xIP/Ethernet module.
A new web page appears; Maintenance  Software  Install image. In front of the URL
to the repository, some options are needed.
Figure 483. Change of firmware, from 3 x IP/Ethernet to 2 x IP/Ethernet + time

transfer
To change firmware in a 3 x IP/Ethernet module, to add time transfer capability (and

remove one useful interface), fill out the field with
-d <slot#1,slot#2,...> --replace NSX0031-N013,NSX0031-NT12
http://<IP>:<Port>/<repos>
This is illustrated above.
To do the reverse:
-d <slot#1,slot#2,...> --replace NSX0031-NT12,NSX0031-N013
http://<IP>:<Port>/<repos>

, which is illustrated below:
Figure 484. Change of firmware, from 2 x IP/Ethernet + time transfer to 3 x

IP/Ethernet
To activate the change, it is necessary to toggle the administrative status of the module,
i.e. to set it first to down and then back to up. This is most easily done from web page
Status  Equipment.
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.
20.3.4 Setting modes for 4 x DS3/E3 Trunk/Access Modules

The 4 x DS3/E3 trunk/access module for Nimbra 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-0001 and firmware for access mode is NSF0014-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 485. Installation of access firmware on a 4 x DS3/E3 module running trunk
firmware starts with the ‘Install image’.
Figure 486. 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.
Multiple targets can be included with a comma separated list.
When the download is finished, save the configuration once more and use the Bring
Installed Image Into Service button. These actions are detailed previously.
An 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.

20.3.5 Changing firmware on JPEG2000 Video Access Modules

From GX4.12 and later releases, there is one version of JPEG 2000 Video Access Module
v2 for Nimbra 600. The module can run different firmware, giving it different properties
like encoding, decoding and 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; if used for decoding, a JPEG decoding
firmware must be 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
Access module v2 6001 E0D0 video
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 487. 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). 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 <Old FW>,<New FW> http://<IP>:<Port>/<Repos>
Of course, both actions can be made from an ftp server rather than an http server.
Multiple targets can be included with a comma separated list.
In order to put JPEG encoding firmware on the module with default (E0D0) 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. Of course, the actions
can be made from an ftp server rather than an http server. Multiple targets can be
included with a comma separated list.
20.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 488. 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.
20.3.5.2 Limitations and licenses

Using either JPEG2000 encoding or decoding firmware requires JPEG2000 feature
licenses. In GX4.12, one feature license is required to encode/decode one stream of SD-
SDI. To encode/decode HD-SDI two licenses are required and to encode/decode 3G-SDI
four licenses are required. Up to eight licenses can be used per module, i.e. at most four
HD-SDI streams can be compressed on a module. The remaining four interfaces can be
used for uncompressed streams.
This release supports JPEG2000 compressed 3G-SDI, HD-SDI and SD-SDI, together with
uncompressed 3G-SDI, HD-SDI, SD-SDI or ASI. Stream selection is made per interface,
i.e. different stream types can be encoded or decoded on a single module.

20.3.6 Changing firmware on 8 x ASI/AES Access Module
8 x ASI/AES Access Module for Nimbra 600 can run on different firmware, giving it
different properties. The module is delivered with AES firmware by default, supporting up
to eight AES audio streams. In addition, there is an ASI version (supports 8 x ASI video
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
AES NSX0033-E001 Supports up to 8 x AES audio streams
ASI NSX0033-A001 Supports up to 8 x ASI video streams
MADI NSX0033-M001 Supports a multiplexed MADI audio stream
Figure 489. 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 AES firmware. To change from the AES
firmware to either ASI or MADI firmware from the web GUI, go to the web page
Maintenance  Software and click the Install Image button.
Figure 490. Downloading ASI firmware, replacing AES default firmware on an 8

x ASI/AES Access Module.
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 ASI 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 if6 --replace NSX0033-E001,NSX0033-A001 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 if6 --replace NSX0033-E001,NSX0033-M001 ftp://user:pass@iov136:2222/repo
Changing from ASI to MADI firmware is done in a similar way. Here it is illustrated from
the http-server.
-d if6 --replace NSX0033-A001,NSX0033-M001 http://192.168.234.99:9090/repos
By extension, changing from MADI to AES becomes:

-d if6 --replace NSX0033-M001,NSX0033-E001 http://192.168.234.99:9090/repos
Of course, the actions can be made from an ftp server rather than an http server. Multiple
targets can be included with a comma separated list (i.e. –d if2,if4,if6).
20.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 AES
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.
20.3.7 Changing firmware on 8 x Gigabit Ethernet Access Module

8 x Gigabit Ethernet Access Module for Nimbra 600 can run on different firmware, giving
it different functionality. The module is delivered with regular (unprotected) Ethernet
firmware. In addition, there is an 1+1 protected version (supports 1+1 protection;
configurable on the service/channel level).
The available firmware modules are presented in the table below.
Firmware Description
NSX0022-0001 8 x Gigabit Ethernet Access Application
NSX0022-ET11 8 x GE Access, S/H 1+1 Option
Figure 491. Different firmware possible to load on an 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 492. 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
targets can be included with a comma separated list.
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.
20.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.
20.3.8 Changing firmware on 10 GE Module

10 GE Module for Nimbra 600 can run on different firmware, giving it different
functionality. The module is delivered with regular 2x10 Gb/s IP/Ethernet trunk
application. In addition, there is an Ethernet Access application that is available in a 1+1
protected version (supports 1+1 protection; configurable on the service/channel level).
The available firmware modules are presented in the table below:
Firmware Description
NSX0037-0001 2 x 10 Gb/s IP/Ethernet trunk application
NSX0037-A002 2 x 10 G Ethernet Access S/H 1+1 Option
Figure 493. Different firmware possible to load on a 10 GE Module

In order to load Ethernet access firmware on a 10 GE 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 494. Replacing regular 10 GE Module firmware with Ethernet Access

firmware
The firmware to be replaced is NSX0037-0001 and the replacement firmware with

Ethernet access 1+1 functionality is NSX0037-A002. Specifically, if the module is installed
in slot number eight, the extended URL becomes (with the same http server, port and
repository as in previous chapter):
-d if8 --replace NSX0037-0001,NSX0037-A002
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 if8 --replace NSX0037-A002,NSX0037-0001
http://192.168.234.99:9090/repos
targets can be included with a comma separated list.
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.
20.3.8.1 License
Note that in order to use Ethernet Access firmware, an additional feature license must be
purchased, irrespective of the need for firmware swap on the module.
20.3.9 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 495. 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.

21 License information
21.1 General
Some elements of this product include third party software released under open source
licenses.
21.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
21.2.1 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.
21.2.1.1 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.
User's Guide License information  437

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.
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.
21.2.1.2 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
21.3 Other open source third party software

21.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.
21.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])
1. Redistributions of source code must retain the above copyright notice, this list of
2. Redistributions in binary form must reproduce the above copyright notice, this list of
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
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.
21.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.
21.3.4 uip
Copyright © 2006, Swedish Institute of Computer Science.
All rights reserved.
1. Redistributions of source code must retain the above copyright notice, this list of
2. Redistributions in binary form must reproduce the above copyright notice, this list of
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
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.
21.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

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

Element Manager Manual PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Element Manager Manual PDF

Uploaded by

Copyright:

Available Formats

User's Guide

Nimbra 300 series

Phone: +46 8 685 04 00

1.1 Overview ...................................................................................................................... 13

1.2 Intended reader ............................................................................................................. 13

1.3 Support and assistance .................................................................................................. 13

1.4 Conventions in this manual ............................................................................................ 13

2 GLOSSARY OF TERMS .............................................................................. 15

3 QUICK START GUIDE ................................................................................20

3.1 Overview ...................................................................................................................... 20

3.2 Configuration of the IP address ...................................................................................... 20

4 KEY CONCEPTS ........................................................................................ 31

4.1 General ......................................................................................................................... 31

5 THE USER INTERFACE ..............................................................................34

5.1 Overview ...................................................................................................................... 34

5.2 Command Line Interface ................................................................................................ 34

5.3 Web interface ................................................................................................................ 34

User's Guide Contents  3

©2017 Net Insight AB, All rights reserved

5.5 Default username/password........................................................................................... 35

5.6 Logging in with a telnet or SSH connection ..................................................................... 35

5.7 Logging in using a web browser ...................................................................................... 35

6 STATUS WEB PAGE .................................................................................. 37

6.1 Overview of Status ........................................................................................................ 37

6.2 Alarms and events ......................................................................................................... 38

6.4 Equipment .................................................................................................................... 42

6.5 Sensors ......................................................................................................................... 48

6.6 Inventory ...................................................................................................................... 49

6.7 Who (is currently logged in) ............................................................................................ 51

6.8 NTP (Network Time Protocol) ........................................................................................ 51

7.1 Overview ...................................................................................................................... 54

7.2 System - settings ........................................................................................................... 55

7.3 System - syslog ............................................................................................................. 58

7.4 System - restart............................................................................................................. 58

7.5 Date and Time ............................................................................................................... 59

7.6 Users ............................................................................................................................ 60

7.7 Preferences ................................................................................................................... 62

7.8 Configurations .............................................................................................................. 63

©2017 Net Insight AB, All rights reserved

7.9 Software (maintenance) ................................................................................................ 67

7.10 SSL Certificate .............................................................................................................. 70

7.11 Alarm I/O (configuration) ............................................................................................... 72

7.12 Cooling ......................................................................................................................... 77

7.13 Software program error alarm ........................................................................................ 77

8.1 General about In-band management .............................................................................. 80

8.2 Configuration ................................................................................................................ 82

8.3 Building networks with DLE ........................................................................................... 83

8.4 IP routing ...................................................................................................................... 84

8.5 Control Network - main web page .................................................................................. 85

8.6 In-band servers .............................................................................................................. 86

8.7 In-band clients .............................................................................................................. 90

8.8 Bandwidth requirements of DLE..................................................................................... 93

8.9 IP interfaces .................................................................................................................. 94

8.10 IP routing configuration ................................................................................................. 97

8.11 SNMP configuration .................................................................................................... 100

User's Guide Contents  5

©2017 Net Insight AB, All rights reserved