LightSOFT NBI V14.0 User Guide

LightSOFT NBI
Version 14.0
NBI User Guide

LightSOFT NBI User Guide
V14.0
Catalog No: X92872
Drawing No: 432006-2461-093-A00
April 2018
Rev01
ECI's NPT-1800, NPT-1200, NPT-1050, NPT-1021, and NPT-1010 are CE2.0 certified.
ECI's qualification lab is accredited by A2LA for competence in electrical testing according to
the International Standard ISO IEC 17025-2005 General Requirements for the Competence of
Testing and Calibration Laboratories.
ECI's management applications run on VMWare virtualization hypervisors.
© Copyright by ECI, 2018. All rights reserved worldwide.

This is a legal agreement between you, the end user, and ECI Ltd. (“ECI”). BY OPENING THE DOCUMENTATION AND/OR DISK PACKAGE, YOU ARE
AGREEING TO BE BOUND BY THE TERMS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT, PROMPTLY RETURN THE
UNOPENED DOCUMENTATION AND/OR DISK PACKAGE AND THE ACCOMPANYING ITEMS (INCLUDING WRITTEN MATERIALS AND BINDERS OR OTHER
CONTAINERS), TO THE PLACE FROM WHICH YOU OBTAINED THEM.
All documentation and/or disk and all information and/or data contained in the documentation and/or disk ["ECI's Proprietary"] is ECI's proprietary
and is subject to all copyright, patent, and other laws protecting intellectual property, and any international treaty provisions, as well as any specific
agreement protecting ECI's rights in the aforesaid information. Any use of ECI's Proprietary for any purposes [included but not limited: published,
reproduced, or disclosed to third parties, in whole or in part] other than those for which it was disclosed, without the express prior written permission
of ECI, is strictly forbidden.
ECI's Proprietary is provided "AS IS" and may contain flaws, omissions, or typesetting errors. No responsibility and or liability whatsoever are assumed
by ECI for you or any other party, for the use thereof, nor for the rights of third parties, nor for any loss or damage whatsoever or howsoever caused,
arising directly or indirectly in connection with ECI's Proprietary, which may be affected in any way by the use and/or dissemination thereof. ECI
reserves the right, without prior notice or liability, to make changes in equipment design or specifications including any change in and to the ECI's
Proprietary.
Any representation(s) in ECI's Proprietary concerning performance of ECI's product(s) are for informational purposes only and are not warranties of
product performance or otherwise, either express or implied. No warranty is granted nor liability assumed in relation thereto, unless specifically
undertaken in ECI's sales contract or order confirmation. ECI's Proprietary is periodically updated, and changes will be incorporated in subsequent
editions. All graphics included in this document are for illustrative purposes only and might not correspond with your specific product version.
The documentation and/or disk and all information contained therein is owned by ECI and is protected by all relevant copyright, patent, and other
applicable laws and international treaty provisions. Therefore, you must treat the information contained in the documentation and disk as any other
copyrighted material (for example, a book or musical recording).
Other Restrictions. You may not rent, lease, sell, or otherwise dispose of ECI's Proprietary, as applicable.
YOU MAY NOT USE, COPY, MODIFY, OR TRANSFER THE DOCUMENTATION AND/OR DISK OR ANY COPY IN WHOLE OR PART, EXCEPT AS EXPRESSLY
PROVIDED IN THIS LICENSE. ALL RIGHTS NOT EXPRESSLY GRANTED ARE RESERVED BY ECI.
All trademarks mentioned herein are the property of their respective holders.
Notwithstanding the generality of the aforementioned, you expressly waive any claim and/or demand regarding liability for indirect, special,
incidental, or consequential loss or damage which may arise in respect of ECI's Proprietary contained therein, howsoever caused, even if advised of
the possibility of such damages.
The end user hereby undertakes and acknowledges that they read the "Before You Start/Safety Guidelines" instructions (when provided by ECI) and
that such instructions were understood by them. ECI shall not be liable to you or to any other party for any loss or damage whatsoever or howsoever
caused, arising directly or indirectly in connection with you fulfilling and/or failure to fulfill in whole or in part the "Before You Start/Safety Guidelines"
instructions.
Contents
Useful information .................................................................................................vi
Related documents ............................................................................................................................... vi
Contact information .............................................................................................................................. vi
Revision history ..................................................................................................................................... vi
1 Getting started with LightSOFT NBI ............................................................. 1-1

1.1 LightSOFT Multilayer Subnetwork (MLSN) ............................................................................ 1-2
1.2 LightSOFT Flow Domain (FD) ................................................................................................. 1-3
1.3 Topology links ........................................................................................................................ 1-3
1.4 Fiber connectivity .................................................................................................................. 1-4
1.5 UMEs ...................................................................................................................................... 1-5
1.5.1 LightSOFT trails on UMEs ........................................................................................................ 1-5
1.5.2 UME object association and naming ....................................................................................... 1-5
1.6 TP data ................................................................................................................................... 1-5
1.7 Trails and SNCs ....................................................................................................................... 1-6
1.7.1 EMS SNCs ................................................................................................................................ 1-6
1.7.2 Optical SNCs ............................................................................................................................ 1-6
1.7.3 SNC types ................................................................................................................................ 1-7
1.7.4 SNC states................................................................................................................................ 1-7
1.7.5 Server trails ............................................................................................................................. 1-7
1.7.6 Error reasons and success/failure of operations ..................................................................... 1-8
1.7.7 CreateAndActivateSNC reply codes ........................................................................................ 1-8
1.7.8 SNC parameters....................................................................................................................... 1-9
1.7.9 Presenting LightSOFT trails to OSS ........................................................................................ 1-10
1.7.10 Editing and reconnecting SNCs ............................................................................................. 1-12
1.7.11 SNCs on UMEs ....................................................................................................................... 1-12
1.7.12 Unique IDs for uploaded SNCs .............................................................................................. 1-12
1.8 Tunnels and SNCs ................................................................................................................. 1-13
1.8.1 Specifying tunnel endpoints .................................................................................................. 1-13
1.8.2 FRRs ....................................................................................................................................... 1-13
1.8.3 Presenting LightSOFT tunnels to OSS .................................................................................... 1-13
1.8.4 IDs for uploaded tunnel SNCs ................................................................................................ 1-14
1.9 Ethernet services and FDFrs ................................................................................................ 1-15
1.9.1 EMS FDFrs ............................................................................................................................. 1-15
1.9.2 FDFr types ............................................................................................................................. 1-15
ECI Telecom Ltd. Proprietary iii

LightSOFT NBI NBI User Guide Contents
1.9.3 FDFr states............................................................................................................................. 1-16

1.9.4 Error reasons and success/failure of operations ................................................................... 1-16
1.9.5 Connectionless Port Termination Point (CPTP) ..................................................................... 1-16
1.10 FDFr parameters .................................................................................................................. 1-17
1.10.1 Traffic mapping tables ........................................................................................................... 1-19
1.10.2 Presenting LightSOFT Ethernet services to the OSS .............................................................. 1-19
1.10.3 Editing FDFrs.......................................................................................................................... 1-20
1.10.4 Unique IDs for uploaded FDFrs ............................................................................................. 1-21
1.11 EML functionality ................................................................................................................. 1-21
1.12 No EMS visibility................................................................................................................... 1-21
1.13 Edge PTPs ............................................................................................................................. 1-21
1.14 Inconsistency ....................................................................................................................... 1-22
1.15 Naming and general object mapping rules .......................................................................... 1-22
1.16 Supported notifications ....................................................................................................... 1-23
1.16.1 Lifecycle notifications and LightSOFT-OSS synchronization .................................................. 1-23
1.16.2 Alarms, TCAs, and other events ............................................................................................ 1-24
1.16.3 Notification configurations ................................................................................................... 1-30
1.16.4 LightSOFT northbound notification service ........................................................................... 1-30
2 Keep-Alive mechanisms............................................................................... 2-1
3 Security ....................................................................................................... 3-1
4 GetRoute cross connect ordering ................................................................ 4-1

4.1 Cross connect structures ....................................................................................................... 4-1
4.2 Cross connect structure components .................................................................................... 4-2
4.3 Cross connect starting and ending points ............................................................................. 4-2
4.4 Flex trail cross connections .................................................................................................... 4-3
4.5 Trail component numbering .................................................................................................. 4-3
4.6 Tunnel component numbering .............................................................................................. 4-4
5 GetRoute returned attributes ...................................................................... 5-1

5.1 Bidirectional trail with protection.......................................................................................... 5-1
5.2 Point-to-multipoint ................................................................................................................ 5-3
5.3 DRI (standard) ........................................................................................................................ 5-4
5.4 DRI with protected links......................................................................................................... 5-6
5.5 DNI ......................................................................................................................................... 5-8
5.6 Protected server trail (unidirectional) ................................................................................... 5-9
ECI Telecom Ltd. Proprietary iv

LightSOFT NBI NBI User Guide Contents
5.7 Protected P2P tunnel ........................................................................................................... 5-10

5.8 P2MP tunnel ........................................................................................................................ 5-11
6 Supported operations ................................................................................. 6-1
7 Obtaining PM status .................................................................................... 7-1

7.1 LSNPerformanceManagementMgr_I interface ..................................................................... 7-1
7.2 Parameters............................................................................................................................. 7-1
7.3 LSNPMTPSelectIterator_I interface ....................................................................................... 7-2
ECI Telecom Ltd. Proprietary v

Useful information
This document explains the usage of MTNM as the Northbound Interface from the LightSOFT® Network
Management System to an Operations Support System (OSS).
Related documents
 LightSOFT NBI Code Reference Manual
 LightSOFT NBI Explanatory Documents
 LightSOFT Documentation Suite
Contact information
Telephone Email
ECI Documentation Group +972-3-9268145 techdoc.feedback@ecitele.com
ECI Customer Support +972-3-9266000 on.support@ecitele.com
Revision history
Revision Section Description
1 N/A New
ECI Telecom Ltd. Proprietary vi

1 Getting started with LightSOFT NBI
LightSOFT supports a NorthBound Interface (NBI) based on both TMF814 v2.1 and TMF814 v3.5.
The NBI supports provisioning, fault management, basic maintenance and performance monitoring
operations for all managed EMSs, including EMSs that manage third-party equipment.
NOTE: For security reasons, you must change your password during the first login, either by
your administrator, or via the LightSOFT GUI.
Provisioning is supported by LightSOFT in the subnetwork view, where the entire NMS topology is
represented as a single subnetwork.
LightSOFT supports provisioning of connections between edge ports of the subnetwork.
For high-order/server connections, LightSOFT may also allow provisioning between ports that are not on
the edge of the subnetwork.
For information about the southbound services configured via LightSOFT, see the LightSOFT User
Documentation Suite.
Certain attributes of southbound services such as ASON/WSON protection and Multisegment Pseudowire
(MS-PW) can also be configured via the NBI. For details, see the LightSOFT NBI Explanatory Documents.
Figure 1-1: Typical network management architecture
ECI Telecom Ltd. Proprietary 1-1

LightSOFT NBI NBI User Guide Getting started with LightSOFT NBI
1.1 LightSOFT Multilayer Subnetwork (MLSN)

The entire LightSOFT topology including all technology layers is reported in a single Multilayered
Subnetwork (MLSN).
Subnetwork Connections (SNCs) are created through the MLSN object.
SNCs correspond to:
 End-to-end trails and the part of the trail that is managed and known within the LightSOFT
subnetwork.
 MPLS tunnels and the part of the tunnel that is managed and known within the LightSOFT
subnetwork.
The subnetwork therefore spans all managed elements (MEs). MEs that are provided over the interface
correspond to LightSOFT MEs at the physical technology layer.
This also includes unmanaged MEs (UMEs).
The Subnetwork Type presented to the OSS (which is the entire LightSOFT network), is always
TOPO_MESH.
Figure 1-2: LightSOFT MLSN

1.2 LightSOFT Flow Domain (FD)

All the Ethernet switches in the entire LightSOFT topology are reported in a single Flow Domain (FD).
Flow Domain Fragments (FDFrs) are created through the FD object.
An FDFr corresponds to either an end-to-end Ethernet service or to the part of a service that is managed
and known within the LightSOFT subnetwork.
1.3 Topology links

Topology links are discovered but not created over the interface.
All links are provided as internal links of the LightSOFT subnetwork.
Virtual links created in the client technology layer in LightSOFT (e.g. SDH is a client of OTN), are reported to
the OSS as links on the same Physical Termination Point (PTP). They are also reported as trails in the server
layer. AdditionalInfo in the TopologyLink object is supported to indicate the underlying trail of a virtual
link.
AdditionalInfoAttribute Values AVC Comment

name
LSNExt_UnderlyingTrail String – RDN of the Yes Only appears for virtual links.
underlying trail. (e.g. RDN is the last part of the LP-STM DN)
This points to
<LightPATH> or
EoS/MoT trail, or
ASON LDL trail.
Topology links connecting UMEs are provided over the interface for UMEs that are uploaded to the OSS.
See section UMEs.
Figure 1-3: LightSOFT Multi-technology MLSN

1.4 Fiber connectivity

Fiber connectivity defines the characteristics of the connectivity between ports connected via physical
fibers.
Defining fiber connectivity provides the following benefits:
 Power equalization: fiber connectivity is essential for ports participating in power equalization to pass
power control parameters to one another (e.g. ports residing in passive optics cards, optics cards and
WDM ports on L1 service cards). With the exception of passive optics cards, these ports cannot
transmit traffic if fiber connectivity configuration is missing. For all other cards, fiber connectivity is
optional.
 Diagnostic information: provided via ONCP (Optics Network Control Parameters).
 Top Down Trail application: Links and trails can be created in LightSOFT and their configuration sent
to the STMS. The STMS can then send the configuration to the NE.
 Fibers can be connected in one of the following ways:
 Intra-fiber connectivity (internal): fibers are connected with an NE. For example connectivity
between cards residing in the same chassis, or between an Apollo card and an Artemis (passive)
optical card. Fiber connectivity parameters defined on one port are automatically copied to the
peer port.
 Inter-fiber connectivity (external): Fiber connectivity between two different NEs. Fiber
connectivity parameters must be defined on the NEs at both endpoints of the fiber.
When fiber connectivity is defined, each port provides details of the fiber connectivity configuration of its
connected peer.
Fiber connectivity is defined on OTUk, OTS, and OCHP ports.
You can view the following OTN link parameters:
Parameter Description Possible Values
LSNExt_ConsistencyStatus Computed consistency state of link  Consistent
in the EMS  Inconsistent
 Incomplete_Unspecified
 Incomplete_Unmanaged
 Incomplete_Unconfigured
LSNExt_ConnectivityType Indicates if the link is Internal or  Internal
External  External
LSNExt_ExpectedFiberLossAend/ Input fiber loss to be configured (in Float (-1, 0-100, ±0.1)
LSNExt_ExpectedFiberLossZend dB)
LSNExt_ConfiguredPMD Polarized Mode Dispersion (PMD)  For intra-fiber connectivity,
default=0.
 For inter-fiber connectivity,
PMD range=0-40.
 Default varies according to
fiber length.

1.5 UMEs
There are situations when a distorted view of the network would be given if UMEs were not uploaded, for
example, LightSOFT trails going through UMEs (i.e. connected to LS MEs on either side of the UME).
A UME may represent customer equipment which the OSS may not have another way of knowing. It is not
always possible to "ignore" a UME, e.g. to directly connect the XDMs on either side of a non-terminal UME.
The links may be of different STM levels and trails may have TSIs, so the UME needs to be uploaded.
All UMEs are uploaded to the OSS.
1.5.1 LightSOFT trails on UMEs

If a LightSOFT trail goes through a UME which has not been uploaded to the OSS, the trail is uploaded to
the OSS with a gap in its route.
Trail endpoints on UMEs are discussed in section TP Data.
1.5.2 UME object association and naming

UMEs shall be uploaded as Managed Elements and included in all requests of the "getManagedElements"
type.
The "productName" attribute shall be set to "UME-xxx", where "xxx" is the type of UME. When the type
cannot be supplied, the attribute shall be simply "UME".
The name of a UME is the same as the name in the LightSOFT database.
NOTE: Regarding the possible loss of UME identification due to loss of the LightSOFT
database, it is the network administration’s responsibility to keep adequate backups of the
LightSOFT database information, so that information regarding UMEs (as well as other
important information) is not lost.
1.6 TP data
Parameters for Termination Points (TPs) can be set or changed from an OSS both directly and as part of an
SNC operation, as described in Namespace Documentation.
When specifying the input data for setTPData or for an SNC operation which changes TP Data, the
operation will be rejected if ingressTrafficDescriptorName and egressTrafficDescriptorName are not both
empty. The rejection is described in section SNC Parameters and Attributes.

1.7 Trails and SNCs

For information on supported trails and SNCs, see:
 EMS SNCs
 Optical SNCs
 SNC types
 SNC states
 Server trails
 Error reasons and success/failure of operations
 createAndActivateSNC reply codes
1.7.1 EMS SNCs

EMS SNCs are provided as cross connect data structures.
For example, the SNC operation getRoute returns the list of cross connects. However, cross connects are
not MTNM objects over the NorthBound Interface.
The order and form of the cross connect information in a returned route is described in GetRoute
CrossConnect Ordering.
1.7.2 Optical SNCs

Optical trails are retrieved by the OSS using the the common eNI commands for trail retrieval operations,
including getAllSubnetworkConnections, getAllSubnetworkConnectionsWithTP, getSNC, getRoute,
getAllSNCsWithRoutes.
The getAllSubnetworkConnections, getAllSubnetworkConnectionsWithTb, and getAllSNCsWithRoutes
take a list of rates as the required parameter.
Only SNCs which carry those rates are returned.
The following types of optical SNCs can be retrieved: OMS, OCH, ODUk (where k specifies the trail rate e.g.
4, 3e, 2, 2e or 1) and LP.
These SNCs have a client-server relationship as follows:
 OCH SNCs use OMS SNCs as server SNCs.
 ODUk SNCs use OCH and higher-order ODUn SNCs as server SNCs.
 LP SNCs can use either OCH SNCs or ODUk SNCs as server SNCs.
In addition, OCH and LP SNCs can contain part of an ODUk SNC. In such a case, the OCH and LO SNCs cannot
function as server SNCs for the ODUks.
The LSNExt_ODUComponent indicates which ODUk is contained in an OCH or LP SNC.
The FEC (Forward Error Correction) and frequency configurations are required for optical trails.
Configuration is performed at the endpoint of the optical SNC and can be received by the OSS.

For more information see Layer Parameters in the Additional Information.
1.7.3 SNC types

Only ST_EXPLICIT type is supported.
Point-to-multi-point trails are treated as single SNCs.
Although in TMF814, ST_EXPLICIT is used to model types of connectivity which are not covered by other
implicit SNC types, the LightSOFT implementation uses this type for all SNCs.
1.7.4 SNC states

LightSOFT uses only the following states:
1. SNCS_ACTIVE when all cross connects have been successfully created and activated in the NEs.
2. SNCS_PARTIAL when one (or more) cross connect(s) has/have not been successfully created and
activated.
3. SNCS_NONEXISTENT is used only in an SNC that is being returned to the OSS after a successful
request to deactivateAndDeleteSNC the SNC, indicating that the SNC no longer exists (i.e. no parts
were left undeleted in the network).
LightSOFT does not allow a trail to be defined without creating it in the network. In other words, LightSOFT
does not support the Pending state of trails.
1.7.5 Server trails

LightSOFT supports the explicit creation and presentation of server trails via the NBI (NorthBound
Interface).
LightSOFT’s handling of server trails is semi-automatic.
When an SDH link is established between XDMs, the server trails are created automatically and are
available to carry low-order trails. However, when non-server high-order trails are needed, or server trails
which traverse XDMs (i.e. not just linking two adjacent XDMs), the existing server trails must be manually
deleted and the new high-order trails created.
When the high-order trails are no longer needed and are deleted, they are not automatically replaced by
regular server trails. The regular server trails should either be manually recreated immediately, or manually
created as needed for low-order traffic.

1.7.6 Error reasons and success/failure of operations

Error reasons appear in two different places depending on the success or failure of the operation.
Failure of an operation is indicated by the raising of an exception. An exception consists of an exception
code (EXCTP_xxx) and an Error Reason field giving further details of the failure.
On the other hand, an operation may succeed but not completely. This case is not an exception, and the
completeness of the operation is indicated in any return parameters of the operation. One of the return
parameters is Error Reason, in which details of the failed parts of the (successful) operation are given.
Note that, according to MTNM rules, an operation can fail by raising an exception only if there is no change
to the system or network resulting from the operation. This can be because there really was no change, or
because LightSOFT undid whatever changes might have occurred.
If there is any change to the system or network after the operation, the operation must succeed (i.e. no
exception raised), and the results can be ascertained from the out parameters.
1.7.7 CreateAndActivateSNC reply codes

In LightSOFT, a new LSNExt_Reply_Codes structure containing reply codes is sent when a trail is created via
createAndActivateSNC and modifySNC.
The structure is:
errorList: error[]
as follows:
error: {object, errorCode, errorText}
object: one of the following:

 DN of the error object(as string)
 "Total"
 "NMS"
 "EMS"
errorCode: integer representation of the error
errorText: the text displayed in the GUI.
Example:
name=LSNExt_Reply_Codes
value=([5]{"[5]Total";0;"[11]Ok.(code=0)"},
{"[3]NMS";49;"[36]Trail created in LightSoft.(code=49)"},
{"[3]EMS";68;"[32]All XCs created in EMS.(code=68)"},
{"[0]";5;"[42]Protection quality does not match.(code=5)"},
{"[0]";7;"[52]Protection quality and layer does not match.(code=7)"})
The first number in brackets represents the number of values in the comma separated list.

Every value has 3 objects: string, number, string. In the example above, the first number [5] represents the
following 5 values in the list, separated by a comma:
{"[5]Total";0;"[11]Ok.(code=0)"}
{"[3]NMS";49;"[36]Trail created in LightSoft.(code=49)"}
{"[3]EMS";68;"[32]All XCs created in EMS.(code=68)"}
{[0]";5;"[42]Protection quality does not match.(code=5)"}
{"[0]";7;"[52]Protection quality and layer does not match.(code=7)"}
The number in brackets at the beginning of each string object describes the number of characters in the
following text. In the example above, the number [5] in the string object "[5]Total" represents the
following 5 characters in Total.
1.7.8 SNC parameters

Values of parameters that are specified by an OSS as part of a request involving SNCs are never ignored.
If unsupported values are specified, the request is rejected with the NOT_SUPPORTED exception, and the
name(s) of the offending parameter(s), separated by commas when there is more than one, is/are put into
the Error Reason field of the exception.
The following SNC parameters are supported:
 EMS Freedom Level: As explicit provisioning of high-order server trails must be done in order to
createAndActivate an SNC requested at the client layer, only EMSFL_CC_AT_SNC_LAYER is
supported.
 Static Protection Level: There is a difference between the MTNM definitions of the values of this
parameter and the ECI definitions. LightSOFT supports the MTNM definitions in the NorthBound
Interface.
The StaticProtectionLevel will take one of the following values: {PREEMPTIBLE, UNPROTECTED,
PARTIALLY_PROTECTED, FULLY_PROTECTED, HIGHLY_PROTECTED}.
The StaticProtectionLevel values are defined as follows:
 PREEMPTIBLE: Has resources that can be taken to recover another SNC, which will result in this
SNC not functioning.
 UNPROTECTED: An SNC that will fail if any resource in its route fails.
 PARTIALLY_PROTECTED: Protection exists but has at least one shared node, shared fiber
(includes shared link or shared optical section), or shared SRLG name.
 FULLY_PROTECTED: An SNC that will not fail if any single managed resource along its route fails
(excluding the originating and terminating nodes for the SNC), for example, an SNC that is
diversely routed at any layer.
 HIGHLY_PROTECTED: A higher level of protection than is possible by simple diverse path
routing. Typically this is achieved in a SONET/SDH environment using dual ring interworking,
where the proper use of links enhances survivability over that offered by simple diverse path
routing. Highly Protected is used when the OSS wishes to request the highest available
protection level from LightSOFT. An SNC or trail which qualifies as Fully Protected and also has a
DRI part, is considered Highly Protected. Note that DRI does not include DNI for this purpose.

 Protection Effort: EFFORT_WHATEVER and EFFORT_SAME are supported. If EFFORT_SAME is

specified, the difference between the requested protection and the resulting protection level will be
left in the Error Reason field.
 Tolerable Impact: Only GOI_MAJOR_IMPACT is supported except when createAndActivateSNC is
used for Reconnect. Then use GOI_HITLESS.
 TPs to Modify: For checkValidSNC, must be empty. For other operations, as in Namespace
Documentation.
 Consider Resources (checkValidSNC): Only True is supported.
 NE TP Inclusions: Must be of the trail layer or its direct server layer (e.g. for a VC-12 trail, a VC-4
server trail may be selected as a constraint, but not a topology link).
 Routing optimization criteria as specified in eNI specifications, including "LSN" extensions, are
supported.
 IngressTrafficDescriptorName, EgressTrafficDescriptorName (TPData): Must be empty.
 Owner (in createData): Must be empty.
 User Label: If empty, LightSOFT generates one using the same algorithm as used by the GUI and XML,
based on endpoints.
 Force Uniqueness (of User Label): True should be supported if performance impact ≤ 30 sec. If True is
not supported, operation should be rejected if True specified.
 Reroute Allowed: Only NO and NA are supported.
 Network Routed: Only NO and NA are supported.
 SNC Type: Only ST_EXPLICIT is supported.
 Full Route: Only False is supported.
 CC Inclusions: Must be empty.
 NE TP SNC Exclusions: Must be empty.
Parameters not listed above behave as described in the LightSOFT NBI Code Reference Manual.
1.7.9 Presenting LightSOFT trails to OSS

LightSOFT trails are presented to an OSS as SNCs.
The fields of SubnetworkConnection_T have the following contents:
Field Details
name See section Unique IDs for Uploaded SNCs
userLabel trail label
nativeEMSName trail's name as it appears in the trails list in LightSOFT
owner as in the component cross connections (EMS SNCs)
sncState see section SNC States
direction according to the direction of the trail
rate as in the component cross connections (EMS SNCs)
staticProtectionLevel see section Error Reasons and Success/Failure of Operations

Field Details
sncType see section SNC Types
aEnd, zEnd lists of endpoints
rerouteAllowed RR_NO, except for ASON trails which can be network rerouted
networkRouted NR_NO, except for ASON trails which need to be network routed
additionalInfo Each of these parameter names begins with "LSNExt_"
LSNExt_TrailConfState Tunnel/trail state Incomplete/Inconsistent/OK required in getAllSNC Corba NBI
output for SDH Trails.
DNI True if DNI trail, else False or omitted
DRI True if DRI trail, else False or omitted
DRIBridges Number of DRI bridges, omitted if not DRI trail
ExtraTraffic True if Extra Traffic trail, else False or omitted
ProtectLayer Current/Underlying/Current_Underlying/
Unprotected
EoSType EoS-VC-12/EoS-VC-3/EoS-VC-4_STS-3c/EoS-STS-1/MoT VC-12/MoT VC-3/MoT VC-
4 STS-3c/MoT STS-1 (EoS/MoT only)
EoSLayer Layer1/Layer2/Layer1AndLayer2 (EoS/MoT only)
ActivateBW Boolean (EoS/MoT only)
DiverseRoutes Short: number of diversely routed groups (0 or 1 = no diversity) (Eos only)
PathType String of chars, one per trail EP, each char one of M/P/B/U
EndPointDiverseRoute <Int>[SP<Int>[SP<Int>]…] Route numbers of EoS/MoT trail EPs
FixedSNC True if all XCs are fixed, otherwise False
TrailId {<workstation Id>, <Trail Id(long)>}
VirtualConcateRate same as in EMS
C2VGoupIndexAEP same as in EMS (see SubnetworkConnection_T)
C2VGoupIndexZEP same
VPNId as in EMS
Customer as in EMS
TypeDetails if flex trail, TYPE_FLEX, else TYPE_NA or leftout

1.7.10 Editing and reconnecting SNCs

SNCs can be edited by using the "LSNExt_EditSNCName" additionalInfo parameter, whose value is the
name of the SNC to be edited.
Changes in the SNCCreateData will be made to the named SNC.
An SNC, which has SNCState = Partial, can be reconnected (i.e. an attempt is made to connect all the cross
connections which have failed to be connected so far) by specifying tolerableImpact=GOI_HITLESS. In this
case, all SNCCreateData is ignored.
1.7.11 SNCs on UMEs

When a LightSOFT trail has an endpoint on a UME and the UME is not uploaded to the OSS, the endpoint of
the SNC presented to the OSS will be the LightSOFT-managed CTP closest to the UME.
Trails with endpoints on a UME that is uploaded to the OSS can be uploaded either with the UME
endpoint(s) or with the CTP endpoint(s), as described above.
An OSS can create a trail with endpoints on CTPs. When LightSOFT creates the trail, it will find the right
UME port to use as an endpoint within LightSOFT. If there is no such UME, an appropriate UME will be
created.
Until the "Upload this UME" attribute is implemented in LightSOFT (i.e. all UMEs are uploaded to the OSS –
see section Uploading UMEs), trails with endpoints on a UME will be uploaded with the endpoint(s) on the
UME. An OSS can create trails with endpoints on UMEs, but cannot create trails with managed CTPs for
endpoints.
1.7.12 Unique IDs for uploaded SNCs

Uploaded SNCs are uniquely identified by the Trail ID maintained in LightSOFT. This ID will be part of the
SNC’s DN when uploaded.
NOTE: Regarding the possible loss of an SNC ID due to loss of the LightSOFT database, it is the
network administration’s responsibility to keep adequate backups of the LightSOFT database
information, so that the information regarding SNCs (as well as other important information)
is not lost.

1.8 Tunnels and SNCs

Most of the information about SNCs presented in Trails and SNCs applies also to Tunnels and SNCs.
1.8.1 Specifying tunnel endpoints

The endpoints of a tunnel are created when the tunnel is created (this is similar to how FDFr endpoints are
created).
 Tunnel endpoints are CTPs which are contained by specially created FTPs. These FTPs are created in
parallel to the FTPs or PTPs which represent MoT or MoE endpoints.
 If there is an MoT/MoE endpoint FTP/PTP named XYZ, there will be an additional FTP, named XYZT,
whose job is to contain tunnel endpoints which use the MoT/MoE. The name of this special FTP is the
same as the name of the MoT FTP or MoE PTP, with the letter "T" added at the end.
 The actual tunnel endpoint CTPs will be returned in the SubnetworkConnection_T structure which is
the out-parameter of the operations.
A tunnel endpoint CTP’s DN should have the following form:
 EMS=lightsoft instance name
 ManagedElement=ME name
 FTP=name of special "T" FTP
 CTP=/MPLS=tunnelnumber
1.8.2 FRRs
FRRs need to be created before the main tunnels that use them.
1.8.3 Presenting LightSOFT tunnels to OSS

LightSOFT tunnels are presented to an OSS as SNCs.
SubnetworkConnection_T fields have the following contents:
Field Details
name The DN of the tunnel. It has the same form as all other DNs of SNCs.
The suggested value of SubnetworkConnection member is
/mpls=n:mm where n:mm is the tunnel ID.
userLabel The tunnel name, which is whatever the OSS sets at creation time.
nativeEMSName The tunnel's display name as it appears in LightSOFT.
owner As set by the OSS, or empty.
sncState See SNC States.
direction Unidirectional.
rate LR_T_MPLS.

Field Details
staticProtectionLevel Either preemptible, unprotected or fully_protected.
Where preemptible means ‘bypass’ and fully_protected means
‘protected’.
sncType ST_EXPLICIT
aEnd, zEnd Lists of endpoints. See Specifying Tunnel Endpoints.
rerouteAllowed RR_NO or RR_NA
networkRouted NR_NO or NR_NA
additionalInfo
LSNExt_TrailId As returned for other trails.
LSNExt_Customer As set by the OSS.
LSNExt_Comment As set by the OSS.
LSNExt_EXPMode L or E. Indicates L-LSP tunnel or E-LSP tunnel.
AlarmReporting On or Off.
LSNExt_TunnelState Tunnel/trail state Incomplete/Inconsistent/OK required in getAllSNC
LSNExt_TunnelOrTrailConfState Corba NBI output for SDH Trails.
LSNExt_TunnelType p2p , p2mp or p2pVirtualRsvp.
LSNExt_SingleServiceOnly (boolean) True means tunnel can only carry a single service.
LSNExt_P2PServiceOnly (boolean) True means tunnel can only carry a P2P service.
LSNExt_FRR_Protection_Mode Link/Node/Dual (for Bypass tunnel).
LSNExt_OamCV Enabled/Disabled.
LSNExt_OAM_ELSPCos (0-7) For E-LSP. Indicates which CoS is to be used for OAM-CV.
LSNExt_Colorn G/Y/GY n is the CoS number (0-7).
LSNExt_BypassProtectedPort DN of the port.
LSNExt_BypassProtectedNode DN of the node.
LSNExt_BypassSRLGDiverse (boolean) True if this bypass tunnel path has no SRLG in common with
the protected link/node.
LSNExt_TunnelAllocatedBW Number of Mbps reserved for this tunnel.
LSNExt_TunnelUnreservedBW Number of Mbps of unreserved bandwidth for this tunnel.
1.8.4 IDs for uploaded tunnel SNCs

Uploaded tunnel SNCs are uniquely identified by the Tunnel ID maintained in LightSOFT. This ID will be part
of the SNC’s DN when uploaded.
NOTE: Regarding the possible loss of an SNC ID due to loss of the LightSOFT database, it is the
network administration’s responsibility to keep adequate backups of the LightSOFT database
information, so that the information regarding SNCs (as well as other important information)
is not lost.

1.9 Ethernet services and FDFrs

An FDFr corresponds to either an end-to-end Ethernet service or to the part of a service that is managed
and known within the LightSOFT Subnetwork.
1.9.1 EMS FDFrs

EMS FDFrs are provided as Matrix Flow Domain Fragment (MFDFr) data structures. For example, the FDFr
operation getFDFrRoute returns the list of MFDFrs.
However, MFDFrs are not MTNM objects over the NorthBound Interface. The order of the MFDFrs needs
to be inferred from their endpoints.
When an FDFr is created, MFDFrs which the FDFr must use (therefore constraining the routing) may be
optionally specified.
1.9.2 FDFr types

A list of FDFr types can be found in the FDFrType_T description in the eNI Documentation Suite.
NOTE: Retrieving services is supported by all FDFr types listed in this section.
Provisioning services is supported by the following:
 FDFRT_POINT_TO_POINT
 FDFRT_POINT_TO_MULTIPOINT
 FDFRT_ERP in ERP PB Ring mode
 FDFRT_POINT_TO_POINT: This type of service associates exactly two endpoints.

 FDFRT_POINT_TO_MULTIPOINT: An FDFr with service endpoints is configured as either a root or a
leaf, but not as both. Frames are delivered from root to leaves and from leaves to root. A P2MP
service must have at least one root, with up to four roots supported.
 E-Tree: A type of P2MP FDFr, in which the standard of no direct communication between leaves is
more strictly enforced than in standard P2MP.
NOTE: The E-Tree service has FDFRT_POINT_TO_MULTIPOINT type and is specified by

LSNExt_ETree FDFr layered parameter.
 FDFRT_VLANTREE: A type of P2MP FDFr, used with Virtual RSVP tunnels to integrate dynamic
signaled MPLS services on IP/MPLS networks. The Virtual RSVP tunnels are used to aggregate
multiple VLANs into a single service.
 FDFRT_MULTIPOINT: The multi-point-to-multi-point service in which frames from each service
endpoint can be delivered to any other endpoint, or can be multi-cast to a set of endpoints.
 FDFRT_ERP: Ethernet Ring Protection (ERP) service supports two operating modes:
 ERP PB Ring: A service which is usually used to prevent loops in PB network access rings. The PB
rings may be configured either as standalone rings or connected in some way to an MPLS
network.

 ERP DH H-VPLS: Provides an ERP dual homing service for networks utilizing H-VPLS
configurations.
 FDFRT_DH_RSTP : The Dual Homing Rapid Spanning Tree Protocol (DH RSTP) service prevents
inefficient loops by creating a loop-free "spanning" tree topology of links connecting all bridges.
 FDFRT_FREEFORM : MP2MP service enabling manual network configuration not subject to standard
validations.
 FDFRT_ROOTED_MULTIPOINT: A type of P2MP service, typically used for multi-cast services such as
IPTV or E-Learning, configured between a root and multiple leaves. Each service endpoint is
configured as either a root or a leaf, but not as both. A rooted MP service must have at least one root,
with up to two roots supported.
1.9.3 FDFr states

The FDFr states are the same as SNC States. See SNC States for trails for further information.
1.9.4 Error reasons and success/failure of operations

Error reasons appear in two different places depending on the success or failure of the operation.
 The failure of an operation is indicated by the raising of an exception. An exception consists of an
exception code (EXCTP_xxx) and an Error Reason field giving further details of the failure.
 On the other hand, an operation may succeed but not completely. This case is not an exception, and
the completeness of the operation is indicated in any return parameters of the operation. One of the
return parameters is Error Reason, in which details of the failed parts of the (successful) operation are
given.
Note that, according to MTNM rules, an exception is raised (i.e. the operation failed) only if there is no
change to the system or network resulting from the operation. This can be because there really was no
change, or because LightSOFT undid whatever changes might have occurred.
If there is any change to the system or network after the operation, the operation must succeed (i.e. no
exception raised), and the results can be ascertained from the "out" parameters.
1.9.5 Connectionless Port Termination Point (CPTP)

A Connectionless Port Termination Point (CPTP) represents a potential port capability for Ethernet, i.e. the
CPTP has potential client TPs which are Flow Points.
A CPTP is not an object. The term CPTP is used for defining the characteristics of a port at a Matrix Flow
Domain.
A CPTP can be a Physical Termination Point (PTP) or a Floating Termination Point (FTP).
A CPTP is modeled as:
 A PTP object if the port is an ETY port.
 An FTP object if the port is an EoS/MoT port of the bridge terminating a SDH trail.
 An endpoint of an MPLS tunnel which is to carry the Ethernet service.

NOTE: An FTP is a type of PTP, which does not represent a physical port.
The Boolean layered parameter for PTPs and FTPs at connectionless layers (e.g. Ethernet), named
ConnectionlessPort, identifies the TP as a CPTP.
The layered parameters marked for CPTP are then relevant.
A CPTP corresponds to an IEEE bridge port, which can be a UNI port (Network Access Port) or a NNI port
(Network Port).
A CPTP will always have directionality set to "bidirectional".
1.10 FDFr parameters

Parameter values specified by an OSS as part of a request involving FDFrs are never ignored.
If unsupported values are specified, the request is rejected with the NOT_SUPPORTED exception, and the
name(s) of the offending parameter(s), separated by commas when there is more than one, is/are put into
the Error Reason field of the exception.
The following FDFr parameters are supported:
 createData -> the FDFrCreateData_T structure which contains the following creation information:
 name -> the OSS can set the name of the FDFr. If no name is given, LightSOFT provides one.
 userLabel -> the service label of the service. If no userLabel is given, LightSOFT generates one.
 forceUniqueness -> True if the service label must be unique.
 owner -> arbitrary string (can be empty) which will be returned to the OSS when the created
FDFr is uploaded. No analysis or parsing or error checking is performed on this string.
 networkAccessDomain -> not used (ignored).
 direction -> Bidirectional.
 administrativeState -> must be Unlocked.
 transmissionParams -> the following layered parameters can be set (see the Layered
Parameters list in the eNI Documentation Suite):
 IVID – the VLAN ID used for switching within the FDFr.
 LSNExt_ERP_RPLPort – DN of RPL port, relevant to ERP PB Ring and ERP DH HVPLS (when
supported) services.
 LSNExt_ERP_Type – string indicating EPR type. Relevant to ERP PB Ring service.
 LSNExt_PBRingLinkList - list of link DNs.
 fullRoute -> must be False.
 fdfrType -> any of the FDFr types supported by LightSOFT can be specified here. For each type,
other parameters must not contradict the type.

 additionalCreationInfo -> the following can be set:

 LSNExt_Customer – the customer associated with the service.
 LSNExt_TrafficEnabled - (boolean) indicates if the service is activated or not upon
creation.
 LSNExt_BSC_Profile – (string) the name of the TC Profile to be used for Broadcast Storm
Control.
 connectivityRequirement -> must be Reject.
 aEnd -> the list of service endpoints when creating an FDFr. This is the list of the DNs of the TPs
which will be the containers of the FDFr endpoints once they are created. The DNs in this list are
usually DNs of Ethernet ports.
 zEnd -> empty.
 internalTPs -> a (possibly empty) list of internal CPTP names that must be included in the route of the
FDFr, as a result of creating the FDFr. FPs are created as clients of the internal CPTPs, and their names
are returned in the internalTPs list at request completion.
 mfdfrs -> an optional (possibly empty) list of MFDFrs that must be in the route of the FDFr.
 tpsToModify -> a list of TPs and parameters to apply to them. On return, the list is updated to provide
the resulting parameter values. The list may refer to flow points that are being created during the
createAndActivateFDFr request or to the containing CPTPs.
 theFDFr -> the FDFr that was created, which is represented by a FlowDomainFragment_T structure.
 notConnectableCPTPList -> the list of CPTPs that could not be connected.
 parameterProblemsTPList -> the list of CPTPs and FPs for which best-effort transmission parameters
could not be set.
Parameters not listed above behave as described in the description of createAndActivateFDFr() in the
LightSOFT NBI Explanatory Documents.
 errorReason -> if the operation succeeds (i.e. no exception), but something not desired happens, the
reason is given in this string.
 exceptions -> as explained in eNI Documentation Suite, raising an exception means that there was no
change in the network (the exception includes an errorReason string).

1.10.1 Traffic mapping tables

Most of the information needed for traffic management of services is specified or discovered using the
Traffic Mapping Tables which are set as a collection of layered parameters of the service endpoints. These
are explained in the LightSOFT NBI Explanatory Documents.
1.10.2 Presenting LightSOFT Ethernet services to the OSS

LightSOFT Ethernet Services are presented to an OSS as FDFrs.
The fields of FlowDomainFragment_T have the following contents:
Field Details
name The display name of the FDFr.
userLabel The service label, whatever the OSS set at creation time.
nativeEMSName LightSOFT’s display name for the service
owner As set by the OSS, or empty.
direction Bidirectional.
aEnd, The list of actual service endpoints.
zEnd Empty.
networkAccessDomain Empty.
flexible True.
administrativeState Unlocked.
SNCS_ACTIVE or SNCS_PARTIAL.
fdfrState
sncType As set by OSS
ServiceStateDetails Nonconformant, Inconsistent, NA, OK
If the state is not OK, then it is either because the SNC is incomplete or
because it is inconsistent.
Tunnel/trail state Incomplete/Inconsistent/OK required in getAllSNC
Corba NBI output for SDH Trails.

Field Details
Layered parameters, returned  IVID
only when relevant:  LSNExt_Protection_Svlan
 LSNExt_ERP_RPLPort
 LSNExt_ERP_Type
 LSNExt_PBRingLinkList
 LSNExt_ProtectedVlanList
 LSNExt_ServiceTunnelList
 LSNExt_TunnelsToUse
 LSNExt_VcLabelScheme
 LSNExt_ETreeState: Extent to which E-Tree endpoints support E-
Tree capability.
 Full = all endpoints.
 Partial = limited number of endpoints.
 LSNExt_ETreeRole - indicates the role of the user endpoint in the
E-Tree service.
additionalInfo that can appear with an FDFr
LSNExt_Customer Customer associated with the service.
LSNExt_Traffic_Enabled (Boolean) Indicates if the service is activated or not upon creation
LSNExt_BSC_Profile (String) Name of the TC Profile to be used for Broadcast Storm
Control.
LSNExt_UseProtectedTunnelsOnly (Boolean)
LSNExt_HVPLS (Boolean)
LSNExt_HVPLS_DomainList As described in AdditionalInfo table in the eNI Documentation Suite
LSNExt_DualHoming (Boolean)
LSNExt_RootedMP_Role
LSNExt_P2MP_Role
LSNExt_IGMP_Snooping
LSNExt_Forward_All
LSNExt_IGMP_Member_Interval
LSNExt_LMQT
1.10.3 Editing FDFrs

FDFrs can be edited by using the modifyFDFr operation.

1.10.4 Unique IDs for uploaded FDFrs

Uploaded FDFrs are uniquely identified by the Eth VPN ID maintained in LightSOFT. This ID will be part of
the FDFr’s DN when uploaded.
NOTE: Regarding the possible loss of an FDFr ID due to loss of the LS database, it is the
network administration’s responsibility to keep adequate backups of the LS database
information, so that the information regarding FDFrs (as well as other important information)
is not lost.
1.11 EML functionality

Some EML functionality, such as retrieval of equipment objects, may be implemented through "tunneling"
and delegation of operations to the EMS. Consequently, not all objects provided over the interface need to
be maintained in the LightSOFT database.
1.12 No EMS visibility

When LightSOFT is managed by the OSS, the OSS will not be able to view information about the EMSs which
are managed by LightSOFT.
The only information visible are the names of the EMSs which appear as prefixes to the names of their MEs.
1.13 Edge PTPs

Since the OSS can connect to any available port (as far as LightSOFT is concerned) and can get the full list
via getALLPtps, the interface gives edge PTP the meaning of being an endpoint to a LightSOFT trail.
A PTP shall be considered an edge PTP in the following cases:
1. Any non-UME PTP which does not have an internal link connected to it is considered to be an edge
PTP.
2. Any non-UME PTP which does have an internal link connected to it, and the link is to another non-
UME PTP, is not considered to be an edge PTP.
3. Any non-UME PTP which has a link connected to it, and the link is to a UME (whether or not the UME
is to be uploaded to a OSS), is considered to be an edge PTP. This is because the OSS can define a trail
with an endpoint on a CTP of this PTP.
4. A UME PTP of a UME which is uploaded to a OSS is an edge PTP if it has a link connected to it, and is
not an edge PTP if it does not have a link connected to it.
5. The PTPs of a UME, which is not uploaded to OSS, are not visible to the OSS from LightSOFT.
The addition or removal of a link that affects the "edge-ness" of a PTP causes an AVC to the OSS, indicating
the change in the "edge" status of the PTP.

1.14 Inconsistency
Two additionalInfo parameters are added to the Managed Element, Termination Point, and Topology Link
objects to indicate an inconsistent state. For TPs, they are layered parameters, since TPs do not have
additionalInfo.
They are:
 LSNExt_Inconsistent, with values {True, False}: True means Inconsistent. When the parameter is not
included, it is the same as False.
 LSNExt_InconsistencyReason, with values (where relevant): Object deleted, Conflict, Invalid object,
Manual Out of Service.
An additionalInfo parameter is added to the MultiLayer Subnetwork object to indicate the "red flag" or
"yellow flag" condition.
This parameter is LSNExt_TrafficConsistency, with values {TC_CONSISTENT, TC_INCONSISTENT,
TC_INCONSISTENT_IN_layer}.
There is no indication whether the condition is "red" or "yellow". When the parameter is not included, it is
the same as TC_CONSISTENT.
If the inconsistency is only in one layer, the TC_INCONSISTENT_IN_layer form is used. Otherwise, if in
multiple layers or the layer is not known, TC_INCONSISTENT is used.
The "layer" part of TC_INCONSISTENT_IN_layer shall be one of the following: EMS, OCH, OMS, LP, HO, LO.
1.15 Naming and general object mapping rules

Naming of MEs and Network Element Layer (NEL) resources.
These include all objects contained in MEs, such as TPs, ProtectionGroup, EquipmentHolder, Equipment.
Such objects are identified over the interface according to the rules in the following table.
Name Value Comment
EMS ECI/LIGHTSOFT_n n is SNMS Id {1,..,n}
ManagedElement EMSname/MEname EMSname: name of EMS as provided by EMS
MEname: original ME identifier as provided by EMS
NOTE: UMEs are presented as Managed Elements - the name is
the name known in LS. There is no EMSname.
PTP, CTP, PGP, Same as from the Same as from the EMS
Equipment, EMS
EquipmentHolder.
Example of a CTP name:

{(EMS, "ECI/LIGHTSOFT_1"), (ManagedElement, "LSN/EMS_XDM_1/87"), (PTP, "27:5"), (CTP,
"/sts3c_au4-j=2")}

Some objects are mapped only from the objects as they exist in LightSOFT. An example is the Subnetwork
and topological links. EMS subnetworks (other than the entire LightSOFT network) are not provided.
Topological links are provided only for links that are recognized in LightSOFT.
Name Value Comment

MultiLayerSubnetwork 1 A single subnetwork provided, combining the LightSOFT
technology layers
Flow Domain 1 A single flow domain is provided
Name Value Comment

TopologicalLink endPtp1/endPtp2/direction/rate  For bidirectional links, endPtps appear in
alphabetical order.
 For unidirectional links, the source PTP precedes
the sink PTP.
Direction and Rate are code numbers.
This form is used to guarantee uniqueness, and so
avoiding errors due to multiple links appearing by
mistake in the LightSOFT database.
1.16 Supported notifications

The following sections describe the type of notifications supported.
1.16.1 Lifecycle notifications and LightSOFT-OSS

synchronization
LightSOFT provides the OSS with all of the object lifecycle notifications that are necessary for the OSS to
maintain synchronization with LightSOFT.
The following lifecycle notifications should be provided for all the objects mentioned above and their
applicable attributes:
 Object Creation - Managed Element, SNC, PTP, PGP, TopologyLink, FDFr, AID
 Object Deletion - Managed Element, SNC, PTP (see below), PGP, TopologyLink, FDFR, AID
 AVC – from all objects, for all attributes (incl. additionalInfo), and for all layered parameters which
have Yes in the AVC column
 State Change - all applicable objects, for all attributes (incl. additionalInfo), and for all layered
parameters which have Yes in the AVC column
 Route Change Notification – SNCs (notification as described in notificationServiceUsage of the TMF's
MTNM documentation suite. See also see section EMS SNCs (cross connects))
SNCs are LightSOFT trails and not EMS cross connects, as explained in section LightSoft Multilayer
Subnetwork (MLSN).

ManagedElement should be created in the unsynchronized state. A state change should be provided as
soon as LightSOFT allows the OSS to query the ManagedElement for all of the contained PTPs (i.e. as soon
as the NE is "recognized"). Alternatively, LightSOFT can provide Object Creation on all of the ME’s PTPs
once the ME is created.
An OSS should not upload from MEs which are in the unsynchronized state.
Object Deletion Notifications of PTPs are not provided when they can be inferred from the ODN of a
containing object, such as a Managed Element.
1.16.2 Alarms, TCAs and other events

For the purpose of fault management, all alarms and TCAs should be forwarded to the OSS.
 TCAs are reported with Object Type TCA and not as alarmed events.
 Quality of Service or PM alarms reported by NEs (when applicable) are mapped to TCAs over the
LightSOFT-OSS interface.
 No designated notification is defined for the Equipment protection or Timing Reference switch. This
issue is resolved within eNI by issuing a nonclearable alarm containing the following information:
 probableCause: UNIDENTIFIED
 nativeProbableCause: IOP Switch | Timing Switch
 additionalText: From: <Timing Reference Name | Equipment Name> To: <Timing Reference
Name | Equipment Name> Reason: <reason of the switch e.g. maintenance>
LightSOFT generates internal alarms for the same reasons that EMS-XDM produces them, where relevant.
These alarms, and any other internal LightSOFT alarms, are sent to the OSS.
The alarmed object is EMS (meaning LightSOFT). An alarm received by LightSOFT from a managed EMS is
sent to the OSS. The alarmed object will be a Managed Element whose name is the name of the EMS (i.e.
EMSname without /MEname).
The following table shows the fields of an alarm notification:
Table 1-1: Alarm notification fields

Name Type Description
"notificationId" string Alarm ID known to the LightSOFT
database.
"objectName" globaldefs::NamingAttributes_T Identifies the LightSOFT object
reporting the alarm.
AID type objects must be uniquely
identified.
"nativeEMSName" string Identifies the object as portrayed on
the LightSOFT user interface.
If objectType is AID, use the native
EMSName sent by the EMS.
"nativeProbableCause" string Identifies the probableCause as
portrayed on the EMS user interface.


"objectType" notifications::ObjectType_T Identifies the type of object reporting
an alarm.
"emsTime" globaldefs::Time_T Time at which the event was reported
by the LightSOFT system.
"neTime" globaldefs::Time_T Time provided by the NE related to
the alarm. In a case where the NE
does not report time, empty string
shall be reported.
"isClearable" boolean Indicates if a clear notification is sent
when resolved.
For most alarms, isClearable is set to
false, because once the episode
occurs, the system continues as usual
and there is no need for a clear
notification.
In the cases where an incident
changes the system’s status, and
disrupts system functionality until
rectified, then isClearable can be set
to true. Examples include:
 NE Disconnect
 Event Loss
"layerRate" transmissionParameters::LayerRate_T Layer to which this alarm is relevant.
"probableCause" string No other string besides the ones
defined below should be used for this
field.
"probableCauseQualifier" string Used with objectName, layerRate,
and probableCause to uniquely
identify an alarm.
eNI format is defined as
"<A>@@<B>@@<C>" where:
 <A> = unsigned integer (<= 11
bits)
 <B> = unsigned integer (<= 3 bits)
 <C> = unsigned integer (<= 16
bits)
"perceivedSeverity" notifications::PerceivedSeverity_T Indicates the severity of the alarm.
Perceived severity should be set to
PS_INDETERMINATE for
AT_TRANSIENT_EVENT conditions


"serviceAffecting" notifications::ServiceAffecting_T Indicates whether the alarm has
affected some service. When
LightSOFT has an algorithm by which
it computes this value, the computed
value will be used. Otherwise, the
value sent by the EMS will be used.
"affectedTPList" globaldefs::NamingAttributesList_T A list of affected TPs.
Contained CTPs are not listed. This
field is optional (indicated by an
empty string) for all alarms except for
alarms on equipment. This is used, for
example, to indicate a list of TPs
affected by an equipment failure.
If the alarm is an alarm on equipment
that supports PTPs, then the ports
(PTPs) supported by this equipment
will be listed in this field (irrespective
of whether the alarm is Service
Affecting or not).
The list should be ordered by PTP
names (ASCII order).
If the EMS sends a list of affected TPs
for nonequipment alarms as well, this
list should also be sent to the OSS.
"additionalText" string More information about the alarm,
such as "Unit is mismounted".
"granularity" Granularity_T Carries the details of the threshold
that has been crossed in a TCA.
"pmParameterName" PMParameterName_T Carries the details of the threshold
"pmLocation" PMLocation_T Carries the details of the threshold
"thresholdType" PMThresholdType_T Carries the details of the threshold
"value" float Carries the details of the threshold
that has been crossed in a TCA. This
parameter is sent to the OSS only if it
was received from the EMS.
"unit" string Carries the details of the threshold
that has been crossed in a TCA. This
parameter is sent to the OSS only if it
was received from the EMS.


"additionalInfo" globaldefs::NVSList_T This allows the communication from
the EMS to the NMS of additional
information which isn't explicitly
modeled.
additionalInfo - Possible values: Indicates that the alarm has been
"LSNExt_AckStatus" "ALM_ACKNOWLEDGED", acknowledged by a user.
"ALM_UNACKNOWLEDGED", Used when alarm acknowledgement
"ALM_NA" is handled using the
performMaintenanceOperation
operation.
additionalInfo - free format string Indicates the user name of the user
"LSNExt_AckUser" that has acknowledged the alarm.
additionalInfo - string Managed Element Native EMS Name.
"LSNExt_MEName" This field can be enabled or disabled
using the IsFillAlarmTrailData
parameter in the NMSNBA.ini file.
additionalInfo - string Name of the Managed Element’s most
"LSNExt_GroupName" direct parent group in the physical
layer. If there is no parent group then
this field is not sent.
This field can be enabled or disabled
additionalInfo - string Trail ID of an affected trail.
"LSNExt_TrailID" If there are multiple trails, list with
comma delimiter. An active alarm that
has its affected trails changed will not
send a new alarm.
The trail ID is a snapshot for when the
alarm was sent.
additionalInfo - string Trail label of an affected trail.
"LSNExt_TrailLabel" If there are multiple trails, list with
comma delimiter. An active alarm that
has its affected trails changed will not
send a new alarm.
The trail label is a snapshot for when
the alarm was sent.


additionalInfo – Possible values: The LightSOFT correlation value for
"LSNExt_ALCV" {"Primary", "Secondary", this alarm.
"NotCorrelated", "Unknown"} The Alarm Correlation feature
requires the appropriate license to be
enabled.
Alarms are sent to the NorthBound
Interface twice, first when just
received (correlation state is
Unknown), then again following
correlation processing with their
correlation state specified as Primary,
Secondary or Not Correlated.
 Primary: The alarm was
determined to be a root cause
alarm.
 Secondary: The alarm was
determined to be a secondary
alarm, precipitated by a primary
alarm.
 Not Correlated: The alarm
underwent correlation processing
but its correlation type could not
be determined.
 Unknown: The alarm did not yet
undergo correlation processing.
NOTES:
Alarm Correlation in the LightSOFT
interface does not distinguish
between Unknown and Not
Correlated alarms, and considers both
as Not Correlated.
The NorthBound interface enables
you to distinguish between these two
alarm categories.
For more information about alarm
correlation, see the LightSOFT Fault
Management and Performance
Monitoring User Guide.
If the LightSOFT server does not have
the Alarm Correlation option
configured, the ALCV field will be sent
with the status Unknown.


additionalInfo – string Customer name of an affected
"LSNExt_Customer" trail,tunnel and/or service.
If there are multiple trails,tunnels
and/or services, list with comma
delimiter. An active alarm that has its
affecting trails,tunnels and/or services
changed will not send a new alarm.
The name of the trail ,tunnel or
service is a snapshot for when the
alarm was sent.
NOTE: The order of customers in
LSNExt_Customer does not
correspond to the order of
trails/tunnels/services reported in an
alarm.
additionalInfo – string Tunnel ID of an affected tunnel.
"LSNExt_TunnelID" If there are multiple tunnels, list with
comma delimiter.
An active alarm that has its affecting
tunnels changed will not send a new
alarm. The tunnel ID is a snapshot for
when the alarm was sent.
additionalInfo – string Name of an affected tunnel.
"LSNExt_TunnelName" If there are multiple tunnels, list with
comma delimiter.
tunnels changed will not send a new
alarm. The tunnel name is a snapshot
for when the alarm was sent.
additionalInfo – string Ethernet VPN ID of an affected
"LSNExt_EthVpnID" service.
If there are multiple services, list with
comma delimiter.
trails changed will not send a new
alarm. The Ethernet VPN ID is a
snapshot for when the alarm was
sent.


additionalInfo – string Name of an affected service.
"LSNExt_ServiceLabel" If there are multiple services, list with
comma delimiter.
services changed will not send a new
alarm. The service label is a snapshot
for when the alarm was sent.
The following parameter is supported only when the "acknowledgeAlarms" operation is supported. In
that case, the "LSNExt_AckStatus" parameter is not needed.
"acknowledgeIndication" notifications::AcknowledgeIndication_T EVENT_ACKNOWLEDGED,
(MTNM v3) EVENT_UNACKNOWLEDGED, or NA if
acknowledgement not supported by
the EMS.
1.16.3 Notification configurations

There are three possible notification service configurations.
The actual configuration used in a specific installation is determined by agreement between ECI and the
OSS implementer.
The notification service configuration that a OSS is using is indicated by a prefix on the "user" parameter
sent in the getEMSSession function.
Possible configurations are:
 LightSOFT NorthBound Notification Service (described below)
No prefix on "user" parameter
 Standard MTNM Notification Service (defined by TMF)
"MTNM" prefix on "user" parameter
 LSN Internal Notification Service (not described in this document)
"LSN" prefix on "user" parameter
1.16.4 LightSOFT northbound notification service

A single channel is used for all types of notifications.
 A loss of an event reported to the OSS can happen, for example, due to overflow of the Notification
Service buffer or internally in LightSOFT.
 A loss of an event can be sensed by using the following mechanism.
An event will be marked with a unique and consecutive number.
Each notification type has its own count, as follows:
 Alarms and TCAs - single NotificationId counter is used (even though they are two distinct MTNM
notification types)
 OC

 OD
 AVC
 State Change
 Route Change
 Protection Switch
 File Transfer Status
Note that the first event (of a certain type) received by the OSS may not necessarily be numbered "1".
Every event after the first will be numbered consecutively, starting with the number of the first one
received. The event following the event with the maximum number will be numbered "1". The maximum
number will be agreed for integration.
The OSS detects a loss of notifications when two consecutive events do not have consecutive numbers.

2 Keep-Alive mechanisms
Two keep-alive methods are available:
 The standard MTNM method is that each end of the interface sends a "ping" operation to the other
end. If an answer is received, the "ping" initiator can conclude that the connection still exists. If no
reply is received, the sender decides how many retries to perform and at what intervals before
concluding that the connection has been lost and deciding on appropriate measures.
 The second method is for only the OSS to send "ping" operations. The OSS chooses this method by
appending the string "@@ss" to its user name when initiating the connection with LightSOFT (ss is a
count of seconds). If LightSOFT does not receive a "ping" operation from the OSS within (t x ss)
seconds, where t is configurable (default 10), LightSOFT will conclude that the connection no longer
exists.

3 Security
Receiving a list of users from an OSS need not be supported in LightSOFT.
Any OSS user who also needs to log in to LightSOFT directly through a LightSOFT console without using the
GUI cut-through from the OSS needs to have his/her user name and password entered manually into
LightSOFT.
When LightSOFT is accessed from an OSS via the GUI cut-through, the request is tagged with the OSS user’s
capabilities category. LightSOFT enforces security within LightSOFT according to this capability category.

4 GetRoute cross connect ordering
This section explains the response which an OSS receives from LightSOFT when the OSS calls the getRoute()
operation.
The getRoute operation is called by an OSS to request from LightSOFT the list of Cross Connects/simple
connections which form a trail/tunnel, along with information about each Cross Connect’s position in the
trail/tunnel. A trail/tunnel is represented by a Subnetwork Connection (SNC).
The getRoute operation returns a list of Cross Connect structures. These structures are called
CrossConnect_T in eNI.
4.1 Cross connect structures

Each cross connect structure contains the following information:
 A list of simple connections, where each simple connection has a source point and a sink point.
Information flows from the source point to the sink point.
 For each simple connection, its position in the trail/tunnel and its protection role are provided.
The list of simple connections is presented as a list of source points (called the aEndName list) and a list of
sink points (called the zEndName list).
The n'th source point in the aEndName list and the n'th sink point in the zEndName list define the n'th
simple connection. The lengths of the two lists must be the same, and that length is the number of simple
connections in the Cross Connect.
Two simple connections are adjacent if there is a topological link/server trail which connects the sink point
of one simple connection to the source point of the other.
A series of adjacent simple connections, where B is adjacent to A, C is adjacent to B, D is adjacent to C, etc.,
is called a subcomponent. A subcomponent which goes between two trail/tunnel ends is a primary
subcomponent. A trail/tunnel subcomponent which has at least one end which is not a trail/tunnel end is a
branch or a bridge.
A component is a primary trail/tunnel component with all of the branches and bridges which split off from
the primary trail/tunnel component. When there are no branches or bridges, the component is the same as
the primary subcomponent.
Examples:
 An unprotected bidirectional trail, between points A and Z, will have two components: one going from
A to Z and one going from Z to A.
 An unprotected unidirectional trail will have one component, going from A to Z.
 A protected bidirectional trail will have four components: A to Z Main, Z to A Main, A to Z Protection,
and Z to A Protection. See the Bidirectional Trail with Protection example. Its trail components are:
A-B-E-F-H-G-K-M (main), M-K-G-H-F-E-B-A (main), A-C-D-E-F-H-J-L-K-M (protection),
M-K-L-J-H-F-E-D-C-A (protection).

LightSOFT NBI NBI User Guide GetRoute cross connect ordering
 See the DRI example for an example of trail components with several subcomponents. The first trail
component has primary subcomponent A-B-E-G-J-L-N and subcomponent E-F. The second trail
component has primary subcomponent A-C-D-E-H-K-M-N and subcomponent H-Q-P-G. The third trail
component has primary subcomponent N-L-J-G-E-B-A and subcomponent G-P-Q-H. The fourth trail
component has primary subcomponent N-M-K-H-F-D-C-A and subcomponent F-E.
4.2 Cross connect structure components

A trail component is either a Main component or a Protection component.
A simple connection in a Cross Connect structure can be part of a Main component or part of a Protection
component or part of two components, one Main and one Protection.
A tunnel component is usually a Main, except in a protected tunnel CC, which has a simple connection for
the bypass tunnel whose head is at the protected tunnel CC.
In point-to-multi-point trails/tunnels, the same simple connection may appear in more than one Cross
Connect structure. In this case, the simple connection in one Cross Connect structure will be part of a
different component than the same simple connection in a different Cross Connect structure. The case
where a simple connection is part of more than one Main component, or more than one Protection
component, in an optical multi-route trail, is not yet supported by the getRoute operation in eNI. For such
trails, getRoute will return all Cross Connects with component number -1 for all simple connections.
Trail/tunnel components are numbered. There is no significance to the number. The significance is only that
two simple connections which have the same component number belong to the same component.
4.3 Cross connect starting and ending points

Note that a trail/tunnel can have more than one starting point and/or more than one ending point.
 Start: First connection in the primary subcomponent, starting at a trail/tunnel starting point.
 Stop: Last connection in the primary subcomponent, ending at a trail/tunnel ending point.
 StartStop: Both a Start and a Stop. The only connection in the primary subcomponent.
 BranchStart: First connection in a non-primary subcomponent, branching off from another
subcomponent.
 BranchStop: Last connection in a non-primary subcomponent, merging into another subcomponent.
 Bridge: Both a BranchStart and BranchStop. The only connection in this non-primary subcomponent.
 Mid: Connection is neither the first nor the last in the subcomponent.
The includeHigherOrderCCs option in the getRoute request is not supported. It is ignored, and the route
without higher order CCs is returned.
When a trail begins at an exit port from a network element (e.g. a server trail), the source point of the first
simple connection of the trail component will be None instead of the name of a connection point. The role
of this simple connection will be Start, and its sequence number will be a positive number. The role of the
next simple connection in the sequence will not be Start.

When a trail ends at an entry port into a network element (e.g. a server trail), the sink point of the last
simple connection of the trail component will be None instead of the name of a connection point. The role
of this simple connection will be Stop, and its sequence number will be greater than the sequence number
of the preceding simple connection. The role of the preceding simple connection in the sequence will not
be Stop.
4.4 Flex trail cross connections

No rules can be stated regarding the presentation of trail components and Cross Connections of flex trails.
The order of components in a flex trail is arbitrary. Flex trails are so indicated in the SNC. The component
numbers for all Cross Connects in a flex trail is -1.
4.5 Trail component numbering

Trail components are numbered according to the following rule:
1. All Main-forward components come first.
2. All Protection-forward components.
3. All Main-backward components.
4. All Protection-backward components.
For bidirectional trails, the decision regarding which direction is forward and which is backward is usually
arbitrary. But they are consistent, i.e. all forward components carry traffic in the same direction and all
backward components carry traffic in the opposite direction.
A simple connection has a sequence number giving its position within its trail subcomponent.
The simple connection with the sequence number N comes after all simple connections with sequence
numbers less than N and comes before all simple connections with sequence numbers greater than N.
Usually simple connection N is preceded by simple connection N-2 and is followed by simple connection
N+2.
The sequence numbering of a component always starts with the primary subcomponent. If there are other
subcomponents, their sequence numbers will be higher than the sequence numbers of the primary
subcomponent.
For each simple connection in a trail Cross Connect, the following information is provided.
NOTE: For an explanation of how this information is presented to the OSS, see getRoute
Return Attributes.
 The trail component number of the Main component to which the simple connection belongs. If this
simple connection is not part of a Main component, the Main Trail Component number is -1.
 The simple connection sequence number within the Main trail component. If this simple connection is
not part of a Main component, the Main Trail Component sequence number is -1.

 The trail component number of the Protection component to which the simple connection belongs. If
this simple connection is not part of a Protection component, the Protection Trail Component number
is -1.
 The simple connection sequence number within the Protection trail component. If this simple
connection is not part of a Protection component, the Protection Trail Component sequence number
is -1.
 The simple connection protection role in the trail. This is either 1 (Main) or 2 (Protection). When a
simple connection is part of an unprotected trail, its protection role is Main (1).
 The simple connection role within the trail subcomponent. It is one of the following strings.
4.6 Tunnel component numbering

A Cross Connect is a list of simple connections.
Tunnel route information is a list of tunnel cross connects.
Each simple connection includes the following:
 In aEnd CTP
 Out zEnd CTP
 Path type (usually Main, except in a protected tunnel CC, which has a simple connection for the
bypass tunnel whose head is at the protected tunnel CC).
A series of adjacent simple connections, where the first simple connection is adjacent to the second, the
second is adjacent to the third and so on, is called a component. Each simple connection belongs to a
component. Components are numbered starting from 1.
For each simple connection in a tunnel Cross Connect, the following information is provided:
 A sequence number indicating its position in the component. The simple connections numbering
indicates the order of the simple connection within the component, and is done in steps of 2 starting
from 1. (1, 3, 5, 7, etc.)
 Its role within the component - either Start, Mid, Stop or BranchStart.
 The path type (usually Main, except in a protected tunnel CC, which has an SC for the bypass tunnel
whose head is at the protected tunnel CC).
Route of P2P unprotected and bypass tunnels includes:
 One primary component numbered 1, each CC is of path type Main (1), with one simple connection
whose role is either Start, Mid or Stop.
 Ordering of the CCs is as explained in simple cross connects – 1, 3, 5. etc.
Route of P2MP tunnel includes:
 Each tunnel path (a tunnel path from the tunnel head to a tunnel tail) is treated as a separate tunnel
component.
 Drop & Continue - i.e. the cross connects can assume the role of Stop in one component, and the role
of Mid in another. Therefore, the cross connects will have two simple connections (Stop and Mid).

5 GetRoute returned attributes
The information about the simple connections of a Cross Connect are returned by getRoute as follows:
 The aEndNameList field of the CrossConnect_T structure contains the list of source points.
 The zEndNameList field of the CrossConnect_T structure contains the list of sink points.
 The CrossConnect_T additional Info attribute named OrderNumber is a list of N 4-tuples, where N is
the number of simple connections, and is the length of the aEndNameList and of the zEndNameList.
The K-th 4-tuple in the list relates to the K-th simple connection.
Each 4-tuple contains the following (in order):
 The component number of the Main trail or the unprotected/protected/bypass tunnel
component to which the simple connection belongs (-1 if it does not belong to a Main trail or a
tunnel component).
 The simple connection’s sequence number within the Main trail or the
unprotected/protected/bypass tunnel component (-1 if it does not belong to a Main trail or a
tunnel component).
 The component number of the Protection trail or the protected tunnel component to which the
simple connection belongs (-1 if it does not belong to a Protection trail or a tunnel component).
 The simple connection sequence number within the Protection trail or the protected tunnel
component (-1 if it does not belong to a Protection trail or a tunnel component).
 The CrossConnect_T additional Info attribute named PathType is a list of N integers, where N is the
number of simple connections, and is the length of the aEndNameList and of the zEndNameList. The
K-th integer in the list relates to the K-th simple connection. Each integer represent the simple
connection protection role: 1, 2, or 3.
 The CrossConnect_T additional Info attribute named XC_Type is a list of N strings, where N is the
number of simple connections, and is the length of the aEndNameList and of the zEndNameList. The
K-th string in the list relates to the K-th simple connection. Each string represents the simple
connection position in the trail/tunnel component.
The examples below give the getRoute information for the diagrams on the following pages, where circles
represent network elements, thick lines are links, and ports are numbered.
5.1 Bidirectional trail with protection

Trail Components:
Main 1: A-B-E-F-H-G-K-M
Main 3: M-K-G-H-F-E-B-A
Protection 2: A-C-D-E-F-H-J-L-K-M
Protection 4: M-K-L-J-H-F-E-D-C-A
Cross Connects:
aEndNameList = ([4]A1, A1, A2, A3) zEndNameList = ([4]A2, A3, A1, A1)

LightSOFT NBI NBI User Guide GetRoute returned attributes
OrderNumber = ([4](1,1,-1,-1), (-1,-1,2,1), (3,15,-1,-1), (-1,-1,4,19))

PathType = ([4]1,2,1,2) XC_Type = ([4]Start, Start, Stop, Stop)
aEndNameList = ([2]B1, B2) zEndNameList = ([2]B2, B1)
OrderNumber = ([2](1,3,-1,-1), (3,13,-1,-1))
PathType = ([2]1,1) XC_Type = ([2]Mid, Mid)
aEndNameList = ([4]E1, E3, E2, E2) zEndNameList = ([4]E2, E2, E1, E3)
OrderNumber = ([4](1,5,-1,-1), (-1,-1,2,7), (3,11,-1,-1), (-1,-1,4,13))
PathType = ([4]1,2,1,2) XC_Type = ([4]Mid, Mid, Mid, Mid)
aEndNameList = ([2]F1, F2) zEndNameList = ([2]F2, F1)
OrderNumber = ([2](1,7,2,9), (3,9,4,11))
aEndNameList = ([4]H1, H1, H2, H3) zEndNameList = ([4]H2, H3, H1, H1)
OrderNumber = ([4](1,9,-1,-1), (-1,-1,2,11), (3,7,-1,-1), (-1,-1,4,9))
aEndNameList = ([2]G1, G2) zEndNameList = ([2]G2, G1)
OrderNumber = ([2](1,11,-1,-1), (3,5,-1,-1))
aEndNameList = ([4]K1, K3, K2, K2) zEndNameList = ([4]K2, K2, K1, K3)
OrderNumber = ([4](1,13,-1,-1), (-1,-1,2,17), (3,3,-1,-1), (-1,-1,4,3))
aEndNameList = ([2]M1, M2) zEndNameList = ([2]M2, M1)
OrderNumber = ([2](1,15,2,19), (3,1,4,1))
PathType = ([2]3,3) XC_Type = ([2]Stop, Start)
aEndNameList = ([2]C1, C2) zEndNameList = ([2]C2, C1)
OrderNumber = ([2](-1,-1,2,3), (-1,-1,4,17))
aEndNameList = ([2]D1, D2) zEndNameList = ([2]D2, D1)
OrderNumber = ([2](-1,-1,2,5), (-1,-1,4,15))
aEndNameList = ([2]J1, J2) zEndNameList = ([2]J2, J1)
OrderNumber = ([2](-1,-1,2,13), (-1,-1,4,7))

aEndNameList = ([2]L1, L2) zEndNameList = ([2]L2, L1)

OrderNumber = ([2](-1,-1,2,15), (-1,-1,4,5)
5.2 Point-to-multipoint
Trail components: Each trail component has a list of simple connections.
For each simple connection, the a-endpoint and z-endpoint are shown, together with the role and the path
type code (1=main, 2=protection).
The sequence number is not shown, but the sequence numbers will be in strict ascending order.
Main 1: A1-A2 Start 1 primary (and only) subcomponent
B1-B2 Mid 1
C1-C2 Mid 1
F1-F2 Mid 1
G1-G2 Mid 1
J1-J2 Mid 1
M1-M2, Mid 1
R1-R2 Stop 1
B1-B2 Mid 1
C1-C3 Mid 1
D1-D2 Mid 1
E1-E2, Stop 1
B1-B2 Mid 1
C1-C2 Mid 1
F1-F2 Mid 1
G1-G3 Mid 1
H1-H2 Mid 1
K1-K2 Mid 1
N1-N2 Mid 1
S1-S2 Stop 1
Main 4: A1-A2, Start 1 primary (and only) subcomponent

B1-B2 Mid 1
C1-C2 Mid 1
F1-F2 Mid 1
G1-G3 Mid 1
H1-H2 Mid 1
K1-K3 Mid 1
L1-L2 Mid 1
P1-P2 Mid 1
T1-T2 Stop 1
5.3 DRI (standard)

The two rings being interconnected are: A-B-E-F-D-C-A and N-M-K-H-Q-P-G-J-L-N.
Each ring is protected independently of the other. If one ring sustains a fiber cut, the other ring remains
fully protected. However, if one of the links which connect between the two rings (E-G and F-H) is cut, one
of the rings is no longer protected.
Trail components: Each trail component has a list of simple connections. For each simple connection, the a-
endpoint and z-endpoint are shown, together with the role and the path type code (1=main, 2=protection).
Main 1: A1-A2 Start 1 primary subcomponent
B1-B2 Mid 1
E1-E3 Mid 1
G1-G3 Mid 1
J1-J2 Mid 1
N1-N3 Stop 1
E1-E2 BranchStart 1 branch subcomponent
F2-F3 BranchStop 1
Protection 2: A1-A3 Start 2 primary subcomponent
C1-C2 Mid 2
D1-D2 Mid 2
F1-F3 Mid 2
H1-H3 Mid 2
K1-K2 Mid 2
M1-M2 Mid 2

N2-N3 Stop 2
F1-F2 BranchStart 2 branch subcomponent
E2-E3 BranchStop 2
Main 3: N3-N1 Start 1 primary subcomponent
L2-L1 Mid 1
J2-J1 Mid 1
G3-G1 Mid 1
E3-E1 Mid 1
B2-B1 Mid 1
A2-A1 Stop 1
G3-G2 BranchStart 1 branch subcomponent
P1-P2 Mid 1
Q1-Q2 Mid 1
H2-H1 BranchStop 1
Protection 4: N3-N2 Start 2 primary subcomponent
M2-M1 Mid 2
K2-K1 Mid 2
H3-H1 Mid 2
F3-F1 Mid 2
D2-D1 Mid 2
C2-C1 Mid 2
A3-A1 Stop 2
H3-H2 BranchStart 2 branch subcomponent
Q2-Q1 Mid 2
P2-P1 Mid 2
G2-G1 BranchStop 2

5.4 DRI with protected links

The two rings being interconnected are: A-B-E-F-D-C-A and N-M-K-H-Q-P-G-J-L-N.
Each ring is protected independently of the other. If one ring sustains a fiber cut, the other ring remains
fully protected. Because of the extra branch subcomponent in each trail component, if one of the links
which connect between the two rings (E-G and F-H) is cut, neither one of the rings becomes unprotected.
B1-B2 Mid 1
E1-E3 Mid 1
G1-G3 Mid 1
J1-J2 Mid 1
N1-N3 Stop 1
F2-F3 BranchStop 1
P1-P2 Mid 1
Q1-Q2 Mid 1
H2-H3 BranchStop 1
C1-C2 Mid 2
D1-D2 Mid 2
F1-F3 Mid 2
H1-H3 Mid 2
K1-K2 Mid 2
M1-M2 Mid 2
N2-N3 Stop 2
E2-E3 BranchStop 2
Q2-Q1 Mid 2

P2-P1 Mid 2
G2-G3 BranchStop 2
L2-L1 Mid 1
J2-J1 Mid 1
G3-G1 Mid 1
E3-E1 Mid 1
B2-B1 Mid 1
A2-A1 Stop 1
P1-P2 Mid 1
Q1-Q2 Mid 1
H2-H1 BranchStop 1
F2-F1 BranchStop 1
M2-M1 Mid 2
K2-K1 Mid 2
H3-H1 Mid 2
F3-F1 Mid 2
D2-D1 Mid 2
C2-C1 Mid 2
A3-A1 Stop 2
Q2-Q1 Mid 2
P2-P1 Mid 2
G2-G1 BranchStop 2
E2-E1 BranchStop 1

5.5 DNI
The same concept as the DRI: independent protection of two rings. But all of the inter-ring connections are
in one node (G).
B1-B2 Mid 1
E1-E2 Mid 1
G1-G4 Mid 1
J1-J2 Mid 1
L1-L2 Mid 1
N1-N3 Stop 1
G1-G2 Bridge 1 bridge subcomponent
C1-C2 Mid 2
D1-D2 Mid 2
F1-F2 Mid 2
G2-G3 Mid 2
H1-H2 Mid 2
K1-K2 Mid 2
M1-M2 Mid 2
N2-N3 Stop 2
L2-L1 Mid 1
J2-J1 Mid 1
G4-G1 Mid 1
E2-E1 Mid 1
B2-B1 Mid 1
A2-A1 Stop 1


M2-M1 Mid 2
K2-K1 Mid 2
H2-H1 Mid 2
G3-G2 Mid 2
F2-F1 Mid 2
D2-D1 Mid 2
C2-C1 Mid 2
A3-A1 Stop 2
5.6 Protected server trail (unidirectional)

Main 1: None-A1 Start 1 primary

subcomponent
B1-B2 Mid 1
C1-C2 Mid 1
F1-F2 Mid 3
G1-G2 Mid 1
J1-J2 Mid 1
M1-M2 Mid 1
R1-None Stop 1
Protection 2: None-E1 Start 2 primary

subcomponent
D2-D1 Mid 2
C3-C2 Mid 2
F1-F2 Mid 3
G1-G3 Mid 2
H1-H2 Mid 2

K1-K2 Mid 2
N1-N2 Mid 2
S1-None Stop 2
Figure 5-1: Protected server trail
5.7 Protected P2P tunnel

Note that although the nodes of the bypass tunnels are depicted in the second figure below, the route
discussed here is of the protected tunnel and not the bypasses.
Tunnel components: Each tunnel component has a list of simple connections. For each simple connection,
the a-endpoint and z-endpoint are shown, together with the role and the path type code (1=main,
2=protection).
Component 1: A1-A2 Start 1
B1-B2 Mid 1
C1-C2 Mid 1
D1-D2 Stop 1
Component 2: A1-A3 Start 2
Component 3: B1-B3 BranchStart 3
Component 4: C1-C3 BranchStart 4

Figure 5-2: Protected P2P tunnel
5.8 P2MP tunnel

Tunnel Components: Each tunnel component has a list of simple connections. For each simple connection,
the a-endpoint and z-endpoint are shown, together with the role and the path type code (1=main,
2=protection).
Tunnel 1: A1-A2 Start 1 primary (and only) subcomponent
B1-B2 Stop 1
Tunnel 2: A1-A3 Start 2 second subcomponent

C1-C2 Mid 2
E1-E2 Stop 2
Tunnel 3: A1-A3 Start 3 third subcomponent
C1-C3 Mid 3
D1-D2 Stop 3
Tunnel 4: A1-A3 Start 4 third subcomponent
C1-C4 Stop 4

Figure 5-3: P2MP tunnel

6 Supported operations
The following is the list of operations defined in the MTNM.
This list explains which operations are supported in the LightSOFT NorthBound Interface and in which
LightSOFT version, which operations are not relevant to an OSS, and why other operations in the list may
not be supported.
The checkmarks P indicate the LightSOFT versions for which an operation is supported. Operations which
are not definitely planned for support in one of these versions have an explanatory note (indicated in the
"see note" column). The notes appear after the table.
Unless otherwise specified in this document or not applicable, note that the behavior of these operations is
as described in Namespace Documentation.
Operations marked MTNM V3 are described in the TMF814 V3 Documentation Suite. Note however that
there will be no support for these operations unless there is a specific need by an implementation partner,
in which case the specifics will be discussed and mutually decided.
Not all the capabilities described in this document are fully supported for all types of EMSs and all types of
equipment managed by LightSOFT.
The level of support depends on the equipment, the EMS type and the LightSOFT version.
MTNM server side functions See
V9.1 V10.1 V11.1 V11.2 V12.0 V12.1 V12.5 V13.0 V13.2 V14.0
note
EMSMgr
acknowledgeAlarms 8, 9
getAllEMS Y Y Y Y Y Y Y Y Y Y
getAllEMSAndMEActiveAlarms Y Y Y Y Y Y Y Y Y Y
getAllEMSAndMEUnacknowledgedActiveAlarms Y Y Y Y Y Y Y Y Y Y 9
getAllEMSSystemActiveAlarms Y Y Y Y Y Y Y Y Y Y
getAllEMSSystemUnacknowledgedActiveAlarms 4, 9
getAllTopLevelSubnetworkNames 1
getAllTopLevelSubnetworks Y Y Y Y Y Y Y Y Y Y
getAllTopLevelTopologicalLinkNames 6
getAllTopLevelTopologicalLinks Y Y Y Y Y Y Y Y Y Y
getTopLevelTopologicalLink 6
getCapabilities Y Y Y Y Y Y Y Y Y Y
getEMS Y Y Y Y Y Y Y Y Y Y
setNativeEMSName Y Y Y Y Y Y Y Y Y Y
setOwner Y Y Y Y Y Y Y Y Y Y

LightSOFT NBI NBI User Guide Supported operations

V9.1 V10.1 V11.1 V11.2 V12.0 V12.1 V12.5 V13.0 V13.2 V14.0
note
setUserLabel Y Y Y Y Y Y Y Y Y Y
unacknowledgeAlarms Y 10
createToplogicalLink Y Y Y Y Y Y Y Y Y Y 20
deleteTopologicalLink Y Y Y Y Y Y Y Y Y Y 20
EmsSession
associatedSession Y Y Y Y Y Y Y Y Y Y
endSession Y Y Y Y Y Y Y Y Y Y
getEventChannel Y Y Y Y Y Y Y Y Y Y
getManager Y Y Y Y Y Y Y Y Y Y
getSupportedManagers Y Y Y Y Y Y Y Y Y Y
Ping Y Y Y Y Y Y Y Y Y Y
EmsSessionFactory
getEmsSession Y Y Y Y Y Y Y Y Y Y
EquipmentInventoryMgr
getAllEquipment Y Y Y Y Y Y Y Y Y Y
getAllEquipmentNames Y Y Y Y Y Y Y Y Y Y 3
getAllSupportingEquipment Y Y Y Y Y Y Y Y Y Y
getAllSupportedPTPs Y Y Y Y Y Y Y Y Y Y
getAllSupportedPTPNames 3
getAllSupportingEquipmentNames 3
getContainedEquipment 3
getEquipment Y Y Y Y Y Y Y Y Y Y 3
provisionEquipment 7
setAlarmReportingOff 7
setAlarmReportingOn 7
unprovisionEquipment 7
EquipmentOrHolderIterator
Destroy Y Y Y Y Y Y Y Y Y Y
next_n Y Y Y Y Y Y Y Y Y Y
NamingAttributesIterator


V9.1 V10.1 V11.1 V11.2 V12.0 V12.1 V12.5 V13.0 V13.2 V14.0
note
GuiCutThroughMgr
destroyGCT Y Y Y Y Y Y Y Y Y Y
getGCTProfileInfo Y Y Y Y Y Y Y Y Y Y
launchGCT Y Y Y Y Y Y Y Y Y Y
CurrentMaintenanceOperationIterator
MaintenanceMgr
getActiveMaintenanceOperations Y Y Y Y Y Y Y Y Y Y
performMaintenanceOperation Y Y Y Y Y Y Y Y Y Y 8
ManagedElementIterator
ManagedElementMgr
getAllActiveAlarms Y Y Y Y Y Y Y Y Y Y
getAllCrossConnections 6
getAllManagedElementNames Y Y Y Y Y Y Y Y Y Y
getAllManagedElements Y Y Y Y Y Y Y Y Y Y
getAllPTPNames Y Y Y Y Y Y Y Y Y Y
getAllPTPs Y Y Y Y Y Y Y Y Y Y
getContainedCurrentTPNames 1
getContainedCurrentTPs 1
getContainedInUseTPNames 1
getContainedInUseTPs 1
getContainedPotentialTPNames Y Y Y Y Y Y Y Y Y Y
getContainedPotentialTPs Y Y Y Y Y Y Y Y Y Y
getContainingSubnetworkNames Y Y Y Y Y Y Y Y Y Y


V9.1 V10.1 V11.1 V11.2 V12.0 V12.1 V12.5 V13.0 V13.2 V14.0
note
getContainingTPNames 1
getContainingTPs 1
getManagedElement Y Y Y Y Y Y Y Y Y Y
getTP Y Y Y Y Y Y Y Y Y Y
setTPData Y Y Y Y Y Y Y Y Y Y
Version
mtnmVersion::getVersion Y Y Y Y Y Y Y Y Y Y
MultiLayerSubnetworkMgr
activateSNC 6
checkValidSNC Y Y Y Y Y Y Y Y Y Y 13
13,
Y Y Y Y Y Y Y Y Y Y
createAndActivateSNC 17
createSNC 6
deactivateAndDeleteSNC Y Y Y Y Y Y Y Y Y Y 16
deactivateSNC 6
deleteSNC 6
getAllEdgePointNames 1
getAllEdgePoints Y Y Y Y Y Y Y Y Y Y
getAllManagedElementNames 1
getAllManagedElements Y Y Y Y Y Y Y Y Y Y
getAllSNCsWithRoute Y Y Y Y Y Y Y Y Y Y
getAllSubnetworkConnectionNames 1
getAllSubnetworkConnectionNamesWithTP 1
getAllSubnetworkConnections Y Y Y Y Y Y Y Y Y Y
getAllSubnetworkConnectionsWithTP Y Y Y Y Y Y Y Y Y Y
getAllTopologicalLinkNames 1
getAllTopologicalLinks Y Y Y Y Y Y Y Y Y Y
getAllTPPoolNames 6


V9.1 V10.1 V11.1 V11.2 V12.0 V12.1 V12.5 V13.0 V13.2 V14.0
note
getAllTPPools 6
getAssociatedTP 2
getMultiLayerSubnetwork Y Y Y Y Y Y Y Y Y Y
getRoute Y Y Y Y Y Y Y Y Y Y
getSNC Y Y Y Y Y Y Y Y Y Y
getSNCsByUserLabel 1
getTopologicalLink Y Y Y Y Y Y Y Y Y Y
getTPGroupingRelationships 6
MultiLayerSubnetworkMgr
20,
Y Y Y Y Y Y Y Y Y
getAllCallsAndTopLevelConnections 21
20,
Y Y Y Y Y Y Y Y Y
getConnectionsAndRouteDetails 21
20,
Y Y Y Y Y Y Y Y Y
establishCall 21
20,
Y Y Y Y Y Y Y Y Y
releaseCall 21
20,
Y Y Y Y Y Y Y Y Y
modifyCall 21
20,
Y Y Y Y Y Y Y Y Y
addConnections 21
20,
Y Y Y Y Y Y Y Y Y
removeConnections 21
SubnetworkIterator
NmsSession
associatedSession 11
endSession 11
eventLossOccurred 5, 11


V9.1 V10.1 V11.1 V11.2 V12.0 V12.1 V12.5 V13.0 V13.2 V14.0
note
eventLossCleared 5, 11
Ping Y Y Y Y Y Y Y Y Y Y 11
EventIterator (notifications)
PerformanceManagementMgr
clearPMData Y Y Y Y Y Y Y Y Y Y
disablePMData Y Y Y Y Y Y Y Y Y Y
disableTCA 6
enablePMData Y Y Y Y Y Y Y Y Y Y
enableTCA 6
getAllCurrentPMData Y Y Y Y Y Y Y Y Y Y
getHistoryPMData 12
getHoldingTime 6
getMEPMCapabilities 6
getTCATPParameter 12
setTCATPParameter 6
PMDataIterator
ProtectionGroupIterator
ProtectionMgr
getAllNUTTPNames 2
getAllPreemptibleTPNames 2
getAllProtectedTPNames 1
getAllProtectionGroups Y Y Y Y Y Y Y Y Y Y
getProtectionGroup Y Y Y Y Y Y Y Y Y Y


V9.1 V10.1 V11.1 V11.2 V12.0 V12.1 V12.5 V13.0 V13.2 V14.0
note
performProtectionCommand Y Y Y Y Y Y Y Y Y Y
retrieveSwitchData Y Y Y Y Y Y Y Y Y Y
Session – see EmsSession and NmsSession
CCIterator
Destroy 6
next_n 6
SNCIterator
Destroy
next_n
TerminationPointIterator
TopologicalLinkIterator
Common
setAdditionalInfo Y Y Y Y Y Y Y Y Y Y
FlowDomainMgr
14,
Y Y Y Y Y Y Y Y Y Y
createAndActivateFDFr 18
deactivateAndDeleteFDFr Y Y Y Y Y Y Y Y Y Y 14
In V6
Y Y Y Y Y Y Y Y Y Y SP1,
getAllFDFRs 15
getFDFrRoute Y Y Y Y Y Y Y Y Y Y 19
getAllSupportedMFD Y Y Y Y Y Y Y Y Y Y
modifyFDFr Y
TCProfileMgr
createTCProfile Y Y Y Y Y Y 20


V9.1 V10.1 V11.1 V11.2 V12.0 V12.1 V12.5 V13.0 V13.2 V14.0
note
modifyTCProfile Y Y Y Y Y Y 20
deleteTCProfile Y Y Y Y Y Y Y Y Y Y
getTCProfile Y Y Y Y Y Y 20
getAllTCProfiles Y Y Y Y Y Y Y Y Y Y
LSNObjectsMgr_I (Proprietary ECI)
getFDFrsWithFilters Y Y Y Y Y Y 20
LSNManagedElementMgr (Proprietary ECI)
getAllAssignedCPTPs Y Y Y Y Y Y Y Y Y Y
getAllFlowDomain Y Y Y Y Y Y Y Y Y Y
createMEGroup Y Y Y Y Y Y Y Y Y Y
deleteMEGroup Y Y Y Y Y Y Y Y Y Y
getAllMEGroups Y Y Y Y Y Y Y Y Y Y
modifyFlowdomain Y Y Y Y Y Y Y Y Y Y
modifyMEGroup Y Y Y Y Y Y Y Y Y Y
modifyMFD Y Y Y Y Y Y Y Y Y Y
getTrace Y Y Y Y Y Y Y Y Y Y
getAllEnabledPM Y Y Y Y Y Y Y Y Y Y
LSNMaintenanceMgr_I (Proprietary ECI)
20,
Y Y Y Y Y Y Y Y
performMaintenanceOperation 22
LSNMultiLayerSubnetworkMgr_I
20,
Y Y Y Y Y Y Y
revertControlPlaneTrailPath 21
20,
Y Y Y Y Y Y Y
forceRerouteControlPlaneTrail 21
20,
Y Y Y Y Y Y Y
retreiveControlPlaneData 21
20,
Y Y Y Y Y Y Y
performControlPlaneMO 21
LSNLogicalIfMgr_I (Proprietary ECI)
createOrModifyLogicalInterface Y Y Y Y Y Y 20
deleteLogicalInterface Y Y Y Y Y Y 20

Notes:
1. Assuming that a OSS works the same way as LightSoft maintaining a local copy of the uploaded
information using the getAllxxx operators, the operation in this row is unnecessary, making the
interface simpler and integration easier. The information provided by this operation is already in the
OSS local copy.
2. Support of this operation will be decided by discussion with integration partners.
3. The need for this operation is not clear. For discussion with the OSS implementer when planning the
interface.
4. The information supplied by this operation is easily obtained by some other supported function.
5. We recommend using the event numbering scheme, making this operation unnecessary. Open to
discussion.
6. MTNM operation that is either not relevant in LightSoft or in the LightSoft northbound interface.
7. LightSoft does not use this operation, so there is no reason for a OSS to ask LightSoft to do it.
8. The Acknowledge Alarm option is supported as a suboption of performMaintenanceOperation
together with other maintenance operations supported in LightSoft.
9. Support for MTNM V3 operations will depend on needs of implementation partners. For now they are
not supported.
10. Will be available when supported by XDM equipment.
11. These are functions which LightSoft can use with OSS support and do not involve support from
LightSoft.
12. Target version has not yet been determined. Supported from EMS-NBI but not supported from
LightSoft-NBI.
13. CheckValidSNC and createAndActivateSNC are not supported for following optical trails:ODU,OCH
MR and OCH with Optical DRI.
14. CreateAndActivateFDFr and deactivateAndDeleteFDFr are supported for PB services only.
15. GetAllFDFRs is supported for P2P, P2MP, E-Tree P2MP (from LightSOFT v8),VLAN Tree (from
LightSOFT v8), MP2MP, ERP PB Ring, ERP DH H-VPLS, DH RSTP, Freeform, and Rooted MP services.
16. DeactivateAndDeleteSNC is supported for MPLS tunnels from LightSOFT v8 and higher.
17. CreateAndActivateSNC is supported for unprotected P2P and P2MP MPLS tunnels from LightSOFT v8
and higher.
18. CreateAndActivateFDFr is supported for P2P Ethernet services transported y MPLS tunnels, from
LightSOFT v8 and higher.
19. GetFDFrRoute is supported or VLAN Tree services, from LightSOFT v8 and higher.
20. MTNM operation is not relevant or not supported in the LightSoft Northbound Interface.
21. MTNM or an proprietary operation is supported for ASON OTN and WSON (from LightSOFT v11.2).
22. The proprietary performMaintenanceOperation is supported for the MPLS-TP LSP Ping maintenance
operation (from LightSOFT v11.1), and for OTDR tests (from LightSOFT v11.2) and IP/MPLS
maintenance operations (from LightSOFT v12) .

7 Obtaining PM status
7.1 LSNPerformanceManagementMgr_I interface

The LSNUnifiedMigrationMgr _I interface includes all ECI proprietary operations used to extend MTNM
Performance Monitoring functionality.
You can request the PM enabling status for selected measurement points, or for all layer rates.
Only measurement points with enabled PM are returned.
void getAllEnabledPM ( in PMTPSelectList_T pmSelectList,
in unsigned long how_many, out PMTPSelectList_T pmStatusDataList,
out LSNPMTPSelectIterator _I pmIt)
raises(globaldefs::ProcessingFailureException);
7.2 Parameters
 in PMTPSelectList_T pmSelectList: identifies the sets of PM measurement points to which the PM
enabling status is requested. Each PM measurement point can be either a termination point or
managed element. If specifying a managed element as the input parameter, the request applies to all
containing termination points.
The measurement point has enabled PM status if PM is enabled for any PM location
(PMTPSelect_T::pMLocationList) and granularity (PMTPSelect_T:: granularityList).The PM location
and granularity are skipped.
 in unsigned long how_many: Maximum number of measurement points to return in the first batch.
 out PMTPSelectList_T pmStatusDataList: First batch of PM status for selected measurement points. It
contains data for measurement points that have enabled PM status. The measurement points are
specified by termination points only.
 If PM status is requested for selected layer rates (PMTPSelect_T::layerRate), only rates that
have enabled PM are specified in the measurement point returned status.
 If PM status is requested for all layer rates(PMTPSelect_T::layerRate is empty), the layer rates
with enabled PM are not specified in the measurement point returned status (i.e.
PMTPSelect_T::layerRate remains empty)
 The PM location (PMTPSelect_T::pMLocationList) and granularity (PMTPSelect_T::
granularityList) are not specified in the measurement point returned status.
 out LSNPMTPSelectIterator _I pmIt: Iterator to retrieve the remaining PM measurement points.
 Raises globaldefs::ProcessingFailureException:
 EXCPT_NOT_IMPLEMENTED: Raised if the server does not support this service.
 EXCPT_INVALID_INPUT: Raised when the measurement point does not support the selected
layer rate.

LightSOFT NBI NBI User Guide Obtaining PM status
 EXCPT_ENTITY_NOT_FOUND:Raised when a measurement points references an object that

does not exist.
 EXCPT_UNABLE_TO_COMPLY: Raised if the server is unable to execute the request for any
other reason.
7.3 LSNPMTPSelectIterator_I interface

The use of iterators allow the OSS to deal with a large number of objects.
 interface LSNPMTPSelectIterator_I
{
boolean next_n(in unsigned long how_many, out PMTPSelectList_T mDataList)
raises (globaldefs::ProcessingFailureException);
unsigned long getLength() raises (globaldefs::ProcessingFailureException);
void destroy() raises (globaldefs::ProcessingFailureException);
};

LightSOFT NBI V14.0 User Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LightSOFT NBI V14.0 User Guide

Uploaded by

Copyright:

Available Formats

LightSOFT NBI

NBI User Guide

ECI's management applications run on VMWare virtualization hypervisors.

© Copyright by ECI, 2018. All rights reserved worldwide.

1 Getting started with LightSOFT NBI ............................................................. 1-1

ECI Telecom Ltd. Proprietary iii

1.9.3 FDFr states............................................................................................................................. 1-16

2 Keep-Alive mechanisms............................................................................... 2-1

3 Security ....................................................................................................... 3-1

4 GetRoute cross connect ordering ................................................................ 4-1

5 GetRoute returned attributes ...................................................................... 5-1

ECI Telecom Ltd. Proprietary iv

5.7 Protected P2P tunnel ........................................................................................................... 5-10

6 Supported operations ................................................................................. 6-1

7 Obtaining PM status .................................................................................... 7-1

ECI Telecom Ltd. Proprietary v

ECI Telecom Ltd. Proprietary vi

ECI Telecom Ltd. Proprietary 1-1

1.1 LightSOFT Multilayer Subnetwork (MLSN)

ECI Telecom Ltd. Proprietary 1-2

1.2 LightSOFT Flow Domain (FD)

1.3 Topology links

AdditionalInfoAttribute Values AVC Comment

ECI Telecom Ltd. Proprietary 1-3

1.4 Fiber connectivity

ECI Telecom Ltd. Proprietary 1-4

1.5.1 LightSOFT trails on UMEs

1.5.2 UME object association and naming

ECI Telecom Ltd. Proprietary 1-5

1.7 Trails and SNCs

1.7.1 EMS SNCs

1.7.2 Optical SNCs

ECI Telecom Ltd. Proprietary 1-6

For more information see Layer Parameters in the Additional Information.

1.7.3 SNC types

1.7.4 SNC states

1.7.5 Server trails

ECI Telecom Ltd. Proprietary 1-7

1.7.6 Error reasons and success/failure of operations

1.7.7 CreateAndActivateSNC reply codes

object: one of the following:

errorCode: integer representation of the error

errorText: the text displayed in the GUI.

ECI Telecom Ltd. Proprietary 1-8

1.7.8 SNC parameters

ECI Telecom Ltd. Proprietary 1-9

 Protection Effort: EFFORT_WHATEVER and EFFORT_SAME are supported. If EFFORT_SAME is

1.7.9 Presenting LightSOFT trails to OSS

ECI Telecom Ltd. Proprietary 1-10

ECI Telecom Ltd. Proprietary 1-11

1.7.10 Editing and reconnecting SNCs

1.7.11 SNCs on UMEs

1.7.12 Unique IDs for uploaded SNCs

ECI Telecom Ltd. Proprietary 1-12

1.8 Tunnels and SNCs

1.8.1 Specifying tunnel endpoints

1.8.3 Presenting LightSOFT tunnels to OSS

ECI Telecom Ltd. Proprietary 1-13

1.8.4 IDs for uploaded tunnel SNCs

ECI Telecom Ltd. Proprietary 1-14

1.9 Ethernet services and FDFrs

1.9.1 EMS FDFrs

1.9.2 FDFr types

 FDFRT_POINT_TO_POINT: This type of service associates exactly two endpoints.