LightSOFT NBI V14.0 Explanatory Documents

LightSOFT NBI
Version 14.0
Explanatory Documents
LightSOFT NBI Explanatory Documents
V14.0
Catalog No: X92782
Drawing No: 432006-2461-093-A00
April 2018
Rev01
ECI's NPT-1200, NPT-1020, and NPT-1010 are CE2.0 certified.
ECI's NPT-1600 complies with the MEF9 and MEF14 standards.
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.
SDH Objects in the eNI and NMS
Contents
1. Abbreviations........................................................................................................................ 2
2. Scope ..................................................................................................................................... 2
3. SDH Object Mapping ............................................................................................................ 2
3.1 SDH Adaptations........................................................................................................... 3
3.2 Electrical SDH PTP ......................................................................................................... 6
3.3 Optical SDH PTP............................................................................................................. 6
4. SDH and SONET Multiplexing and MTNM layerRates ...................................................... 7
5. Managed Element SDH Extension Attributes .................................................................... 8
6. Protection Group Attributes .............................................................................................. 8
1. Appendix: Example of MTNM Objects in an NMS SDH Trail ........................................... 18
2. Appendix: MTNM Alarm Reporting Configuration for Equipment and
Termination Points............................................................................................................... 19
3. Appendix: MTNM/NMS Service State Definition for Equipment and Termination
Points ................................................................................................................................... 21
4. Appendix: MTNM SDH/SONET CTP Object Name Convention ...................................... 23
5. Appendix: Signal Label Mapping of G.707 to MTNM ...................................................... 25
1
1. Abbreviations
ABO - Alarm Bearing Object

CTP - Connection Termination Point (MTNM/ITU)
DSR - Digital Signal Rate (MTNM)
EMS - Element Management System (eNM-vX or eNM-XDM)
eNI - ECI Northbound Interface
MTNM - Multi-technology Network Management
NMS - Network Management System
PTP - Physical Termination Point (MTNM)
TTP - Trail Termination Point (ITU)
2. Scope
To present the MTNM objects that will be managed in the SDH layer of the NMS and
the operations relating management of SDH objects that will be performed through
the MTNM NML-EML standard interface and Lightscape extensions.
The document contents is consists of the following.

• Section C SDH Object Mapping details the mapping requirements of
ITU/Lightscape objects to MTNM Objects. NMS objects can be based on
these objects but do not have to correspond on a 1:1 basis with these objects.
For example the MTNM Physical Termination Point (PTP) object can
encapsulate a layer that can functions as a trail end-point in the NMS (e.g. an
OCH TTP or 2M PI). In such a case it is reasonable for the trail endpoint to be
represented by an object other than the PTP (or rather split the PTP into several
objects).
• Section D specifies the implementation details of creating the multiplexing
structure of SDH/SONET ports based on MTNM information (avoiding
unnecessary calls to the EMS).
• Section E lists MTNM and Lightscape extension attributes of SDH termination
(PTP layers or terminated AU4) and connection points (CTP).
3. SDH Object Mapping
In MTNM the Physical Termination Point (PTP) object encapsulates all transmission
objects that have a 1:1 correspondence with the physical port. Only ITU TTPs can be
encapsulated within the PTP. Objects that have internal flexibility and/or are have
intra-node connections are mapped to the Connection Termination Point (CTP).
MTNM PTPs are layered: each layer can correspond to a managed transmission
object. Some layers cannot be directly mapped to a transmission object but to an
attribute of a managed transmission object. For example "Physical Optical" or
"Physical Electrical" can be mapped to a single SPI attribute or an equipment
attribute.
2
Two unidirectional SDH transmission objects (e.g. in eNM-XDM) are mapped to a
layerRate that is a part of a single bi-directional MTNM TP object.
MTNM alarms are raised against specific layerRates. LayerRates that are not mapped
to an ABO or mapped to an ABO as a "secondary" layerRate cannot emit alarms. For
example "Physical Optical" alarms in LSN equipment are raised against the
corresponding equipment object so that the "Physical Optical" layer is "unmanaged".
3.1 SDH Adaptations
The following are PDH-SDH adaptations include ports of PIO2_84, PIO345, TR2,
TR34, and TR140 cards.
MTNM ITU / Lightscape EMS
VCx TTP
CTP x =12,3,4
VC x=12,3,4
E i=1,2,3 P12 for framed E1

(when unavailable
the Ei layer in
CTP is still
present)
E i=1,2,3 PTP
DSR 2M,34M,140M PI
n=2M,34M,140M
Physical Electrical
3
• The PDH layerRate is mapped both to the PTP and CTP of the PDH port.
• PDH alarms of the ingress E1 are raised against the E1 layer of the PTP object.
• PDH alarms of the egress E1 (e.g. P12 object) are raised against the E1 layer of
the CTP object
• The transmission parameters of the E1/E2/E3 can only be retrieved or set
through the PTP object.
• Sink and source PDH and SDH TPs are merged to form single bi-directional
PTP and CTP objects when possible.
EMS Implementation Issues:
For Syncom both VC-E and VC-W contained by the PI or SPI in a tributary
are mapped to a single CTP (contained by the PDH PTP).
Alarm Reporting. A single value is sufficient. It will be "on" whenever at

least either the East or West VC report alarms. Setting alarm reporting "on"
will set both the East and West VC on simultaneously.
The actual trail trace and expected trail trace can be reported for each side by
mapping these attributes to the TU. This implies that the trail trace can only
be retrieved from the TU once the XC is created.
The following are GBE-SDH adaptations that apply to the GBE port of XDM DIO
cards.
MTNM LSN EMS
PTP
Ethernet Ethernet
Encapsulation
DSR GBE (e.g. ProtocolType
Concatenation
= HDLC)
Group
GBE
CTP
Fragment
Optical Section VC4 TTP
VC4
OPI
Physical Optical
• GBE alarms, and PM are available on the GBE layer of the PTP.
• The "Fragment" layer in the PTP represents the GBE concatenation group.
o FragmentAlloction- TP parameter on this layer that will indicate the
current number of VC4s that the GBE (encapsulated in an HDLC
4
frame) is mapped to.
o FragmentAlloctionMax parameter will indicate the maximum number
of VC4s that are available for assignment to this port (Not in eNI
v2.0).
o FragmentActiveAlloction - will indicate the actual rate of the WAN
connection i.e. the actual number of CTPs that are carrying active
Ethernet traffic. (Not in eNI v2.0).
• The "Encapsulation" layer reflects the framing protocol (e.g. HDLC). It will be
necessary once different protocols types can be configured and/or supported by
the equipment. This layer is not provided in eNI V2.0.
5
3.2 Electrical SDH PTP
Includes ports of ATRE, TRSE, and SIO1_8E cards

MTNM ITU
PTP
MS TTP
MS STM1
RS STM1
RS TTP
DSR STM1
Section Physical
Interface
Physical Electrical
3.3 Optical SDH PTP
Includes ports of (non-colored) TRSO, ATRO, ASF, SIO1_16, SIO4_4, SIO16_1,

and SIO64. Colored SIOs are covered in Yakov Zimmerman's Optical Objects in
NGM.
MTNM ITU
PTP
MS TTP
MS n=1,4,16,64
RS n=1,4,16,64
RS TTP
DSR n=1,4,16,64
Section Physical
Interface
OCH (INACTIVE)
Optical Section
Physical Optical
• SPI LOS alarm is raised against the DSR layer. The DSR layer will be present
in both electrical and optical SDH PTPs.
• SDH PTP in a (standard) regenerator ends at the dotted line (i.e. it excludes the
MS TTP).
6
4. SDH and SONET Multiplexing and MTNM layerRates
MTNM layerRates are shared for both SDH and SONET. For example STS3c and
AU4 are identified with a single layerRate. Only LO TU3 is distinguished as an
SDH only layerRate.
LR_Line_OC[n]_STS[n]_and_MS_STM[n/3]
[n/3] n [n/12]
MS EXT DCC 0..n
LR_STS3c_and_AU4_VC4 LR_STS1_and_AU3_High_Order_VC3 LR_STS12c_and_VC4_4c
0..n
3 "SDH Only" Terminated and Mapped RS EXT DCC
TUG3 LR_STS48c_and_VC4_16c [n/48]
1..1 7
LR_STS192c_and_VC4_64c [n/192]
TU3 TUG2 or VT Group 7
Terminated and Mapped
MS DCC 1..1
1..1
4 3 1
RS DCC
LR_VT1_5_and_TU11_VC11 LR_VT2_and_TU12_VC12 LR_VT6_and_TU2_VC2
Contiguous SDH containers (VC4_4c, VC4_16c etc.) in the above are represented
over the interface as a single object.
EMS Implementation Issue:
The EMS shall map the first VC object of a concatenation group of a Contiguous type
to the contiguous object as in the above diagram following the MTNM naming
convention. E.g. a contiguous group containing AU4-5 to AU4-8 shall be mapped to
a VC4_4c CTP indexed as the 2nd such CTP for any STM16 or STM64 PTP.
NMS Implementation Issues:
The multiplexing structure (LO map) can be constructed in the NMS according to the
following parameters:
7
1. The termination mode of the HO CTP. The multiplexing structure / LO
map only needs to be created for HO CTPs that are terminated and mapped.
2. The SDH/SONET mode of the PTP1 and layerRate of the HO CTP (AU3 or
AU4). For all SONET ports LO terminations should not be created for
the HO AU4/STS3c CTP. This should not occur since the SONET
STS3c cannot be terminated and based on #1.
3. The supported layerRates of the containing subnetwork and the containing
managed element. For example Lightscape subnetworks and managed
elements will not return the TU11_VC11 as a supported layerRate.
The NMS should only create a TU map for HO CTPs according to the intersection of
managedElement supportedLayerRates and the Subnetwork supportedLayerRates.
For example if TU12 connectivity is not supported by both the managed element and
the containing Subnetwork then it should not need to be created.
NOTE:
The TUG and VT groups are not MTNM objects but are obtainable through the
MTNM k-l-m naming convention (refer to Appendix IV).
5. Managed Element SDH Extension Attributes
The Managed Element should have additional attributes indicating the active timing
source:
• LSNExt_ActiveTimingSrcType:
LINE/EXTERNAL/TRIBUTARY/INTERNAL.
• LSNExt_ActivePTPSrc - PTP name acting as timing source of the NE. In case
that the timing source is other than LINE/TRIBUTARY the value is null.
For Syncom NEs with an East and West Timing Generator there is also:
• LSNExt_ActiveTimingSrcTypeWest
LINE/EXTERNAL/TRIBUTARY/INTERNAL.
• LSNExt_ActivePTPSrcWest - PTP name acting as timing source of the NE. In
case that the timing source is other than LINE/TRIBUTARY the value is null.
6. Protection Group Attributes

1. name
See The eNI Object Naming Specification
document
1
The NE can be assumed to be SDH if the LO_TU3 layerRate is supported by the managedElement or
Subnetwork. If the managedElement does not support the LO_TU3 but supports connectivity at other
LO LayerRates and STS-3c (equivalent of AU4) it can be assumed that all NE ports support SONET
only. I.e. the NMS does not allow mixed SONET and SDH ports within the same managedElement.
8
2. userLabel
By default the same as the nativeEMSName. The attribute is settable by NMS (will
not be used by eNM v9.0).
3. NativeEMSName
This is equivalent to the object name as displayed in the EMS GUI. See The eNI
Object Naming Specification document for examples.
4. Owner
NULL by default. This attribute is settable by the NMS (will not be used by eNM
v9.0).
5. protectionGroupType
PGT_MSP_1_PLUS_1
PGT_2_FIBER_BLSR
6. protectionSchemeState
PSS_UNKNOWN,
PSS_AUTOMATIC,
PSS_FORCED_OR_LOCKED_OUT
7. reversionMode
RM_UNKNOWN,
RM_NON_REVERTIVE,
RM_REVERTIVE
8. rate
For PGT_MSP_1_PLUS_1:
24 = LR_Line_OC1_STS1_and_MS_STM0,
or
28 = LR_Line_OC192_STS192_and_MS_STM64
For BLSR:
or
28 = LR_Line_OC192_STS192_and_MS_STM64
9. pgpTPList
List of 2 (bi-directional) PTPs
9
10. pgpParameters
• "SPRINGNodeId" - The SPRINGNodeId is used to identify the
managedElement during creation of SNCs. This is needed for BLSRs to
identify the ingress and the egress nodes so that they know where to loop
around in case of failure. "0".."15" (may be any other string that matches the
SPRINGNodeId transmission parameter values), "Unknown"
• "wtrTime" Wait To Restore time, in seconds. "-1" may be used to indicate an
unknown value or when this parameter is not applicable
• "SwitchPosition" "IDLE","PASS_THROUGH","SWITCH"
• "HoldOffTime" Time duration for which the alarm condition must persist
before the switch takes place. "Unknown", "Infinite", or in milliseconds.
11. additionalInfo
• LSNExt_MSPRingId - decimal format. Uniquely identifies the MSPRing in the

domain of the EMS
• ServiceState - {"IN_SERVICE", "OUT_OF_SERVICE"} Indicates whether
the ring is active or inactive
H. Termination Point Attributes
1. name
PTP objects the names are free format according to TMF814. For performance
considerations and testability GDMO DN is provided whenever the naming
convention is undefined in TMF814. For eNI naming please refer to the See The eNI
Object Naming Specification document.
MTNM specifies mandatory conventions for naming CTPs. An example for the
naming convention for an SDH CTP is the following name identifying the 1.3.2 TU12
CTP in the 4th AUGRP of an STMn./sts3c_au4-j=4/vt2_tu12-k=1-l=3-m=2
See the Appendix IV for the complete set of rules.
2. nativeEMSName
The nativeEMSName is used to represent the objects over the interface as they appear
on the EMS GUI.
The label used for the nativeEMSName is defined as a unique identifier in the scope
of the NE. For layered objects that map to multiple objects in the EMS the
nativeEMSName omits the class name of the object. For example the PTP name will
include the slot name and the port number (e.g. I5-2) but will emit the SPIO, RS or
MS class identifiers.
10
LSN Implementation:
• The NE "System Title" is omitted in order to avoid an avalanche of AVCs in
case of a "System Title" update.
• The "src" or "snk" suffix indicating the directionality of the TP is removed
when two unidirectional TPs are mapped to a single bi-directional TP over the
interface (in case of SDH objects in eNM-XDM).
• The nativeEMSName for layered objects is the lowest layer object.
3. userLabel
UserLabels can optionally be set by the (LSN) NMS. The default value of the
userLabel is the object's nativeEMSName.
Requirement:
The TP userLabel is used in the PM history files provided to the NMS as specified in
TMF814. In order to relate the PM data to NMS trails the NMS will assign the
userLabels of trail endpoints as the NMS trail label. This will require the EMS to
allow the upper level manager to assign a userLabel to all objects that collect PM
data. I.e. setting the user label will be supported for all VC TTP, TCM points, and
AU and TU CTPs when applicable.
11
4. CTP Termination Mode
AU4 CTP TUx CTP

(ITU) (ITU) TUx_VCx MTNM
x=12, 2, 3 CTP (Neither
AU4_VC4 Terminated nor
MTNM CTP Available for
(Neither VC4 TTP Mapping - fixed)
Terminated
nor Available
for Mapping)
AU4_VC4 MTNM
PTP CTP (Terminated &
MS n=1,4,16,64
Mapped)
AU4 CTP
(ITU)
RS n=1,4,16,64
PTP
HO SDH/SONET Path Termination

The termination mode of a HO CTP indicates whether the HO path is terminated in
order to allow LO connectivity.
• Only in the "Terminated and Mapped" state, client rate CTPs can be
used in SNCs.
• Only in the "Neither terminated nor mapped" state can the ITU CTP be
cross-connected at its given rate (e.g. AU4-AU4 XC).
• The termination mode of LO SDH CTPs with adaptations (e.g. VC12 in
PIO or TR2 cards) is TM_NA
Examples:
o In XDM the AU4-VC4 XC indicates whether the AU4 is
terminated and mapped.
o The termination mode of VC in PDH tributary cards is
"TM_NA"
o The XDM AU4 CTP is considered "terminated and mapped"
only when both AU4Src and the AU4Snk are terminated and
mapped in a bi-directional cross-connect.
The NMS will construct a HO Server trail termination for any two AU4_VC4 CTP
contained by MS TTPs that terminate the toplogical link, share the same AUG index
(see the naming convention details in Appendix IV) and for each AU4_VC4 CTP that
12
is terminated and mapped. The NMS will be able to create and discover
unidirectional server trails.
NOTE:
Terminate and map operation creates a bi-directional termination and mapping of the
AU4. I.e. the bi-directional CTP cannot be used to support one unidirectional server
trail, going through and one unidirectional server trail termination as supported by the
standard MTNM interface. Either the CTP supports a single bi-directional server trail
terminated in the NE, or two unidirectional server trails that are going through.
Lightscape Implementation:
There will be a VC4 unidirectional termination mode attribute as an extension, in
order to allow creation of unidirectional server trails (prior to creating the
unidirectional AU4 SNC going through in the inverse direction)
Layered parameter LSNExt_TerminationMode with the following values will be
supported.
LSNExt_TerminationMode tpMappingMode (MTNM standard attribute)

"TERMINATED_AND_AVAILABLE_FOR_MAPPING_ TM_TERMINATED_AND_AVAILABLE_FOR_MAPPING
BIDIRECTIONAL"
"NEITHER_TERMINATED_NOR_AVAILABLE_FOR_ TM_NEITHER_TERMINATED_NOR_AVAILABLE_FOR_MAPPING
MAPPING"
"TERMINATED_AND_AVAILABLE_FOR_MAPPING_ TM_NEITHER_TERMINATED_NOR_AVAILABLE_FOR_MAPPING
UNIDIRECTIONAL"
"SNK_TERMINATED_AND_AVAILABLE_FOR_MAPP TM_NEITHER_TERMINATED_NOR_AVAILABLE_FOR_MAPPING
ING",
"SRC_TERMINATED_AND_AVAILABLE_FOR_MAPP TM_NEITHER_TERMINATED_NOR_AVAILABLE_FOR_MAPPING
ING"
The 3rd case represents the case where AU4s in both directions are terminated as uni-
directional endpoints and the RDI function is suppressed in the VC4 termination.
In the 1st case the AU4 is terminated through a bi-directional XC implying that the
CTP can only be an endpoint for a bi-directional server trail.
The EMS will check the transmissionParameters provided by the NMS when the
termination mode is set. When the extension attributes for termination mode are
available, the EMS will only use the extension attributes.
DCC Termination (LSN Proprietary Support of DCC CTPs)
DCC CTPs can be cross - connected with one another (in XDM) or cross-connected to
DCC TTPs in the COM.
In the current MTNM DCC TTPs in the COM cannot be represented since there is no
Physical Termination Point that supports them.
DCC termination in the COM can be represented through the Termination mode
attribute of the DCC CTPs supported by the SDH PTPs and the DCC mode
transmission parameter attribute of the MS and RS layers.
13
DCC CTPs will be created for Syncom and Micro equipment for each SDH PTP. The
MS or RS DCC CTP will be "terminated and mapped" only when the DCC Mode
attribute of the MS or RS is "terminated in COM" respectively.
5. SDH Transmission Parameters
All AVCs emit AVC unless noted otherwise.
"Physical Optical" & "Physical Electrical" Layers

• "Location" always indicated for the lowest "physical" layer.
The location will indicate the equipment that contains the transmission object.
NOTE:
In some cases this will not correspond to the equipment that actually contains
the actual physical port (this is not entirely in compliance with MTNM). For
example M2_84 module contains the PIO2_84 physical ports but not the
software transmission objects.
The following is an example for a PTP Location:

/rack=1/shelf=1/slot=15/sub_slot=4/port=1
Equipment /rack=1/shelf=1/slot=15/sub_slot=4/ is the name of the "equipment
holder" object that contains the supporting equipment.
Physical PTP (Tx/Rx) alarms are mapped to the corresponding equipment objects.
The "Physical Optical" & "Physical Electrical" layers will not be managed within
the PTP. I.e. the 1st layer in the electrical PTP and the 1st two layers in the optical
SDH PTP do not emit alarms, and will not have the alarm reporting indication.
• LSNExt_NativeLocation -
Indicates the equipment slot name that contains the port as it is called in the EMS
GUI. For example, the location "Slot I5" or "105" is provided for XDM and
Syncom equipment respectively.
• LSNExt_EquipmentProtected – Enabled / Disabled

Indicates whether the card supporting the port is protected by equipment
protection.
OCH Layer
• ThisLayerActive -
INACTIVE implies a non-colored SDH port
ACTIVE implies a colored SDH port where other TP parameter may apply.
See the Optical Objects in the NGM NMS document for more details.
14
DSR STM n=1,4,16,64 and DSR 2M, 34M and 140M Layer
• AlarmReporting (see Appendix II)
Sets the reporting and/or detection on/of for the SPI LOS alarm.
• ServiceState (See Appednix III)
RS STM n=1,4,16,64 Layer
• AlarmReporting (see Appendix II)
• ServiceState (See Appednix III)
• LSNExt_DCCMode - possible values are "TERMINATED_IN_COM" /

"THROUGH" / "TERMINATED_IN_EXTBYTES" / "DISABLED" and will
be used by the NMS to construct the DCC map and/or INFO application. The
values THROUGH and TERMINATED_IN_EXTBYTES will imply that the
DCC bytes going through the NE are transparent and the NE does not use the
DCC bytes coming in on this port. The DCC network can be drawn on the
topology based on this information as in the above diagram.
• TrailTraceExpectedRx - read/write (by NMS) 16 character string.

Setting this value can enable TIM alarms for mismatch of the J0. The NMS
can set this value to match with the TrailTraceActual Tx in the source PTP
when creating a topology link. (Please refer to the requirement in Yakov
Zimmerman's Topolgy Link Document).
Note:
o Size of the TrailTrace in SONET may be limited to 1 byte.
o Syncom equipment may not support TrailTrace (J0) at the RS layer.
• TrailTraceActualTx - read/write
If modified, the same unique value needs to be assigned by the NMS to the
transmitted value and the sink's expectedRx value.
• TrailTraceActualRx - read only

Evaluation of the received RS J0 can be used for automatic discovery of the
topology in the NMS and/or for checking for a misconnection of a fiber.
Changes in this attribute do not involve an AVC.
• TrailTraceMonitor – read/write {on ,off}
15
Indicates whether the monitoring of the TrailTraceActualRx is enabled and TIM alarms
are generated. By default the TTI monitoring and TIM alarms are enabled.
MS STM n=1,4,16,64 Layer
• AlarmReporting - (see Appendix II)
• ServiceState - (See Appednix III)
• LSNExt_DCCMode - as for the RS layer.
• MSLockout - Possible values are "locked out", "" (NULL). This value is set by
the EMS to indicate the MS section is locked out. The value can be changed by
the NMS using the protection group performProtectionCommand() operation.
VCx/VC4_Xc,x=12,3,4 X=4,16,64 Layers
• SignalLabelActualTx
This is in decimal format with values between 0 and 255. Please refer to
"Appendix V: Signal Label Mapping of G.707 to MTNM" for the applicable
values.
In EMS GUI is the Signal Label is provided as:
"Equipped Unspecified" (5) /
"Unequipped" (0)/
"TUG Structure" (2) /
"34M" (4) /
"140M" (4 or 12) /
"ATM" (19) / "VC AIS" (255)
"Asynchronous" / "Bit Asynchronous" / "Byte Asynchronous" (4 or 12)
• SignalLabelExpectedRx - this value is read/write (needs to be set for the
aggregate AU4 when terminating in a TR140 VC4 in order to avoid PLM).
Values are as in SignalLabelActualTx.
Setting this value from the NMS is of lower priority.
• SignalLabelActualRx
• TrailTraceExpectedRx - read/write (by NMS) 16 character string.
Requirement:
Setting this value can enable the TIM alarm to detect possible misconnections.
The NMS will set this value for each sink CTP of an SNCP switch point and
trail end point. The value set for each of the sink CTPs will match with the
TrailTraceActualTx of the source CTP when creating an end-to-end trail. The
trail creation application should allow the user to override automatic setting of
the Trail Trace.
• TrailTraceActualTx - read/write
• TrailTraceActualRx - read only
Trail trace will be used by the NMS to perform a "Check Path Trace" operation.
The TrailTraceActualRx should match for all CTPs along the path of the trail to
the TrailTraceActualTx of the source CTP when the CTPs support the trail
trace attribute. Changes in this attribute do not involve an AVC.
• TrailTraceMonitor – read/write {on ,off}, same as for the RS layer
• protectionSchemeState - values: "PSS_AUTOMATIC" or
"PSS_FORCED_OR_LOCKED_OUT". Applies to the reliable CTP in SNCP
and to indicate a forced switch or lockout without regard to direction.
16
E1 2M / E3 34M / DS3 45M Layer
• FrameFormat - values
"unframed" - all signals
"sf" - E1 superframe / multiframe
• ClientRate - decimal format nnnn.ppp in units of Mbit/s.
This parameter indicates the total bandwidth used in case of fractional E1. i.e.
ClientRate = N x 64Kbit/s / 1024 where N is the number of time slots used.
Fragment Layer
• ServiceState -
o SERV_NA: when different state for source and sink (of the
configured state)
o IN_SERVICE: when both src and sink Expected and Actual data is
active
o OUT_OF_SERVICE_BY_MAINTENANCE: both the configured /
o expected src and sink data is inactive
o OUT_OF_SERVICE: if dataActiveActual (sink) is false while
expected/configured of both source and sink are true For more detail
on the general usage see Appednix III: MTNM / NMS Service State
Definition for Equipment and Termination Points.
• LSNExt_FragmentationAllocation - this parameter is based on MTNM V3.0
suggested modeling for Ethernet Over SDH/SONET and Inverse Multiplexing.
The value will be provided for the Fragment layer of the PTP and will indicate
the number of VC4s (and/or STS1) currently associated to the GBE protection
group.
• FragmentationAllocationMax (not in eNI v2.0)
• FragmentActiveAllocation (not in eNI v2.0)
17
1. Appendix: Example of MTNM Objects in an NMS SDH Trail
CTP 1 - 34M/VC3 CTP in PDH tributary CTP6 - AU4_VC4 CTP

terminationMode - NA terminationMode - Terminated and Available
CTP 4 - AU4
connectionState - Source Connected for Mapping
terminationMode - Neither Terminated Nor
Available for Mapping connectionState - Not Connected
CTP2 - TU3 contained by CTP3
connectionState - Bidirectionally Connected
terminationMode - Neither Terminated Nor CTP7 - TU3 contained by CTP6
Available for Mapping terminationMode - Neither Terminated Nor
CTP 5 - AU4
connectionState - Sink Connected Available for Mapping
terminationMode - Neither Terminated Nor
Available for Mapping connectionState - Source Connected
CTP3 - AU4_VC4 CTP
connectionState - Bidirectionally Connected
terminationMode - Terminated and Available CTP 8 - 34M/VC3 CTP in PDH tributary
for Mapping terminationMode - NA
connectionState - Not Connected connectionState - Sink Connected
TU3_VC3 Subnetwork 2 Subnetwork 3

AU4_VC4 AU4_VC4
Subnetwork 1
4 5 6
3
TU3_VC3
2 7
TU3_VC3 TU3_VC3
1 8
34 M 34 M
ST
34M CT
MS Link (EMS or NMS created)
Bidirectional HO SNC
Unidirectional LO SNC
PTP
CTP
18
2. Appendix: MTNM Alarm Reporting Configuration for
Equipment and Termination Points
MTNM V2 provides a limited scope of fault management configuration. Alarm

reporting / monitoring setting can be applied to equipment and transmission objects
(in MTNM each transmission object or a number of transmission objects are mapped
to PTP and/or CTP layerRate(s)).
Transmission Object Alarm Reporting
TP Transmission Parameter AlarmReporting - values possible:

{"on", "off"} - read / write
• "On" when the master mask is off / MON.
• "Off" when the master mask of the object is switched on / "NMON" /

"masked".
• NA when all probable causes are either Non-Reported or undetected then the
setting of the mask is irrelevant. This also applies to unmanaged layers that do
not generate alarms. when NA applies then the TP parameter is not provided
over the EMS-NMS interface.
When the NMS sets alarm reporting "on", if masking is available the master mask
will be switched to MON.
When the NMS sets alarm reporting "off", the master mask it is set to NMON (or
MASKED when NMON is unavailable).
The master mask is set for both near-end and far-end alarms (if applicable) when the
termination point is bi-directionally connected. If it is Sink-connected only the near-
end alarms are masked. When the termination is Source-connected the far-end alarms
are masked.
Requirement:
The NMS will only set alarm reporting for transmission objects acting as a sink for an
CTPs involved in an SNCP switch point and all trail endpoints.
NOTE:
Setting the alarm reporting on for the source of a unidirectional trail will cause the
associated sink to report alarm while the CTP is not necessarily sink-connected.
When the NMS aggregates the alarm reporting status of multiple objects, the alarm
reporting contains the value "on" when at least one of the objects reports alarms. I.e.
19
when the CTP aggregates a VC-E and VC-W then the alarm state is "on" when either
VC-E or VC-W alarms are not masked.
When the alarm reporting is set on an AU4/VC4 CTP that is "terminated and mapped"
the alarmReporting attribute is set "on" on the VC4 TTP and not on the AU4 CTP.
Equipment Object Alarm Reporting
Equipment_T::alarmReportingIndicator - values possible {true, false}
• "On" when at least one of the applicable probable causes is both detected and
reported.
• "Off" when all of the equipment's applicable probable causes are either non-
reported or not detected.
The support of the operations used to enable alarm reporting for equipment is lower
priority and will not be required in the first phase of the NMS or TEMIP.
20
3. Appendix: MTNM/NMS Service State Definition for
Equipment and Termination Points
MTNM specifies a single state to reflect both the ITU operational and administrative
state of an object. The NMS will display the serviceState in the object "Info"
application and trail creation will allow the routing of trails through TPs that are "in
service". The serviceState is defined as a transmission parameter for the PTP and
CTP objects.
The CTP can be out of service when the containing PTP is in service, but the CTP or
containing HO CTP is OUT_OF_SERVICE_BY_MAINTENANCE (e.g. if a forced
AIS is invoked on a VC).
According to MTNM the serviceState can be read / write attribute. eNM-XDM and
eNM V8.5 will support the serviceState as a read-only attribute. I.e. the NMS will not
be able to put an equipment or TP out of service.
The state can take on the following 3 values:
IN_SERVICE
This means that the equipment or connection and physical termination point are
able to carry the signal.
LSN implementation:
• Only PTP and equipment objects will indicate that they are
IN_SERVICE when the operational state is enabled.
OUT_OF_SERVICE
Faulty or non-actual/installed equipment may cause the equipment and/or

transmission objects to be "out-of-service".
LSN Implementation:
• CTPs will not provide this indication since this may cause a state
change avalanche when a card is physically installed.
• PTPs are considered out of service only when the containing equipment
(OM / OT / Card) is not physically installed.
21
OUT_OF_SERVICE_BY_MAINTENANCE
Indicates that there is a current maintenance operation that is active for the
given object. All maintenance operations are considered traffic affecting.
When the port can be set as Enabled or Disabled (e.g. GBE object of a DIO
card) then the PTP layer will appear as
OUT_OF_SERVICE_BY_MAINTENANCE whenever the Port is disabled.
LSN Implementation:
• PTPs and CTPs provide this indication when persistent maintanance
operations are performed (loopback, Forced AIS, FERF).
SERV_NA
Provided when there is no sufficient information to provide the exact service

state.
LSN implementation:
• Will be indicated by CTPs that are not
OUT_OF_SERVICE_BY_MAINTENANCE. The NMS can rely on the
service state of the containing PTP and the indication that the
The ITU-MTNM mapping is defined in MTNM as follows:
ITU ITU MTNM Service State

Operational Administrativ
State e State and
Lightscape
Port Enable /
Disable
enabled unlocked and IN_SERVICE
Port Enabled
locked or Port OUT_OF_SERVICE_BY_MAINTENANCE

Disabled
disabled unlocked and OUT_OF_SERVICE
Port Enabled
locked or Port OUT_OF_SERVICE_BY_MAINTENANCE
Disabled
The administrative state is not currently used by the eNM or the embedded software
i.e. it is not set to locked prior to or as a consequence of invoking maintenance
operations.
Whenever the operational state is disabled the Service State is

"OUT_OF_SERVICE". If the operational state is not supported, the TP and
equipment service states shall be out of service whenever the equipment is not
installed or there is a mismatch of installed and expected equipment types.
The IN_SERVICE indication for PTPs and HO CTPs shall allow the NMS to route
SNCs only through CTPs that are currently in service, when requested to do so by the
user. Both PTP and CTP service states should be taken into account.
22
4. Appendix: MTNM SDH/SONET CTP Object Name Convention
Possible PTP CTP Layer CTP Tuple. Comments
Rate
STM[n]_OC[3n] Multiplex /line[3n]_ms[n]=1 n=[1,4,16,64]. MS CTP on
section regenerators
Regenerator /section[3n]_rs[n]=1 n=[1,4,16,64]. RS CTP on
section Optical Physical STMn / OC3n
STM64_OC192 sts192c_vc4_64c /sts192c_vc4_64c=1 The number is sequential with
respect to the layer rate within
the PTP
sts48c_vc4_16c /sts48c_vc4_16c=[1..4]
sts12c_vc4_4c /sts12c_vc4_4c=[1..16]
sts3c_au4 /sts3c_au4-j=[1..64] The layer rate represents the
AUG numbering where the
number of au4s is exactly 1.
sts1_au3 /sts1_au3-j=[1..64]-k=[1..3] The layer rate represents the
number of au4s is exactly 1 and
the number of au3s is 3 per
AUG. For example, the 7th
STS-1 on an OC-192 PTP would
be called “/sts1_au3-j=3-k=1”,
and the 11th STS-1 would be
called “/sts1_au3-j=4-k=2”
tu3_vc3 /sts3c_au4-j=[1..64]/tu3_vc3-
k=[1..3]
vt6_tu2 /sts3c_au4-j=[1..64]/vt6_tu2-
k=[1..3]-l=[1..7]
k=[1..3]-l=[1..7]-m=[1..3]
STM16_OC48 sts48c_vc4_16c /sts48c_vc4_16c=1
sts12c_vc4_4c /sts12c_vc4_4c=[1..4]
the number of au3s is 3 per AUG
k=[1..3]
k=[1..3]-l=[1..7]
k=[1..3]-l=[1..7]-m=[1..3]
STM4_OC12 sts12c_vc4_4c /sts12c_vc4_4c=1
the number of au3s is 3 per AUG
k=[1..3]
23
k=[1..3]-l=[1..7]
k=[1..3]-l=[1..7]-m=[1..3]
STM1_OC3 sts3c_au4 /sts3c_au4-j=1
sts1_au3 /sts1_au3-j=1-k=[1..3]
tu3_vc3 /sts3c_au4-j=1/tu3_vc3-k=[1..3]
vt2_tu12 /sts3c_au4-j=1/vt2_tu12-k=[1..3]-
l=[1..7]-m=[1..3]
STM0_OC1_EC1 sts1_au3 /sts1_au3=1 There is no need for j and k as
AU3 is not derived out of a
AUG
E4 sts3c_au4 (VC4) /sts3c_au4=1 This represents the SDH (G805
TTP) CTP contained in a E4
PTP. For PDH adapted to
sdh/sonet. This is multilayer
CTP for support of transmission
parameters at more than 1 rate.
DS3 Low order VC-3 /tu3_vc3=1 PDH adaptation; multilayer CTP
E3 Low order VC-3 /tu3_vc3=1 PDH adaptation; multilayer CTP
E1 VC-12 /vt2_tu12=1 2 Mbp/s PDH adapted to VC12
24
5. Appendix: Signal Label Mapping of G.707 to MTNM
The G.707 Hex code, is mapped to the MTNM decimal code in the following 2 tables.
(values for low order VC12 and VC2 V5 signal label are found in the second table)
One byte is allocated to indicate the composition or the maintenance status of the
VC-4-Xc/VC-4/VC-3.
G.707 – C2 byte coding
MSB LSB Hex code Interpretation MTNM / Decimal Code

1234 5678 (Note 1)
0000 0000 00 Unequipped or 0
supervisory-unequipped
(Note 2)
0000 0001 01 Reserved (Note 3) 1
0000 0010 02 TUG structure, see 7.2 2
0000 0011 03 Locked TU-n (Note 4) 3
0000 0100 04 Asynchronous mapping of 4
34 368 kbit/s or
44 736 kbit/s into the
Container-3, see 10.1.2
0000 0101 05 Mapping under 5
development (Note 9)
25
1234 5678 (Note 1)
0001 0010 12 Asynchronous mapping of 18
139 264 kbit/s
into the Container-4, see
10.1.1.1
0001 0011 13 ATM mapping, see 10.2.1 19
and 10.2.2
0001 0100 14 MAN DQDB [1] 20
mapping, see 10.4
0001 0101 15 FDDI [3]-[11] mapping, 21
see 10.5
0001 0110 16 Mapping of HDLC/PPP 22
[12], [13] framed signal
according to 10.3
0001 0111 17 Mapping of Simple Data 23
Link (SDL) with SDH
self synchronizing
scrambler (Note 8)
0001 1000 18 Mapping of HDLC/LAPS 24
[15] framed signals
according to 10.3
0001 1001 19 Mapping of Simple Data 25
Link (SDL) with set-reset
scrambler (Note 8)
0001 1010 1A Mapping of 10 Gbit/s 26
Ethernet frames [14]
(Note 8)
0001 1011 1B Flexible Topology Data 27
Link mapping (Note 8)
1100 1111 CF Reserved (Note 7) 207
1110 0001 E1 Reserved for national use. 224
… … … …
1111 1100 FC 252
1111 1110 FE Test signal, O.181 254
specific mapping (Note 5)
1111 1111 FF VC-AIS (Note 6) 255
1234 5678 (Note 1)
G.707 Notes on the above table:

NOTE 1 – There are 209 spare codes left for future use.
NOTE 2 – Value "0" indicates "VC-4-Xc/VC-4/VC-3 path
unequipped or supervisory-unequipped". This value
is originated in the case of an open connection and in the
case of a supervisory unequipped signal that contains no
26
payload.
NOTE 3 – Value "1" should not be used in any equipment
designed after the approval (10/00) of this Recommendation.
In the past this code meant "Equipped
– non-specific" and has been used in cases where a
mapping code is not defined in the above table, see code
"05" for new designs. For interworking with (old)
equipment designed to transmit only the values "0" and
"1", the following conditions apply:
– for backward compatibility, old equipment shall
interpret any value received other than value "0" as an
equipped condition;
– for forward compatibility, when receiving value "1"
from old equipment, new equipment shall not generate
a PayLoad Mismatch alarm.
NOTE 4 – The code "03" shall, for backward
compatibility purposes, continue to be interpreted as
previously defined even if the locked mode byte
synchronous mappings are not defined any more.
NOTE 5 – Any mapping defined in Recommendation O.181
which does not correspond to a mapping defined in
Recommendation G.707 falls in this category.
NOTE 6 – Value "FF" indicates VC-AIS. It is generated by
a TCM source if no valid incoming signal is available and a
replacement signal is generated.
NOTE 7 – Previous value assigned for an obsolete
mapping of HDLC/PPP framed signal [12], [13].
NOTE 8 – These mappings are under study and the signal
labels provisionally allocated.
NOTE 9 – Value "05" is only to be used in cases where a
mapping code is not defined in the above table. By using this
code the development or experimental activities is isolated
from the rest of the SDH network. There is no forward
compatibility if a specific signal label is assigned later. If that
is done the equipment that has used this code must either be
reconfigured to use that new specific signal label or be
recycled.
27
G.707 - VC-2/VC-1 V5 Signal label coding
b5 b6 b7 Meaning
0 0 0 Unequipped or supervisory-unequipped
0 0 1 Reserved (Note 1)
0 1 0 Asynchronous, see 10.1.3.1, 10.1.4.1 and 10.1.5.1
0 1 1 Bit synchronous, see 10.1.3.2 and 10.1.5.2 (Note 2)
1 0 0 Byte synchronous, see 10.1.4.2, 10.1.4.3, 10.1.5.3 and 10.1.5.4
1 0 1 Extended signal label described in 9.3.2.4 (Note 1)
1 1 0 Test signal, O.181 specific mapping (Note 3)
1 1 1 VC-AIS (Note 4)
NOTE 1 – Value "1" should not be used in any equipment designed after the approval (10/00) of
this Recommendation. In the past this code meant "Equipped – non-specific" and has been used
in cases where a mapping code is not defined in the above table, see code "101" and extended
signal label "02" in Table 9-11 for new designs. For interworking with (old) equipment
designated to transmit only the values "0" and "1", the following conditions apply:
– For backward compatibility, old equipment shall interpret any value received other than
"0" as an equipped condition.
– For forward compatibility, when receiving value "1" from old equipment, new equipment
shall not generate a PayLoad Mismatch alarm.
NOTE 2 – In the case of a VC-12, the code "3" shall, for backward compatibility purposes,
continue to be interpreted as previously defined even if the bit synchronous mapping of
2048 kbit/s signal is not defined anymore.
NOTE 3 – Any non-virtually concatenated mapping defined in Recommendation O.181 that does
not correspond to a mapping defined in Recommendation G.707 falls in this category.
NOTE 4 – Value "7" indicates VC-AIS. It is generated by a TCM source if no valid incoming
signal is available and a replacement signal is generated.
28
Optical Objects in the NGM NMS
Contents
1. Scope ....................................................................................................................................................... 2
2. Requirement Glossary ........................................................................................................................... 2
3. NMS TP Objects - Layer Rates and Layered Parameters In Use ......................................................... 5
3.1. NMS acquisition of TPs .................................................................................................................... 5
3.2. Physical Optical Layer (PO) .............................................................................................................. 7
3.3. Optical Section Layer (OS) ............................................................................................................... 8
3.4. OTS Layer: .......................................................................................................................................... 8
3.5. OMS Layer: ........................................................................................................................................ 9
3.6. OCH Layer ........................................................................................................................................ 10
3.7. DSR Layer ......................................................................................................................................... 14
3.8. ProtectionGroup object ................................................................................................................ 16
3.9. Topology Links and SNC objects ................................................................................................... 18
3.9.1.OTN Topology Links (e.g. OTS Trails) Built with OTS PTPs as endpoints. .................................... 18
3.9.2.OMS Trails ................................................................................................................................... 18
3.9.3.OCH Trails ................................................................................................................................... 18
3.9.4.Light Path trails ........................................................................................................................... 18
3.9.5. TCM Trails .................................................................................................................................. 19
3.9.6.Optical Supervisory Trails (OSC).................................................................................................. 19
3.9.7.SDH Topology Links – Virtual Links ............................................................................................. 19
3.9.8.Connection rules ......................................................................................................................... 19
4. Mapping of the eNI ................................................................................................................................ 20
4.1. Functional Equipment Modeling ................................................................................................... 18
Page 1 of 22
1. Scope
This document describes the objects to be managed in the NGM NMS for Optical Networks.
The section NMS TP Objects - Layer Rates and Layered Parameters In Use describes the
objects that are required to be managed by the NMS. The implementation of these objects is
beyond the scope of these requirements.
The section Mapping of the eNI describes the mapping of objects that must be performed by
the EMS/NE in presenting them to an MTNM compliant NMS.
2. Requirement Glossary
R - indicates a requirement.
CR - indicates a conditional requirement. This is used for requirements that are
required to be implemented under certain conditions.
OR - indicates an optional requirement. This is includes requirements that are “Nice
to Have”.
p0, p1, p2, p3, p4, p5 – indicate priority. p0 is the highest priority and is the default
priority unless otherwise noted.
otp – indicates the document (Optical TPs) in which this requirement first appears.
Example:
[OR.otp.23.p2] – Indicates an optional requirement found in the Optical TP
requirements document. This is the 23rd requirement with a priority of 2.
Page 2 of 22
3. NMS TP Objects - Layer Rates and Layered Parameters In Use
3.1. NMS acquisition of TPs

The NMS discovers TP objects via the eNI/MTNM interface. The discovery of PTP objects
may be via a get operation or via object creation notifications. The discovery of CTP
objects may be via a get operation or based on the NMS knowledge of the CTP structure
for a given PTP. Value changes are received via AVCs.
Unmanaged elements will be addressed in a separate document.
TP Parameters that are detailed below are defined in the MTNM or eNI extensions. These
parameters are optional. There is no guarantee that we will receive all these parameters.
As such the NMS must be shall assume defaults when possible. If no default value is
possible then in order for us to interoperate with another vendor’s EMS we will require
these parameters.
Some parameters are applicable to a specific layer rate but affect other layers. This
document assumes that the parameter will be provided only for the layer rate to which it
belongs and will not be repeated for the layer rates it affects. (There is no problem for the
EMS to provide it in both places if implementation is simplified.) An example of this is the
parameter “number of OCH channels supported”. This is an attribute of the OMS object but
affects the connection rules of the OTS object.
This table defines the MTNM attributes for the OTS/OMS PTP,OTS
PTP, OS/OCH/(DSR/RS) PTP, and OS PTP object [R.otp.1]
globaldefs::NamingAttributes_T name name="EMS"; value=
name="ManagedElement";value=
name="PTP"; value=
// see the eNI Object Naming Specification
string nativeEMSName Name as of this object as displayed in the EMS // see the eNI Object
Naming Specification
string userLabel Shall be identical to the nativeEMSName (Other vendors may
support different value for this and the nativeEMSName. The NMS
will use only the nativeEMSName)
string owner NULL
globaldefs::NamingAttributes_T NULL
ingressTrafficDescriptorName
egressTrafficDescriptorName
TPType_T type TPT_PTP
TPConnectionState_T connectionState TPCS_NA
TerminationMode_T tpMappingMode TM_NA
Directionality_T direction D_SOURCE

D_SINK // for OTN we will map all objects as uni-directional (even
for the Mux/Demux)
transmissionParameters::LayeredParamet typedef sequence<LayeredParameters_T> LayeredParameterList_T;
erList_T transmissionParams
TPProtectionAssociation_T TPPA_NA
tpProtectionAssociation
boolean edgePoint True for network and client side ports
False for ports that are internal to a Optical NE.
// e.g. for a TRP the client side port is an edge in ADD_DROP
configuration while all other ports of TRPs are non-edge. Applies
when the functional node is defined in the EMS.
globaldefs::NVSList_T additionalInfo
Page 5 of 22
This table defines the MTNM attributes for the OMS and OCH CTP objects. The specific TP
parameters are specified below. [R.otp.2]

name="PTP"; value=
name="CTP"; value=
// see the eNI Object Naming Specification
// typically the value will be set to indicate that the port is tunable.
// For ports with a single value (e.g. OADM tributary ports) the CTP
should indicate the frequency value.
string nativeEMSName Name as of this object as displayed in the EMS // // see the eNI
Object Naming Specification
string userLabel Shall be identical to the nativeEMSName of the CTP object.
string owner NULL
ingressTrafficDescriptorName
TPType_T type TPT_CTP
TPConnectionState_T connectionState TPCS_SOURCE_CONNECTED,
TPCS_SINK_CONNECTED,
TPCS_NOT_CONNECTED // not used in V3
TPCS_NA, // not used
TPCS_BI_CONNECTED // not used
TerminationMode_T tpMappingMode • TM_NA, // not used
• TM_NEITHER_TERMINATED_NOR_AVAILABLE_FOR_MAPPI
NG // always used
• TM_TERMINATED_AND_AVAILABLE_FOR_MAPPING // not
used
Directionality_T direction D_SOURCE
D_SINK // for OTN we will map all objects as uni-directional (even
for the Mux/Demux)
transmissionParameters::LayeredParamet Typedef sequence<LayeredParameters_T>
erList_T transmissionParams LayeredParameterList_T;
TPProtectionAssociation_T TPPA_NA.
tpProtectionAssociation For PTPs of transponders that are associated for protection the value
will be TPPA_PSR_RELATED. See section 3.8 for more details.
boolean edgePoint Same as containing PTP
Page 6 of 22
3.2. Physical Optical Layer (PO)
This is the lowest layer of optical transmission equivalent to the layer of the optical
fiber. This layer also exists in SDH PTPs.
Layer rate in the MTNM is: LR_PHYSICAL_OPTICAL
TP Parameter Definition Usage

Location indicates the location of used by the NMS for
the port in the managed organizing the ports. List of
element. Typically this PTPs may be very long. A
identifies the card contains single ME may have
this port. hundreds of PTPs. The NMS
shall present lists of PTPs
grouped by their location.
[R.otp.3] When CTPs are
identified it shall be able to
determine their location
based on their conatining
PTP location. [CR.otp.4.p1]
NativeLocation indicates the The NMS shall

nativeEMSName of the present lists of PTPs grouped
equipment / slot that by their NativeLocation.
contains the port. The [R.otp.3]
nativeEMSName is the
name of the object as
displayed in the EMS GUI.
AlarmReporting (TBD - indicates if this object’s This attribute only

see use of alarms are masked. appears when the object reports
OMSP for SDH and alarms. For objects that do not
single channel links) report alarms (e.g. UME or
physical layer of a transponder
PTP) the
TP parameter does not appear.
ServiceState (TBD - see indicates if its card is This parameter shall

use of not in service, such as not be displayed as part of the
Optical Amplifier used for currently installed, (=OUT TP attributes. [R.otp.6]
SDH) OF SERVICE) or under Pathfinder will not
maintenance (=OUT OF route a path over a PTP whose
SERVICE BY state is OUT_OF_SERVICE
MAINTENANCE). when the pathfinder criteria is
set to “In service links only.
(This is used to prevent using
expected card resources for
trails that need to be used
immediately.) [CR.otp.7.p3that
need to be used immediately.)
[CR.otp.7.p3]
Page 7 of 22
3.3. Optical Section Layer (OS)
This is a layer in a PTP object that forms the endpoint of a topology link in the OTN layer for a
(normally single channel) pre-OTN link I.e. between the transponder colored port to the DWDM
MUX/DEMUX.
Layer rate in the MTNM is: LR_OPTICAL_SECTION

AlarmReporting indicates if this object’s The alarm status of an
alarms are masked. object will have a
distinctive indication
in case the
AlarmReporting of
the object is “Off”.
For example instead
of an alarm status of
No Alarm the status
will be ”Non-
Reported” [R.otp.5]
ServiceState same as for PO same as for PO
3.4. OTS Layer:

This is a layer in the PTP object that forms the endpoints of a topology link in the OTN Layer of
the NMS.
Layer rate in the MTNM is: LR_Optical_Transmission_Section

AlarmReporting same as for OS same as for OS
ServiceState same as for PO same as for PO
Page 8 of 22
3.5. OMS Layer
This object forms the endpoints of an OMS Trail in the OTN layer.
Typically the EMS encapsulates in a single PTP the OMS object and the OTS object. This is the
case when the OTS section and OMS section are of the same length. The exception is when the
OMS trail goes through an element. In this case the TP of OMS layer rate is a CTP and a SNC
of the OMS rate indicates the cross connection connectivity across the NE. (see below regarding
OMS trails.)
There is requirement to manage the OMS trails as independent trails (this is different than
SDH where it is acceptable to manage RS and MS sections as single entity, in general). The requirements
based on this OMS object are described below and affect the PTP and the OMS
trail.
Layer rate in the MTMN is: LR_Optical_Multiplex_Section

ServiceState same as for OS same as for OS

FrequencySpacing indicates which This value is an attribute that shall be
spacing displayed as an attribute of an Optical PTP or OMS
(ITU grid) is CTP.
being used. [R.otp.8]
Typical values This is used by the NMS in determining compatibility
are between
200, 100 and 50. different TPs (see
connectivity rules below) and also in OTN monitoring
algorithms. [CR.otp.9]
FrequencyBand indicates which Used in the

frequency band connection validation rules. Must match or be
(R (Red), B compatible. Unrestricted is compatible with C or L but
(Blue), C or L or limits the trails using the link to a single band.
Unrestricted) is [R.otp.13]
being used. If
unspecified
assumed to be
Unrestricted.
Page 9 of 22
MaxNumberOCh Indicates the This value is an attribute that shall be displayed as an
number of attribute of an Optical PTP. [R.otp.10]. This parameter is
OCH trails that used in the connection validation rules. Must match or
can use an OMS be compatible.
object. For some OMS objects this parameter may not exist. In
this case the object is unrestricted. An example of
equipment that supports unrestricted number of OCH
trails is an InlineAmplifier (some types of them).
[CR.otp.11]
This parameter is used by the NMS to restrict the
number of OCH trails that may be created within an
OMS section. For some OMS objects this parameter
may not exist. In this case the object is not limited in the
number of OCH trails that may be contained in this
object. An example of unrestricted number of OCH
trails is an InlineAmplifier (some types of them).
[CR.otp.12]
3.6. OCH Layer

This object is used in optical OCH trails (and SNCs) managed by the NMS. The OCH can be a
CTP (e.g. in an OADM) or PTP (e.g. TRP, SIO).
Layer rate in the MTNM is: LR_Optical_Channel

ServiceState same as for PO Same as for PO.
TBD if OUT_OF_SERVICE OUT_OF_SERVICE may have to

and IN_SERVICE is provided be concluded from the state of the
or NA to avoid avalanche of containing PTP when the OCH is
a CTP.
AVC notifications when
MUX/DEMUX/OADM card is
installed.
ClientRate indicates the bitrate of the
client (e.g. the trail of type
SDH, ATM, GbE using the
optical trail).
It is defined in the format
nnnn.ppp in units of Mb/s.
Page 10 of 22
ClientType “SONET”, “SDH” "GBE" This value, when supplied by
(Giga-Bit Ethernet), The the EMS, shall be displayed as
MTNM specification also part of the attributes of the
defines clients of type "ATM", OCH CTP and SNC.
”IP” ,"HYBRID",“BB” (for [OR.otp.16.p2]
Broadband). For CBR the
ClientType will indicate BB.
The default when unspecified
is "ANY".
The ClientType and rate are

unspecified for OCH CTPs but
are always specified for OCH
as a part of the PTP.
LSNExt_SpecificClientType The attribute will contain a
finer granularity of
ClientTypes: for example
STM1, STM4 for SDH or
FastEthernet, FDDI, Fiber
Channel etc. for CBR.
MaxClientRate Indicates the rate of clients that Not used by LSN
may use the optical OCH trail.
A common example is for this
value to be limited to 2.5G
(=STM16 traffic).
MinClientRate at times a minimum client rate NOT Used by LSN

is enforced. E.g for TRP10 the
value is STM16 and for TRP25
the value is STM1.
FECOverhead Should indicate must be the same (enabled or
(Forward Error Correction) "Enabled" or disabled for endpoints of a
"Disabled" trail). The attribute should be
considered as free format since
Possibly when different types it may also distinguish beween
of FEC are implemented this different types of FEC
attribute will also indicate the [CR.otp.26]
proportion of overhead in
decimal format i.e. 07.0 % FEC shall be displayed as part
of the object’s attributes.
[R.otp.27.p2]
Page 11 of 22
NumberOfTunableFrequencies For OCH objects that can The potential
transmit or receive at more channels/frequency (based on
than one frequency this manipulating the following
attribute indicates the number three parameters) value is
of options possible. (applies to displayed as an attribute of the
cards such as Transponders, CTP. [CR.otp.31.p2]
SIO cards, and ASFC cards). This value is used when
creating optical OCH trails.
[CR.otp.32.p2]
TunableBaseFrequency For tunable lasers indicates the
first channel supported.
In case that the base channel in
the EMS is the last channel,
then the
TunableBaseFrequency need to
be converted to the first, i.e.
lowest tunable frequency
selection allowed by the
equipment.
TunableFrequencySpacing for tunable lasers indicates the

steps from one supported
channel to the next. These
three values,
NumberOfTunableFrequencies,
TunableBaseFrequency and
TunableFrequencySpacing are
manipulated to determine the
available channels.
Page 12 of 22
TunedFrequency for tunable lasers (LSN This value is displayed as an
implementation: also for non- attribute of the CTP. The units
tunable lasers) indicates the will be in THZ e.g. 192.10.
current channel used for For some OCH CTPs this
transmit or receive. When the value is unrestricted until a trail
OCH is not restricted to any uses the CTP in which case the
specific frequency then the OCH of the closest transmitter
attribute will not be provided is the assumed
over the interface. channel/frequency. Sink CTPs
are an example of CTPs which
do not have their own OCH
channle/frequency[R.otp.28.p0]
The OCH trail may have
multiple channels along its
end-to-end path.[R.otp.29.p0] In
the case that another OCH
object with a TunedFrequency
also appears in the OCH Trail
the OCH trail will be able to
this take into consideration and
indicate frequency/channel for
different portions of the trail.
[CR.otp.30.p3]
The connection rules of will
validate that if a single OCH
is supported in the PTPs
being connected and if both
of the OCH have an
assigned frequency then the
frequencies must match.
This is the case of a TRP
connected to a AWG Mux.
(This may be the case
also for a Demux to a TRP if
the TRP is configured to a
single receive frequency.)
[R.ntl.?]
ThisLayerActive When the OCH frequency is OCH must be active for

undefined or the OCH is of the connection validation of a
client PTP of a transponder source colored port to a
then the OCH will appear as DWDM MUX.
inactive. OCH of a regenerator
or network PTP of a
transponder will always appear
as active.
Page 13 of 22
Additional OTN TP Parameters (Not in V3):
• TrailTraceExpectedRx – for FEC enabled objects this may exist.
• TrailTraceActualRx– for FEC enabled objects this may exist
• TrailTraceActualTx – for FEC enabled objects this may exist
• TrailTraceMonitor – for FEC enabled objects this may exist. This may be
enabled or disabled. If disabled the other PathTrace values are not
displayed.
• FrequencySpread
Usage (Not in V3):
• TrailTraceMonitor – for FEC enabled objects there exists a PathTrace .
This may be enabled or disabled. If disabled the other PathTrace values
are not displayed. [R.otp.43]
• TrailTraceExpectedRx , PathTraceActualRx, PathTraceActualTX- values
are displayed to the user if PathTrace is enabled. . [R.otp.44]
• TrailTraceActualTx
• TrailTraceActualRx
3.7. DSR Layer

This object is used in clients of the OCH trails. When the client technology is managed (e.g.
SDH/SONET) the DSR object is of no use for NMS. When the client of the OCH trail is not of
a technology managed by the NMS then the DSR trail is the object that comprises the client
trail. For example for a transponder that handles GbE the GbE source/sink objects are modeled
as DSR_GbE. A SNC of DSR_GBE objects is presented to the NMS from the EMS to
represent the connectivity pointers within the transponder.
Note: The OTN, in G. 709, defines a new layer, which is called ODUk (similar to VC-x in SDH).
As such ODU trails will be established over the OTN. In the future when the equipment will
manage this layer and the NMS manages this equipment then the "DSR" layer will be replaced by
sublayers to support ODUk trails.
Possible layer rates in the MTMN are:
• 50 = LR_DIGITAL_SIGNAL_RATE, Raw binary electrical signal of

unspecified rate // used for CBR transponders
• 87 = LR_DSR_Gigabit_Ethernet,
• 73 = LR_DSR_OC3_STM1,
• 76 = LR_DSR_OC48_and_STM16,
• 77 = LR_DSR_OC192_and_STM64
• 91 = LR_Line_OC768_STS768_and_MS_STM256
Relevant TP Parameters (layered Parameters)

• ServiceState – same as for OCH
• ClientType - same as for OCH
• ClientBitrate - same as for OCH
• LSNExt_SpecificClientType
• 50 = LR_DIGITAL_SIGNAL_RATE, Raw binary electrical signal of unspecified rate
Page 14 of 22
Protocol / Client Bit-rate (nnnn.ppp in OCH and DSR ClientType
LSNExt_SpecificClientType Mb/s)
Fiber Channel 2.12 Gbps BB
Fiber Channel 1.0625 Gbps BB
Fiber Channel 531Mbps BB
FDDI 100Mbps BB
FICON 1.0625 Gbps BB
ESCON 200 Mbps BB
Fast Ethernet 100 Mbps BB
SDI 270Mbps BB
Serial Digital HDTV 1.485 Gbps BB
ADC digital video 2.38 Gbps BB
ADC digital video 1.3 Gbps BB
ADC digital video 595 Mbps BB
ADC digital video 148.75 Mbps BB
User selected bit-rate 50Mbps to 2.7Gbps BB
For
• 24 = LR_Line_OC1_STS1_and_MS_STM0,
• 76 = LR_DSR_OC48_and_STM16,
• 77 = LR_DSR_OC192_and_STM64

OC1 or STM0 SDH or SONET
For
• 87 = LR_DSR_Gigabit_Ethernet

GBE 1.25 Gb/s GBE
Page 15 of 22
3.8. ProtectionGroup object
Protection on the drop side requires the association of 2 transponders for protection. The 2
transponders are connected to the client equipment through a coupler.
RS SNC /
DSR SNC
c A
o s
u s P
p o
l
ci
G
e
r at O
io
n
plitter is used on the Add side, does not require the use of 2 transponders or a protection
association. A protection group will point to 2 OCH sink PTPs. All protection switch events
will identify the Protection Group as well as the switch from and switch to TPs.
The protection group will allow the NMS to request the active PTP. The PM when available
after the protection switch will be available through the protection group object.
The PTPs on the client side (without an active OCH) of the Transponders associated for
protection will indicate the protection through the MTNM protection association PTP
attribute.
RS / DSR
SNC RS / DSR
SNC s
s p
p li
li tt
tt e
e r
r
Page 16 of 22
A coupler is connected to 2 transponder add channels on the client side and do not require
protection association / an optical protection group.

name="ProtectionGroup"; value=
// see eNI Object Naming Specification Document
string nativeEMSName Name as of this object as displayed in the EMS // see the eNI Object
Naming Specification
string userLabel Shall be identical to the nativeEMSName (Other vendors may
support different value for this and the nativeEMSName. The NMS
will use only the nativeEMSName)
string owner NULL
ProtectionGroupType_T PGT_MSP_1_PLUS_1
protectionGroupType
ProtectionSchemeState_T PSS_UNKNOWN,
protectionSchemeState PSS_AUTOMATIC,
PSS_FORCED_OR_LOCKED_OUT
reversionMode RM_NON_REVERTIVE,
RM_REVERTIVE
transmissionParameters::LayerRate_T LR_Optical_Channel
LR_Optical_Transmission_Section (e.g. see OMSP)
globaldefs::NamingAttributesList_T 2 PTPs containing the OCH endpoints of the standby and protected
pgpTPList transponder units.
globaldefs::NVSList_T pgpParameters "wtrTime" - Wait To Restore time, in seconds. "-1" may be used to
indicate an unknown value or when this parameter is not applicable.
"HoldOffTime" - Time duration for which the alarm condition must
persist before the switch takes place. "Unknown", "Infinite", or in
milliseconds.
Page 17 of 22
3.9. Topology Links and SNC objects
3.9.1.OTN Topology Links (e.g. OTS Trails) Built with OTS PTPs as endpoints.
3.9.2.OMS Trails
OMS Trail OMS objects as part of SNCs and for endpoints. .[R.otp.32]
Uses OTS links as server trails.

From the transponder to Mux there is no OMS trail. .[R.otp.33.p2]
3.9.3.OCH Trails
Have OCH objects as part of SNCs and for endpoints. Uses OMS trails ( and
when no OMS trail exists it uses OTS Links) as server trails. .[R.otp.34]
3.9.4.Light Path trails
1. STM-N Light Path

For SDH trails over WDM this is used instead of the SPI. Uses OCH trails as
server trails:
STM-1 Light Path

STM-4 Light Path
STM-16 Light Path
STM-64 Light Path
In the future
STM-256 Ligh Path
2. GBE Light Path

For GBE trails the cross connect (SNC) is performed with the DSR object of rate
DSR_GBE. . GBE Light Path trails use a one or more server trail of the rate
OCH. [R.otp.35]
3. Digital Signal Light Path

For 2R (unspecifed client type) trails the cross connect (SNC) is performed with the
DSR object of rate DSR. 2R trails use 1 or more server trail of the rate
OCH.[R.otp.36]
Page 18 of 22
3.9.5. TCM Trails
In OTN networks there will be TCM trails. In the initial phase of the NMS they
will not be supported.
3.9.6.Optical Supervisory Trails (OSC)

In OTN networks there will be OSC trails. In the initial phase of the NMS they
will not be supported.
3.9.7.SDH Topology Links – Virtual Links

Created when STM-N Lightpath trails form MS section connectivity.
For example, if an OCH trail is created between two TRP_SDH transponders and
these transponders are connected to SDH cards. Because the Transponder is
modeled as having RS SNCs to denote the connectivity, a MS trail section can be
created between the two SDH cards.
See the System Specification on NGM Topology Links for more detailed
information.
3.9.8.Connection rules
See the System Specification on NGM Topology Links for more detailed
information.
Page 19 of 22
4. Mapping of the eNI
The embedded software and the EMS support the following transmission objects:
• OPI objects - used for client connections. For SDH clients this is the equivalent of the
SPI object.
• SPI Objects.
• OPSn (where the capacity n>=0, n = 0 representing a non-colored port),
• OMS
• OTS
• OCH
• ODUk , OTU - not used in V3.
Required SNCs to represent cross connects and connectivity pointers

• RS SNC – for SDH transponders to express the connectivity pointer. [R.otp.37]
• DSR SNC – in GBE and 2R transponder cards for connectivity of GBE and 2R.
[R.otp.38]
• OCH SNC – for, MUX/Demux, OADM, [R.otp.39]
• OMS SNC – for inline amplifiers, OMSP cards [R.otp.40]
• ODU SNC - not in the initial phase [CR.otp.41]
The following figures are used to illustrate the mappings that are required to be performed.
M S LR = M S
R S LR = R S
O P U
O D U L R = D S R
O T U
O C H
LR = O C H
O C C
O M S L R = O M S
O T S L R = O T S
P h y s ic a l L R = P h y s ic a l O p t ic a l
IT U - T O b je c ts M T N M O b je c t s
F ig u r e 1 : IT U - T O b je c t s m a p p e d in t o M T N M L a y e r
Page 20 of 22
M S LR = M S
R S LR = R S
O P U
O D U L R = D S R
O T U
O C H
LR = O C H
O C C
O P S LR = O p t ic a l S e c t io n
P h y s ic a l L R = P h y s ic a l O p t ic a l
IT U - T O b je c ts M T N M O b je c t s
F ig u r e 1 : IT U - T O b je c t s m a p p e d in t o M T N M L a y e r
4.1. Functional Equipment Modeling
Pre-OTN SDH Transponder

SNC
CTP RS
RS
RS n=1,4,16,64
n=1,4,16,64
PTP
DSR DSR
n=1,4,16,64 n=1,4,16,64
RS
OCH
OCH OCH
(active / (active /
inactive) inactive)
OCH
Optical OPS Optical

Section Section
(1) (1)
Physical Optical Physical Optical
OPS
Pre-OTN GBE Transponder

SNC
CTP
DSR GBE DSR GBE
PTP
OCH OCH
(active / (active /
inactive) inactive)
Optical
Section Optical
(1) Section
(1)
Page 18 of 22
Pre-OTN CBR Transponder
SNC
CTP
DSR DSR
PTP
OCH OCH
(active / (active /
inactive) inactive)
Optical
Section Optical
(1) Section
(1)
DWDM Amplifier used in the OTN layer (e.g. OFA or OFA_M)

CTP
OMS OMS
SNC
PTP
OTS
OTS
Optical Amplifier used for SDH

• LOS alarms that are emitted on the OPS object are mapped to the Physical Optical
layer over the EMS-NMS interface - TBD.
• serviceState and alarmReporting TP parameters will be provided on the physical layer
- TBD.
CTP
Optical Optical
Section Section
SNC
PTP
MUX / DEMUX
Demux Mux
OCH
OCH
PO
OS
OS
PO
OCH
OCH
PO
OS
OS
PO
OCH 1 OCH 1
OCH
OCH
PO
OS
OS
PO
OCH 2 OCH 2
OMS OMS
OCH
OCH
OCH 3 OCH 3
PO
OS
OS
PO
OTS OTS
PO PO
OCH 4 OCH 4
... ...
OCH n OCH n
OCH
OCH
PO
OS
OS
PO
Page 19 of 22
OADM
• PO is a server layer to either OTS or OS layers in all of the following PTPs
• Without the extensions port there shall be only 2 C band OTS-OMS PTPs a single Src
PTP and a single Snk PTP.
• The number of OPS (in MTNM mapped to PO and OS layers) PTPs depends on the
number of ADD/DROP channels. I.e. the following is a diagram of an OADM 4 AB
with extension. It has 4 OPS Snk PTPs, and 4 OPS Src PTPs.
East West
AB (with extension)
OCH n
OMS
OTS OCH 16
OCH
32
OCH 5
OCH k (Blue) ... OCH 4

OCH
17
OMS OCH 4
OCH 1
OMS OCH OCH 3
n-4
OTS OCH
OTS OMS OMS
16 OTS ... OCH 2 OTS
(Red) OCH 3
(C) OCH 1
OCH 4 OCH 1
OCH 2
OCH 3 OCH n
OCH 1
OCH 5
OCH 2 OCH
n-4
OMS OMS
OCH 4
OCH OCH OCH OCH OTS ... OTS
OCH OCH OCH OCH
OCH 1
OCH 1 OCH 3
OPS OPS OPS OPS OPS OPS OPS OPS

OCH 2
OCH OCH OCH OCH OCH OCH OCH OCH

OCH 1
OPS OPS OPS OPS OPS OPS OPS OPS
OMSP
The following will be modelled in order to allow usage also in SDH technology and single OCH (i.e.
OPS1) links:
Pre-OTN or SDH
PO
OS PO
OS SNC Snk
PO Src Protec
Snk OS tion
OS Src
PO Group
Snk
Src
...
PO
PO
• LOS alarms that are emitted on the OPS object when mapped to PO onlyin the PTP
are mapped to the Physical Optical layer over the EMS-NMS interface.
• serviceState and alarmReporting TP parameters will be provided on the physical layer
Page 20 of 22
OPM
OMS
OTS
PO (Snk)
OMS OMS
OTS OTS
PO (Snk) PO (Snk)
...
OMS
OTS
PO (Snk)
• The OPM will support 4 OTS/OMS ports that do not contain CTPs.
SDH Colored Port (ASFC or colored SIO)

• Any colored SDH port should provide the OCH layer that contains the frequency attribute of
the laser that is connectable to a DWDM Mux.
AU4
CTP
AU4_VC4
AU4
MS TTP
PTP
MS STM
n=1,4,16, 64
MS TTP
RS TTP
RS STM n=1,4,16,
64
DSR STM
n=1,4,16, 64
RS TTP
OCH TTP
OCH (active /
inactive)
OCH TTP
OPI
Optical Section
(1)
Physical Optical
OPI
Page 21 of 22
RS / STM-N LP Trail and MS Virtual Link for SDH Layer
DSR STM-N
Link
OCH
OMS
OS OTS OTS OS
SDH NE
Colored SIO
Inline Amplifier in SDH NE
Transponder
TRP25
WDM Network Using Optical

MUX/DEMUX
End of document
Page 22 of 22
Table of Contents
1 Introduction .......................................................................................................................3
1.1 Scope.............................................................................................................................. 3
1.2 Other relevant documents .............................................................................................. 3
1.3 Document history ............................................................................................................ 3
1.4 Abbreviations, Naming Conventions ............................................................................... 3
2 eNI Specification for L2 Ethernet and MPLS Tunnel Management ..............................4
2.1 Introduction ..................................................................................................................... 4
2.2 Pointer to eNI documentation ......................................................................................... 4
2.3 Objects and Entities ........................................................................................................ 4
2.4 MPLS objects.................................................................................................................. 6
2.4.1 CTP as tunnel endpoints ............................................................................................. 6
2.4.2 Ethernet FPs contained by tunnel endpoints ............................................................... 6
2.4.3 FTP as MoT , MoE,IC-MOE, MoF or MoG endpoint .................................................... 6
2.4.4 FTP as owner of tunnel endpoints ............................................................................... 6
2.4.5 SNC used as tunnel XC ............................................................................................... 7
2.4.6 Creating and Editing Tunnel SNCs .............................................................................. 7
2.5 eNI operations ................................................................................................................ 8
2.5.1 general requirements and comments .......................................................................... 8
2.5.2 operations supported by eNI ........................................................................................ 8
2.5.3 details of FDFr creation and activation ........................................................................ 9
2.5.4 details of FDFr deactivation and deletion .................................................................. 10
2.5.5 details of FDFr modification (incl. adding & removing FPs to/from FDFr).................. 10
2.6 Attributes and Life Cycles of Objects and Entities ........................................................ 11
2.6.1 Connectionless Port Termination Point (CPTP) (Ethernet Port) ................................ 11
2.6.1.1 Life Cycle and Notifications .................................................................................... 12
2.6.1.2 Attributes................................................................................................................. 12
2.6.1.3 Additional Information ............................................................................................. 12
2.6.2 Matrix Flow Domain (MFD) (Ethernet Bridge and MPLR Label Switch) .................... 12
2.6.2.2 Attributes................................................................................................................. 12
2.6.3 Flow Domain Fragment (FDFr) .................................................................................. 13
2.6.3.2 Attributes................................................................................................................. 13
2.6.4 Flow Point (FP) .......................................................................................................... 13
2.6.4.2 Attributes................................................................................................................. 14
2.6.5 Tunnel end-point CTP ................................................................................................ 14
2.6.5.2 Attributes, Additional Information, Layered Parameters ......................................... 14
2.6.6 SNC as tunnel cross-connect .................................................................................... 14
2.6.7 MoT, MoE, IC-MOE, MoF or MoG endpoints ............................................................ 14
2.6.8 Traffic Conditioning Profile (TC Profile) – Policer Parameters ................................... 14
2.6.8.2 Attributes................................................................................................................. 15
2.6.8.4 Traffic Conditioning parameters supported when TC profiles not supported .......... 15
2.7 Naming of Objects ........................................................................................................ 15
2.8 PTP/FTP/CTP/MFD Layers .......................................................................................... 17
2.8.1 ETY Port (PTP) .......................................................................................................... 17
2.8.2 EoS Port (FTP) .......................................................................................................... 17
2.8.3 L1 ETY Port (PTP) (as in DIO) ................................................................................. 17
2.8.3.1 Old DIO ................................................................................................................... 17
eNI for Ethernet & MPLS r5.0 page 1 of 56

2.8.3.2 New DIOs ............................................................................................................... 17
2.8.4 MoT Port (FTP) .......................................................................................................... 18
2.8.5 Container of tunnel endpoints (FTP) .......................................................................... 18
2.8.6 Matrix Flow Domain (MFD) ........................................................................................ 18
2.8.7 MoE Port (PTP) ......................................................................................................... 18
2.8.8 IC-MoE/MoF Port ....................................................................................................... 19
2.8.9 MoG Port ................................................................................................................... 19
2.9 Classification of Ethernet Frames ................................................................................. 19
2.9.1 General ...................................................................................................................... 19
2.9.2 Classification using the Traffic Mapping Table .......................................................... 19
2.10 Alarms........................................................................................................................... 20
2.11 Performance Monitoring ............................................................................................... 20
2.12 Maintenance commands for tunnels ............................................................................. 20
2.12.1 Maintenance for FRR protected tunnel ...................................................................... 20
2.12.2 Maintenance for 1:1 protected tunnel ........................................................................ 21
3 Example scenario for Ethernet services ......................................................................22
4 Example of Tunnel Modeling .........................................................................................27
4.1 MoF connectivity model in the MPLS layer ................................................................... 31
4.2 MoG connectivity model ............................................................................................... 31
5 Setting Up Tunnels With Ethernet Services (Example Sequence) .............................32
6 Uploading Bypass Tunnels Before Main Tunnels .......................................................32
7 Descriptive diagrams for tunnels ..................................................................................33
8 Object modeling for MPLS tunnels ...............................................................................35
8.1 Table 1: CTP used in tunnels – TerminationPoint_T .................................................... 35
8.2 Table 2: SNC used as tunnel XC .................................................................................. 36
8.3 Table 3: FTP used as MoT/MoE/IC-MoE/MoF/MoG endpoints .................................... 37
9 Traffic Mapping Tables...................................................................................................39
10 Performance Monitoring Counters ...............................................................................42
11 Layering Diagram for Ethernet over SDH/SONET .......................................................50
12 Layering Diagram for MPLS Tunnels and Ethernet over MPLS .................................51
13 Example of MS-PW .........................................................................................................56

1 Introduction
1.1 Scope
This document specifies the interface between LightSoft and EMS (EMS-XDM and EMS-BGF) for
Layer 2 Ethernet Topology Management, Ethernet Service Management, MPLS Tunnel
Management, Ethernet-over-MPLS Management, and MPLS-over-Ethernet management.
This specification extends the eNI specification, and is based on MTNM v3.5 of the TM Forum.
1.2 Other relevant documents

[1] MCS Ethernet Services EMS-NE Requirements SRQ, Mishael Wexler
Since the links keep changing, there is no attempt to provide it here.
[2] MCS Switch and Port Management SRQ, Mishael Wexler
[3] eNI Documentation Suite, based on TMForum MTNM specification
http://nsd/RND/Management/MSIS%20Documents/eNI/eNI%203.5%20Documenation%20Suite.html
[4] Data Cards – General Information, Rony Pikarski, Rotem Cohen
[5] NMS Tunnel Management, Shell Nakash
[6] MPLS XC Management, Shell Nakash
[7] Dual FRR Updates (NMS), Shell Nakash
[8] SD1-16E_LayeredParameters_in_ECI_environment
See the MTNM/eNI Supporting Documents list in [3]
[9] LSv9 MPLS Tunnel in NPT SRQ, Ron Sdayoor
Since the links keep changing, there is no attempt to provide
[10] LSv9.1 MPLS over GRE SRQ, Ron Sdayoor
Since the links keep changing, there is no attempt to provide
[11] LSv11 DiffServ Tunnel SRQ, Ron Sdayoor
Since the links keep changing, there is no attempt to provide it here
[12] LightSoft L2 Data Services SRQ.docx, Erez Segev
Since the links keep changing, there is no attempt to provide it here
1.3 Document history

For the changes made prior to release 5.0, see release 4.8.
1.4 Abbreviations, Naming Conventions

Abbreviation Description
CAC Connection Admission Control
FP Flow Point
NPT Network Packet Transport, a XDM shelf which contains MoF links
PSI Packet Switch Interfaces
MoT MPLS over Transport
MoE MPLS over Ethernet
IC-MoE Inter card MoE
MoF MPLS over Fabric, an internal MPLS link in the shelf
MoG MPLS over GRE

MS-PW Multi Segment Pseudo Wire
GRE Generic Routing Encapsulation
FRR Fast Re-Route
2 eNI Specification for L2 Ethernet and MPLS Tunnel Management
2.1 Introduction
The ECI Northbound Interface (eNI) is the interface which connects between ECI managed EMSs
and LightSoft, and between LightSoft and an upper level management system (OSS).
This document specifies the functionality of this interface for Layer 2 Ethernet and for MPLS.
This section describes the functionality in terms of the supported Objects and Entities, their attributes
and parameters, and the communication functions performed by EMS and NMS with these functions.
Note that ECI-managed EMSs implement “Singleton” rather than “Network” Functionality. As a result,
the EMS-LightSoft interface implements only those objects and entities required for this Singleton
functionality. In particular, only Matrix Flow Domains (which represent Ethernet bridges) are
supported, instead of Flow Domains. The only Flow Domain Fragments are Matrix Flow Domain
Fragments, which are Flow Domain Fragments restricted to a single Matrix Flow Domain. In a
“Singleton” implementation, each Managed Element is its own Multi-Layer Subnetwork.
The LightSoft-OSS interface implements “Network” functionality, which presents the entire network
managed by LightSoft as a single Subnetwork and a single Flow Domain.
The DiffServ tunnel is supported .It is a special type of MPLS tunnel in which the (regular) CAC
mechanism is not utilized, but instead, the tunnel’s traffic is routed (in each SNC) via a special
queues block (DiffServ Block) available in the MPLS port. The main management functions required
are designing the capacity of each per-CoS queue in the DiffServ block and monitoring the CoS
queues (PM, utilization, average rate).
The eNI LightSoft-EMS supports MS-PW according to [12] LightSoft L2 Data Services SRQ.docx,
Erez Segev. The MS-PW is not object that managed by MTNM , but rather the configuration of FPs
that reside under tunnel EPs and provide connection points of FDFr s to the tunnels. An example of
the topologies with MS-PW is shown in the Figure 13-1 Example of topology with MS-PW.
2.2 Pointer to eNI documentation

eNI is the ECI implementation of the TMForum’s MTNM EML-NML interface specification. There are
a some differences between eNI and the official MTNM definitions. Refer to eNI documentation for
data structures, operation names, parameter and exception codes, and mapping objects and
operations to managers.
The MTNM data structures and enums are used wherever possible, even though not all fields of data
structures, and not all values of enums, are used by eNI.
See [3] for a link to the eNI Documentation Suite.
2.3 Objects and Entities

This section describes the objects and entities which are used in the interface.
MTNM Objects/Entities Other names Comment

to be supported
Managed Element (ME) Standard MTNM object for each ME.
LightSoft can retrieve a list of all managed
MTNM object MFDs (Bridges) contained in an ME.

to be supported
Matrix Flow Domain Bridge MFD is used to represent a Bridge. In the
(MFD) PE singleton mode, an FD coincides with an
MFD, and therefore we do not need to
MTNM object model FDs.
Connectionless Port Ethernet Port Special case of PTP, differentiated by the
Termination Point layered parameter “ConnectionlessPort”
(CPTP) being True. Can be either PTP or FTP,
corresponding to ETY use or EoS use. Can
MTNM entity be either UNI or NNI.
Flow Domain Fragment Matrix Flow Domain Allows the flow of traffic between Flow
(FDFr) Fragment Points. Represents a single L2 VPN in the
Flow provider network.
VSI In singleton mode, represents a single L2
VPN flow across a bridge. This coincides
with a Matrix Flow Domain Fragment, which
MTNM object is not an MTNM object.
Flow Point (FP) Special case of CTP, distinguished by being
a client of a CPTP with layer rate
LR_Ethernet. An FP is named by a CPTP,
and is associated with a FDFr. It represents
either an Ethernet Service Endpoint on an
Ethernet UNI Interface or the Registration of
the Service on an Ethernet NNI Interface.
A Flow Point always exists with respect to a
specific FDFr and cannot exist
independently of an FDFr. It is created when
an FDFr is created or when a CPTP is
MTNM entity added to an FDFr. It is deleted when the
FDFr is deleted or when its containing CPTP
is removed from an FDFr.
Traffic Conditioning Named profiles containing traffic
Profile (TC Profile) conditioning parameter values. They are
created/deleted/modified by an NMS or an
OSS, and are maintained in EMSs and
MTNM object NMS. The NMS assigns profiles to Ethernet
Service Endpoints.
Note that this is the only way in which
policers are modeled. There is no other
modeling for policers.
Traffic Mapping Table This is a table used to classify traffic. It
selects incoming frames to be sent to
different FDFrs, based on VID and/or
priority. It is also used to assign traffic
classes and traffic conditioning parameters.
It is comprised of a set of layered
MTNM entity parameters of a Flow Point, as explained in
the Layered Parameters chapter (chapter 9).

2.4 MPLS objects
2.4.1 CTP as tunnel endpoints
These CTPs are used to model In-Segments and Out-Segments.

For bypass tunnels, the CTP which is the tunnel endpoint will contain CTPs which are the connection
points for the protected tunnels. These contained CTPs are the place where preparation is made
before entering the bypass tunnel. E.g., pre-bypass label swapping happens here. At the bypass
tunnel endpoint itself, label stacking occurs.
CTPs which are tunnel endpoints will be created when the tunnel is created. Tunnel creation results
from a createAndActivateSNC operation, which will also cause the creation of the in-segments and
out-segments which are the tunnel endpoints. A CTP created this way will be contained by one of the
following: an FTP which represents an MoT, MoE,IC-MoE ,MoF or MoG endpoint, a CTP which
represents an endpoint of the tunnel which will carry the tunnel being created, an FTP whose purpose
is to be a holder of tunnel endpoints as described in section 2.4.4. The attributes/parameters of the
CTPs to be created will be specified as part of the A-End Creation List and Z-End Creation List
parameters of the createAndActivateSNC operation. The actual resulting values of the CTP
parameters are returned in the A-End and Z-End parameters.
The table of CTP attributes and parameters can be found in section 8.1. Some of the attributes listed
are not relevant to MPLS, but they appear in the table because they are found in the structures and
need to be given some value. Attributes/Parameters marked with * can be set during creation.
Attributes/Parameters which are used only for creation are so indicated. Since CTPs will be created
during the createAndActiveSNC operation, the setting of creation-time values is explained in the
comments, unless obvious or explicit in the Segment Use columns.
2.4.2 Ethernet FPs contained by tunnel endpoints
An Ethernet service (FDFr) carried by a tunnel is modeled by having the FDFr endpoint, called Flow
Point (FP), which are special cases of CTPs, be contained by the tunnel endpoint CTP, at the point
where the FDFr goes into or comes out of the tunnel. The FP is created by the EMS as a result of the
createAndActivateFDFr operation, with the tunnel endpoint CTP specified in the aEnd list of the
operation.
Note that if there are N destinations, number of tunnel endpoint CTPs specified could be Nx8x2,
meaning 8 classes of service, each with an ingress and egress side, for each destination.
2.4.3 FTP as MoT , MoE,IC-MOE, MoF or MoG endpoint
An MoT FTP is where tunnels are encapsulated/extracted to/from a transport trails. These FTPs are
very similar to the VCG objects. The layering for this FTP is presented in section 2.8.4.
An MoE FTP is where tunnels are encapsulated/extracted to/from Ethernet transport services.
An IC-MoE or MoF FTPs is where tunnels are encapsulated/extracted to/from internal connections or
fabric matrix of MPLS (e.g. MCS) cards respectively. See Figure 4-3 MoF model in the NPT shelf
A MoG FTP is where tunnels are encapsulated/extracted to/from connection over unmanaged
IP/MPLS network. See Figure 4-4 P2P MoG connectivity
2.4.4 FTP as owner of tunnel endpoints

The FTPs will be created at card-assignment, as follows: For each MoT/MoE/IC-MoE/MoF/MoG FTP
which is created at MCS (or other MPLS support) card assignment, there will be a matching FTP.
This second FTP will contain the head-end or tail-end CTPs for all of the tunnels whose transport side
go through the partner FTP. The name of this second FTP will be the same as its partner, with the
letter "T" appended. E.g., if the transport FTP is named 34, the tunnel-oriented partner will be 34T.
The layering for this FTP is presented in section 2.8.5.

2.4.5 SNC used as tunnel XC
eNI models multi-component SNCs as a list of A-End CTPs and a list of Z-End CTPs, where the lists
are of the same length. The connection between the first CTP of the A-End list and the first CTP of
the Z-End list is called the first component. The connection between the Nth CTP of the A-End list
and the Nth CTP of the Z-End list is called the Nth component. The same CTP can appear more than
once in the same End List, and in bi-directional SNCs, the same CTPs appear in both lists. In a bi-
directional SNC, the A-End CTP of one component will be the Z-End CTP of another, and vice versa.
Tunnel XCs, as defined in [6], are modeled as SNCs, of rate LR_T_MPLS, with additional parameters
as needed for MTNM MPLS and additional proprietary parameters as needed by ECI.
A FRR protected point-to-point XC tunnel is modeled as an SNC with two or more components. In the
ingress case, there will be two components, since there can be only one bypass in the ingress
direction. One component (main) connects the in-segment with the out-segment, and the other
component (protection) connects the in-segment with a CTP contained by the in-segment of the
bypass tunnel. (see chapter 7) In the egress case, one component (main) connects the in-segment
with the out-segment, and the other component(s) (protection) connect(s) the bypass tunnel(s) with
the out-segment.
A 1:1 protected point-to-point XC tunnel is modeled as a bidirectional SNC with four components: two
main components connect working in-segment with the working out-segment and vice versa and two
protection components connect protection in-segment with the protection out-segment and vice
versa.
A tunnel XC which is part of a P2MP tunnel is modeled as an SNC with several main components,
one for each subtunnel. These components with have a common in-segment, and may also have
common out-segments. A FRR protected tunnel XC component which is part of a P2MP tunnel is
actually modeled as several components, according to the number of bypass tunnels involved, as
described for protected point-to-point tunnel XCs. (see Figure 7-2) In Head and Transit SNCs, the
relation between protected and protecting components is given by the Tunnel Protector List attribute.
In a Tail SNC, whether P2P or P2MP, a Main component may have several Protection components,
so Tunnel Protector is not usable, but the relationship between a Main component and its Protection
components can be ascertained, if needed, from the endpoints of the components.
Bypass tunnels are represented by their own SNCs.The attributes and parameters for tunnel XCs
represented by SNCs are found in section 8.2. Some of the attributes listed are not relevant to MPLS,
but they appear in the table because they are found in the structures and need to be given some
value.
Attributes/Parameters marked with * can be set during creation, using the SNCCreateData_T
structure. Attributes/Parameters which are used only for creation can be so identified in the
Implementation column.
The DiffServ tunnels are represented by regular MPLS SNCs with the additional configuration( See
SNC additional info parameters, eNI Documentation Suite , REF [3]) that allows using DiffServ block
based on MFD capability(see MFD layered parameter, eNI Layered Parameters document REF [8])
The Bandwidth allocated per CoS in the DiffServ block can be retrieved or configured on the
associated MPLS port.
2.4.6 Creating and Editing Tunnel SNCs

Tunnel SNCs (including Bypass tunnel SNCs and 1:1 protected tunnel) are created using the
createAndActivateSNC operation. They are edited using the same operation, but including the "Edit
SNC Name" parameter in the Additional Creation Info field of SNCCreateData_T. The LightSoft-OSS
interface also supports the modifySNC operation for tunnels.
During creation, the tunnel endpoints are created. Therefore, the A-End List and Z-End List fields of
SNCCreateData_T contain the TPs which will be the containers of the tunnel endpoint CTPs which
are to be created. The parameters which are to be passed to the created CTPs are placed in a
TPData_T which is part of the TPDataList_T which is passed as the tpsToModify parameter of the
operation. The tpName field of the TPData_T contains the container name of the CTP to be created
(as it appears in the A-End List or Z-End List), but the parameters are for the created CTP. The actual

names and parameters of the created CTPs are returned in the A-End List and Z-End List fields of
the SubnetworkConnection_T which is returned at the end of the operation.
During editing, the A-End List and Z-End List fields of SNCCreateData_T contain both actual SNC
endpoint CTPs and containers of SNC endpoint CTPs which are to be created. The EMS needs to be
able to distinguish between them. The parameters which are to be passed to the created CTPs are
placed in a TPData_T which is part of the TPDataList_T which is passed as the tpsToModify
parameter of the operation. The tpName field of the TPData_T contains the container name of the
CTP to be created (as it appears in the A-End List or Z-End List), but the parameters are for the
created CTP. Parameters which are to be passed to the already existing SNC endpoint CTPs are
placed in a TPData_T whose tpName field contains the name of the actual SNC endpoint (as it
appears in the A-End List or Z-End List). A TPData_T whose tpName field contains the name of a
container of an existing SNC endpoint CTP contains parameters which are to be passed to the
container TP. (Note that this is the MTNM definition, but is not currently used by LightSoft.) The
actual names and parameters of all SNC endpoint CTPs, whether pre-existing or created during the
operation, are returned in the A-End List and Z-End List fields of the SubnetworkConnection_T which
is returned at the end of the operation.
Note that the convention described here is an internal ECI convention.
2.5 eNI operations

21B
The operations supported by eNI.
2.5.1 general requirements and comments

40B
• Since CPTPs and FPs are TPs, all TP operations apply to them, and the appropriate TP
operations are used to set and retrieve their information. The same is true for MoT/MoE/IC-
MoE/MoF/MoG endpoint FTPs and tunnel endpoint CTPs, which are also TPs like all other
TPs and all the operations apply.
• MTNM requires that CPTPs be assigned to MFDs, to accommodate systems where there is
flexibility in the association between ports and bridges. In addition, MTNM requires that
CPTPs be declared as edge ports or not. Since ECI does not provide for flexibility in port-
bridge association, and since in singleton mode all ports are edge, we need not support the
operations which assign CPTPs to MFDs or which set the role of a CPTP. CPTPs will be
created already associated to their MFDs, and with the fdEdge role.
• The "Retrieve" operations below retrieve all of the information belonging to the retrieved items.
• The data structures as specified in MTNM 3.5 are used, even though not all fields are relevant
in eNI.
• Raising exceptions: explained for each operation in [3].
• According to the rules of MTNM, only an operation which fails can raise an exception, and
when an operation fails, no change can have happened to the system. Therefore, if some
failures occur after the system has begun to be changed, either the system servicing the
operation must roll back to the pre-operation state, or the operation succeeds and specific
failures are returned to the caller. In most cases, the failures involve not being able to add or
remove a CPTP or FP to/from an FDFr, or not being able to change some TP parameter. In
these cases, the operation succeeds, failed TPs are returned in a list called “failedTPs”, and
TPs whose parameters could not be modified as requested are returned in a list called
“parameterProblemsTPList”.
2.5.2 operations supported by eNI

41B
The following is the list of operations supported.

The specification for each operation is found in [3].

Each operation is supported both for EMS-LS and LS-OSS, unless otherwise noted.
• getAllFlowDomains (LS-OSS only)
• modifyFlowDomain (LS-OSS only)
• getAllSupportedMFDs
• getAllAssignedCPTPs
• getAllFDFrs
• createAndActivateFDFr
• deactivateAndDeleteFDFr
• modifyFDFr (LS-OSS only)
• getFDFrRoute (LS-OSS only)
• MDFIterator
• FDFrIterator
• getAllPTPs, getAllPTPNames  retrieves also PTPs related to Ethernet and MPLS
• getTP  retrieves also TP related to Ethernet or MPLS
• getContainedInUseTPs
• setTPData
• getAllCrossConnections
• setNativeEMSName
• setUserLabel
• setOwner
• setAdditionalInfo
• getAllSubnetworkConnections
• getAllSubnetworkConnectionsWithTP
• SNCIterator
• CCiterator
• getRoute (LS-OSS only)
• getAllSNCsWithRoutes (LS-OSS only)
• LSN_SNCsWithRoutesIterator (LS-OSS only)
• getSNC
• createAndActivateSNC
• modifySNC (LS-OSS only)
• deactivateAndDeleteSNC
• checkValidSNC
• enablePMData
• disablePMData
• clearPMData
• getHistoryPMData
• getAllCurrentPMData
• PMDataIterator
• createTCProfile (LS-OSS only)
• deleteTCProfile (LS-OSS only)
• getAllTCProfiles (LS-OSS only)
• TCProfileIterator
• getMACdestinations (proprietary ECI operation) (EMS-LS only)
2.5.3 details of FDFr creation and activation

In the following description, in the EMS-LS interface, the server is the EMS and the caller is LS,
and in the LS-OSS interface, the server is LS and the caller is the OSS.
1) The server checks the syntax of the request. If the request is not valid, the "invalid input"
exception is raised.
2) The server checks the existence of the provided CPTPs. If one of the CPTPs does not exist, an
exception is raised: "Entity not found: One of the provided CPTPs does not exist".

3) If an FDFr with the same properties as specified in the request already exists, an exception is
raised: "Object in use: An FDFr with same properties already exists".
4) In the EMS-LS case, if the specified CPTPs don’t all belong to the same MFD, an exception is
raised: "TP invalid endpoint: Not all provided CPTPs belong to the same Matrix Flow Domain".
5) If the caller has provided an FDFr name and the specified name already exists in the MFD, an
exception is raised: "Object in use: The specified FDFr name already exists in the Matrix Flow
Domain".
6) If any of the mandatory input parameters cannot be satisfied, an exception is raised: "Unable to
comply: At least one of the mandatory input parameters cannot be satisfied". Mandatory
parameters are parameters which are marked “not best effort”.
7) In traffic mapping tables specified for created FPs, if there is any unrecognized information or if
there is internal inconsistency (e.g., inconsistent column lengths), an exception is raised:
"Unable to comply: Unrecognized or inconsistent mapping criteria".
8) In traffic mapping tables specified for created FPs, if table contents would result in frames being
mapped to more than one FDFr, an exception is raised: "Unable to comply: Frames map to
more than one FDFr".
9) Note that eNI allows creation of an FDFr with less than two FPs, even though standard MTNM
does not allow it.
10) If the caller provides transmission parameters for the involved CPTPs and FPs, then it is up to
the server to provision the parameters on these TPs before or after the activation of the Flow
Domain Fragment, as appropriate. All CPTPs and FPs which cannot be provisioned, or for
whom mandatory transmission parameters cannot be set, must not be added to the new FDFr
and have to be returned in the "failedTPs" list (for every FP which is not added to the FDFr, the
corresponding server CPTP has to be added to the list). CPTPs and FPs, for which only best-
effort transmissions parameters could not be set, have to be added to the new FDFr and must
be returned in the “parameterProblemsTPList” list. The alarm reporting on the CPTPs and the
containing FPs should be turned on by the server as part of this request, unless otherwise
specified via the transmission parameter "AlarmReporting".
11) If no exceptions were raised, the server initiates the activation of the FDFr, and replies with a
success indication. There may be TPs listed in the "failedTPs" list and/or the
“parameterProblemsTPList” list. The server forwards FDFr object creation notifications to the
caller. The server forwards AVC notifications for any PTPs who had attributes or parameters
modified.
2.5.4 details of FDFr deactivation and deletion

2) The server checks the existence of the specified FDFr. If it does not exist, an exception is
raised: "Entity not found". However, it is also acceptable for the server to succeed if the FDFr
which is being deleted already doesn’t exist.
3) If the FDFr cannot be deleted because of communication loss with the NE, an exception is
raised: "NE Communication Loss".
4) The FDFr and associated FPs are deleted. (VLAN IDs are unregistered at the appropriate
places.)
5) If no exceptions were raised, the server replies with a success indication. The server forwards
FP and FDFr object deletion notifications to the caller.
2.5.5 details of FDFr modification (incl. adding & removing FPs to/from FDFr)

2) The server checks the existence of the specified FDFr. If it does not exist, an exception is
raised: "Entity not found".
3) The server checks the existence of the provided TPs to be modified (not added or removed). If
one of the TPs does not exist, or is not involved in the FDFr, an exception is raised: "Entity not
found: One of the provided TPs does not exist or is not involved in the FDFr".
4) The server checks the existence of the provided CPTPs and FPs for addition or removal. If any
do not exist, an exception is raised: "Entity not found: One of the provided TPs does not exist".
5) If the CPTPs specified for removal don’t all belong to the FDFr, an exception is raised: "TP
invalid endpoint: TPs being removed do not belong to the Flow Domain Fragment".
6) If the CPTPs specified for addition don’t all belong to the same MFD as the FDFr, an exception
is raised: "TP invalid endpoint: TPs being added to not belong to the Matrix Flow Domain".
(Note that it is valid to include a CPTP which is already associated with the FDFr. No FP OCN is
issued in this case, but there may be AVCs.)
7) If any of the mandatory input parameters cannot be satisfied, an exception is raised: "Unable to
comply: At least one of the mandatory input parameters cannot be satisfied".
8) In traffic mapping tables specified for any FPs, if there is any unrecognized information or if
there is internal inconsistency (e.g., inconsistent column lengths), an exception is raised:
"Unable to comply: Unrecognized or inconsistent mapping criteria".
9) In traffic mapping tables specified for any FPs, if table contents would result in frames being
mapped to more than one FDFr, an exception is raised: "Unable to comply: Frames map to
more than one FDFr".
10) Note that eNI allows defining an FDFr with less than two FPs, even though standard MTNM
does not allow it.
11) If any of the mandatory transmission parameters of existing TPs cannot be set, an exception is
raised: "Unable to comply: At least one mandatory transmission parameter cannot be set".
12) Any new CPTP or FP which cannot be provisioned, or for whom mandatory transmission
parameters cannot be set, must not be added to the FDFr and must be returned in the
"failedTPs" list (for every FP which is not added to the FDFr, the corresponding server CPTP
has to be added to the list). New CPTPs and FPs, for which only best-effort transmissions
parameters could not be set, have to be added to the new FDFr and must be returned in the
“parameterProblemsTPList” list. Existing CPTPs and FPs, for which only best-effort
transmissions parameters could not be set, must be returned in the “parameterProblemsTPList”
list.
13) If no exceptions were raised, the server adds and removes the FPs as specified, and replies
with a success indication. There may be TPs listed in the "failedTPs" list and/or the
“parameterProblemsTPList” list.
2.6 Attributes and Life Cycles of Objects and Entities

In the following descriptions, in the EMS-LS interface, the server is the EMS and the caller is
LS, and in the LS-OSS interface, the server is LS and the caller is the OSS.
2.6.1 Connectionless Port Termination Point (CPTP) (Ethernet Port)

A Connectionless Port Termination Point (CPTP) represents a potential port capability for
connectionless technologies, i.e. the CPTP has potential client TPs which are Flow Points.
A CPTP is not an object. The term CPTP is used in this specification 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, or as an FTP object if the port is an EoS port of
the bridge terminating an SDH trail. (FTP: 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", shall identify 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 an UNI port (Network Access Port) or an
NNI port (Network Port).
A CPTP will always have Directionality set to "bidirectional".
The MTNM specification provides for the situation where there is flexibility in the association between
ports and bridges (e.g., in a card with two bridges and the card's ports can be assigned to either).
Therefore, there is a sequence specified for defining the port role of a port. Ports begin as
unassigned and are then assigned and are then declared as edge or internal. In all the Ethernet
cards currently offered, there is no flexibility is association between ports and bridges. Further, when
working in singleton mode, all ports are edge and therefore CPTPs will be created with the port role
"fdEdge".
2.6.1.1 Life Cycle and Notifications

In Ethernet cards, whose ports are pre-assigned, CPTPs are created by the EMS when the card is
assigned. In cards which require operator assignment of ports, a CPTP is created when an operator
performs the port assignment (not via eNI). The EMS notifies the NMS of the creation. If LS is
supporting a LS-OSS connection, the CPTP creation is reported to the OSS.
In Ethernet cards which allow operator unassignment of ports, CPTPs are deleted when ports are
unassigned. CPTPs representing assigned ports are deleted when their supporting card is
unassigned. The EMS notifies the NMS of the deletions. If LS is supporting a LS-OSS connection, the
CPTP deletion is reported to the OSS.
2.6.1.2 Attributes
Since a CPTP is actually a PTP, its attributes include the PTP attributes. There are many layered
parameters which are relevant to CPTPs which are not relevant to PTPs which are not CPTPs.
The value of "ConnectionlessPort" is always True (since this is what makes it a CPTP). The value of
"PortTPRoleState" is always "fdEdge".
2.6.1.3 Additional Information
2.6.2 Matrix Flow Domain (MFD) (Ethernet Bridge and MPLR Label Switch)
An MFD instance is created by the EMS when an Ethernet/MPLS card is assigned. The EMS notifies
LightSoft of the creation. If LS supports a connection to an OSS, LS notifies the OSS of the creation.
An MFD instance is deleted by the EMS when its supporting card is unassigned. The EMS notifies
LightSoft of the deletion. If LS supports a connection to an OSS, LS notifies the OSS of the deletion.
2.6.2.2 Attributes
• Common Attributes (Name, User Label, Native EMS Name, Owner, Additional Information)
These are handled as in all other objects.
• Layered Transmission Parameters see [8]
• Network Access Domain not used
• Flexible
False for bridges which have no flexibility in configuring how frames pass from port to port.
Otherwise True. (Currently, ECI does not have fixed MFDs, so it's always True.)
• TMD Profile Pointer not used
• TMD Profile State not used

None.
2.6.3 Flow Domain Fragment (FDFr)

In "singleton" mode, a Flow Domain Fragment is wholly contained within a Matrix Flow Domain. (In
non-singleton mode, an FDFr can have internal points and a “route”. In singleton mode, they cannot.)
An FDFr instance is always created by request. If the operation ends successfully, the server notifies
the caller of the creation.
An FDFr instance is deleted by request. If the operation ends successfully, the server notifies the
caller of the deletion.
2.6.3.2 Attributes
User Label will be used to hold the Service Name of the service of which this FDFr is a part.
• Layered Transmission Parameters see [8]
• aEnd TPs list of Flow Points which are connected by this FDFr; on
creation, this lists the containers of the eventual
endpoints
• zEnd TPs not used
• Direction Bidirectional
• Flexible
This is False for bridges which have no flexibility in configuring how frames pass from port to port.
Otherwise True. (Currently, ECI does not have fixed MFDs.)
• Administrative State not used (indicates if flow of frames is allowed)
• FDFr Type see the flowDomainFragment_T struct in [3]
• FDFr State see the flowDomainFragment_T struct in [3]

See FlowDomainFragment_T description in [3].
2.6.4 Flow Point (FP)

A Flow Point is not an object. The term Flow Point is used in this specification for defining the
characteristics of a CTP which is an endpoint of an FDFr. An FP is distinguished by the fact that it is a
client of a CPTP, and has layer rate "Ethernet".
Flow Points are created as CTP objects when the associated FDFr is created, and are deleted when
the associated FDFr is deleted. Flow Points are also created when CPTPs are added to an FDFr, and
are deleted when the containing CPTPs are removed from an FDFr. Flow Points do not exist without
an associated FDFr.
FPs always have Directionality set to "bi-directional".
An FP is named by the name of its associated FDFr, which is taken from its L2VPN ID. (Note that this
is proprietary to eNI. The TMF MTNM specification states that the name of an FP is taken from the IVID of the
FDFr, or an arbitrary string, prefixed with "P", if there is no IVID.)

When an FDFr is created, or when CPTPs are added to an FDFr, FPs are created. When an FDFr is
delete, or when CPTPs are removed from an FDFr, FPs are deleted. Creation and deletion
notifications do not need to be sent, since the names are known from the names of the associated
FDFrs. This is analogous to not sending notifications for connection oriented CTPs, since their names
are known from the timeslots which they represent. (Note that in TMF MTNM, notifications for FPs are
sent, because FPs are named by the IVID value of the associated FDFrs, but not all FDFrs have IVID values
and the names of those FPs are not known. However, this is not a relevant consideration in eNI.)
Attributes and parameters of FPs can be changed. Appropriate AVCs and SCs are sent.
2.6.4.2 Attributes
Since an FP is actually a CTP, the attributes are exactly the same attributes as a CTP. There are
layered parameters which are relevant to FPs which are not relevant to CTPs which are not FTPs.
See the eNI Layered Parameters document ([8]).
A most important parameter of the FP is the Traffic Mapping Table, which is comprised of several FP
layered parameters. See the Traffic Mapping Table explanation in the Layered Parameters chapter.
The use of a Traffic Mapping Table, and the expected contents of a Traffic Mapping Table when
used, depends on the Interface Type of the CPTP which contains the FP. See section 2.9.2.

See the eNI documentation for TerminationPoint_T.
2.6.5 Tunnel end-point CTP
These CTPs are used to model In-Segments and Out-Segments.

For bypass tunnels, the CTP which is the tunnel endpoint will contain CTPs which are the connection
points for the FRR protected tunnels. These contained CTPs are the place where preparation is
made before entering the bypass tunnel. E.g., pre-bypass label swapping happens here. At the
bypass tunnel endpoint itself, label stacking occurs.

CTPs which are tunnel endpoints will be created when the tunnel is created. Tunnel creation results
from a createAndActivateSNC operation, which will also cause the creation of the in-segments and
out-segments which are the tunnel endpoints. A CTP created this way will be contained by one of the
following: an FTP which represents a MoT/MoE/IC-MoE/MoE/MoG endpoint, a CTP which represents
an endpoint of the tunnel which will carry the tunnel being created, an FTP whose purpose is to be a
holder of tunnel endpoints as described in section 2.4.3. The attributes/parameters of the CTPs to be
created will be specified as part of the A-End Creation List and Z-End Creation List parameters of the
createAndActivateSNC operation. The actual resulting values of the CTP parameters are returned in
the A-End and Z-End parameters.
Attributes and parameters of CTPs can be changed. Appropriate AVCs and SCs are sent.
2.6.5.2 Attributes, Additional Information, Layered Parameters

See section 8.1.
2.6.6 SNC as tunnel cross-connect

See section 8.2
2.6.7 MoT, MoE, IC-MOE, MoF or MoG endpoints

See section 8.3
2.6.8 Traffic Conditioning Profile (TC Profile) – Policer Parameters

Traffic Conditioning Profiles are supported only in the LS-OSS interface.

A Traffic Conditioning Profile (TC Profile) object represents a collection of attributes, which are used
to define the traffic conditioning parameters (e.g., bandwidth characteristics) to be applied at the
ingress FP of a FDFr.
TC Profiles are associated to FPs via the "Traffic Mapping Table" contained in the "Layered
transmission parameters" attribute. Refer to the chapter which describes the "Traffic Mapping Table".

TC Profiles are created and deleted by an OSS or by a LightSoft operator, when LightSoft supports
GUI for this. Object Creation Notifications and Object Deletion Notifications are sent.
TC Profiles cannot be modified. Therefore, AVCs will be issued only for Common Attributes. SCs are
not expected.
2.6.8.2 Attributes
The User Label will be the field which is displayed as the name of the profile (e.g., Gold, Silver,
…)
• Layered Transmission Parameters see the eNI Layered Parameters document ([8])
• Default indicates that the TC Profile cannot be deleted

none defined
2.6.8.4 Traffic Conditioning parameters supported when TC profiles not supported

In the EMS-LS interface, the Traffic Conditioning parameters (sometimes called "policer parameters")
are passed in the Traffic Mapping Table in a special column called "TcParams". The string which is
passed, in a particular cell of the Traffic Mapping Table, is either "(CIR=nnn,CBS=mmm)" or
"(CIR=nnn,CBS=mmm,EIR=jjj,EBS=kkk)". See the chapter which describes the "Traffic Mapping
Table".
When the Policer Rate Type of the MFD, which supports an FP, is "1-rate", the CIR-CBS form of the
parameter string must be passed. When the Policer Rate Type of the MFD, which supports an FP, is
"2-rate", the CIR-CBS-EIR-EBS form of the parameter string must be passed. An operation will be
rejected by the EMS if the form of the parameter does not match the Policer Rate Type.
In the EMS-LS interface, the TC Profile column of the Traffic Mapping Table is used to pass a profile
name between the EMS and LightSoft. This is informative and does not refer to a profile managed
over the interface. There is no uniqueness or existence criteria for this name. The special profile
name "Blocking" or "NoRateLimit" is used when the TC Params string is specified as "Blocking" or
"NoRateLimit".
2.7 Naming of Objects
CPTP same as PTP or FTP

FP under EMS, …
ETY ManagedElement, …
PTP, …
CTP, /eth=Pn or CTP, /ethvid=m n = FDFr's L2VPNID, m = FDFr's SVLAN
FP under EMS, …
EoS ep ManagedElement, …
FTP, …
CTP, /eth=Pn or CTP, /ethvid=m n = FDFr's L2VPNID, m = FDFr's SVLAN

FP under EMS, …
tunnel ep ManagedElement, …
FTP, …
CTP, /tmpls=tunnelID /eth=Pn or CTP, /tmpls=tunnelID /ethvid=m
n = FDFr's L2VPNID, m = FDFr's SVLAN
MoT EMS, …
endpoint ManagedElement, …
FTP, {arbitrary number}
MoE Same as any ETY port.
endpoint
IC-MoE Same as any MoE port
endpoint
MoF Same as any MoE port.
endpoint
MoG Same as any MoE port.
endpoint
holder of EMS, …
tunnel ManagedElement, …
endpoints FTP, {same as parallel MoT endpoint , MoE,IC-MoE, MoF or MoG port, with "T" as suffix
– see section 2.4.4}
tunnel EMS, …
CTP – FTP, …
under FTP CTP, /tmpls=tunnelID
tunnel EMS, …
CTP – FTP, …
under CTP CTP, /tmpls=tunnelID1/tmpls=tunnelID2
ID1=ID of containing tunnel, ID2=ID of this tunnel
FP under EMS, …
tunnel EP– ManagedElement, …
connection PTP, …
point of a CTP, /TMPLS=<EMSTunnelID >/vpn=<n>[/label=<m>]
FDFr to a
tunnel
where n = FDFr's L2VPNID,
[/label=<m>] – optional layer which specified only when the FP is a part of the
MS-PW Path
m- VC LABEL
MFD EMS, …
ManagedElement, …
MatrixFlowDomain, {same as card which hosts the bridge}
FDFr EMS, …
FlowDomain, /ManagedElement=n/BridgeId=m n= ME's ID, m= MFD's ID
FlowDomainFragment, /vpn=n[/emsvpn=k] or FlowDomainFragment, /ethvid=m
n = FDFr's L2VPNID, m = FDFr's SVLAN
[/emsvpn=k] - optional layer which specified only for MS-PW FDFr ( i.e. the FDFr of
“FDFRT_MS_PW” type.See FDFrType_T in [3]).
k = FDFr's EMS VPN ID
TC EMS,…
Profile TCProfile, {unique name} LS-OSS only

2.8 PTP/FTP/CTP/MFD Layers
see chapter 11 for a graphic view of TP layering
2.8.1 ETY Port (PTP)

LR_Ethernet 96 eth
LR_DSR_Fast_Ethernet 97 dsr_fast_ethernet
or LR_DSR_Gigabit_Ethernet 87 dsr_Gb
or LR_DSR_10Gigabit_Ethernet 113 dsr_10Gb_ethernet
LR_Optical_Channel (only if optical port) 40
LR_OPTICAL_SECTION (only if optical port) 49
LR_PHYSICAL_ELECTRICAL 46
or LR_PHYSICAL_OPTICAL 47
2.8.2 EoS Port (FTP)

LR_Ethernet 96 eth
LR_Encapsulation 98 encapsulation
LR_Fragment 99
CTP
LR_Fragment 99
LR_STS1_and_AU3_High_Order_VC3 14 sts1_au3
or LR_ STS3c_and_AU4_VC4 15 sts3c_au4
or LR_VT2_and_TU12-VC12 11 vt2_tu12
or LR_Low_Order_TU3_VC3 13 tu3_vc3
2.8.3 L1 ETY Port (PTP) (as in DIO)
2.8.3.1 Old DIO

LR_Fragment 99
LR_DSR_Gigabit_Ethernet 87 dsr_Gb
CTP
LR_Fragment 99
2.8.3.2 New DIOs

LR_Fragment 99
LR_Ethernet 96 eth

CTP
LR_Fragment 99
2.8.4 MoT Port (FTP)

or LR_T_MPLS 309 t_mpls
"ProtocolIdentifier"=TMPLS
LR_Fragment 99
CTP (server side)
LR_Fragment 99
CTP (client side) – this is the in-segment or out-segment of a tunnel
LR_T_MPLS 309 t_mpls
2.8.5 Container of tunnel endpoints (FTP)

CTP – this is the in-segment or out-segment of a tunnel
LR_Encapsulation (Ethernet -> MPLS) 98 encapsulation
"ProtocolIdentifier"=TMPLS
CTP – this is the FP of the FDFr
LR_Ethernet (Ethernet -> MPLS) 96 eth
2.8.6 Matrix Flow Domain (MFD)

LR_Ethernet 96 eth
2.8.7 MoE Port (PTP)

LR_T_MPLS 309 t_tmpls
LR_Ethernet 96 eth
or LR_DSR_10Gigabit_Ethernet 113 dsr_10Gb_ethernet

2.8.8 IC-MoE/MoF Port
LR_Ethernet 96 eth
LR_DSR_10Gigabit_Ethernet 113 dsr_10Gb_ethernet
2.8.9 MoG Port

LR_LSNEXT_IP 32051
LR_Ethernet 96 eth
LR_DSR_10Gigabit_Ethernet 113 dsr_10Gb_ethernet
LR_OPTICAL_SECTION 49
LR_PHYSICAL_OPTICAL 47
2.9 Classification of Ethernet Frames

2.9.1 General
Classification of frames refers to deciding which frames go from an ingress port to which FDFrs, and
what handling is to be done with them.
Classification rules are expressed by the Traffic Mapping Table associated with a Flow Point. Refer to
the section giving the details of the "Traffic Mapping Table". Since a Flow Point represents the
association of a port (CPTP) with an FDFr, its Traffic Mapping Table gives the rules for classifying
and mapping frames from the FP’s containing CPTP to the FDFr associated with the FP.
The possible values of Interface Type are: “UNI”, "E-NNI", "I-NNI", “NNI”, "Unconfigured". The legal
values for a particular port depend on the card which hosts the port.
Note that the selection of frames from a port can also be affected by the value of the
"PortAcceptableFrameTypes" parameter.
2.9.2 Classification using the Traffic Mapping Table

If the VLAN ID column is not included, all VLAN IDs are selected.
If the Priority column is not included, all priorities are accepted.
If there is neither a VLAN ID column nor a Priority column, all frames are selected. The Traffic
Mapping Table can then have only one row, giving the Traffic Class and/or TC Profile (or TC Params)
to be applied to all frames.
Note that in the eNI implementation (and not according to MTNM), the Priority column is not used for
classification. Only the VLAN ID column is used for classification. The Priority column is used only for
mapping the incoming Priority to a Traffic Class.
If no Traffic Class column is included, a default Traffic Class is used. The defaults are: for UNI ports,
the default Traffic Class is 0, and for NNI ports, the priority field will be unchanged
If no TC Profile column (or TC Params column) is included, the operation which creates/modifies the
FP is rejected by the EMS. (This is proprietary eNI behavior. The MTNM behavior is that the EMS
selects a default TC Profile to use.)
If no Traffic Mapping Table is included, the operation which creates/modifies the FP is rejected by the
EMS. (This is proprietary eNI behavior. The MTNM behavior is that all frames are accepted, and the
EMS selects a default TC Profile to use.)
In I-NNI ports, a Traffic Mapping Table is needed only if the port is a Dual Homing BPDU port.

2.10 Alarms
The following is the mapping of EMS alarms to Probable Causes of MTNM . When an alarm is
reported, the EMS alarm name should be passed as the Native Probable Cause.
EMS alarm name MTNM alarm
AN Failure CFG_ABORT
Partner Offline BLOCKED_FE
Partner Link Down BLOCKED_FE
Partner AN Failure CFG_ABORT_FE
Link Down LINK_DOWN
Partial Link Down PARTIAL_LINK_DOWN
Port over quota UNIDENTIFIED
Rx Buffer Overflow Pkts RX_FAIL
OAM Discovery Failed UNIDENTIFIED
OAM Lost Link LINK_DOWN
OAM Remote Link Fault UNIDENTIFIED
OAM Local Link Event UNIDENTIFIED
OAM Remote Link Event UNIDENTIFIED
Tunnel OAM UNIDENTIFIED
Note that TCAs do not need MTNM Probable Cause names. They are sent with the name of the
counter (including Location) and with the Native Probable Cause name. See the documents in [4] for
the list of TCAs.
2.11 Performance Monitoring

PM can be collected on MFDs and FDFrs, in addition to termination points. See section 2.5.2, the
item relating to PM collection on MFDs and FDFrs.
For the list of PM counters, see Chapter 10.
2.12 Maintenance commands for tunnels

2.12.1 Maintenance for FRR protected tunnel
Two new maintenance commands are defined for tunnels: "FORCE_FRR" and "LOCKOUT_FRR".
They are put into action by the eNI "performMaintenanceOperation", and operate on the MoT
endpoint FTP. The command both performs the operation and affects the value of
LSNExt_FRR_Mode.
void maintenanceOps::MaintenanceMgr_I::performMaintenanceOperation
(in CurrentMaintenanceOperation_T maintenanceOperation,
in MaintenanceOperationMode_T maintenanceOperationMode)
Where CurrentMaintenanceOperation_T contains the TpName, the operation, the layer rate, and
additional information, and MaintenanceOperationMode_T is either MOM_OPERATE or
MOM_RELEASE. The TpName is the name of the MoT FTP where the command is to take effect.
The layer rate is LR_Ethernet. There is no additional information to provide (the additionalInfo field is
empty).
Effect of commands:
operation="FORCE_FRR", mode=MOM_OPERATE
Traffic is forced to the bypass tunnels. LSNExt_FRR_Mode is set to "ForcedSwitch".
operation="LOCKOUT_FRR", mode=MOM_OPERATE
Traffic is forced to the main tunnels. LSNExt_FRR_Mode is set to "Lockout".
operation="LOCKOUT_FRR" or "FORCE_FRR", mode=MOM_RELEASE
Traffic on all tunnels is returned to the automatic mode. LSNExt_FRR_Mode is set to "Auto".
(The "release" will take effect even if the operation specified does not match the current FRR
mode.)
The exceptions raised by the operation are the same as in previous versions of EMS and NMS.

2.12.2 Maintenance for 1:1 protected tunnel
The following maintenance commands for a bidirectional 1:1 protected tunnel are supported:
1. “Lockout” - Lockout protection path of 1:1 protected tunnel: the protection path is unavailable
for traffic.
2. “ForcedSwitch” -switches traffic to protection path of 1:1 protected tunnel.
3. “ManualSwitch” -switches traffic to protection path of 1:1 protected tunnel, unless a fault
condition exists on the protection path.
4. “Release”: An action that clears the active maintenance command.
The maintenance commands on 1:1 protected bidirectional tunnel are performed via MTNM
ProtectionMgr_I::performProtectionCommand operation. The caller (NMS) should use the MTNM
input parameters of ProtectionMgr_I::performProtectionCommand as following:
reliableSinkCtpOrGroupName –DN of the SNC for which protectionCommand was requested
in case of bidirectional tunnel
fromTp – should be ignored(be empty)
toTp - should be ignored(be empty)
The server (EMS) should return the switchData output parameter of
ProtectionMgr_I::performProtectionCommand operation which contains:
protectionType –PT_SNCP in case of in case of bidirectional tunnel
switchReason – is defined according to MTNM definition
layerRate - LR_T_MPLS in case of bidirectional tunnel
groupName - DN of the SNC for which protectionCommand was requested in case of
bidirectional tunnel
protectedTP - should be ignored (be empty)
switchToTP - should be ignored(be empty)
The exceptions raised by the operation are the same as in previous versions of EMS and NMS with
following exceptions:
EXCPT_UNABLE_TO_COMPLY is raised if the PC_EXERCISER operation were
requested for bidirectional tunnel.
EXCPT_UNABLE_TO_COMPLY is raised if the ProtectionMgr_I::performProtectionCommand
operation were performed for a unidirectional tunnel.
The caller (NMS) retrieves the maintenance operation that was applied on bidirectional tunnel by
obtaining SNC’s additional information (i.e. the LSNExt_MaintenanceCommand in additionalInfo
field)
The EXCPT_UNABLE_TO_COMPLY should be raised if the ProtectionMgr_I::retrieveSwitchData

was performed for tunnel(i.e. reliableSinkCtpOrGroupName parameter specifies DN of the MPLS
SNC)

3 Example scenario for Ethernet services
12345678 24681357 87654321
Q 4126 V
A 1066 4126 D
H 4126 L R 1066 X
B 3333 E
S 747 Y
I 36925817
75318642 1066 M 71852963

J
3333
N
C 747 F K 747
T 3333
P Z
747
G U
Rectangles represent bridges, each with bridge id displayed on top.

Open circles with letters represent ports.
Thick lines are EoS trails connecting ports of different bridges.
Colored lines with numbers are Ethernet services, each with its VLAN ID.
Solid colored small circles represent Flow Points which are created with FDFrs.
1) The NMS discovers the bridges, each with its bridge ID.
2) When the bridge ports are assigned by the NMS operator (or are pre-assigned), CPTPs are
created, each with InterfraceType set to Unconfigured, PortTpRoleState set to fdEdge, and
ConnectionlessPort set to True. Ports A, B, I, C, V, X, Y, Z are PTPs and the rest are FTPs. (Note
that FTPs were introduced in MTNM 3.0; see FTP)
3) NMS operator configures ports A, B, I, C as UNI, ports V, X, Y, Z as E-NNI, and the rest as I-NNI.
4) NMS tells the EMS to create seven TC Profiles, named Gold, Silver, Bronze, BestEffort,
GoldPlus, SilverPlus, and BronzePlus. Each is configured with appropriate traffic conditioning
values. not in EMSv7/LSv4
5) The NMS operator creates eight EoS trails between I-NNI ports: D-H, E-J, F-K, G-U, P-S, N-T,
M-R, L-Q.
6) The NMS operator creates four Ethernet services: 1066, 4126, 3333, and 747, which are to have
the following characteristics:
Each FDFr accepts customer frames from UNI ports (on the left side of the diagram), pushes
S-Tags onto the frames, moves the frames through the service, and sends them out through
the E-NNI ports (on the right side of the diagram), without stripping the S-tags. Frames that
came in from the E-NNI ports have S-Tags, which will be stripped when sent out through the
UNI ports.
1066 accepts all tagged frames from port A, and maps them to four traffic classes
4126 accepts frames with VLAN IDs between 1001 and 2000 from port B, and maps them to four
traffic classes; the frames which come from the SP via port V use different TC profiles
3333 accepts frames with VLAN IDs between 2001 and 4000 from port B, and frames with
VLAN IDs between 1001 and 4000 from port I, and maps them to two traffic classes but
with different TC profiles for different VLAN ranges; untagged frames are accepted from
port I and are given a C-TAG with VLAN ID 4000
747 accepts only untagged frames from port C, and maps them to a default traffic class
using a default TC profile
This results in the following sequence of operations which the NMS sends to the EMS. (This is for
illustration purposes, and does not claim to show all of the parameters which could be set.)
a) createAndActivateFDFr()
MFD=12345678
Endpoints={A, E}
IVID=1066

Configure TP:
Name={EMS=…, ME=…, PTP=A}
PortAcceptableFrameTypes = VlanTaggedOnly
Configure TP:
Name={EMS=…, ME=…, PTP=A, CTP=/vid=1066}
AddSTag=True
TrafficMapping_Table_Count = 4
TrafficMappingFrom_Table_Priority = 000-001,010-011,100-101,110-111
TrafficMappingTo_Table_TrafficClass = 0,1,2,3
TrafficMappingTo_Table_TCProfile = BestEffort, Bronze, Silver, Gold
LSNExt_TrafficMappingTo_Table_TCParams = (CIR=aa,CBS=bb),
(CIR=cc,CBS=dd), (CIR=ee,CBS=ff), (CIR=gg,CBS=hh)
Configure TP:
Name={EMS=…, ME=…, PTP=E, CTP=/vpn=2466}
AddSTag=False
b) createAndActivateFDFr()
MFD=36925817
Endpoints={J, M}
IVID=1066
Configure TP:
Name={EMS=…, ME=…, PTP=J, CTP=/vpn=2466}
AddSTag=False
Configure TP:
Name={EMS=…, ME=…, PTP=M, CTP=/vpn=2466}
AddSTag=False
c) createAndActivateFDFr()
MFD=87654321
Endpoints={R, X}
IVID=1066
Configure TP:
Name={EMS=…, ME=…, PTP=X}
Configure TP:
Name={EMS=…, ME=…, PTP=X, CTP=/vpn=2466 }
AddSTag=False
TrafficMappingFrom_Table_VID = 1066, 1066, 1066, 1066
TrafficMappingFrom_Table_Priority = 0,1,2,3
Configure TP:
Name={EMS=…, ME=…, PTP=R, CTP=/vpn=2466 }
AddSTag=False
d) createAndActivateFDFr()
MFD=12345678
Endpoints={B, D}
IVPN=9753
Configure TP:

Name={EMS=…, ME=…, PTP=B}
Configure TP:
Name={EMS=…, ME=…, PTP=B, CTP=/vpn=9753}
AddSTag=True
TrafficMappingFrom_Table_VID = 1001-2000,1001-2000,1001-2000,1001-2000
Configure TP:
AddSTag=False
e) createAndActivateFDFr()
MFD=24681357
Endpoints={H, L}
IVPN=9753
Configure TP:
Name={EMS=…, ME=…, PTP=H, CTP=/vpn=9753}
AddSTag=False
Configure TP:
Name={EMS=…, ME=…, PTP=L, CTP=/vpn=9753}
AddSTag=False
f) createAndActivateFDFr()
MFD=87654321
Endpoints={Q, V}
IVPN=9753
Configure TP:
Name={EMS=…, ME=…, PTP=V}
Configure TP:
Name={EMS=…, ME=…, PTP=V, CTP=/vpn=9753}
AddSTag=False
TrafficMappingFrom_Table_VID = 4126, 4126, 4126, 4126
TrafficMappingFrom_Table_Priority = 0,1,2,3
TrafficMappingTo_Table_TCProfile = BestEffort, BronzePlus, SilverPlus, GoldPlus
Configure TP:
Name={EMS=…, ME=…, PTP=Q, CTP=/vpn=9753}
AddSTag=False
g) createAndActivateFDFr()
MFD=12345678
Endpoints={B, I, E}
IVPN=86
Configure TP:

Name={EMS=…, ME=…, PTP=B}
Configure TP:
Name={EMS=…, ME=…, PTP=B, CTP=/vpn=86}
AddSTag=True
TrafficMappingTo_Table_TCProfile = Silver, SilverPlus, Gold, GoldPlus
Configure TP:
AddSTag=False
Configure TP:
Name={EMS=…, ME=…, PTP= I}
PortAcceptableFrameTypes = All
PVID = 4000
PortDefaultUserPriority = 7
Configure TP:
Name={EMS=…, ME=…, PTP= I, CTP=/vpn=86}
AddSTag=True
TrafficMappingTo_Table_TCProfile = Silver, SilverPlus, Gold, GoldPlus
h) createAndActivateFDFr()
MFD=36925817
Endpoints={J, N}
IVPN=86
Configure TP:
Name={EMS=…, ME=…, PTP=J, CTP=/vpn=86}
AddSTag=False
Configure TP:
Name={EMS=…, ME=…, PTP=N, CTP=/vpn=86}
AddSTag=False
i) createAndActivateFDFr()
MFD=71852963
Endpoints={T, Z}
IVPN=86
Configure TP:
Name={EMS=…, ME=…, PTP=Z}
Configure TP:
Name={EMS=…, ME=…, PTP=X, CTP=/vpn=86}

AddSTag=False
TrafficMappingFrom_Table_VID = 3333,3333
TrafficMappingFrom_Table_Priority = 2,3
TrafficMappingTo_Table_TCProfile = SilverPlus, GoldPlus
Configure TP:
Name={EMS=…, ME=…, PTP=T, CTP=/vpn=86}
AddSTag=False
j) createAndActivateFDFr()
MFD=12345678
Endpoints={C, F, G}
IVPN=7717
Configure TP:
Name={EMS=…, ME=…, PTP=C}
PortAcceptableFrameTypes = UntaggedOnly
Configure TP:
Name={EMS=…, ME=…, PTP=C, CTP=/vpn=7717}
AddSTag=True
Configure TP:
Name={EMS=…, ME=…, PTP=F, CTP=/vpn=7717}
AddSTag=False
Configure TP:
Name={EMS=…, ME=…, PTP= G, CTP=/vpn=7717}
AddSTag=False
k) createAndActivateFDFr()
MFD=71852963
Endpoints={U, Z}
IVPN=7717
Configure TP:
Name={EMS=…, ME=…, PTP=Z}
Configure TP:
Name={EMS=…, ME=…, PTP=Z, CTP=/vpn=7717}
AddSTag=False
TrafficMappingFrom_Table_VID = 747
Configure TP:
Name={EMS=…, ME=…, PTP=U, CTP=/vpn=7717}
AddSTag=False

4 Example of Tunnel Modeling
The following example snippet uses an example from [6], slightly augmented by me to show a shared
bypass tunnel.
Figure 4-1
Unprotected XC PE2
P6
I X O Protected XC
1
1 1 I X O 1
Bypass XC
Bypass XC
P1
I X O 2 I X O
1
Protected XC
PE1 1
1 P2
3
I X O 2
Protected XC Bypass XC Bypass XC
1
1
I X O I X O 4 I X O
P5
1
1
Bypass XC 2 Bypass XC
I X O I X O
Protected XC 2
Protected XC
1
O
2
I X O I X
3
O
3
Bypass XC Bypass XC
I X O I X O
4 4
1 PE3
Bypass XC
Bypass XC
P3 1
I X O I X O
1
Protected XC
1 2
I X O 1
Bypass XC
1
P4 Bypass XC
I X O
3 I X O
I In-Segment [Ingress I/F, Label] I Head In-Segment

O Out-Segment [Egress I/F, Label] O Tail Out-Segment
X Cross-Connect [Tunnel ID]
n m
= Pxx/FTP=left/CTP=n = Pxx/FTP=right/CTP=m

Same picture, with marked tunnels
Figure 4-2
Protected tunnels are brown, bypass tunnels are orange.

Bypass tunnel 3 protects both tunnel 1 and the "upper" subtunnel of tunnel 2.
The "upper" subtunnel of tunnel 2 is protected by bypass tunnels 3 and 4.
The "lower" subtunnel of tunnel 2 is protected by bypass tunnels 5 and 6.
Unprotected XC PE2
P6 1
I X O Protected XC
1
I X O 1
1
1 1
Bypass XC
Bypass XC 3
P1
I X O 2 I X O
1
Protected XC
PE1 1
1 P2
3
I X O 2
2
Protected XC Bypass XC Bypass XC
1
1
I X O I X O 4 I X O
1 P5 4
1
1
Bypass XC 2 Bypass XC 2
I X O I X O
Protected XC 2
Protected XC
1
O
2
I X O I
2 3
O
3
Bypass XC Bypass XC
I X O I X O
4 4 2
1 PE3
Bypass XC
Bypass XC
P3 1
I X O I X O
1
6 Protected XC
1 2
I X O 1
2
Bypass XC
1
P4 Bypass XC
I X O
3 I X O
5

FTPs and CTPs
/ME=PE1/FTP=left /ME=PE1/FTP=right /ME=PE1/FTP=bypass1 /ME=PE1/FTP=bypass2

/CTP=1 /CTP=1 /CTP=1 /CTP=1
/CTP=3 /CTP=2
/CTP=4

/CTP=3 /CTP=2
/CTP=4

/CTP=2 /CTP=1 /CTP=1
/CTP=3
/ME=P1/FTP=left /ME=P1/FTP=right
/CTP=1 /CTP=1
/CTP=1 /CTP=1
/CTP=1 /CTP=1
/CTP=1 /CTP=1
/ME=P5/FTP=left /ME=P5/FTP=right /ME=P5/FTP=bypass1 /ME=P5/FTP=bypass2
/CTP=2 /CTP=1 /CTP=1
/CTP=3
/CTP=4
/CTP=1 /CTP=1
For brevity, CTPs will be designated without the "ME", "FTP", or "CTP" part,
e.g., PE2/left/3, or P5/bypass1/1/1.
P5/bypass2/1 is (by way of example) an internal CTP which is the endpoint of the second bypass XC
in P5. It is the entrance into (exit from) this bypass tunnel for protected tunnels.
P5/bypass2/1/1 is the connection point for the first protected XC into/from the second bypass XC.

SNCs
For each SNC in this example, some of the parameters are given, to give the feel of the model
concept.
Tunnel Tunnel Path Tunnel Destination Tunnel

SNC A-End List Z-End List Protection Protector Type Role PE ID
PE1-1 PE1/left/1 PE1/right/1 Protected 2 M Head PE21
PE1/left/1 PE1/bypass1/1/1 Bypass P PE2
PE1-2 PE1/left/2 PE1/right/3 Protected 3 M Head PE22
PE1/left/2 PE1/right/3 Protected 4 M PE3 2
PE1-3 PE1/bypass1/1 PE1/right/2 Bypass M PE23
PE1-4 PE1/bypass2/1 PE1/right/4 Bypass M PE35
PE2-1 PE2/left/1 PE2/right/1 Protected M Tail PE11
PE2/bypass1/1/1 PE2/right/1 Bypass P PE1
PE2-3 PE2/left/2 PE2/bypass1/1Bypass M PE13
P1-1 P1/left/1 P1/right/1 Bypass M 3
P5-1 P5/left/1 P5/right/2 Protected 2 M Transit 2
P5/left/1 P5/bypass1/1/1 Bypass P
P5/left/1 P5/right/3 Protected 4 M
P5/left/1 P5/bypass2/1/1 Bypass P
P5-2 P5/bypass1/1 P5/right/1 Bypass M 4
P6-1 P6/left/1 P6/right/1 Unprotected M Transit 1
Note 1: Even though SNC P6-1 is part of a protected tunnel, this SNC is marked Unprotected, since it has no
protection component in this SNC.
Note 2: The Path Type of a Bypass component is marked M, because it is the main component of the Bypass
XC.

4.1 MoF connectivity model in the MPLS layer
MoF introduce new ability which allows MPLS cards to connect to each via the fabric (the NE matrix).
Each MPLS connectivity between a PSI port( i.e. PSI is an Ethernet PTP with PortType=PSI) in one
MPLS (e.g. MCS) card to a PSI port at another MPLS card over the Packet Switch is modeled as
separate MoF link. Multiple MoF endpoints on the same PSI port are modeled as separate MoF ports
assigned to the MFD (PE). See [9] ,Each MoF port has a link to parent PSI port( i.e. name of parent
PSI port)
Figure 4-3 MoF model in the NPT shelf
PE
PE1
Hidden PSI port
MoF Port Hidden L2 SW
MoF Link
L2 Switch
PE2 PE3
4.2 MoG connectivity model
MoG port allows connectivity over unmanaged L3 VPN to another MoG peer port. At the MoG output,
the MPLS-TP Packet is encapsulated by MAC of NH router, IP GRE header with IP Address of the
sending MoG port, and Destination IP which is the IP Address of the remote peer MoG port. The
IP/MPLS network is unmanaged and hidden from NMS MPLS/Ethernet layer.See [10]

Figure 4-4 P2P MoG connectivity
5 Setting Up Tunnels With Ethernet Services (Example Sequence)

This is a Singleton view. The setup is per MCS.
Assign the LER card. This will cause creation of all needed FTPs.
Create the SNCs which will serve as bypass tunnels. This also creates their endpoint CTPs.
Create the SNCs which will serve as working tunnels, connecting to transport FTPs, bypass endpoint
CTPs, and tunnel-end CTP holders, as needed. The tunnel endpoint CTPs will be created.
For each service, create an FDFr between the participating UNI port CPTPs and the endpoint CTPs
of the participating tunnels. The creation includes parameters for the FPs which will be created by this
operation, such as the Traffic Mapping Tables which specify the classification of incoming frames,
and parameters for the policers. For each FDFr endpoint specified in the creation operation, an FP
will be created.
6 Uploading Bypass Tunnels Before Main Tunnels

Since main tunnels are carried by bypass tunnels, the NMS must be able to upload all bypass tunnels
before uploading the main tunnels. In order to provide for this, three special layer rates are defined,
which are used only in the "getAllSubnetworkConnections" operations, and its derivatives, like
"getAllSubnetworkConnectionsWithTP". The three layer rates are LR_LSNEXT_TUNNEL,
LR_LSNEXT_BYPASS_TUNNEL, and LR_LSNEXT_NOT_MPLS. Specifying
LR_LSNEXT_BYPASS_TUNNEL in a "getAllSubnetworkConnections" operation will retrieve only
bypass tunnels. Specifying LR_LSNEXT_TUNNEL in a "getAllSubnetworkConnections" operation will
retrieve only main tunnels. Specifying LR_T_MPLS in a "getAllSubnetworkConnections" operation will
retrieve only all tunnels. Specifying LR_LSNEXT_NOT_TMPLS in a "getAllSubnetworkConnections"
operation will retrieve all SNCs which do not have layer rate LR_T_MPLS, i.e., all SNCs except for
main tunnels and bypass tunnels.

7 Descriptive diagrams for tunnels
Figure 7-1 P2P Tunnels protected by The pictures of tunnels are actually pieces of tunnels. These
pieces are SNCs in singleton mode and XCs in non-singleton
FTP which holds tunnel endpoint CTPs Protected SNC/XC, with main from to and protection from to .
FTP 1T
Head/Tail Tunnel 11 to PE 1 FTP 1

FTP for Transport (e.g., MoT endpoint)
PTP (ETY)
Ethernet
FDFr VCn
Head/Tail Tunnel 12 to PE 1
FDFr FTP 2
FTP 2T
Head/Tail Tunnel 13 to PE 1 Bypass Tunnel to PE 1
FP VCn
tunnel endpoint CTP

is contained in
FTP 5T
Transit Tunnel 21 to PE 2
Inverse multiplexing
FTP 3
FTP 3T
FTP 5 created but not used

Transit Tunnel 22 to PE 2
FTP 4T FTP 4
Transit Tunnel 23 to PE 2 Bypass Tunnel to PE 2

Figure 7-2 Point to Multipoint Tunnels
Protected Point to Multipoint Tunnels The pictures of tunnels are actually pieces of tunnels. These
pieces are SNCs in singleton mode and XCs in non-singleton
FTP
FTP
FTP for Transport (e.g., MoT endpoint)
Head/Tail Tunnel 11 to PE 1 & PE 3
A P2MP tunnel XC is modeled as

a multi-component SNC with a FTP
common A endpoint.
FTP
Head/Tail Tunnel 13 to PE 1 & PE 3 FTP FTP
Bypass Tunnel to PE 1
A protected P2MP tunnel XC is modeled as a

multi-component SNC with a common A Bypass Tunnel to PE 3
endpoint, in which some components protect
others. Several protected components can be
protected by the same protecting component.
FTP FTP
Transit Tunnel 21 to PE 2 & PE 4
Transit Tunnel 23 to PE 2 & PE 4


8 Object modeling for MPLS tunnels
8.1 Table 1: CTP used in tunnels – TerminationPoint_T

* = This attribute/parameter can be set when CTP created during tunnel SNC creation.
Field of struct * value Written by Comments
AVC
name * See object naming table (§ 2.7) EMS Named by tunnel FTP or by MoT/MoE/IC-MoE/MoF/MoG FTP or by
Y
bypass endpoint;
userLabel Tunnel name (User Label) of the EMS & on creation, taken from User Label of SNC
Y
containing tunnel NMS
nativeEMSname Same as User Label Y EMS
owner Owner of the containing tunnel EMS & on creation, taken from Owner of SNC
Y
NMS
ingressTrafficDescriptorName <empty> Not used in eNI
egressTrafficDescriptorName <empty> Not used in eNI
type CTP EMS
connectionState TPCS_Not_Connected, EMS on creation, set according to the Direction of the SNC and whether the
TPCS_Source_Connected, CTP is in the A-End list or the Z-End list or both
Y
TPCS_Sink_Connected,
TPCS_BI_Connected
tpMappingMode * Terminated_and_Available_for_ EMS & if not specified in the tpMappingMode field of TPData_T, in the
Mapping (tunnel termination) NMS tpsToModify list, then it is set to
Neither_Terminated_nor_Availab Y Neither_Terminated_nor_Available_for_mapping if the CTP is owned by a
le_for_mapping (tunnel MoT FTP, else it is set to Terminated_and_Available_for_Mapping
continuation)
direction D_Source (in-segment) EMS on creation, set according to the Direction of the SNC and whether the
D_Sink (out-segment) Y CTP is in the A-End list or the Z-End list or both;
D_Bidirectional (both)
transmissionParams:layer LR_T_MPLS EMS

Field of struct * value Written by Comments
AVC
transmissionParams: * Layered Parameters; contains the parameters specified for layer
transmissionParams LR_T_MPLS in CTPs in [8], and any other layered parameters which are
relevant; null if no layered parameters; on SNC creation, these are taken
--> Per parameter from the tranmissionParams field of TPData_T in tpsToModify; if the TP
Name in TPData_T is of a TP which is the container of an SNC endpoint
being created, the parameters in that TPData_T refer to the created TP,
otherwise they refer to the named TP.
tpProtectionAssociation NA EMS
edgePoint false EMS
additionalInfo * --> Per parameter See [3]: additionalInfo in TerminationPoint_T (relevant to tunnel endpoints)
8.2 Table 2: SNC used as tunnel XC

Note: A parameter whose value begins with "list of" is a list of values which is parallel to the component list. The Nth member of the list is the value for the Nth component.
* = This attribute/parameter can be set during tunnel SNC creation.
AVC
Written
Field of struct * Value(s) Comments
by
name * See object naming table (§ 2.7) EMS,
Y NMS on
creation
EMS &
userLabel Tunnel name Y
NMS
nativeEMSName Same as User Label Y EMS
EMS &
owner Owner of the tunnel Y
NMS
sncState Partial if not all of the SNC's parts could be created in the network (does not apply in
Active, Partial Y EMS
singleton mode)
direction * CD_UNI, , CD_BI Y EMS Specifies the direction of the subnetwork connection
rate * EMS,
LR_T_MPLS NMS on
creation

AVC
Written
Field of struct * Value(s) Comments
by
staticProtectionLevel EMS-LS: UNPROTECTED Always UNPROTECTED, the same as our handling for singleton SNCs in SDH
EMS &
LS-OSS: {preemptible, Y
NMS
unprotected, fully_protected}
sncType * Explicit EMS & Simple; (ADD_DROP_A, ADD_DROP_Z map be needed in future for interworking)
Y
NMS
aEnd * list of TPs list of TPs; if Explicit SNC type, there must be the same number of TPs in the A-End
list and in the Z-End list; the Nth TP in the A-End list corresponds to the Nth TP in the
Z-End list; In SubnetworkConnection_T, each TP is the actual CTP which is a source
EMS,
Y CTP of the SNC; in SNCCreateData_T, each TP is either itself a source CTP or is to
NMS
contain a source CTP which will be created by this operation, as ascertained by the
EMS; when an SNC supports several subtunnels or bidirectional tunnel, there may be
several components with the same TP-pair
zEnd * list of TPs list of TPs; if Explicit SNC type, there must be the same number of TPs in the A-End
list and in the Z-End list; the Nth TP in the A-End list corresponds to the Nth TP in the
Z-End list; In SubnetworkConnection_T, each TP is the actual CTP which is a sink
EMS,
Y CTP of the SNC; in SNCCreateData_T, each TP is either a sink CTP or is to contain a
NMS
sink CTP which will be created by this operation, as ascertained by the EMS; when an
SNC supports several subtunnels or bidirectional tunnel, there may be several
components with the same TP-pair
rerouteAllowed * NA EMS, Yes = tunnel can be rerouted by the network (below the NMS level) for recovery. (only
Y
NMS NA in LightSoft)
networkRouted * NA EMS,
NMS
additionalInfo * --> See [3]: additionalInfo in SubnetworkConnection_T (relevant to tunnels)
8.3 Table 3: FTP used as MoT/MoE/IC-MoE/MoF/MoG endpoints

* = This attribute/parameter can be changed using the setTPData operation or a specific "set" operation.
AVC
Written
Attribute/Parameter * Implementation Value(s) Comments
by
TerminationPoint_T:name or naming scheme should be similar to EoS trail
Name * Y EMS
TPData_T:tpName endpoints
EMS,
User Label * TerminationPoint_T:userLabel Y
NMS

AVC
Written
Attribute/Parameter * Implementation Value(s) Comments
by
Native EMS Name TerminationPoint_T:nativeEMSName Y EMS
Owner EMS,
* TerminationPoint_T:owner Y
NMS
Ingress Transmission TerminationPoint_T: <empty>
Descriptor ingressTrafficDescriptorName
Egress Transmission Descriptor TerminationPoint_T: <empty>
TP Type TerminationPoint_T:type PTP EMS
Connection State TerminationPoint_T: Not_Connected, EMS
ConnectionState Source_Connected,
Y
Sink_Connected,
Bi_Connected
Termination Mode TerminationPoint_T: Terminated_and_ EMS &
tpMappingMode or Available_for_ NMS
*
TPData_T: Mapping
tpMappingMode
Direction TerminationPoint_T: Source EMS
direction Sink Y
Bidirectional
Layer Rate TerminationPoint_T: LR_T_MPLS EMS
transmissionParams:layer
Transmission Parameters TerminationPoint_T: Layered Parameters; contains the parameters
transmissionParams: specified for layer LR_T_MPLS in FTPs in [8],
transmissionParams or per and any other layered parameters which are
* --> relevant
TPData_T: parameter
transmissionParams:
transmissionParams
Protection Association TerminationPoint_T: EMS
NA
tpProtectionAssociation
Edge Point TerminationPoint_T:edgePoint false EMS
Additional Info TerminationPoint_T:additionalInfo per See [3]: additionalInfo in TerminationPoint_T
-->
parameter (relevant to tunnel endpoint FTPs);

9 Traffic Mapping Tables
The Traffic Mapping Table is used to select frames coming in to an FDFr at an FP, and to specify some processing decisions for the selected
frames. A Traffic Mapping Table is expressed as a set of layered parameters belonging to the FP.
A Traffic Mapping Table is conceptually a table with up to four standard columns and as many rows as are needed to select frames for this FP.
At a particular row, there can be a cell which specifies the VLAN IDs of the frames to be selected, and another cell which specifies the User
Priorities of the frames to be selected. There can be a cell which specifies the Traffic Class that the selected cells are to be assigned to, and a
cell which specifies the Traffic Conditioning Profile which is to be applied to the selected frames. Additional proprietary columns can be added,
as needed and agreed between cooperating systems. In eNI, three proprietary columns are used, as explained below.
Valid values of VLAN ID include a single value, a range (xxxx-yyyy), "all", "allOthers", and "untagged".
Valid values of Priority include a single value, a parenthesized list of single values separated by comma, a range (x-y), "all", and "allOthers".
(Note: "allOthers" is currently not supported in ECI.)
Valid values of Traffic Class include a single value between 0 and 7, “default” or empty (same as “default”), and "discard". The last choice,
"discard", is an eNI proprietary value. It is added to give the possibility to explicitly specify that a certain selection of frames (which can include
all frames) should be discarded. (When the NMS sets the value of Traffic Class to "discard", it shall also set the values of TCParams and
TCProfile to "discard" in the same row of the Traffic Mapping Table.)
A Flow Point (FP) is the endpoint of an FDFr associated with a particular port (PTP or FTP). All the frames which are selected by a Traffic
Mapping Table at an FP are sent from the port to the FDFr who owns this FP. It is an error to have two FPs, associated with the same port,
which select the same frames. Any frames which are not selected by any of a port's FPs are dropped.
It is an error to have selection criteria such that a frame would be selected by more than one row of the table.
It is an error to have a mismatch between the value of TrafficMapping_Table_Count and the length of any column.
The three proprietary eNI columns are: TC Params, Egress Priority, and Egree Traffic Class. The corresponding layered parameters are:
"LSNExt_TrafficMappingTo_Table_TcParams", "LSNExt_TrafficMappingTo_Table_Priority", and
"LSNExt_TrafficMappingFrom_Table_TrafficClass".
The TC Params column will be used until TC Profiles are supported, in addition to the TcProfile column. It is used to pass the actional traffic
conditioning parameters. The TC Profile column will just be used to pass the name of a profile which is not managed. (It can also be "Blocking"
or "NoRateLimit", as explained below.) The TC Params column contains a string, which is usually of the form
"(CIR=cccc,CBS=bbbb,EIR=eeee,EBS=eeee)" and can also be of the form "(CIR=cccc,CBS=bbbb)" when EIS and EBS are not relevant. The
string will be "Blocking" or "NoRateLimit" when the policing mode is Blocking or NRL. When the value of TCParams is "Blocking", the value of
TCProfile, in the same row, shall also be "Blocking". When the value of TCParams is "NoRateLimit", the value of TCProfile, in the same row,
shall also be "NoRateLimit". When the value of Traffic Class is "discard", the values of TCParams and TCProfile will also be "discard".
In I-NNI ports, a Traffic Mapping Table is needed only if the port is a Dual Homing BPDU port.

Egress Priority and Egress Traffic Class are used to map Traffic Class to Priority in the egress direction at a flow point. The valid values of
Egress Priority and Egress Traffic Class are the same as for Traffic Class and Priority, respectively. (Note the reversal!)
Here is an example of a Traffic Mapping Table. The left-hand columns are the selection criteria, and the right-hand columns are the assignment
results.
VLAN ID Priority Traffic Class TC Profile
1-1000 0-1 0 wood
Note that this example is according to the MTNM definition.
1-1000 2-3 1 tin In ECI usage, there is no connection between the VLAN ID column
1-1000 4-5 2 zinc and the other columns, and therefore, the same priority cannot
1-1000 6-7 3 plastic appear in more than one row.
1001-2000 0-2 0 best-effort
1001-2000 3-7 1 silver
2001-3600 0 0 best-effort
2001-3600 1-6 2 gold
2001-3600 7 3 platinum
All frames whose VID (in the outermost header) has a value between 1 and 1000, and whose priority field (in the outermost header) is 000 or
001, will be sent to the FDFr whose FP owns this table, will be assigned to Traffic Class 0, and will be assigned the TC Profile "wood".
"All" is a valid value in the Priority column. "All", "AllOthers", and "Untagged" are valid values in the VLAN ID column. (“AllOthers” will act like
“All” when no other VLAN Ids are specified anywhere relevant to this table.)
This table would be implemented, by layered parameters of the FP, as follows:
TrafficMappingFrom_Table_VID = 1-1000,1-1000,1-1000,1-1000,1001-2000,1001-2000,2001-3600,2001-3600,2001-3600
TrafficMappingFrom_Table_Priority = 0-1,2-3,4-5,6-7,0-2,3-7,0,1-6,7
TrafficMappingTo_Table_TrafficClass = 0,1,2,3,0,1,0,2,3
TrafficMappingTo_Table_TCProfile = "wood", "tin", "zinc", "plastic", "best-effort", "silver", "best-effort", "gold", "platinum"
Note: Until TC Profiles management is supported, an additional line will be passed, for example:
LSNExt_TrafficMappingTo_Table_TCParams = (CIR=1000,CBS=1500,EIS=2000,EBS=2500), (CIR=5000,CBS=6400),etc.
Another Note: If Egress columns are used, they might look like this (not connected to the above example):
LSNExt_TrafficMappingFrom_Table_TrafficClass = 0-1,2-3,4,5-7
LSNExt_TrafficMappingTo_Table_Priority = 0,2,4,7
MSTI Table Example
The MSTI Table, below, will be encoded as follows:
MSTI_Table_Count = "3"

MSTI_Table_ID = “1,2,3”
MSTI_Table_BridgePriority = “<Bpriority #1>,< Bpriority #2>,< Bpriority #3>”
MSTI_Table_PathCost = “<Pcost #1>,< Pcost #2>,<Pcost #3>”
MSTI_Table_PortPriority = “<Ppriority #1>,<Ppriority #2>,< Ppriority #3>”
MSTI_Table_RootPort = “<Droot #1>,<Droot #2>,<Droot #3>”
ID Bridge Priority Path Cost Port Priority Root Port
1 <Bpriority #1> <Pcost #1> <Ppriority #1> <Droot #1>
VID to MSTI Table Example

The VID_to_MSTI Table is a two column table in which the first column is an MSTI ID and the second column is a VLAN ID, or a range of VLAN
IDs, or "AllOthers". If multiple VLAN IDs map to the same MSTI ID, but the list of VLAN IDs cannot be expressed as a single range, each VLAN
ID or range will appear in a different row, and each of these rows will have the same value for MSTI ID.
The VID to MSTI Table, below, will be encoded as follows:
VID_to_MSTI_Table_Count = "7"
VID_to_MSTI_Table_VID = "1,2,3,2,5,3,5"
VID_to_MSTI_Table_Count = "1-1000,1001-2000,2001-3000,3001-4000,4001-4150,4151,4152-4094"
MSTI ID VLAN Ids

1 1-1000
2 1001-2000
3 2001-3000
2 3001-4000
5 4001-4150
3 4151
5 4152-4094

10 Performance Monitoring Counters
This list gives the performance monitoring counters to be reported from the EMS to the NMS.
Each line in the list gives the XDM counter name, the MTNM counter name, and the MTNM location.
ETH PM Counters reported on Ethernet ports (PTPs, FTPs)
c1024_1518Octets PMP_PKTS1024TO1518OCTETS PML_NEAR_END_Rx
c1519_MxFrameSizeOctets PMP_PKTS1519TOMAXOCTETS PML_NEAR_END_Rx
c64Octets PMP_PKTS64OCTETS PML_NEAR_END_Rx
DuplicateMacAlrtSec LSNEXT_DUPLICATE_MAC PML_NEAR_END_Tx
IfOutWredPercent LSNEXT_WRED_PRCNT PML_NEAR_END_Tx
IfPortDropOctetsCosPercent0 LSNEXT_PORT_DROP_OCTETS_PRCNT0 PML_NEAR_END_Tx
IfPortDropPktsCos0 LSNEXT_PORT_DROP_PKTS0 PML_NEAR_END_Tx
IfPortPassedOctetsCos0 LSNEXT_PORT_OCTETS0 PML_NEAR_END_Tx
IfPortPassedPktsCos0 LSNEXT_PORT_PKTS0 PML_NEAR_END_Tx

LinkDownSeconds PMP_LOLS PML_NEAR_END_Rx
PHYErrors LSNEXT_PHY_ERRORS PML_NEAR_END_Rx
PortForwardTrans LSNEXT_STP_FWD_TRANSITIONS PML_NEAR_END_Tx
PrioRandDropOctets0 LSNEXT_PRIO0_RAND_DROP_OCTETS PML_NEAR_END_Tx
Prio0StatsPkts PMP_PRIO_PKTS0 PML_NEAR_END_Tx
RxHdrErrPkt LSNEXT_HDR_ERR_PKTS PML_NEAR_END_Rx
RxOctetsBad LSNEXT_ERROR_OCTETS PML_NEAR_END_Rx
RxPauseFrame PMP_PAUSEFR PML_NEAR_END_Rx
StatsBadPkts PMP_ERRORS PML_NEAR_END_Rx
StatsConfBroadcastPkts PMP_BROADCASTPKTS PML_NEAR_END_Rx
StatsConfMulticastPkts PMP_MULTICASTPKTS PML_NEAR_END_Rx
StatsCrcAlignErrors PMP_AE PML_NEAR_END_Rx
StatsFragmentsPkts PMP_SFRAGS PML_NEAR_END_Rx
StatsJabbersPkts PMP_SJABBERS PML_NEAR_END_Rx
StatsOctets PMP_OCTETS PML_NEAR_END_Rx
StatsOversizePkts PMP_FTLE (note: changed in MTNM3.5) PML_NEAR_END_Rx
StatsPkts PMP_FRAMES PML_NEAR_END_Rx
StatsUndersizePkts PMP_SUPKTS PML_NEAR_END_Rx
TxAverageOctetsRate LSNEXT_OCTET_RATE_AVG PML_NEAR_END_Tx
TxDropTimeoutOctets LSNEXT_DROP_TIMEOUT_OCTETS PML_NEAR_END_Tx
TxDropTimeoutPackets LSNEXT_DROP_TIMEOUT_PKTS PML_NEAR_END_Tx
TxOctets PMP_OCTETS PML_NEAR_END_Tx
TxPeakOctetsRateTimeStamp LSNEXT_OCTET_RATE_PK_TIME PML_NEAR_END_Tx
TxPktsOK PMP_FRAMES PML_NEAR_END_Tx
TxUtilization LSNEXT_UTILIZATION PML_NEAR_END_Tx
VlanPortInOctetsDiscard LSNEXT_VID_DISCARD_OCTETS PML_NEAR_END_Rx
IgmpRxNoErrorPackets LSNEXT_IGMP_FRAMES PML_NEAR_END_Rx
IgmpHeaderMcSrcAddrError LSNEXT_IGMP_MC_SRC_ADDR_ERRORS PML_NEAR_END_Rx
IgmpIpFragments LSNEXT_IGMP_IP_FRAGMENTS PML_NEAR_END_Rx
IgmpHeaderTypeError LSNEXT_IGMP_HDR_TYPE_ERRORS PML_NEAR_END_Rx

IgmpAddrNotInMcStreamRange LSNEXT_IGMP_ADDR_OUTOFRANGE PML_NEAR_END_Rx
IgmpAddrToMacAmbiguity LSNEXT_IGMP_GRP_ADDR_AMBIG PML_NEAR_END_Rx
IgmpHostQueueOverflow LSNEXT_IGMP_HOST_QUEUE_OVERFLOW PML_NEAR_END_Rx
IgmpQueriesAtAccessPort LSNEXT_IGMP_ACCESS_PORT_FRAMES PML_NEAR_END_Rx
IgmpOtherDiscards LSNEXT_IGMP_OTHER_DISCARDS PML_NEAR_END_Rx
VCG SINK PM Counters reported on VCG objects

Pcs LSNEXT_PCS PML_NEAR_END_Rx
Uas PMP_UAS PML_NEAR_END_Rx
Utl LSNEXT_UTILIZATION PML_NEAR_END_Rx
POLICER PM Counters reported on service endpoints (CTPs which are FPs of FDFrs)
<cos> is an integer between 0 and 7, the CoS of the policer
DropOctets LSNExt_ingressDropOctetCount<cos> PML_NEAR_END_Rx
ActOctets LSNExt_ingressOctetCount<cos> PML_NEAR_END_Rx
DropPkts LSNExt_ingressDropFrameCount<cos> PML_NEAR_END_Rx
ActPkts LSNExt_ingressFrameCount<cos> PML_NEAR_END_Rx
GreenOctets PMP_ingressGreenOctetCount<cos> PML_NEAR_END_Rx
YellowOctets PMP_ingressYellowOctetCount<cos> PML_NEAR_END_Rx
GreenPkts PMP_ingressGreenFrameCount<cos> PML_NEAR_END_Rx
YellowPkts PMP_ingressYellowFrameCount<cos> PML_NEAR_END_Rx
ConfOctetRate LSNExt_ingressConfOctetRate<cos> PML_NEAR_END_Rx
CirUtilization LSNExt_ingressCirUtilization<cos> PML_NEAR_END_Rx
PerCentNonConforming LSNExt_ingressNonconfOctetPrcnt<cos> PML_NEAR_END_Rx
SWITCH PM Counters reported on MFD objects

StpTopChanges
LoClsDiscardPkts LSNEXT_LOW_PRIO_DISCARD PML_NEAR_END_Rx
ForwardedPkts PMP_FRAMES PML_NEAR_END_Tx
LoClsDiscardPercentPkts LSNEXT_LOW_PRIO_DISCARD_PRCNT PML_NEAR_END_Rx
FdbFull LSNEXT_FDB_FULL PML_NEAR_END_Rx
FibUtilization LSNEXT_FIB_UTILIZATION PML_NEAR_END_Rx
FibQuotaUtilization LSNEXT_FIB_QUOTA_UTILIZATION PML_NEAR_END_Rx
VSI PM Counters reported on FDFr objects

McVpnOctets LSNEXT_VID_OCTETS PML_NEAR_END_Rx
McVpnOctetsDropped LSNEXT_VID_OCTET_DISCARDS PML_NEAR_END_Rx
McVpnPacketsDropped LSNEXT_VID_FRAME_DISCARDS PML_NEAR_END_Rx
McVpnAverageRate LSNEXT_VID_AVERAGE_RATE PML_NEAR_END_Rx

McVpnUtilization LSNEXT_VID_UTILIZATION PML_NEAR_END_Rx
QuotaDroppedPkts LSNEXT_QUOTA_DISCARDS PML_NEAR_END_Rx
TxPassPackets per CoS PMP_FRAMES0 PML_NEAR_END_Tx
PMP_FRAMES1 PML_NEAR_END_Tx
TxPassOctets per CoS PMP_OCTETS0 PML_NEAR_END_Tx
PMP_OCTETS1 PML_NEAR_END_Tx
TxWredDropPackets per CoS PMP_DISCARDS0 PML_NEAR_END_Tx
PMP_DISCARDS1 PML_NEAR_END_Tx
TxWredDropOctets per CoS LSNEXT_OCTET_DISCARDS0 PML_NEAR_END_Tx
LSNEXT_OCTET_DISCARDS1 PML_NEAR_END_Tx
TxAverageOctetsRate per CoS LSNEXT_OCTET_RATE_AVG0 PML_NEAR_END_Tx
LSNEXT_OCTET_RATE_AVG1 PML_NEAR_END_Tx

TxFlowUti per CoS LSNEXT_UTILIZATION0 PML_NEAR_END_Tx
LSNEXT_UTILIZATION1 PML_NEAR_END_Tx
TxDropPercent per CoS LSNEXT_DISCARD_PRCNT0 PML_NEAR_END_Tx
LSNEXT_DISCARD_PRCNT1 PML_NEAR_END_Tx
MacMove LSNEXT_MACMOVE PML_NEAR_END_Rx
GFP and HDLC PM Counters reported on Encapsulation layer

RxValidCDF PMP_FRAMES PML_NEAR_END_RX
RxByte PMP_OCTETS PML_NEAR_END_RX
TxCDF PMP_FRAMES PML_NEAR_END_TX
TxByte PMP_OCTETS PML_NEAR_END_TX
DiscardedFrames PMP_DISCARDS PML_NEAR_END_TX
FcsErr PMP_FCSE PML_NEAR_END_RX
TxFifoDroppedFrames PMP_FIFO_DISCARDS PML_NEAR_END_TX
RxtHecMultipleErrors PMP_ERRORS PML_NEAR_END_RX
MPLS counters and TCAs

The following maps the counters and TCAs specified in [6] to MTNM names.
PerfLspInPackets PMP_FRAMES PML_NEAR_END_RX
PerfLspInOctets PMP_OCTETS PML_NEAR_END_RX
PerfLspInAverageRateBitsSec LSNEXT_AVERAGE_RATE PML_NEAR_END_RX
PerfLspInUtilization LSNEXT_UTILIZATION PML_NEAR_END_RX
TunnelDownSec PMP_LOLS PML_NEAR_END_RX
TunnelDownSecRatioPpm LSNEXT_DOWN_RATIO_PPM PML_NEAR_END_RX
PerfLspOutPackets PMP_FRAMES PML_NEAR_END_TX
PerfLspOutOctets PMP_OCTETS PML_NEAR_END_TX
PerfLspOutWredPackets PMP_DISCARDS PML_NEAR_END_TX

PerfLspOutWredOctets LSNEXT_DISCARD_OCTETS PML_NEAR_END_TX
PerfLspOutAverageRateBitsSec LSNEXT_AVERAGE_RATE PML_NEAR_END_TX
PerfLspOutUtilization LSNEXT_UTILIZATION PML_NEAR_END_TX
PerfLspOutWredRatioPpm LSNEXT_DISCARD_RATIO_PPM PML_NEAR_END_TX
TCA is defined for the following counter: LSNEXT_DISCARD_PRCNT PML_NEAR_END_TX
The following maps the counters specified in [2] to MTNM names.

InLabelLookupFailures LSNEXT_LABEL_LOOKUP_FAIL PML_NEAR_END_RX
IfHdrErrPackets PMP_ERRORS PML_NEAR_END_RX
TTLZeroPackets PMP_DISCARDS PML_NEAR_END_RX
The following maps these TE performance counters and TCAs, specified in [5], to MTNM names. They are defined on MoT endpoint FTPs
(except for one defined on MFDs, as noted). TE performance counters which begin with "CoS" represent sets of eight counters, one for each
Class of Service.
PortTxPackets PMP_FRAMES PML_NEAR_END_TX
PortTxOctets PMP_OCTETS PML_NEAR_END_TX
PortTxWredPackets LSNEXT_PORT_DROP_OCTETS PML_NEAR_END_TX
PortTxWredOctets LSNEXT_PORT_DROP_PKTS PML_NEAR_END_TX
PortTxAverageRateBitsSec LSNEXT_OCTET_RATE_AVG PML_NEAR_END_TX
PortTxWredRatioPpm LSNEXT_PORT_WRED_RATIO PML_NEAR_END_TX
PortRxPackets PMP_FRAMES PML_NEAR_END_RX
PortRxOctets PMP_OCTETS PML_NEAR_END_RX
PortTxUtilization LSNEXT_UTILIZATION PML_NEAR_END_TX
CoSTxPackets LSNEXT_PORT_PKTS0 PML_NEAR_END_TX
LSNEXT_PORT_PKTS1 PML_NEAR_END_TX
CoSTxOctets LSNEXT_PORT_OCTETS0 PML_NEAR_END_TX
LSNEXT_PORT_OCTETS1 PML_NEAR_END_TX
CoSTxWredPackets LSNEXT_PORT_DROP_PKTS0 PML_NEAR_END_TX

LSNEXT_PORT_DROP_PKTS1 PML_NEAR_END_TX
CoSTxWredOctets LSNEXT_PORT_DROP_OCTETS0 PML_NEAR_END_TX
LSNEXT_PORT_DROP_OCTETS1 PML_NEAR_END_TX
CoSTxAverageRateBitsSec LSNEXT_OCTET_RATE_AVG0 PML_NEAR_END_TX
LSNEXT_OCTET_RATE_AVG1 PML_NEAR_END_TX
CoSTxWredRatioPpm LSNEXT_WRED_RATIO0 PML_NEAR_END_TX
LSNEXT_WRED_RATIO1 PML_NEAR_END_TX
CoSTxUtilization LSNEXT_UTILIZATION0 PML_NEAR_END_TX
LSNEXT_UTILIZATION1 PML_NEAR_END_TX
PortRxHdrErrPackets LSNEXT_HDR_ERR_PKTS PML_NEAR_END_RX
LowCosRxDiscardPackets (MFD counter)LSNEXT_LOW_PRIO_DISCARD PML_NEAR_END_RX

TCAs are defined for the following counters:
LSNEXT_PORT_WRED_RATIO PML_NEAR_END_TX

11 Layering Diagram for Ethernet over SDH/SONET

12 Layering Diagram for MPLS Tunnels and Ethernet over MPLS

CTP (FP) Mapping ETH to & from MPLS tunnel end
LR_Ethernet
CTP (FP) For Ingress, flow is left to right. For Egress, right to left.
LR_Ethernet FDFr
4095 J J = number of flows in tunnel

K = number of tunnels
L = number of tunnels in MoT
PTP (CPTP) M = number of VCs in MoT
CTP
LR_Ethernet LR_Encapsulation
LR_T_MPLS - InSegment for ETH to MPLS direction

LR_DSR - OutSegment for MPLS to ETH direction
_xxx_Ethernet
LR_Physical… CTP
LR_T_MPLS - OutSegment for ETH to MPLS dir
K - InSegment for MPLS to ETH dir
Tunnel
FTP XC FTP
L
xxx = Fast LR_T_MPLS Holder for tunnel LR_T_MPLS
endpoint CTPs LR_Encapsulation
Gigabit
(with T suffix) LR_Fragment (adaptation)
CTP (LO)
CTP LR_vc…
LR_Fragment CTP (HO)
MoT (termination)
endpoint M LR_vc…
LR_…
PTP
Note that using ETY here is VC XC
for example only. EoS can N
appear here instead. LR_Line…
LR_Section…
ETH LSR trans-
bridge switch port LR_DSR…
matrix
ETH --> Tunnel LR_Physical…
ETY ETH <-- Tunnel MoT

Transit MPLS XC
CTP CTP
LR_ T_MPLS LR_T_MPLS
FTP tunnel
XC FTP
LR_T_MPLS L L
LR_T_MPLS
LR_Encapsulation LR_Encapsulation
LR_Fragment (adaptation) LR_Fragment (adaptation)
CTP CTP
LR_Fragment (termination) LR_Fragment (termination)
LR_vc…
LR_vc… VCG VCG M
CTP M
LR_vc…
XC VCn VCn XC
PTP
N N
LR_Line…
LR_Section…
LR_DSR… trans- L = number of tunnels in MoT LSR trans-

port M = number of VCs in MoT switch port
LR_Physical…
matrix N = STM level matrix

Protected Tunnels
Protection at head-end and tail-end
CTP (FP)
LR_Ethernet
J
CTP
Normally the upper XC is used. In case of failure, the
LR_Encapsulation lower XC is used, which may result in same preparation for
using the bypass tunnel (e.g., swap labels), and then entry
to the bypass tunnel, which involves label stacking.
LR_T_MPLS
CTP
K LR_T_MPLS
CTP FTP
FTP
LR_T_MPLS – preparation for bypass L LR_T_MPLS
LR_T_MPLS
tunnel J LR_Encapsulation
Holder for tunnel CTP
XC LR_Fragment (adaptation)
endpoint CTPs LR_T_MPLS - bypass tunnel
(with T suffix) CTP (LO)
CTP LR_vc…
CTP
K LR_Fragment
LR_T_MPLS MoT CTP (HO)
tunnel (termination)
FTP XC endpoint M
LR_…
LR_vc…
L FTP
Many protected LR_T_MPLS
LR_T_MPLS
tunnels can be Holder for tunnel
LR_Encapsulation
carried by the same endpoint CTPs
LR_Fragment (adaptation) PTP
bypass tunnel. (with T suffix) VC XC
N
LR_Line…
CTP trans-
MoT
LR_Fragment port LR_Section…
LSR endpoint
M (termination)
matrix
LR_…
switch LR_DSR…
LR_Physical…
VC XC

Protected Tunnels
Protection at head-end and tail-end
Many protected
tunnels can be
carried by the same
bypass tunnel.
Normally the upper XC is used. In case of failure, the
lower XC is used, which may result in same preparation for
using the bypass tunnel (e.g., swap labels), and then entry
to the bypass tunnel, which involves label stacking.
CTP
LR_T_MPLS
CTP
LR_T_MPLS
FTP
CTP FTP
LR_T_MPLS LR_T_MPLS – preparation for bypass L LR_T_MPLS
tunnel J LR_Encapsulation
LR_Encapsulation XC CTP LR_Fragment (adaptation)
LR_Fragment LR_T_MPLS - bypass tunnel
(adaptation) CTP (LO)
CTP LR_vc…
CTP
K
MoT LR_T_MPLS MoT
LR_Fragment CTP (HO)
tunnel
endpoint FTP XC endpoint M (termination)
LR_vc…
FTP LR_…
LR_T_MPLS L
LR_T_MPLS
Holder for tunnel
LR_Encapsulation
endpoint CTPs
LR_Fragment (adaptation) PTP
VC (with T suffix) VC XC
N
LR_Line…
CTP trans-
MoT
LR_Fragment port LR_Section…
LSR endpoint
M (termination)
matrix
LR_…
switch LR_DSR…
LR_Physical…
VC XC

13 Example of MS-PW
Figure 13-1 Example of topology with MS-PW

ECI Northbound Interface (eNI)
Session Establishment
References
[1] eNM Northbound Interface v2.0, based on TMF814, available at

[2] TM Forum 513 v2.0, TM Forum Business Agreement: NML-EML Interface for Management of
SONET/SDH/WDM/ATM Transport Networks.
[3]TM Forum 608 v2.0, TM Forum Information Agreement: NML-EML Interface for Management of
SONET/SDH/WDM/ATM Transport Networks.
[4] TM Forum 814 v2.0, TM Forum Solution Set: NML-EML Interface for Management of
SONET/SDH/WDM/ATM Transport Networks.]
[5] TM Forum 814A v2.0, TM FORUM Implementation Statement (IS) Template and Guidelines
NML-EML Interface For Management of SONET/SDH/WDM/ATM Transport Networks
CORBA Naming Service Usage
• The EMS is only required to register with the Naming Service

• The Naming Service is persistent
• A Naming Service is required only on the NMS
• The EMS only registers with the Naming Service for the version that is supported by the EMS.
1
Naming Service Location Setup
Lightscape EMS XDM and EMS Syncom allow configuration of an NMS Naming Service address
when launching the EMS through the configuration dialog.
In the Naming Server Parameters type in the location(s) of all CORBA eNI Naming Service
instance(s) in the format
<host>:<port>[","<host>:<port>]*
Where:
<host> := host name or host IP where the northbound CORBA Naming Service is installed
<port> := the port identifier where the northbound CORBA Naming Service can be found
For example "ariel:8888, saturn:7777".
2
Naming Service Naming Tree and Format
EMS Name (distinguishing, invariant identifier established by the EMS, unique across the network
management domain using "CompanyName/EMSName" or “CompanyName:EMSName” (where the
“/” and the “:” are semantically equivalent1); each company ensures that the EMSName is unique
relative to the CompanyName and blank spaces, “/” and “:” are not allowed within the name).
The Naming Graph uses the unique EMS name “CompanyName/EMSName” or
“CompanyName:EMSName” (e.g. VendorA:EMSA).
• Naming Containment – kind and id (i.e. a Name-Value pair with Name as KIND and Value as
ID)
• kind = EmsSessionFactory_I; Version, EmsInstance, Vendor, Class
• id = value:
o For EmsSessionFactory_I, the id is the name of the EMS as specified in the value field of the only
NameAndStringValue_T element of the name field of the EMS_T structure.
o For Version, the id is the value returned by the getVersion operation. The version may be reported as
“n.m” or “n_m”2 (E.g. “3.0” or the equivalent “3_0”).
o For EmsInstance, the id is the same as the Network_R1 and/or EmsSessionFactory_I id, as applicable.
o For Vendor, the id is the first part of the EmsInstance id (i.e., the CompanyName part, which precedes
the “/” or the “:”).
o For Class, the id is always “TMF_MTNM”.
1
The “/” character has a reserved usage in the OMG Naming Service. Using the “/’ requires usage of escape characters
which that does not work well with many Naming Service implementations. As an alternative the “:” character may be
used.
2
The “.” character has a reserved usage in the OMG Naming Service. Using the ‘.’ requires usage of escape characters
which that does not work well with many Naming Service implementations. As an alternative the “_” character may be
used.
3
The diagram below is an example EMS Naming Context for ECI Lightscape Optical Networks EMS XDM and EMS
Syncom. The naming contexts are represented by hollow nodes and the EMS entry point objects are represented by filled
nodes.
Naming Graph:
EMS with V1.0 and V2.0
Root
ID: TMF_MTNM
Kind: Class
ID: LSN
Kind: Vendor
ID: LSN:EMS_XDM_1 ID: LSN:EMS_SYNCOM_4

Kind: EmsInstance Kind: EmsInstance
ID: 2_0 ID: 2_0

Kind: Version Kind: Version
ID: VendorA/EMS1 ID: VendorA/EMS2

Kind: EmsSessionFactory_I Kind: EmsSessionFactory_I
4
Session Establishment
• Once the EMS entry point object is retrieved through the Naming Service the session can be
established with the EMS. The entry point refers to the EmsSessionFactory_I CORBA interface in
TMF 814 IDL
• The session is established through the operation
EmsSessionFactory_I:: getEmsSession( in string user,
in string password,
in nmsSession::NmsSession_I client,
out emsSession::EmsSession_I emsSessionInterface)
raises(globaldefs::ProcessingFailureException)
• The user name provided in session establishment needs to be a user name that is configured in the
EMS. A prefix of “MTNM” in the user name needs to exist in order to configure the Notification
Service for a standard MTNM Notification Service configuration with support of Event Loss3
notifications and operation invocation.
• Once the eNI session is established the OMG Notification Service channel can be retrieved
through the EmsSession_I::getEventChannel() operation.
3
This configuration is not available in releases prior to 2004. The Event Loss support of the standard MTNM configuration
is required only in case the NMS uses filtering in the OMG Notification Service. Otherwise the NMS may make rely on the
Notification Identifiers provided by the EMS to be consecutive for each event type (with the exception of NT_ALARM and
NT_TCA that share the same Notification Identifier counter)
5
The following is session establishment use case provided in the MTNM Business Agreement (TMF
513):
Name NMS creates a session with EMS
Summary The NMS client finds the entry point EMS objects of the required version. It
also registers and connects to the notification service as a consumer of
notifications. Finally, the NMS synchronizes its network database.
This use case contains some implementation details about the usage of CORBA
naming and notification services. It also assumes that there exists one
notification service per EMS (as recommended but not mandatory.
Actor(s) NMS
Pre-Conditions Post-conditions of Error! Reference source not found..
Begins When NMS (re)starts – in which case this use case is performed for every EMS to be
enrolled - or detects that there is a new EMS that it wishes to enroll.
Description The NMS locates the EMS’ entry point object.
1) The NMS retrieves the version of the EMS for validation as described in
Error!
Reference source not found..
2) The NMS sets up a session with the EMS.
The EMS may perform identification and authentication by verifying the user id
and the password provided by the NMS. It is then able to detect security
violations and to send out appropriate alarms.
3) The NMS sends the request to retrieve the capabilities from the EMS.
4) The EMS replies with its supported capabilities.
5) The NMS retrieves the reference on the event channel to be used from the
6
out all notifications that occurred during the NMS’ downtime. In this case the
NMS can synchronize its database by evaluating these notification.
Note:
There are timeout values recommended for alarms and other events. After these
times the notification service discards notifications. If an NMS downtime had
exceeded these times the NMS should synchronize the active alarms or the
whole configuration, respectively. If event loss (synchronization) notifications are
supported by the EMS then the NMS will synchronize the alarms and/or the entire
configuration once retrieving such a notification.
8) If the NMS starts for the first time or if it decides to discard all notifications sent
out in step 6, it (re)discovers the EMS’ network inventory as described in the
Error! Reference source not found..
9) The NMS periodically checks the availability of the EMS.
10) The EMS periodically checks the availability of the NMS
Ends When Either NMS or EMS calls one of the following use cases:
Exceptions 1) No compatible version of the entry point object.
2) ACCESS_DENIED - Raised in case of security violation.
3) INVALID_INPUT – Raised in case of invalid NMS session specified.
4) INTERNAL_ERROR - Raised in case of non-specific EMS internal failure.
Post-Conditions There exists a valid session between NMS and EMS which is supervised by both. The
NMS is initialized and ready to communicate with the EMS as well as to receive
notifications.
Traceability
7
eCI Northbound Interface (eNI)
V3.5
Object Naming Specification for eNM XDM,

Syncom, APT, and STMS
eCI Northbound Interface (eNI) Object Naming Specification for eNM XDM, Syncom, APT, and STMS
V3.5
May 2016
1st Edition
ECI's NPT-1200, NPT-1020, 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, 2002-2016. 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
1 eNI Object Identifier and Label Types .......................................................... 1-1
1.1 Object Name .......................................................................................................................... 1-1
1.2 NativeEMSName .................................................................................................................... 1-1
1.3 UserLabel ............................................................................................................................... 1-1
1.4 Terminology ........................................................................................................................... 1-1
2 Object Naming Conventions ........................................................................ 2-1

2.1 Equipment Object Naming..................................................................................................... 2-1
2.2 CTP Object Naming ................................................................................................................ 2-1
2.3 SubnetworkConnection (SNC) Object Naming ...................................................................... 2-5
2.4 Protection Groups Object Naming ......................................................................................... 2-5
2.5 Topology Link Object Naming ................................................................................................ 2-5
2.6 Ethernet Object Naming ........................................................................................................ 2-6
2.7 Multi-Layer Routing Area Object Naming (MLRA) ................................................................. 2-6
2.8 Call Naming ............................................................................................................................ 2-7
2.9 Top Level Connection Naming ............................................................................................... 2-7
2.10 Proxy PTP Object Naming ...................................................................................................... 2-8
2.11 Logical Interface (LIF) Object Naming .................................................................................... 2-8
2.12 Traffic Conditioning Profile Object Naming ........................................................................... 2-9
2.13 Routing Instances and Protocols............................................................................................ 2-9
2.13.1 Routing Instance - Object Naming .......................................................................................... 2-9
2.13.2 Protocol Instance - Object Naming ....................................................................................... 2-10
2.13.3 Protocol Instance Entity - Interface Object Naming .............................................................. 2-10
2.13.4 Protocol Instance Entity - Virtual Router Object Naming...................................................... 2-11
2.13.5 Protocol Instance Entity - BGP Group Object Naming .......................................................... 2-11
2.13.6 Protocol Instance Entity - BGP Neighbor Object Naming ...................................................... 2-12
2.13.7 Protocol Instance Entity - LDP Peer Object Naming .............................................................. 2-12
2.13.8 Protocol Instance Entity - OSPF Virtual Link Object Naming ................................................. 2-13
2.13.9 Protocol Instance Entity - Virtual Router (VRRP Group) Instance Object Naming ................ 2-14
2.13.10 Protocol Instance Entity – Static Route Object Naming ........................................................ 2-14
2.14 Multicast Protocols .............................................................................................................. 2-15
2.14.1 Protocol Instance Entity – PIM Static RP Object Naming ...................................................... 2-15
2.14.2 Protocol Instance Entity – PIM Any-Cast RP Object Naming ................................................. 2-15
2.14.3 Protocol Instance Entity – PIM Candidate RP Object Naming ............................................... 2-16
ECI Telecom Ltd. Proprietary iii

eCI Northbound Interface (eNI) Object Naming Specification Contents
for eNM XDM, Syncom, APT, and STMS
2.14.4 Protocol Instance Entity – PIM Candidate BSR Object Naming ............................................. 2-16
ECI Telecom Ltd. Proprietary iv

1 eNI Object Identifier and Label Types
1.1 Object Name

The Name is the fully distinguished name of the object over the interface. An operation can be invoked over
the interface based on this identifier. It is a sequence of (Name, Value) pairs reflecting the object hierarchy.
TMF #814 specifies a naming convention for EMS, Equipment, Equipment Holder, and CTP. Note that {} does
not appear in the object name.
1.2 NativeEMSName
The label of each object as displayed in the EMS GUI. The label provided is the NE System Title at the Managed
Element level (not guaranteed to be a unique identifier). For object contained by the Managed Element, the
fully distinguished label in the scope of the NE is provided. (See the examples in the following tables).
1.3 UserLabel
The EMS must support setting the userLabel for all objects. The userLabel is a field "owned" by the NMS. The
EMS may display the userLabel in the EMS GUI. The NMS may set this field.
1.4 Terminology
Unless stated otherwise, the following terminology is used for SDH object names.
{m} – GDMO DN class index (short)
{n} – GDMO DN instance (long)
{j} – AUG index
{k} – TUG3 index
{l} – TUG2 index
{m} – TU12 index
{i},{h},{k},{l} – other index of type short
{o} - other index of type long
ECI Telecom Ltd. Proprietary 1-1

2 Object Naming Conventions
2.1 Equipment Object Naming

The naming convention follows the TMF#814 convention of equipment holder numbering according to the
physical location from left-to-right, top-to-bottom.
Table 1 Equipment Object Naming
ObjectName – ObjectName - Value Comment nativeEMSName Object name as it
Name example of object appears in the eNM
in the given level Alarm Log
EMS LSN/EMS_XDM_{u} u – integer which makes "Saturn" -

the LSN/EMS_XDM EMS
name unique in the NMS
Naming Service.
The nativeEMSName is
composed of the EMS
workstation host name
ManagedElement {n} n – is the NE "myNE" "myNE"

NetworkElementId. i.e.
similar to the read-only NE
attribute.
EquipmentHolder /rack=1/shelf={i}/slot={h} "I3" -
Equipment "1" "I3" "myNE : Slot # I3"
2.2 CTP Object Naming

The naming convention for CTP objects must follow the TMF#814 j-k-l-m convention.
Table 2 High Order CTP
ObjectName – ObjectName - Value Comment nativeEMSName Object in the given level
Name example of object as it appears in the eNM
in the given level Alarm Log
EMS LSN/EMS_XDM_{u} "Saturn" -
ManagedElement {n} n – is the NE "myNE" "myNE"

NetworkElementId
PTP {m}:{n} The "object class" in the "I3-STM-1" "myNE : I3-SPIO-Snk-1"

nativeName to be used
or
for SDH PTPs is "STM"
"myNE : I3-RS-Snk-1"
or
"myNE : I3-MS-Snk-1"
CTP /sts3c_au4-j={j} "I3-VC4-2" "myNE : I3-VC4Snk-2"

eCI Northbound Interface (eNI) Object Naming Specification Object Naming Conventions
The complete ObjectName of the lowest level CTP object in the above containment hierarchy can be:
{(EMS, "LSN/EMS_XDM_1"), (ManagedElement, "87"), (PTP, "27:5"), (CTP, "/sts3c_au4-j=2")}
The nativeEMSName shall be:
"I3-VC4-2"
Table 3 Low Order CTP
ObjectName – ObjectName - Value Comment nativeEMSName Object in the given
Name example of object in level as it appears
the given level in the eNM Alarm
Log
ManagedElement {n} "myNE" "myNE"
PTP {m}:{n} same as in the above same as in the

above
CTP /sts3c_au4-j={j}/vt2_tu12-k={k}-l={l}-m={m} "110-VC4-1W : TU12-1- "myNE :

1-2"
110-VC4-1W :
TU12Snk-1-1-2"
Table 4 RS CTP - unidirectional CTP contained by unidirectional PTP
ObjectName – ObjectName - Value Comment nativeEMSName Object in the given level as it appears
Name example of object in in the eNM Alarm Log
the given level
PTP {m}:{n} same as in the above same as in the above
CTP /section3_rs1=1 "I5-RS-Snk-1" "myNE :I5-RS-Snk-1
Table 5 Tunable OCH CTP - unidirectional CTP contained by unidirectional PTP

ObjectName – ObjectName - Value Comment nativeEMSName Object in the given level as it
Name example of object appears in the eNM Alarm Log
in the given level
PTP {m}:{n} “I3-OPS-Src-1” “I3-OPS-Src-1”
CTP /frequency=tunable-number={i} NULL NA

Table 6 Non-tunable OCH CTP (in OADM or WDM MUX/DEMUX) - unidirectional CTP contained by
unidirectional PTP
Name example of object in as it appears in the eNM
the given level Alarm Log
PTP {m}:{n} The nativeEMS name is “I3-OTS-Snk-1” or "myNE : I3-OTS-Snk-1”

provided for the lowest “I3-OPS-Snk-1”
or
layer object mapped to the
PTP. "myNE : I3-OPS-Snk-1”
CTP /frequency=nnn.nn decimal format nnn.nn NULL NA

reflecting frequency in THz
Table 7 OMS CTP - unidirectional CTP contained by unidirectional PTP

ObjectName – ObjectName - Value Comment nativeEMSName example of Object in the given level as it
Name object in the given level appears in the eNM Alarm
Log
PTP {m}:{n} “I3-OTS-Snk-1” "myNE : I3-OTS-Snk-1”
CTP /oms=1 "I3-OMS-Snk-1" "myNE : I3-OMS-Snk-1”
Table 8 OS CTP (unidirectional CTP contained by unidirectional PTP)

ObjectName – Name ObjectName - Value Comment nativeEMSName Object in the given level as it
example of object in the appears in the eNM Alarm
given level Log
PTP {m}:{n} “I3-OPS-Snk-1” "myNE : I3-OPS-Snk-1”
CTP /os=1 "I3-OPS-Snk-1" "myNE : I3-OPS-Snk-1”
Table 9 ODU CTP

given level Log

given level Log
PTP {m}:{n} j=1,2 “I3-ODUj-Snk-1” "myNE : I3-ODUj-Snk-1”
CTP /dsr=n or "I3-ODUj-Snk-1" "myNE : I3-ODUj-Snk-1”

j=1,2
/oduj
Table 10 Proxy ODUk CTP

ObjectName ObjectName - Value Comment nativeEMSName Object in the given
– Name example of object in level as it appears in
the given level the eNM Alarm Log
EMS NA "NA"
ManagedElem NA "NA"
ent
PTP {m}:{n} “ODU2-u0/2”
CTP ODUk=1/ODUl=[1..i] where:&nbspk=1,2,2e,3e,4&nb “ODU2-u0/2:1"

spspecifies&nbspHO&nbspODU
&nbspCTP&nbsprate;
l=0/odu_slot,1,2,2e,3e,oduf_fc
400,oduf_fc800,oduf_sdi3g
specifies&nbspLO&nbspODU&
nbspCTP&nbsprate;
The proxy ODUk CTP naming is used when server (EMS) doesn’t manage specified ODUk TP and therefore
the values for “EMS” and “ManagedElement” components are not applicable.
Table 11 Proxy OCH CTP - Object Naming

ObjectName ObjectName - Comment nativeEMSName Object in the given
– Name Value example of object level as it appears in
in the given level the eNM Alarm Log
EMS NA EMS&nbspis&nbspnot&nbspapplicable "NA"
ManagedEle NA ME&nbspis&nbspnot&nbspapplicable "NA"

ment
PTP The same value as Represents&nbspthe&nbspunique&nbsp

for regular OCH position&nbspof&nbspthe&nbspPTP
CTP with&nbsprespect&nbspto&nbspthe&nb
spmanaged&nbspelement
CTP The same value as Represents&nbspOCH&nbspCTP&nbspwi

for regular OCH th&nbspappropriate&nbspfrequency :
CTP Tunable&nbspOCH&nbspCTP:/frequency
=tunable_number= {&nbspi } Non&nbsp
tunable&nbspOCH&nbspCTP: /frequency
=nnn.nn
The proxy OCH CTP naming is used when server (EMS) doesn’t manage specified OCH TP, therefore the values
for “EMS” and “ManagedElement” components are not applicable.

2.3 SubnetworkConnection (SNC) Object Naming

Table 12 SubnetworkConnection (SNC)
ObjectName – Name ObjectName - Value Comment nativeEMSName Object in the given level
example of object in as it appears in the eNM
MultiLayerSubnetwork {n} "myNESystemTitle" "myNESystemTitle"
SubnetworkConnection {o} “myXCSetLabel” "myNESystemTitle :

myXCSetLabel”
Table 13 Fixed SubnetworkConnection (SNC) e.g. DWDM SNCs

ObjectName – Name ObjectName - Value Comment nativeEMSName Object in the given
example of object level as it appears in
in the given level the eNM Alarm Log
MultiLayerSubnetwork {n} n - networkElementId "myNESystemTitle" "myNESytemTitle"
SubnetworkConnection {o} o - XCSetId or TrailId in “myXCSetLabel” “myNESystemTitle :

the EMS myXCSetLabel”
2.4 Protection Groups Object Naming

Table 14 Protection Groups (MSP Linear, MSP Ring, Optical)
ObjectName – Name ObjectName - Value nativeEMSName example of object Object in the given level as
in the given level it appears in the eNM
Alarm Log
PGP {m:n} NULL for MSP or I5-OPG-1 for optical NA for MSP or
protection group
"myNE : I5-OPG-1"
2.5 Topology Link Object Naming

Table 15 Topology Link
ObjectName – Name ObjectName - Value nativeEMSName example of Object in the given level as it
object in the given level appears in the eNM Alarm Log
TopologicalLink {m:n}/{m:n} "myNE1 - myNE2" -

2.6 Ethernet Object Naming

VLAN CTP Naming scheme is based on the VID:
/vlanId = {0..4094} , where 0 represents untagged & priority tagged frames (and when the PVID is not set
otherwise).
VLAN CTP Naming scheme for a TP representing a wild card mapping of all VLANs:
/vlanId = 4095
A similar convention shall be used for matrixFDs:
Name Value
EMS As usual
ManagedElement As usual
matrixFD /BridgeId={1..n}
and matrixFDFragments:
Name Value
EMS As usual
MatrixFD /BridgeId={1..n}
matrixFDFR /VlanId = {1..4094}
For TMCs:
Name Value
EMS As usual
TMC Free format string
2.7 Multi-Layer Routing Area Object Naming

(MLRA)
The MLRA naming convention is specified for Top Level MLRA.

Table 16 Multi-Layer Routing Area Object Naming (MLRA)

Name example of object level
in the given level
EMS ECI/EMS_STMS_{u} EMS_STMS_{u}- the name of EMS "ECI/EMS_STMS_777"

that manage control plan specified
by HeadEnd;where
{u} – integer which makes the EMS
name unique in the NMS Naming
Service.
MultiLayerSubn TLRA The top level Routing Area is not a "TLRA"

etwork named entity in the ASON Control
Plane
as a consequence the EMS/NMS
must fabricate a name.
2.8 Call Naming

Table 17 Call Naming
Name example of object level
in the given level
EMS ECI/EMS_STMS_{u} EMS_STMS_{u}- the name of EMS "ECI/EMS_STMS_777"

that manage control plan specified
by HeadEnd;where
{u} – integer which makes the EMS
name unique in the NMS Naming
Service.
Call MLRA={n}/CallId={o} Specified by two-tuple and includes: "MLRA=70/CallId=0.c.2

MLRA={n} - defines the Routing 9.9.52.4dv40"
Node (subnetwork of Managed
Element) that manages HeadEnd
CallId={o} - an unique identifier of
the Call provided by control plane.
2.9 Top Level Connection Naming

Table 18 Top Level Connection Naming
ObjectName – ObjectName - Comment nativeEMSName Object in the given
Name Value example of object level
in the given level
EMS ECI/EMS_STMS EMS_STMS_{u}- the name of EMS that "ECI/EMS_STMS_777"

_{u} manage control plan specified by
HeadEnd;where
{u} – integer which makes the EMS name
unique in the NMS Naming Service.

ObjectName – ObjectName - Comment nativeEMSName Object in the given

Name Value example of object level
in the given level
MLRA {n} {n} - unique identifier in scope of EMS ; "70"

defines the Routing Node( subnetwork of
ME) that manages HeadEnd.
SubnetworkCo CallId={n}/Id={o} Specified by two-tuple and includes Call "CallId=0.c.29.9.52.4dv

nnection and connection identifiers. Where: 40/
{n} - the unique identifier of the Call Id=Trail_70_16-
provided by control plane. 0.c.29.9.52.4dv40-
main"
{o}- the unique identifier of the
connection specified by control plane.
2.10 Proxy PTP Object Naming

WSON Call EP Proxy OTUk/OTS PTP
Table 19 Proxy PTP Object Naming
ObjectName – ObjectName - Comment nativeEMSNam Object in the given
Name Value e example of level as it appears in
object in the the eNM Alarm Log
given level
EMS NA EMS&nbspis&nbspnot&nbspapplicable "NA"
ManagedEleme NA "NA"
ME&nbspis&nbspnot&nbspapplicable
nt
PTP The same value Represents&nbspthe&nbspunique&nbsppositio

as for regular n&nbspof&nbspthe&nbspPTP
OCH CTP with&nbsprespect&nbspto&nbspthe&nbspman
aged&nbspelement
2.11 Logical Interface (LIF) Object Naming

The naming convention for LIF object follows the TMF#814 j-k-l-m convention, while replacing the last
component as described in the following table.
Table 20 Logical Interface (LIF)
ObjectName – ObjectName - Comment nativeEMSName example Object in the given level as it
Name Value of object in the given level appears in the eNM Alarm Log
EMS LSN/EMS_XD "EMS=ECI/EMS_NPT_111" -

M_{u}
ManagedElement {n} n – is the NE "1423"

NetworkElementId


PTP {m}:{n} Represents the "4:3"

unique position of
the PTP with respect
to the managed
element
LIF {j} "1" "EMS=ECI/EMS_NPT_111/

ManagedElement=1423/PTP=4:3/L
IF=1"
2.12 Traffic Conditioning Profile Object Naming

The TC profile is associated with a MatrixFD.
Table 21 Traffic Conditioning Profile
ObjectName – ObjectName - Comment nativeEMSName example of Object in the given level as it
Name Value object in the given level appears in the eNM Alarm Log
EMS LSN/EMS_XDM_ "EMS=ECI/EMS_NPT_111" -

{u}
ManagedElem {n} n – is the NE "1423"

ent NetworkElementId
MatrixFD /BridgeId={1..n} "/BridgeId=1"
ProfType {t}/ProfName={n} t – is a legal profile "PriToCos/ProfName=Profile1 "EMS=ECI/EMS_NPT_111/Manag

type " edElement=1423/
MatrixFlowDomain=/BridgeId=1/
n – is a unique profile
ProfType=PriToCos/ProfName=P
name, in context of
rofile1"
the profile type
2.13 Routing Instances and Protocols

2.13.1 Routing Instance - Object Naming
Table 22 Routing Instance - Object Naming
EMS LSN/EMS_NPT_ "ECI/EMS_NPT_111" -

{u}

NetworkElementId
MatrixFlowDomai /BridgeId={1..n} Represents MFD "4:3"

n


RI {n} Routing Instance (Virtual "1" “EMS~~ECI/EMS_NPT_111@@

Routing and Forwarding) ManagedElement~~1423@@M
atrixFlowDomain~~/BridgeId=1
@@RI~~1”
2.13.2 Protocol Instance - Object Naming

Table 23 Protocol Instance - Object Naming
example of object in the as it appears in the eNM
given level Alarm Log
EMS LSN/EMS_NPT_{u} "ECI/EMS_NPT_111" -

NetworkElementId
MatrixFlowDomain /BridgeId={1..n} Represents MFD "4:3"
RI {n} Routing Instance (Virtual "1"

Routing and Forwarding)
PI /Protocol=<Protocol Protocol Instance “EMS~~ECI/EMS_NPT_1

Type>/Key={1..n} <Protocol Type> 11@@ManagedElement
specifies the type of the ~~1423@@MatrixFlowD
protocol : e.g. ISIS, LDP, omain~~/BridgeId=1@@
OSPF, BGP, PIM, IGMP, RI~~1@@PI~~/Protocol=
STT_ROUTES. ISIS/Key=1”
2.13.3 Protocol Instance Entity - Interface Object Naming

Table 24 Protocol Instance Entity - Interface Object Naming
ObjectName – Name ObjectName - Value Comment nativeEMSName example Object in the given level
of object in the given as it appears in the eNM
level Alarm Log

NetworkElementId
PTP {m} m – Port identifier "4:3"
LIF {k} k – LIF identifier "1"
IsisIf, or OspfIf, or {n} n – instance identifier “14” “EMS~~ECI/EMS_NPT_1

LdpIf, or PimIf, or 11@@ManagedElement
IgmpIf ~~1423@@PTP~~4:3@
@LIF~~1@@IsisIf~~14”

2.13.4 Protocol Instance Entity - Virtual Router Object

Naming
Table 25 Protocol Instance Entity - Virtual Router Object Naming
Name example of object in the as it appears in the eNM

NetworkElementId
LIF {n} n – LIF identifier "1"
VrId {n} n – VR instance identifier “1” “EMS~~ECI/EMS_NPT_1

11@@ManagedElement
~~1423@@PTP~~4:3@
@LIF~~1@@VrId~~1”
2.13.5 Protocol Instance Entity - BGP Group Object Naming

Table 26 Protocol Instance Entity - BGP Group Object Naming
Name example of object in the as it appears in the eNM

NetworkElementId

PI /Protocol=<Protocol BGP Protocol Instance ,

Type>/Key={1..n} i.e. <Protocol
Type>=BGP
Group {1..n} Group “EMS~~ECI/EMS_NPT_1

11@@ManagedElement
~~1423
@@MatrixFlowDomain~
~/BridgeId=1@@RI~~0
@@PI~~/Protocol=BGP/
Key=1@@Group~~1”

2.13.6 Protocol Instance Entity - BGP Neighbor Object

Naming
Table 27 Protocol Instance Entity - BGP Neighbor Object Naming

NetworkElementId

PI /Protocol=<Protocol BGP Protocol Instance ,

Type>/Key={1..n} i.e. <Protocol
Type>=BGP
Group {1..n} Group
Peer {1..n} BGP Neighbor “EMS~~ECI/EMS_NPT_111

@@ManagedElement~~14
23@@MatrixFlowDomain~
~/BridgeId=1@@RI~~0@
@PI~~/Protocol=BGP/Key=
1@@Group~~1@@Peer~~
36”
2.13.7 Protocol Instance Entity - LDP Peer Object Naming

Table 28 Protocol Instance Entity - LDP Peer Object Naming
example of object in appears in the eNM Alarm
the given level Log

NetworkElementId
RI {n} Routing Instance "0"

(Virtual Routing
and Forwarding)
PI /Protocol=<Protocol LDP Protocol

Type>/Key={1..n} Instance , i.e.
<Protocol
Type>=LDP

the given level Log
Peer {1..n} Peer identifier “EMS~~ECI/EMS_NPT_111@

@ManagedElement~~1423
@@MatrixFlowDomain~~/Bri
dgeId=1@@RI~~0@@PI~~/P
rotocol=LDP/Key=1@@Peer~
~1”
2.13.8 Protocol Instance Entity - OSPF Virtual Link Object

Naming
Table 29 Protocol Instance Entity - OSPF Virtual Link Object Naming
ObjectName – Name ObjectName - Comment nativeEMSName Object in the given level as it
Value example of object in appears in the eNM Alarm Log
the given level

NetworkElementId

(Virtual Routing and
Forwarding)
PI /Protocol=<Protoco Protocol Instance ,

l Type>/Key={1..n} i.e. <Protocol
Type>=OSPF
VLink {1..n} Virtual Link ordered “EMS~~ECI/EMS_NPT_111@@M

number anagedElement~~1423
@@MatrixFlowDomain~~/Bridge
Id=1@@RI~~0@@PI~~/Protocol
=OSPF/Key=1@@VLink~~1”

2.13.9 Protocol Instance Entity - Virtual Router (VRRP

Group) Instance Object Naming
Table 30 Protocol Instance Entity - Virtual Router (VRRP Group) Instance Object Naming
the given level Log

NetworkElementId
LIF {k} k – LIF identifier "1"
VrrpInst {n} n – instance “4” “EMS~~ECI/EMS_NPT_111@

identifier @ManagedElement~~1423@
@PTP~~4:3@@LIF~~1@@Vr
rpInst ~~4”
2.13.10 Protocol Instance Entity – Static Route Object

Naming
Table 31 Protocol Instance Entity – Static Route Object Naming
the given level

NetworkElementI
d

(Virtual Routing
and Forwarding)
PI /Protocol=<Protoco Protocol Instance

l Type>/Key={1..n} , i.e. <Protocol
Type>=STT_ROUT
ES
Route {1..n} ordered number “EMS~~ECI/EMS_NPT_111@@Ma

nagedElement~~1423
@@MatrixFlowDomain~~/BridgeId
=1@@RI~~0@@PI~~/Protocol=
STT_ROUTES/Key=1@@Route~~5”

2.14 Multicast Protocols

2.14.1 Protocol Instance Entity – PIM Static RP Object
Naming
Table 32 Protocol Instance Entity – PIM Static RP Object Naming

NetworkElementId
PI /Protocol=<Protocol PIM Protocol Instance

Type>/Key={1..n} , i.e. <Protocol
Type>=PIM
SttRP {1..n} Static RP Instance “EMS~~ECI/EMS_NPT_111

number @@ManagedElement~~14
23
@@MatrixFlowDomain~~/
BridgeId=1@@RI~~0@@PI
~~/Protocol=PIM/Key=1@
@SttRP~~1”
2.14.2 Protocol Instance Entity – PIM Any-Cast RP Object

Naming
Table 33 Protocol Instance Entity – PIM Any-Cast RP Object Naming
example of object in appears in the eNM Alarm Log
the given level

NetworkElementId
PI /Protocol=<Protocol PIM Protocol

Type>/Key={1..n} Instance , i.e.
<Protocol
Type>=PIM

example of object in appears in the eNM Alarm Log
the given level
AnyCastRP {1..n} Any-Cast RP “EMS~~ECI/EMS_NPT_111@@

Instance number ManagedElement~~1423
@@MatrixFlowDomain~~/Brid
geId=1@@RI~~0@@PI~~/Prot
ocol=PIM/Key=1@@AnyCastRP
~~1”
2.14.3 Protocol Instance Entity – PIM Candidate RP Object

Naming
Table 34 Protocol Instance Entity – PIM Candidate RP Object Naming
the given level
EMS LSN/EMS_NPT_{u "ECI/EMS_NPT_111" -

}

NetworkElementId
PI /Protocol=<Proto PIM Protocol Instance

col , i.e. <Protocol
Type>/Key={1..n} Type>=PIM
CandRP {1..n} Candidate RP “EMS~~ECI/EMS_NPT_111@@M

Instance number anagedElement~~1423
=PIM/Key=1@@CandRP~~1”
2.14.4 Protocol Instance Entity – PIM Candidate BSR Object

Naming
Table 35 Protocol Instance Entity – PIM Candidate BSR Object Naming
the given level

NetworkElementId


the given level
PI /Protocol=<Protoco PIM Protocol

l Type>/Key={1..n} Instance , i.e.
<Protocol
Type>=PIM
CandBSR {1..n} Candidate BSR “EMS~~ECI/EMS_NPT_111@@M

Instance number anagedElement~~1423
=PIM/Key=1@@CandBSR~~1”

Service Effect - Alarm Attributes
AffectedPTPList Attribute
All equipment alarms should indicate the PTPs affected by the alarm.
For XDM:
1) IO Cards - the PTPs supported by the card
2) IO Tranceiver Modules - the PTPs directly supported by the module
3) PIO CCP Modules - all PTPs that are supported by the PIO card
4) Optical CCP Modules - Dummy PTPs directly contained by the module
5) HLXC - all PTPs in the NE that contain crossconnectible CTPs (i.e. PTPs of all
cards that show in the XC create window). (6) is acceptable if (5) cannot be
implemented due to the effect on performance.
6) For all other common cards - the affectedPTP list shall be empty indicating that all
the PTPs of the NE are affected.
For Syncom:
1) For all SPU cards affectedPTPs are the same PTPs supported by the ATRx card
that supports the equivalent SPIs (for the RS/MS supported by the SPU)
2) For all other tributary and aggregate cards the affected PTPs always include the
PTPs contained by that card.
3) For TRS1_4 the MTRO and MTRE modules each affect a single PTP that it is
direcly supported.
4) For all BIM cards the affectedPTPs are all PTPs that contain CTPs that are
crossconnectible within that NE (same as for XDM HLXC cards). (5) is
acceptable if (4) cannot be implemented due to the effect on performance.
5) All other common cards: - the affectedPTP list shall be empty indicating that all
the PTPs of the NE are affected.
For Micro Equipment:

1) Micro Tributary Extension Card - all PTPs supported by that card.
2) All other common cards and modules (including the MAC) - the affectedPTP list
shall be empty indicating that all the PTPs of the NE are affected.
Service Affecting Indication
The EMS will indicate to the NMS that service has been affected when both
conditions are satisfied:
1) The severity of the alarm is "Major" or "Critical"

2) There is traffic defined that goes through or terminates in the related
transmission and/or contained transmission objects.
Condition 2 is explained as follows:

1) if the alarmed object is a CTP then the CTP is an end-point of an SNC.
2) if the alarmed object is a PTP, then one or more of the CTPs is an endpoint of
an SNC.
3) if the alarmed object is an equipment then one or more of the PTPs provided in
the affectedPTPs field contains one or more CTPs that are an endpoint of an
SNC.
4) If the equipment alarm affectedPTPList is empty (e.g. for a non-IO / common
card), or the alarm applies to the entire NE, service is affected if there is one or
more SNCs going through and/or terminated in the NE.
5) The SNCs are used to carry traffic. I.e. if fixed SNCs are identified then the
equipment Usage state is "on".
6) If any of the above 1-5 conditions cannot be verified then the effect on service
shall be "unknown".
GetRoute CrossConnect Ordering
This document explains the response which an OSS will receive from LightSoft when the OSS calls the getRoute() operation. This document refers to
LightSoft versions beginning with v6.
1. The getRoute operation is called by an OSS (upper level network manager) to request from LightSoft the list of Cross Connects which form a trail,
along with information about each Cross Connect’s position in the trail. A trail is represented by a Subnetwork Connection (SNC).
2. The getRoute operation returns a list of Cross Connect structures. These structures are called CrossConnect_T in eNI. See getRoute() and
CrossConnect_T in the eNI Documentation Suite.
3. Each Cross Connect structure contains the following information:
a) 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.
b) For each simple connection, its position in the trail and its protection role are provided.
4. 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.
5. Two simple connections are adjacent if there is a topological link 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 trail
subcomponent. A trail subcomponent which goes between two trail ends is a primary trail subcomponent. A trail subcomponent which has at least
one end which is not a trail end is a branch or a bridge. A trail component is a primary trail component with all of the branches and bridges which
split off from the primary trail component. When there are no branches or bridges, the trail component is the same as the primary trail
subcomponent.
6. Examples:
a) 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.
b) An unprotected unidirectional trail will have one component, going from A to Z.
c) 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).
GetRoute CrossConnect Ordering Page 1 of 14
d) 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.
7. A trail component is either a Main component or a Protection component. A simple connection in a Cross Connect structure can be either part of
a Main component or part of a Protection component. When a segment connecting a source to a sink is part of two components, one Main and
one Protection, it will appear twice, once as a Main simple connection and once as a Protection simple connection. In point-to-multipoint trails and
in optical multi-route trails, the same simple connection may appear more than once in a Cross Connect structure, with the same Main/Protection
role, but belonging to different components.
8. Trail components are numbered. There is no significance to the number. The significance is that two simple connections which have the same
component number belong to the same component. However, trail components are numbered according to the following rule: All Main-forward
components come first, followed by all Protection-forward components, followed by all Main-backward components, followed by 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. The possible exception are trails in which there are disjoint trail segments – some of these are referred to as X trails. The directionality
of disjoint segments may not be consistent.)
9. 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 trail component always starts with the primary subcomponent.
10. For each simple connection in a Cross Connect, the following information is provided. Section 15 explains how the information is presented to the
OSS over the interface.
a) 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.
b) The simple connection’s 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.
c) 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.
d) The simple connection’s 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.
e) The simple connection’s 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).
f) The simple connection’s role within the trail subcomponent. It is one of the following strings.
Note that a trail can have more than one starting point and/or more than one ending point.
i) Start First connection in the primary subcomponent, and starts at a trail starting point.
ii) Stop Last connection in the primary subcomponent, and ends at a trail ending point.
iii) StartStop It’s both a Start and a Stop. (It’s the only connection in the primary subcomponent.)
iv) BranchStart 1st connection in a non-primary subcomponent; branches off from another subcomponent.
v) BranchStop Last connection in a non-primary subcomponent; merges into another subcomponent.
vi) Bridge Both a BranchStart and BranchStop. (It’s the only connection in this non-primary subcomponent.)
vii) Mid The connection is neither the first nor the last in the subcomponent.
11. The includeHigherOrderCCs option in the getRoute request is not supported. It is ignored, and the route without higher order CCs is returned.
12. 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.
13. 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.
14. 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 simple connections in a flex trail is -1.
15. The information about the simple connections of a Cross Connect are returned by getRoute as follows:
a) The aEndNameList field of the CrossConnect_T structure contains the list of source points.
b) The zEndNameList field of the CrossConnect_T structure contains the list of sink points.
c) 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 aEndNameList and of 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 component to which the simple connection belongs (-1 if it doesn’t belong to a
Main trail component), the simple connection’s sequence number within the Main trail component (-1 if it doesn’t belong to a Main trail
component), the component number of the Protection trail component to which the simple connection belongs (-1 if it doesn’t belong to a
Protection trail component), the simple connection’s sequence number within the Protection trail component (-1 if it doesn’t belong to a
Protection trail component). Note that either the first and second terms of the 4-tuple are used (and the third and fourth contain -1) or the third
and fourth terms are used (and the first and second contain -1).
d) 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 aEndNameList and of zEndNameList). The K-th integer in the list relates to the K-th simple connection. Each integer represent the
simple connection’s protection role: 1 or 2.
e) 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 aEndNameList and of zEndNameList). The K-th string in the list relates to the K-th simple connection. Each string represent the
simple connection’s position in the trail component, as explained in section 10.f).
Examples
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.
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:
1. aEndNameList = ([4]A1, A1, A2, A3) zEndNameList = ([4]A2, A3, A1, A1)
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)
2. 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)
3. 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)
4. aEndNameList = ([4]F1, F1, F2, F2) zEndNameList = ([4]F2, F2, F1, F1)
OrderNumber = ([4](1,7,-1,-1), (-1,-1,2,9), (3,9,-1,-1), (-1,-1,4,11))
5. 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))
6. aEndNameList = ([2]G1, G2) zEndNameList = ([2]G2, G1)

OrderNumber = ([2](1,11,-1,-1), (3,5,-1,-1))
7. 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))
8. aEndNameList = ([4]M1, M1, M2, M2) zEndNameList = ([4]M2, M2, M1, M1)
OrderNumber = ([4](1,15,-1,-1), (-1,-1,2,19), (3,1,-1,-1), (-1,-1,4,1))
PathType = ([4]1,2,1,2) XC_Type = ([4]Stop, Stop, Start, Start)
9. aEndNameList = ([2]C1, C2) zEndNameList = ([2]C2, C1)

OrderNumber = ([2](-1,-1,2,3), (-1,-1,4,17))
10. aEndNameList = ([2]D1, D2) zEndNameList = ([2]D2, D1)

OrderNumber = ([2](-1,-1,2,5), (-1,-1,4,15))
11. aEndNameList = ([2]J1, J2) zEndNameList = ([2]J2, J1)

OrderNumber = ([2](-1,-1,2,13), (-1,-1,4,7))
12. aEndNameList = ([2]L1, L2) zEndNameList = ([2]L2, L1)

OrderNumber = ([2](-1,-1,2,15), (-1,-1,4,5)

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

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.
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
DRI with protected links

(same diagram as standard DRI)
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

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
Protected Server Trail (Unidirectional)

Note: The main path goes from A1 to R1. The protection path goes from E1 to S1.
Main 1: None-A1 Start 1 primary 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-None Stop 1
Protection 2: None-E1 Start 2 primary subcomponent
D2-D1 Mid 2
C3-C2 Mid 2
F1-F2 Mid 2
G1-G3 Mid 2
H1-H2 Mid 2
K1-K2 Mid 2
N1-N2 Mid 2
S1-None Stop 2

Bidirectional Trail with Protection
G 2
1
1 B 2
2
2
1
1 A E 2 1 F 2 1 H 1 K 2 1 M 2
3 3
3 3
1 C 2 1 D 2
1 2
J 2 1 L
Point-to-Multipoint
1 A 2 1 B 2 1 C 2 1 F 2 1 G 2 1 J 2 1 M 2 1 R 2
3 3
1
1
D H 2 1 K 2 1 N 2 1 S 2
2
3
1
1
E
L 2 1 P 2 1 T 2
2

DRI
1 B 2 1 E 3 1 G 3 1 J1 2 1 L 2
2 2 3
1
2 1
N 3
1 A P
2
3 2
1 2
Q M
2 1
2
2
1 C 2 1 D 2 1 F 3
K
2 1
1 H 3
DNI
1 B 2 1 E 2
1 J1 2 1 L 2
1 G 4 3
2 1
2
3 N 3
1 A
2
3
2 1
1 C 2 1 D 2 1 F H 2 1 K 2 1 M 2

Protected Server Trail
A 1 1 B 2 1 C 2 1 F 2 1 G 2 1 J 2 1 M 2 1 R
3 3
1 1
E 1 2 D H 2 1 K 2 1 N 2 1 S

Performance and
Monitoring
Management
in ECI EMS-NMS
Interface (eNI)
Performance Management in eNI page 1 of 18

Contents
0B
1 PM provided over MTNM ........................................................................ 3

1.1 XDM PM provided over MTNM ...................................................................................... 3
1.2 Apollo PM provided over MTNM.................................................................................... 4
2 Syncom and Micro PM provided over MTNM .......................................... 5
3 Optical Parameters.................................................................................. 6
3.1 Optical Parameters for Optical Section / OCH ................................................................ 6
3.2 ONCP Port data parameters (OTS ports) ........................................................................ 6
3.3 ONCP Channel data parameters (OCHP, OTU and CTPs3 of OTS
ports)............................................................................................................................... 7
3.4 ONCP thresholds of port data parameters (OTS ports) .................................................. 8
3.5 ONCP thresholds of channel data parameters (OCHP, OTU).......................................... 9
4 Ethernet PM .......................................................................................... 10
5 Supported MTNM PM Operations ......................................................... 14
6 PM support in EMS-Syncom .................................................................. 16
7 PM Record Fields ................................................................................... 17

1 PM provided over MTNM
1.1 XDM PM provided over MTNM

PM Parameter
(location)
UAS (bi-directional)
FEC_EC (NE Rx)

BBE (NE Rx)
BBE (FE Rx)

UAS (NE Rx)
OFS (NE Rx)
UAS (FE Rx)

NPJ (NE Rx)
SES (NE Rx)
SES (FE Rx)
PPJ (FE Rx)

CV (NE Rx)
ES (NE Rx)
CV (FE Rx)
PJ (NE Rx)
ES (FE Rx)
4
4
Layer
3
RS_STMn √ √ √ √ √
MS_STMn √ √ √ √ √
VC4_64C √ √ √ √ √ √ √ √ √ √ √ √
VC4_16C √ √ √ √ √ √ √ √ √ √ √ √
VC4_4C √ √ √ √ √ √ √ √ √ √ √ √
VC4/AU4 √ √ √ √ √ √ √ √ √ √ √ √
VC3/TU3/AU3/STS1 √ √ √ √ √ √ √ √ √ √ √ √
TU2 √ √ √ √ √ √ √ √ √ √ √ √
VC12/TU12 √ √ √ √ √ √ √ √ √ √ √ √
DS3/45M √1 √2 √ √ √ √1 √1 √1 √1 √1
E3/34M √1 √2 √ √ √ √1 √1 √1 √1 √1
E1/2M √1 √2 √ √ √ √1 √1 √1 √1 √1
OCH (with FEC) /OTUk √ √ √ √ √
DSR_GBE √ √ √ √
Fragment √ √ √ √
(Virtual Concat Group)
1
Applies if the PDH signal is framed
2
Applies if the PDH signal is unframed
3
OFS is provided as an extension parameter “LSNExt_OFS” for RS_STMn.
4
BBE is provided as CV for SONET NEs.

1.2 Apollo PM provided over MTNM
LSNEXT_MONITORED_SECON
PM Parameter
(location)
Layer
FEC_EC (NE Rx)

UAS (NE Rx)
BBE (NE Rx)
SES (NE Rx)

ES (NE Rx)
1
DS (any)
OTUk √ √ √ √ √ √
1
Applies for any type of PM location

2 Syncom and Micro PM provided
over MTNM
PM
Parameter
TC UAS (NE/FE Rx/Tx)

TC BBE (NE/FE Rx/Tx)
TC SES (NE/FE Rx/Tx)

(location)
TC ES (NE/FE Rx/Tx)
Layer
UAS (NE Tx /Rx)
BBE (NE Tx /Rx)
UAS (FE Tx /Rx)

SES (NE Tx /Rx)
BBE (FE Tx /Rx)
SES (FE Tx /Rx)

ES (NE Tx /Rx)
ES (FE Tx /Rx)
6
OFS (NE Rx)

6
6
6
6
CV (NE Rx)
6
CV (FE Rx)
PJ (NE Rx)
6
RS_STMn √ √ √ √ √
MS_STMn √ √ √ √
6
VC4 √ √ √ √ √ √ √ √ √ √ √ √ √
VC3 √ √ √ √ √ √ √ √ √
VC12 √ √ √ √ √ √ √ √ √
140M √ √ √ √ √5 √5 √5 √5
DS3/45M √ √ √ √ √5 √5 √5 √5
E3/34M √ √ √ √ √5 √5 √5 √5
E1/2M √ √ √ √ √5 √5 √5 √5
5
Far end PM parameters are supported for PDH only when the PDH signal is fully framed
supporting backward indications.
6
In Syncom VC4 PM parameters are supported for TCM and for both the Tx (Outgoing TCM
measurements) and the Rx.

3 Optical Parameters
3.1 Optical Parameters for Optical Section

/ OCH
PM Parameter PM Location Granularity Unit Comment
PMP_RPL PML_NEAR_END_Rx NA dBm Rx Power
PMP_TPL PML_NEAR_END_Tx NA dBm Tx Power
PMP_OPT_LBIAS PML_NEAR_END_Tx NA mA Laser Bias
PMP_OPT_LTEMP PML_NEAR_END_Tx NA C Laser Temp
3.2 ONCP Port data parameters (OTS

ports)
Parameter Location Granularity Unit Comment
LSNEXT_OPT_TOTAL_PWR PML_NEAR_END_Rx, NA dBm Total power

PML_NEAR_END_Tx
LSNEXT_OPT_ AVERAGE_PWR PML_NEAR_END_Rx, NA dBm Average power
PML_NEAR_END_Tx per channel
LSNEXT_OPT_NUM_CHANNEL PML_NEAR_END_Rx, NA Actual # of
PML_NEAR_END_Tx channels (Nch)
LSNEXT_OPT_ACT_SPAN_LOSS PML_NEAR_END_Rx NA dB Actual span
loss
LSNEXT_OPT_EXP_SPAN_LOSS PML_NEAR_END_Rx NA dB Expected
accumulated
span loss
LSNEXT_OPT_INITAL_GAIN PML_NEAR_END_Tx NA dB Initial gain of
amplifier card
excluding
RAMAN
LSNEXT_OPT_ACTUAL_GAIN PML_NEAR_END_Tx NA dB Actual gain of
amplifier card
excluding
RAMAN
LSNEXT_OPT_ACTUAL_RAMAN_GAIN PML_NEAR_END_Tx NA dB Initial gain of
RAMAN
amplifier card
LSNEXT_OPT_ACTUAL_TILT PML_NEAR_END_Tx NA dB Actual tilt of
amplifier card
excluding
RAMAN

3.3 ONCP Channel data parameters (OCHP,
OTU and CTPs3 of OTS ports)
Parameter Location Granularity Unit Comment
LSNEXT_OPT_FREQUENCY PML_NEAR_END_Rx, NA THz Frequency
PML_NEAR_END_Tx
LSNEXT_OPT_SIGNAL_TYPE PML_NEAR_END_Rx, NA Payload Type of the
PML_NEAR_END_Tx type signal
LSNEXT_OPT_CHANNEL_DISPERSION PML_NEAR_END_Rx, NA ps/nm Acc.
PML_NEAR_END_Tx dispersion of
the channel
LSNEXT_OPT_CHANNEL_SPREADING PML_NEAR_END_Rx, NA GHz Filtering
PML_NEAR_END_Tx tolerance of
the channel
LSNEXT_OPT_CHANNEL_PWR PML_NEAR_END_Rx, NA dBm Power
PML_NEAR_END_Tx
LSNEXT_OPT_CHANNEL_OSNR PML_NEAR_END_Rx, NA dB/0.1nm OSNR
PML_NEAR_END_Tx
LSNEXT_OPT_CHANNEL_PMD PML_NEAR_END_Rx, NA psec PMD
PML_NEAR_END_Tx
LSNEXT_OPT_CHANNEL_PDL PML_NEAR_END_Rx, NA dB PDL
PML_NEAR_END_Tx
LSNEXT_OPT_CHANNEL_NLT PML_NEAR_END_Rx, NA dBm The
PML_NEAR_END_Tx accumulated
nonlinearity
threshold
LSNEXT_OPT_CHANNEL_DISTANCE PML_NEAR_END_Rx, NA km The
PML_NEAR_END_Tx accumulated
distance
4
LSNEXT_OPT_ACT_SPAN_LOSS PML_NEAR_END_Rx NA dB Actual span
loss
4
LSNEXT_OPT_EXP_SPAN_LOSS PML_NEAR_END_Rx NA dB Expected
accumulated
span loss
Comments to table:
1
44/88 X OCH CTPs for Mux / DeMux, FOADM,ROADM
2
OMS CTP for amplifiers, DCF, C/T Filter
3
OMS CTP of OTS PTP should specify a frequency for which ONCP data will be retrieved
4
Relevant only for OCHP ports of OLP card

3.4 ONCP thresholds of port data parameters (OTS ports)
Granul Location
Parameter Location Unit Comment
arity in Trail
PML_NEAR_END_Rx,
LSNEXT_OPT_TOTAL_PWR_MIN NA dBm Min Total power all TPs
PML_NEAR_END_Tx
PML_NEAR_END_Rx,
LSNEXT_OPT_TOTAL_PWR_MAX NA dBm Max Total power all TPs
PML_NEAR_END_Tx
LSNEXT_OPT_ACT_SPAN_LOSS_MIN PML_NEAR_END_Rx NA dB Minimum accumulated span loss all TPs
LSNEXT_OPT_ACT_SPAN_LOSS_MAX PML_NEAR_END_Rx NA dB Maximum accumulated span loss all TPs
PML_NEAR_END_Tx Amplifier
TPs
LSNEXT_OPT_INITAL_GAIN_MIN NA dB Minimum initial gain
excluding
RAMAN
TPs
LSNEXT_OPT_INITAL_GAIN_MAX NA dB Maximum initial gain
excluding
RAMAN
TPs
LSNEXT_OPT_ACTUAL_GAIN_MIN NA dB Minimum actual gain
excluding
RAMAN
TPs
LSNEXT_OPT_ACTUAL_GAIN_MAX NA dB Maximum actual gain
excluding
RAMAN
PML_NEAR_END_Tx RAMAN
LSNEXT_OPT_ACTUAL_RAMAN_GAIN_MIN NA dB Minimum actual gain Amplifier
TPs
PML_NEAR_END_Tx RAMAN
LSNEXT_OPT_ACTUAL_RAMAN_GAIN_MAX NA dB Maximum actual gain Amplifier
TPs

3.5 ONCP thresholds of channel data parameters (OCHP, OTU)
Granul
Parameter Location Unit Comment Location in Trail
arity
Only for OTU, non-OTN
1 Acc. dispersion of the
LSNEXT_OPT_CHANNEL_DISPERSION_MIN PML_NEAR_END_Rx,PML_NEAR_END_Tx NA ps/nm colored and OCHP(Alien
channel
Lambda)
1 Acc. dispersion of the
LSNEXT_OPT_CHANNEL_DISPERSION_MAX PML_NEAR_END_Rx,PML_NEAR_END_Tx NA ps/nm colored and OCHP(Alien
channel
Lambda)
1
LSNEXT_OPT_CHANNEL_PWR_MIN PML_NEAR_END_Rx,PML_NEAR_END_Tx NA dBm Minimum Power threshold colored and OCHP(Alien
Lambda)
1
LSNEXT_OPT_CHANNEL_PWR_MAX PML_NEAR_END_Rx,PML_NEAR_END_T NA dBm Maximum Power threshold colored and OCHP(Alien
Lambda)
1
LSNEXT_OPT_CHANNEL_OSNR_MIN PML_NEAR_END_Rx,PML_NEAR_END_Tx NA dB/0.1nm Minimum OSNR thresholds colored and OCHP(Alien
Lambda)
1
LSNEXT_OPT_CHANNEL_PMD_MAX PML_NEAR_END_Rx,PML_NEAR_END_Tx NA psec Maximum PMD threshold colored and OCHP(Alien
Lambda)
1
LSNEXT_OPT_CHANNEL_PDL_MAX PML_NEAR_END_Rx,PML_NEAR_END_Tx NA dB Maximum PDL threshold colored and OCHP(Alien
Lambda)
1 The maximum accumulated
LSNEXT_OPT_CHANNEL_NLT_MAX PML_NEAR_END_Rx,PML_NEAR_END_Tx NA dBm colored and OCHP(Alien
nonlinearity threshold
Lambda)
Minimum accumulated Only for OCHP ports of
LSNEXT_OPT_ACT_SPAN_LOSS_MIN PML_NEAR_END_Rx NA dB
span loss OLP card
Maximum Only for OCHP ports

LSNEXT_OPT_ACT_SPAN_LOSS_MAX PML_NEAR_END_Rx NA dB
accumulated span loss of OLP card
1
PML_NEAR_END_Rx location is relevant for OTU and non-OTN colored ports and PML_NEAR_END_Tx location relevant for OCHP Alien Lambda

4 Ethernet PM
Ethernet PM parameters are presented in the following table. 64 bit counters shall be
provided within the 32 bits allowed in MTNM with an indication of Invalid if the counter
exceeds the 32 bits. The counters which apply also to LAG objects are checked in the LAG
column.
Counter Name RFC EMS counter name eNI counter name eNI PM Location LAG
StatsOctets 2819 Rx Octets PMP_OCTETS PML_NEAR_END_Rx √
StatsPkts 2819 Rx Pkts PMP_FRAMES PML_NEAR_END_Rx √
StatsConfBroadcastPkts 2819 Rx Broadcast Pkts PMP_BROADCASTPKTS PML_NEAR_END_Rx √
StatsConfMulticastPkts 2819 Rx Multicast Pkts PMP_MULTICASTPKTS PML_NEAR_END_Rx √
StatsCRCAlignErrors 2819 Rx CRC Align Error Pkts PMP_AE PML_NEAR_END_Rx √
StatsUndersizePkts 2819 Rx Undersize Pkts PMP_SUPKTS PML_NEAR_END_Rx √
StatsOversizePkts 2819 Rx Oversize Pkts PMP_SOPKTS PML_NEAR_END_Rx √
StatsFragments 2819 Rx Fragments PMP_SFRAGS PML_NEAR_END_Rx √
StatsJabbers 2819 Rx Jabber Pkts PMP_SJABBERS PML_NEAR_END_Rx √
TxPktsOK Tx Pkts PMP_FRAMES PML_NEAR_END_Tx √
StatsBadPkts Rx Error Pkts PMP_ERRORS PML_NEAR_END_Rx √
RxOctectsBad Rx Error Octets LSNEXT_ERROR_OCTETS PML_NEAR_END_Rx √
TxAverageOctectRate Tx Average Octet Rate LSNEXT_OCTET_RATE_AVG PML_NEAR_END_Tx √
TxPeakOctetRate Tx Peak Octet Rate LSNEXT_OCTET_RATE_PK PML_NEAR_END_Tx √
TxPeakOctetRateTimest Tk Peak Timestamp LSNEXT_OCTET_RATE_PK_TIME PML_NEAR_END_Tx √
amp
PrioRandomDropOctets 3289 RED Drop Octets BE LSNEXT_PRIO0_RAND_DROP_OCTE PML_NEAR_END_Tx √
0 TS
PrioRandomDropOctets 3289 RED Drop Octets LSNEXT_PRIO2_RAND_DROP_OCTE PML_NEAR_END_Tx √
2 Bronze TS
PrioRandomDropOctets 3289 RED Drop Octets Silver LSNEXT_PRIO4_RAND_DROP_OCTE PML_NEAR_END_Tx √
4 TS
PrioRandomDropOctets 3289 RED Drop Octets Gold LSNEXT_PRIO6_RAND_DROP_OCTE PML_NEAR_END_Tx √
6 TS
TxOctets Tx Octets PMP_OCTETS PML_NEAR_END_Tx
RxPauseFrame 2665 Rx Pause Frames PMP_PAUSEFR PML_NEAR_END_Rx
TxPauseFrame Tx Pause Frames PMP_PAUSEFR PML_NEAR_END_Tx
VlanPortInDiscards Rx VLAN Pkt Discards LSNEXT_VID_DISCARD_PKTS PML_NEAR_END_Rx
DuplicateMacAlrtSec Duplicate MAC Alert LSNEXT_DUPLICATE_MAC PML_NEAR_END_Tx
Seconds
PortForwardTrans Port Forward LSNEXT_STP_FWD_TRANSITIONS PML_NEAR_END_Tx
Transitions
StatsCrcAlignErrors 2819 Rx CRC Align Error Pkts PMP_AE PML_NEAR_END_Rx
Prio0StatsPkts 2819 Unicast Pkts BE PMP_PRIO_PKTS0 PML_NEAR_END_Tx
Prio2StatsPkts 2819 Unicast Pkts Bronze PMP_PRIO_PKTS2 PML_NEAR_END_Tx
Prio4StatsPkts 2819 Unicast Pkts Silver PMP_PRIO_PKTS4 PML_NEAR_END_Tx
Prio6StatsPkts 2819 Unicast Pkts Gold PMP_PRIO_PKTS6 PML_NEAR_END_Tx
TxUtilization Tx Utilization LSNEXT_UTILIZATION PML_NEAR_END_Tx

The following PM counters are added for EMS-XDM v6.2:
 EthPmCounters
 TxDropTimeoutPackets LSNEXT_DROP_TIMEOUT_PKTS PML_NEAREND_Tx
 TxDropTimeoutOctets LSNEXT_DROP_TIMEOUT_OCTETS
PML_NEAREND_Tx
 IfPortDropPktsCos0 LSNEXT_PORT_DROP_PKTS0 PML_NEAREND_Tx
 IfPortPassedOctetsCos0 LSNEXT_PORT_OCTETS0 PML_NEAREND_Tx
 IfPortPassedPktsCos0 LSNEXT_PORT_PKTS0 PML_NEAREND_Tx
 VlanPortInOctetsDiscard LSNEXT_VID_DISCARD_OCTETS PML_NEAREND_Rx
 RxHdrErrPkt LSNEXT_HDR_ERR_PKTS PML_NEAREND_Rx
 IfPortDropOctetsCosPercent0 LSNEXT_PORT_DROP_OCTETS_PRCNT0
PML_NEAREND_Tx
PML_NEAREND_Tx

PML_NEAREND_Tx
PML_NEAREND_Tx
PML_NEAREND_Tx
PML_NEAREND_Tx
PML_NEAREND_Tx
PML_NEAREND_Tx
 IfOutWredPercent LSNEXT_WRED_PRCNT PML_NEAREND_Tx
 TxUtilization LSNEXT_UTILIZATION PML_NEAREND_Tx
 LinkDownSeconds PMP_LOLS PML_NEAREND_Rx
 PHYErrors LSNEXT_PHY_ERRORS PML_NEAREND_Rx
 c64Octets PMP_PKTS64OCTETS PML_NEAREND_Rx
 c65_127Octets PMP_PKTS65TO127OCTETS PML_NEAREND_Rx
 c1519_MxFrameSizeOctets PMP_PKTS1519TOMAXOCTETS PML_NEAREND_Rx
 RxBufferOverflow LSNEXT_OVERFLOW PML_NEAREND_Rx
 VcgSinkPmCounters
 Pcs LSNEXT_PCS PML_NEAREND_Rx
 Uas PMP_UAS PML_NEAREND_Rx
 Utl LSNEXT_UTILIZATION PML_NEAREND_Rx
 PolicerPmCounters
 GreenOctetsPMP_ingressGreenOctetCount PML_NEAREND_Rx
 YellowOctets PMP_ingressYellowOctetCount PML_NEAREND_Rx
 GreenPkts PMP_ingressGreenFrameCount PML_NEAREND_Rx
 YellowPkts PMP_ingressYellowFrameCount PML_NEAREND_Rx
 BridgePmCounters
 LoClsDiscardPkts LSNEXT_LOW_PRIO_DISCARD PML_NEAREND_Rx
 ForwardedPkts PMP_FRAMES PML_NEAREND_Tx
 LoClsDiscardPercentPkts LSNEXT_LOW_PRIO_DISCARD_PRCNT
PML_NEAREND_Rx

 FdbPmCounters
 FdbFull LSNEXT_FDB_FULL PML_NEAREND_Rx
 FibUtilization LSNEXT_FIB_UTILIZATION PML_NEAREND_Rx
 FibQuotaUtilization LSNEXT_FIB_QUOTA_UTILIZATION PML_NEAREND_Rx
 VsiPmCounters
 McVpnOctets LSNEXT_VID_OCTETS PML_NEAREND_Rx
 McVpnOctetsDropped LSNEXT_VID_OCTET_DISCARDS PML_NEAREND_Rx
 McVpnPacketsDropped LSNEXT_VID_FRAME_DISCARDS PML_NEAREND_Rx
 McVpnAverageRate LSNEXT_VID_AVERAGE_RATE PML_NEAREND_Rx
 McVpnUtilization LSNEXT_VID_UTILIZATION PML_NEAREND_Rx
 QuotaDroppedPkts LSNEXT_QUOTA_DISCARDS PML_NEAREND_Rx

10 Additional Info
For additional info parameters per object structure, see the following sections:
SNC SubnetworkConnection_T, SNCCreateData_T, SNCModifyData_T

FDFr FlowDomainFragment_T, FDFrCreateData_T, FDFrModifyData_T
Termination Point TerminationPoint_T
Managed Element ManagedElement_T
Topological Link TopologicalLink_T, TLCreateData_T
Protection Group ProtectionGroup_T
Cross Connection CrossConnect_T
EMS EMS_T
Subnetwork MultiLayerSubnetwork_T
MFD MatrixFlowDomain_T
Equipment Equipment_T, EquipmentHolder_T
TCProfile TCProfile_T
Switch Data SwitchData_T
Maintenance Ops CurrentMaintenanceOperation_T
ME Group LSN_MEGroup_T
Configure Protection Group LSNConfigureProtectionGroupData_T
MaintenanceAssociation LSN_OAM_MaintenanceAssociation_T
Call Call_T,CallCreateData_T,CallModifyData_T
Top Level SNC Top Level SubnetworkConnection_T, SNCCreateData_T
Logical Interface LSN_CTPData_T, TerminationPoint_T

LightSoft NBI Explanatory Documents Additional Info
10.1 SNC
Name SubnetworkConnection_T Default Possible Values AVC Comment EMS-LS Version
SNCCreateData_T when not or Data Type LS-OSS Information
SNCModifyData_T provided empty=both
A<n>Role, Z<n>Role SubnetworkConnection_T depends on {CMEndPoint, NO Explained in SD1-1_additionalInfoUsage (in

SNCCreateData_T NE traversal LCEndPoint} Supporting Documents).
SNCModifyData_T
AlarmReporting SubnetworkConnection_T On {On, Off} YES Applies only to Alarms which are reported by the
SNCCreateData_T SNC, regardless of the setting for the related TPs.
SNCModifyData_T
Fixed SubnetworkConnection_T False boolean No Fixed and LSNExt_FixedSNC are set to the same
value. Both are used for version compatibility.
LSNExt_aEndVC4Ind SNCCreateData_T <VC4Index>[,<VC4Index> List of decimal format n or nn (short). This list is EMS-LS
exList SNCModifyData_T [,<VC4Index>]...] mandatory for SNC TPs defined on ASF16 in EMS
Syncom. The size of the list is defined by the size of
the aEnd list and defines a VC4 for each aEnd TP.
LSNExt_ASON_Asso SubnetworkConnection_T not relevant {Trail ID} YES EMS-NMS: used in ASON Headend SNCs EMS-LS LSv7
ciatedTrailID
LSNExt_AsonExtraTr SubnetworkConnection_T not relevant integer {1-64} YES EMS-NMS: Number of Extra Traffic VC4s within a EMS-LS LSv7
afficVcSize VCG; used in ASON Headend SNCs
LSNExt_ASON_Head SubnetworkConnection_T High {High(1), YES The Headend Priority value of an ASON trail.
EndPriority SNCCreateData_T LowWithDelay(2)}
SNCModifyData_T
LSNExt_ASON_Local SubnetworkConnection_T not relevant {Non-Localized, Strict YES NMS-OSS: This is equivalent to the LS user selection
izedRestoration SNCCreateData_T Localization, Relaxed on the LS GUI.
Localization} EMS-NMS: used in ASON Headend SNCs


LSNExt_ASON_WTR SubnetworkConnection_T 0 integer in range 0,1 to YES(N WTR is the stabilization delay in minutes following LSv8.1
SNCCreateData_T 1440 orthb rerouting a trail before traffic is switched back to the
ound originally provisioned path.
only) 0 - means :
- unspecified WTR which is defined by ME
- not relevant for not ASON trail
- not relevant for ASON Extra Traffic trail
LSNExt_ASON_Prot SubnetworkConnection_T not relevant {"1+R"(1),"1++"(2), YES EMS-LS

ection SNCCreateData_T "1+1+R"(3), EMS-NMS: used in ASON Headend SNCs
SNCModifyData_T "ExtraTraffic"(4)}
{"1+R"(1),"1++"(2), YES NMS-OSS only: This is equivalent to the LS user LS-OSS LSv8
"1+1+R"(3), selection on the LS GUI.
"ExtraTraffic"(4),
"ExtraTraffic &
Underlying"(5),
"1+R & Underlying"(6),
"1++ & Underlying"(7),
"1+1+R & Underlying"(8)}
LSNExt_ASON_Rero SubnetworkConnection_T Provisioned Provisioned(1), YES Used for LightSoft-OSS only. Not used for LDL or DLT.
ute_State Rerouted(2), SC
Restoration(3),
Preempted(4),
Rerouted_Preempting(5)
LSNExt_ASON_Confi SubnetworkConnection_T "OK" {"OK","Not Configured"} YES Used for LightSoft-OSS only. "Not Configured" if LS-OSS LSv8
guration the association failed.Otherwise "OK"
LSNExt_ASON_Asso SubnetworkConnection_T not relevant {"Unassociated",“Incompl YES Used for LightSoft-OSS only. Status of a trail LS-OSS LSv8
ciation ete”,“Associated"} association. Not used for a trail that is not ASON.
LSNExt_BypassProte SubnetworkConnection_T DN of node no for bypass tunnels LS-OSS LSv7

ctedNode


LSNExt_BypassProte SubnetworkConnection_T DN of port no for bypass tunnels LS-OSS LSv7

ctedPort
LSNExt_BypassSRLG SubnetworkConnection_T False Boolean yes true if this bypass tunnel path has no SRLG in LS-OSS LSv7
Diverse common with the protected link/node
LSNExt_C2VGroupIn SNCCreateData_T same as

dexAEP SNCModifyData_T LSNExt_VirtualConcatAEP
LSNExt_C2VGroupIn SNCCreateData_T same as

dexZEP SNCModifyData_T LSNExt_VirtualConcatZEP
LSNExt_Color<n> SubnetworkConnection_T GY G/Y/GY yes for E-LSP tunnels; <n> is the CoS number (0-7) LS-OSS LSv7
SNCCreateData_T
LSNExt_ControlPlan SubnetworkConnection_T (HEAD, TAIL) YES Read/Write from/to EMS, indicates if the NE (that
eSncRole contains the SNC), is Head End or Tail End of the
ASON trail. The Head End is responsible to reroute
the ASON trail upon link failure. EMS to LightSoft
only.
LSNExt_Customer SubnetworkConnection_T NULL Free format string Yes

SNCCreateData_T
SNCModifyData_T
LSNExt_DefaultFro SubnetworkConnection_T EMS NamingAttributes_T; one Yes This is used only in protected SNCs, and is needed LSv6
m SNCCreateData_T determines of the elements in the only when there are multiple main paths. It allows
SNCModifyData_T what value aEndList the NMS to specify the default active endpoint.
to use. When the NMS does not provide this parameter, the
EMS makes its own decision.


LSNExt_Destination SubnetworkConnection_T no default Number within the legal YES Each Network ID in the list indicates the Network ID EMS-NMS
NWList SNCCreateData_T range for network IDs. of the Destination PE in the corresponding position
SNCModifyData_T in the Destination PE List. Used only for EMS-NMS.
For bidirectional tunnel, PE A
LSNExt_DestinationNWList is PE Z LSNExt_SourceNW
, and PE Z LSNExt_DestinationNWList is PE A
LSNExt_SourceNW PE.
LSNExt_EditSNCNa SNCCreateData_T DN of SNC to be edited

me
LSNExt_EMSSignatu SubnetworkConnection_T last EMS signature No used only when object is sent with an OCN EMS-LS
re
LSNExt_EXPMode SubnetworkConnection_T L (L,E) YES Indicates L-LSP tunnel or E-LSP tunnel. Not used
when SNC is not a tunnel SNC.
LSNExt_FixedSNC SubnetworkConnection_T False boolean No Whether the SNC is fixed and cannot be removed
through deleteAndDeactivateSNC().
LSNExt_FlexReason SubnetworkConnection_T Integer Yes Indicates the reason that the trail was declared as
Flex. LightSoft to OSS only.
LSNExt_FRR_Protec SubnetworkConnection_T "Node", "Link", "Dual" no indicates what the FRR is protecting LS-OSS LSv7
tion_Mode SNCCreateData_T


LSNExt_Inclusion SNCCreateData_T list of 6-tuples, parallel to Each 6-tuple has the following mandatory fields:
DataList the neTpInclusions list, 1. path type: M | P | B
i.e., for every member of 2. direction: one of the Directionality_T values
neTpInclusions, there is a 3. Extra traffic (relevant for data trails): boolean
6-tuple in 4. Bridge number: integer
InclusionDataList, in the 5. Bridge source EP: DN in string form
corresponding place in 6. Diverse route number: integer
the list; the form of each
6-tuple is explained in
Comment.
LSNExt_LPCapacity SubnetworkConnection_T "STM-1", "STM-4", Specifies the capacity of a lightpath. Only for LS-OSS LSv7
"STM-16", "FC-1G", lightpaths.
"FC-2G","GBE", "GBE8"
LSNExt_OAM_ELSPC SubnetworkConnection_T 0 0-7 YES For E-LSP, indicates which CoS is to be used for
oS SNCCreateData_T OAM-CV.
LSNExt_OamCV SubnetworkConnection_T Disabled Enabled/Disabled yes LS-OSS LSv7
LSNExt_OchMultiro SubnetworkConnection_T False Boolean YES indicates if an OCH trail is multiroute LS-OSS
ute SNCCreateData_T


LSNExt_OchRouteA SubnetworkConnection_T List of List of lists of strings. Yes Applies to OCH SNCs only. Indicates for each A-Z pair EMS-LS LSv6
ndBridgeList SNCCreateData_T empty lists. Outer list is parallel to A-Z the list of Main OCH Route IDs, Protection OCH
SNCModifyData_T pair list. Each inner list Route IDs, Main OCH Bridge IDs, and Protection OCH
has up to 64 strings, Bridge IDs to which it belongs. Optional.
where each string has
four characters and is of
the form XYnn. X is either
M or P (standing for Main
or Protection), Y is either
R or B (standing for Route
or Bridge), and nn is a
two digit number
between 01 and 16. An
inner list can be empty.
LSNExt_RouteAndBr SubnetworkConnection_T empty list. List of lists of strings. Yes Specifies the path type and the bridge number for EMS-LS LSv9
idgeList SNCCreateData_T Outer list is parallel to A-Z each A-Z pair. Applies for any OTN layer except OCH.
SNCModifyData_T pair list. Each inner list For OCH layer see LSNExt_OchRouteAndBridgeList
has up to 64 strings,
where each string has
four characters and is of
the form XYnn. X is either
M or P (standing for Main
or Protection), Y is either
R or B (standing for Route
or Bridge), and nn is a
two digit number
between 01 and 16. An
inner list can be empty.


LSNExt_DNIBridgeLi SubnetworkConnection_T Empty list List of integers in range 0 Yes Specifies if an A-Z pair belongs to DNI Bridge. EMS-LS LSv9
st SNCCreateData_T - 255. The list is parallel 0 - means : A-Z pair does not belong to the DNI
SNCModifyData_T to A-Z pair list. Bridge;
Other valid integer – means: A-Z pair belong to the
DNI Bridge;
Empty list - means : not relevant
Applies for any OTN layer.
LSNExt_ProtectLaye SubnetworkConnection_T integer, see comment 0 UNDERLYING

r 1 CURRENT
2 CURRENT_UNDERLYING
3 UNDEFINED (for unprotected)
LSNExt_Reply_Code SNCCreateData_T empty list list of reply codes NO This parameter is sent only when the SNC structure LS-OSS
s SNCModifyData_T or not relevant to the request is returned as a reply to createAndActivateSNC,or
reported for which this SNC_T is modifySNC, to an OSS.
being returned
LSNExt_SearchPara SubnetworkConnection_T <first criteria> Criteria may be:

meters [,<second criteria> 0 NUMBER_LINKS
[,<third criteria> 1 NUMBER_ELEMENTS
[,<fourth criteria>]]] 2 DIRECTIONALITY_TYPE
3 USER_ASSIGNED_QUALITY
list of integers, where an 4 USER_ASSIGNED_COST
integer represents a 5 DISTANCE
criterion as listed in the 6 NUMBER_INTERSECTIONS_DUCTS
Comment 7 NUMBER_INTERSECTIONS_SGMNT
8 NUMBER_INTERSECTIONS_ME
9 NUMBER_INTERSECTIONS_SGMNT_OPTI
10 LOCATION_CARD
11 LOAD_UTILIZATION
12 NUMBER_SRLGS
LSNExt_SingleServic SubnetworkConnection_T False Boolean no True means tunnel can carry only a single service; LS-OSS LSv7
eOnly v7, Northbound


LSNExt_SNCOriginat SubnetworkConnection_T (MNG, CP) YES Indicates if the SNC was created/modified through
or SNCModifyData_T management (MNG) or Control Plane (CP) .
LSNExt_SourceNW SubnetworkConnection_T no default Number within the legal YES The Network ID part of the Source PE ID. EMS-LS
SNCCreateData_T range for network IDs. Number within the legal range for network IDs.
SNCModifyData_T For bidirectional tunnel both tunnel endpoint are
Head & Tail, at PE A, PE A Net Id is the local
LSNExt_SourceNW, at PE Z, PE Z Net ID
LSNExt_SourceNW is the local LSNExt_SourceNW.
LSNExt_Special_Trai SubnetworkConnection_T not a {LDL, DLT} NO Indicates that the trail (network SNC) is of a special LS-OSS
l special trail type. When a trail is not one of these special types,
the parameter does not exist.
LSNExt_SubnetSign SubnetworkConnection_T last subnetwork signature No used only during Fast Recovery Upload, from EMS to EMS-LS
ature LightSoft, when requested by LightSoft, or used only
when object is sent with an OCN
LSNExt_TimestampS SubnetworkConnection_T current LightSoft No used only when object is sent with an OCN LS-OSS
ignature SNCCreateData_T timestamp
SNCModifyData_T
LSNExt_TrailId SubnetworkConnection_T {<Workstation Id> ; <Trail Yes BG EMS will not provide this attribute.
Id (long)>}
LSNExt_TrailShape SubnetworkConnection_T UNDEFINED one of the following NO Describes the "shape" or "architecture" of the trail LS-OSS
strings: UNDEFINED(0),
FLEX(1),POINT_TO_POINT
(2),POINT_TO_MULTIPOI
NT(3),X(4),Y(5),DIVROUTE
_P2P(6)
LSNExt_TunnelAlloc SubnetworkConnection_T integer yes number of Mbps reserved for this tunnel; same LS-OSS LSv7
atedBW meaning as in GUI


LSNExt_TunnelType SubnetworkConnection_T p2p p2p, p2mp, NO P2P - Point to Point MPLS-TP Unidirectional or LS-OSS LSv7
SNCCreateData_T p2pVirtualRsvp, NA Bidirectional tunnel
P2MP - Point to Multipoint MPLS-TP
Unidirectional tunnel.
p2pVirtualRsvp - P2P unidirectional RSVP-TE
tunnel.
A bypass tunnel can only be P2P tunnel
Not set or reported for SNCs which do not

represent MPLS tunnels.
LSNExt_TunnelUnre SubnetworkConnection_T integer yes number of Mbps of unreserved BW for this tunnel; LS-OSS LSv7
servedBW same meaning as in GUI
LSNExt_TypeDetails SNCCreateData_T NULL {Flex} No Flex - The trail being reported by LightSoft to an OSS
SNCModifyData_T is a Flex trail.
LSNExt_UtilizationC SubnetworkConnection_T <first low>,<first high>, Values are integers

onstraint <second low><second 0 <= X <= 100
high> low <= high
first <= second
same as from GUI and XML
LSNExt_VirtualConc SubnetworkConnection_T List of group indices. Yes Whether there is a CtoV concatenation group for
atAEP SNCCreateData_T <C2VgroupIndex> each of the concatenation groups provided in the
SNCModifyData_T [<sp><C2VgroupIndex> Aend TP list.
[<sp><C2VgroupIndex>]... A string example of the attribute for an SNC
] consisting of 2 virtually concatenated VC4_4V in the
The indices count the Aend:
group (CTP multiples of LSNExtVirtualConcatEP - "[2] 1 5" where the number
LSNExt_VirtualConcatRat [2] indicates the size of the list, 1 is the AUG index of
e) position within the the 1st VC4 group, 5 is the index of the 2nd VC4
Aend list. group.
LSNExt_VirtualConcateRate- 4 where 4 indicates a
VC4_4V rate.


LSNExt_VirtualConc SubnetworkConnection_T Decimal format Yes N where N is an interger 4..64. CTPs in the Aend or
ateRate Zend list will always be sorted by group.
LSNExt_VirtualConc SubnetworkConnection_T List of group indices. Yes Whether there is a CtoV concatenation group for
atZEP SNCCreateData_T <C2VgroupIndex> each of the concatenation groups provided in the
SNCModifyData_T [<sp><C2VgroupIndex> Zend TP list.
[<sp><C2VgroupIndex>]... A string example of the attribute for an SNC
] consisting of 2 virtually concatenated VC4_4V in the
The indices count the Zend:
group (CTP multiples of LSNExtVirtualConcatEP - "[2] 1 5" where the number
LSNExt_VirtualConcatRat [2] indicates the size of the list, 1 is the AUG index of
e) position within the the 1st VC4 group, 5 is the index of the 2nd VC4
Zend list. group.
LSNExt_VirtualConcateRate- 4 where 4 indicates a
VC4_4V rate.
LSNExt_VPNId SNCCreateData_T NULL Free format string Yes

SNCModifyData_T
LSNExt_zEndVC4Ind SubnetworkConnection_T <VC4Index>[,<VC4Index> List of decimal format n or nn (short). This list is EMS-LS
exList SNCCreateData_T [,<VC4Index>]...] mandatory for SNC TPs defined on ASF16 in EMS
SNCModifyData_T Syncom. The size of the list is defined by the size of
the aEnd list and defines a VC4 for each zEnd TP.
SNC_REVERTIVE False Boolean YES Relevant for protected SNCs, when the reversion
mode (revertive, nonrevertive) is known and can be
set for the specific SNC (independent of the general
setting for the NE). "True" means revertive. In the
LightSoft-to-OSS direction, can be sent by LS when
known for the entire SNC, and can be set by the OSS
if LightSoft supports it.
Deprecated since v11.1. Replaced by
LSNExt_ReversionMode


LSNExt_LSPNum_Lis SubnetworkConnection_T Empty list List of 16-bit unsigned No List of LSP number. LSP number is a 16bit integer, EMS-LS LSv9
t SNCCreateData_T integer unique within this tunnel and must differ between
Updated in
SNCModifyData_T Main and Protection LSP.
LSv12
The Nth LSP number in the list, is the LSP number of
the Nth component in the aEnd TP list. When the
LSP is Bidirectional LSP the same LSP number may
appear several times in the list. When bidirectional
path is protected by a bypass, the bypass relevant
LSP number should be NA(-1).
Applies only for bidirectional SNC.
In IP MPLS PEs:
1. This parameter shall be defined also for
unidirectional tunnels.
2. This list shall be 0 or 1 (for backward
compatibility with XDM)
3. Should be the same for all SNCs of the tunnel.
4. The value '0' shall be used for unidirectional LSP
or the Main LSP of a bidirectional tunnel; The
value '1' shall be used for the Protection LSP of
a bidirectional tunnel.
5. A bypass tunnel is considered as a unidirectional
tunnel.
This attribute is relevant for all PE-types. In case of
unidirectional tunnels, it should be downloaded to
the PE only if
LSNExt_Capability_IP_MPLS_Support='true'.
LSNExt_LDI_Enable SubnetworkConnection_T NA “enabled”, Yes The operational state of the LDI AIS (Link Down AIS) EMS-LS LSv9
d SNCCreateData_T “disabled”,”NA”(default) of the main LSP in the tunnel. Relevant for a transit
SNCModifyData_T bidirectional SNC.


LSNExt_ProtectionL SubnetworkConnection_T NA “enabled”, Yes The operational state of the LDI AIS (Link Down AIS) EMS-LS LSv9
DI_Enabled SNCCreateData_T “disabled”,”NA”(default) of the protection LSP in this SNC. Relevant for a
SNCModifyData_T transit SNC.“NA” is used for not supporting Pes
LSNExt_BFDPeriod SubnetworkConnection_T NA Number in ms, from BFD Yes BFD transmission period of the Main LSP in this SNC. EMS-LS LSv9
SNCCreateData_T period list of the MFD. Relevant for a Head & Tail SNC. Applies only for
SNCModifyData_T See bidirectional SNC with LR_T_MPLS layer.
LSNExt_Capability_BFDPe
riod_List
LSNExt_BFDEnable SubnetworkConnection_T NA “enabled”, “disabled”, Yes Enables the BFD transmission on the Main LSP. EMS-LS LSv9
SNCCreateData_T “NA”(default) Applies only for bidirectional SNC with LR_T_MPLS
SNCModifyData_T layer.
LSNExt_ProtectionB SubnetworkConnection_T NA Number in ms, from BFD Yes BFD transmission period of the Protection Main LSP EMS-LS LSv9
FDPeriod SNCCreateData_T period list of the MFD. in this SNC. Relevant for a Head & Tail SNC. Applies
SNCModifyData_T See only for bidirectional SNC with LR_T_MPLS layer.
LSNExt_Capability_BFDPe
riod_List
LSNExt_ProtectionB SubnetworkConnection_T NA “enabled”, “disabled”, Yes Enables the BFD transmission on the Protection LSP. EMS-LS LSv9
FDEnable SNCCreateData_T “NA”(default) Applies only for bidirectional SNC with LR_T_MPLS
SNCModifyData_T layer.
LSNExt_HoldOffTim SubnetworkConnection_T NA Number in ms, from Hold Yes Hold Off Time of the Main LSP in this SNC. Relevant EMS-LS LSv9
e SNCCreateData_T Off capability of the MFD. for a Head & Tail SNC.
SNCModifyData_T See
LSNExt_Capability_HoldO
ff_Range
LSNExt_ProtectionH SubnetworkConnection_T NA Number in ms, from Hold Yes Hold Off Time of the Protection LSP in this SNC. EMS-LS LSv9
oldOffTime SNCCreateData_T Off capability of the MFD. Relevant for a Head & Tail SNC.
SNCModifyData_T See
LSNExt_Capability_HoldO
ff_Range


LSNExt_LSP_WTR SubnetworkConnection_T NA(default). 0-12 minute, in steps of 1 Yes Wait To Restore Time to delay reversion to Normal EMS-LS LSv9
SNCCreateData_T minute,”NA” state when recovering from a failure condition on
SNCModifyData_T the Main LSP in this SNC. Relevant for a Head & Tail
SNC.
LSNExt_ReversionM SubnetworkConnection_T Revertive “NA”(default),"Revertive" yes The Linear Protection reversion mode of the EMS-LS LSv9
ode SNCCreateData_T , "NonRevertive" bidirectional tunnel. Relevant for Head & Tail SNC.
SNCModifyData_T
LSNExt_PathType SubnetworkConnection_T U List of {M, P, B, Yes The NMS will indicate for each A-Z pair if it is a part used
SNCCreateData_T U}<PathType>[<sp><Path of the Main or Protection path, Both, or
SNCModifyData_T Type>[<sp><PathType>]... Undefined.For bidirectional tunnel: M- marks the
] Main LSP, P- marks Bypass or Protection LSP.
LSNExt_ControlCha SubnetworkConnection_T NA “NA”,0-7 YES Control Channel CoS value of a Bidirectional tunnel. EMS-LS LSv9
nnelCoS SNCCreateData_T BWn> = 0 for this CoS & TunnelOam = Enabled.
SNCModifyData_T Values: 0-7, NA
LSNExt_TunnelRole SubnetworkConnection_T no default "Head","Tail","Transit","T SNC Role EMS-LS LSv

SNCCreateData_T ransit&Tail","Head&Tail"
SNCModifyData_T
LSNExt_EOSLayer SNCCreateData_T Layer1 Layer1(1) Yes Optional for EoS trail, Error for LS-OSS
SubnetworkConnection_T Layer2(2) non-EoS trail
HubAndSpoke(3)
LSNExt_EOSType SubnetworkConnection_T EoS_VC12(1) Yes Required for EoS trail, else LS-OSS
SNCCreateData_T EoS_VC3(2) Error; rate of trail must be
EoS_VC4_STS3c(3) consistent with EoS rate
EoS_STS1(4)
MoT_VC12(5)
MoT_VC3(6)
MoT_VC4_STS3c(7)
MoT_STS1(8)


LSNExt_BFD_UpTim SubnetworkConnection_T NA String in format No The time that elapsed since the BFD session last LSv9.1
e HHHHH:MM:SS, where entered Up state. When BFD session exited in Up
H - integer in range 0-9 state, the time is halted. Whenever the BFD session
specifies hours enters Up state this time is reset.
MM – integer in range Applicable only on Head&Tail Main bidirectional LSP.
0-60 specifies minutes It’s dynamic data, sent from server on an explicit eNI
S – integer in range 0-60 request
specifies seconds
LSNExt_ProtectionB SubnetworkConnection_T NA String in format No The time that elapsed since the BFD session last LSv9.1
FD_UpTime HHHHH:MM:SS, where entered Up state. When BFD session exited in Up
H - integer in range 0-9 state, the time is halted. Whenever the BFD session
specifies hours enters Up state this time is reset.
MM – integer in range Applicable only on Head&Tail Protection
0-60 specifies minutes bidirectional LSP.
SS – integer in range 0-60 It’s dynamic data, sent from server on an explicit eNI
specifies seconds request
LSNExt_BFD_State SubnetworkConnection_T “NA” “AdminDown”,” Down”, No Specifies Main LSP local BFD session state at a Head LSv9.1
“Up”, “Unknown”, & Tail PE of a bidirectional tunnel.
“NA”(default) Values:
“AdminDown” -(Admin Down state) session is held
administratively down.
“Down” - the session is down.
“Up” - BFD session is working.
“Unknown” – the state of BFD session is unknown
“NA”- (default) not applicable.
It’s dynamic data, sent from server on an explicit eNI
request


LSNExt_ProtectionB SubnetworkConnection_T “NA” “AdminDown”,” Down”, No Specifies Protection LSP local BFD session state at LSv9.1
FD_State “Up”, “Unknown”, a Head & Tail PE of a bidirectional tunnel.
“NA”(default) Values:
“AdminDown” -(Admin Down state) session is held
administratively down.
“Down” - the session is down.
“Up” - BFD session is working.
“Unknown” – the state of BFD session is unknown
“NA”- (default) not applicable.
request
LSNExt_AIS_LDI_Sta SubnetworkConnection_T “NA” “Yes”, ”No”, ”NA” No Indicates if an AIS Link Down Indication is present or LSv9.1
te not for the Main LSP in the Head & Tail PE.
request
LSNExt_ProtectionA SubnetworkConnection_T “NA” “Yes”, ”No”, ”NA” No Indicates if an AIS Link Down Indication is present or LSv9.1
IS_LDI_State not for the Protection LSP in the Head & Tail PE.
request
LSNExt_Operational SubnetworkConnection_T “NA” "Up", "Down", "NA" No The BD tunnel operational state. LSv9.1
State Values:
“Up” – at list one LSP is operative.
“Down” - all tunnel LSPs are failed.
“NA” - (default) not applicable.
request


LSNExt_PSC_State SubnetworkConnection_T “NA” “NA”,“Normal”, No Protection Switch Coordination (PSC) protocol state LSv9.1
“LocalUnavailable”, per SNC. Relevant for a Head & Tail SNC. PSC state
“RemoteUnavailable”, values:
“LocalProtectingFailure”, a. NA – (default) not applicable.
“RemoteProtectingFailur b. Normal - Both the protection and working paths
e”, are fully allocated and active, data traffic is being
“LocalProtectingAdminist transported over the working path, and no trigger
rative”, events are reported within the domain.
”RemoteProtectingAdmin c. Unavailable - The protection path is unavailable -
istrative”, either as a result of an operator Lockout command
”LocalWTR”,”RemoteWT or a failure condition detected on the protection
R”, “LocalDNR”, path.
”RemoteDNR” d. ProtectingFailure - The working path has reported
a failure condition and the user traffic is being
transported on the protection
e. ProtectingAdministrative The operator has
issued a command switching the user traffic to the
protection path.
f. WTR - Wait-to-Restore The protection domain is
recovering from an SF condition on the working path
that is being controlled by the Wait-to-Restore
(WTR) timer.
g. DNR- Do-not-Revert state - The protection domain
has recovered from a Protecting state, but the
operator has configured the protection domain not
to automatically revert to the Normal state upon
recovery.
The PSC remains in this state until the operator
issues a command to revert to the Normal state or
there is a new trigger to a different state.It’s
dynamic data, sent from server on an explicit eNI
request


LSNExt_Maintenanc SubnetworkConnection_T “NA” “NA”,“Lockout", Yes Required if LSNExt_DRI is Yes EMS-LS LSv9.1
eCommand "ForcedSwitch", Contains number of DRI-bridges.applied to MPLS
"ManualSwitch", Head & Tail SNCs.
”Release” Values:
1. Lockout of Protection: the Protection LSP is
unavailable for traffic.
2. Forced switch: Switches traffic to Protection LSP,
unless an equal or higher priority switch-over
command is in effect.
3. Manual switch: Switches traffic to Protection LSP,
unless a fault condition exists on the Protection LSP
or an equal or higher priority switch-over command
is in effect.
4. Release: An action, initiated externally, that clears
the active external command.
5. NA (default)
LSNExt_WTR SubnetworkConnection_T,S 5 integer in range 0,1 to 12 Yes Relevant for protected SNCs,Specifies the time in EMS-LS LSv11.1
NCCreateData_T minutes of Wait to Restore before traffic is
switched back to the main path
0 - means :
- unspecified WTR
- not relevant for not protected SNCs
LSNExt_ReversionM SubnetworkConnection_T,S “NA” “Revertive”, Yes Relevant for protected SNCs, when the reversion EMS-LS LSv11.1
ode NCCreateData_T “NonRevertive”, “NA” mode is known and can be set for the specific SNC
(independent of the general setting for the NE).
In the LightSoft-to-OSS direction, can be sent by LS
when known for the entire SNC, and can be set by
the OSS if LightSoft supports it.


LSNExt_DiffServ_En SubnetworkConnection_T,S “false” “true”, “false” Yes This parameter is only being used with tunnel SNC EMS-LS LSv11.1
abled NCCreateData_T objects.
The parameter defines whether (=”true”) or not
(=”false”) this tunnel SNC is DiffServ enabled. In the
latter case the tunnel SNC should use the DiffServ
block in the outpout port
The parameter can be configured by both EMS and
NMS. However, while the EMS can modify the value
of this parameter, the NMS cannot change the value
of an existing SNC.
Note : Supported since APTv4
LSNExt_SourcePE_I SubnetworkConnection_T,S Integer 0-65535 Yes For IP/MPLS networks: This parameter is the LSB of EMS-LS LSv12
D NCCreateData_T the Source PE's LSNExt_IPAddr (Router ID).
For IP MPLS/Upgraded PE: The NMS shall internally
assign a value to this attribute at tunnel-creation
time, same value for all tunnel's SNCs. However, it
should download the attribute only to PEs for which
LSNExt_SourceNW_ SubnetworkConnection_T,S Integer 0-65535 Yes For IP/MPLS networks: This parameter is the MSB of EMS-LS LSv12
ID NCCreateData_T the Destination PE's LSNExt_IPAddr (Router ID).


LSNExt_Destination SubnetworkConnection_T,S Integer 0-65536 Yes For IP/MPLS networks: This parameter is the LSB of EMS-LS LSv12
PE_ID NCCreateData_T the Destination PE's LSNExt_IPAddr (Router ID).
LSNExt_Destination SubnetworkConnection_T,S Integer 0-65536 Yes For IP/MPLS networks: This parameter is the MSB of EMS-LS LSv12
NW_ID NCCreateData_T the Destination PE's LSNExt_IPAddr (Router ID).
LSNExt_PETunnel_N SubnetworkConnection_T,S String (length up to 32 no The PE/MFD Tunnel Name for this tunnel. After EMS-LS LSv12
ame NCCreateData_T characters) tunnel-creation, by CLI/EMS user or by LS, the name
cannot be changed. The pattern should be unique
within the PE scope. When LS configures a tunnel,
the value of this attribute is preceded by "LS".
The PE Tunnel Name must be the same at each PE
that the tunnel traverses.
This attribute is relevant for all PE-types. It should be
downloaded to the PE only if


LSNExt_PETunnelID SubnetworkConnection_T,S Unsigned16 no PE Tunnel Identifier for this tunnel. The pattern EMS-LS LSv12
NCCreateData_T should be unique among all tunnels that this PE
serves as their head-PE.
In the case of a bidirectional tunnel, the pattern
should be unique among all tunnels that are
configured between the same source and
destination PEs.
The attribute should be configured to the same
pattern in all tunnel’s cross-connections.
During top-down tunnel-creation the NMS
automatically sets a unique value for the Head PE
and sets this value to all tunnel's cross-connections.
This attribute is relevant for all PE-types. It should be
downloaded to the PE only if
LSNExt_Tunnel_EIR SubnetworkConnection_T,S Integer yes The Tunnel EIR value for this CoS EMS-LS LSv12
_COS0, … , NCCreateData_T
LSNExt_Tunnel_EIR
_COS7
LSNExt_Tunnel_EIR SubnetworkConnection_T,S Integer 1..63 yes The Tunnel EIR Weight for this CoS. The AVC for this EMS-LS LSv12
_Weight_COS0, … , NCCreateData_T attribute is required only in case the matching EIR
LSNExt_Tunnel_EIR Weight Mode is set to "manual".
_Weight_COS7
LSNExt_Tunnel_EIR SubnetworkConnection_T,S "auto" (default), yes The Tunnel EIR Weight Mode for this CoS. In case the EMS-LS LSv12
_Mode_COS0, … , NCCreateData_T "manual" attribute is set to "manual" then the matching EIR
LSNExt_Tunnel_EIR Weight value is required. Otherwise, the EIR Weight
_Mode_COS7 is automatically assigned by the NE.

10.2 FDFr
Name FlowDomainFragment_T Default Possible Values AVC Usage Comment EMS-LS Version
FDFrCreateData_T when not or Data Type LS-OSS Information
FDFrModifyData_T provided empty=both
LSNExt_MESignature FlowDomainFragment_T ME signature No R/O used only during Fast Recovery Upload EMS-LS
value from EMS to LightSoft, when
requested by LightSoft, or when object
is sent with an OCN
LSNExt_EMSSignature FlowDomainFragment_T last EMS No R/O used only when object is sent with an EMS-LS
signature OCN
LSNExt_TimestampSignature FlowDomainFragment_T current LightSoft No R/O used only when object is sent with an LS-OSS
timestamp OCN
LSNExt_DualHoming FlowDomainFragment_T FALSE boolean Yes R/O Indicates if the FDFr/service is

dual-homed.
LSNExt_VFIB_Prov_Size FlowDomainFragment_T number Yes R/W VFIB Provisioned Size

FDFrCreateData_T
FDFrModifyData_T
LSNExt_VFIB_Actual_Size FlowDomainFragment_T number No R/O It is filled in with the current size of the
VFIB whenever the FDFr is uploaded or
whenever NMS gets this parameter
from EMS.
LSNExt_IGMP_Snooping FlowDomainFragment_T Enable/Disable Yes R/W IGMP Snooping mode

FDFrCreateData_T
FDFrModifyData_T
LSNExt_Forward_All FlowDomainFragment_T Enable/Disable Yes R/W Flood All Groups

FDFrCreateData_T
FDFrModifyData_T

LSNExt_IGMP_Member_Interval FlowDomainFragment_T Yes R/W IGMP Group Membership Interval

FDFrCreateData_T
FDFrModifyData_T
LSNExt_LMQT FlowDomainFragment_T Yes R/W IGMP Last Member Query

FDFrCreateData_T
FDFrModifyData_T
LSNExt_MC_Group_Table FlowDomainFragment_T see comment Yes R/W Multicast Group Table

FDFrCreateData_T A list of pairs, where each pair contains
FDFrModifyData_T a DN and an IP address. The DN is the
DN of a port which is part of the
Multicast Group. The IP Address is the
Multicast Address statically configured
to be forwarded over the port.
LSNExt_BSC_Profile FlowDomainFragment_T string Yes R/W Broadcast Storm Control profile name
FDFrCreateData_T
FDFrModifyData_T
LSNExt_BSC_CIR FlowDomainFragment_T long Yes R/W Broadcast Storm Control CIR value
FDFrCreateData_T
FDFrModifyData_T
LSNExt_BSC_CBS FlowDomainFragment_T long Yes R/W Broadcast Storm Control CBS value
FDFrCreateData_T
FDFrModifyData_T
LSNExt_BSC_EIR FlowDomainFragment_T long Yes R/W Broadcast Storm Control EIR value
FDFrCreateData_T
FDFrModifyData_T
LSNExt_BSC_EBS FlowDomainFragment_T long Yes R/W Broadcast Storm Control EBS value
FDFrCreateData_T
FDFrModifyData_T

ServiceStateDetails FlowDomainFragment_T NA {Nonconformant, Yes RO Indicate a problem condition in the LS-OSS

Inconsistent, NA} FDFr. When these conditions exist, the
FDFr State will be set to Partial, and
the Service State Details to a value
indicating the problem. When the FDFr
State is not Partial, the Service State
Details can be set to NA, or not sent.
LSNExt_G8031_Role FlowDomainFragment_T NA {"End", "Main", Yes R/W Indicates the role of a singleton FDFr EMS-LS
FDFrCreateData_T "Protection", which is part of a service which is
FDFrModifyData_T "NA"} G.8031 protected.
LSNExt_HVPLS FlowDomainFragment_T False or boolean Yes(Not R/W Indication that the service is HVPLS LS-OSS
FDFrCreateData_T not implemented
FDFrModifyData_T reported in LSv7 )
LSN_HVPLS_DomainList FlowDomainFragment_T empty List of HPVLS Yes(Not R/W ([size of HVPLS domain LS-OSS
FDFrCreateData_T list or not domains. implemented sequence]{“[string_size]hvplsDomain
FDFrModifyData_T reported each domain has: in LSv7 ) name”;boolean;([size of MFD's DN
sequence ]“[string_size]MFD DN”))})
i. Displayable
name (no e.g.
checking done) ([2]{“[12]hvplsDomain1”;True;([1]“[88]DN
ii. Spoke (T/F) of MFD with lengh 88 characters”)},
iii. List of MFDs {“[12]hvplsDomain2”;False;([2]”[88]DN of
(DNs) MFD with lengh 88 characters”,“[90]DN of
MFD with lengh 90 characters”)})
LSNExt_VFIB_Size_Profile FlowDomainFragment_T NA string. "VFib" Yes R/W VFIB Quota. The quota is configured by EMS-LS LSv12
FDFrCreateData_T profile-name referring to one of the vFIB Quota profiles
FDFrModifyData_T ("VFib" profile-type) available at the related
PE.

LSNExt_MTU_Mismatch_Ignore FlowDomainFragment_T True “true”, “false” Yes R/W Ignore PW MTU in tLDP PW signaling. EMS-LS LSv12.1
FDFrCreateData_T Used only for tLDP signaled PW.
FDFrModifyData_T MTU Mismatch Ignore should be
configured per PW. Boolean. Should
not be sent to VSI in PE with
LSNExt_Capability_IP_MPLS_Protocols
with out tLDP.
LSNExt_VPN_ID FlowDomainFragment_T LSNExt_L 4 octets Hex No R/W User config 4 bytes. Internal format is 7 EMS-LS LSv12
FDFrCreateData_T 2VPN_ID number bytes where 4 bytes are VPN ID and 3 bytes
FDFrModifyData_T In are the OUI.
Used by NMS / CLI to network-wise
MS-PW
coordination of the VPN.
S-PE: Static PW: Used also as default PW ID (Aka
network- Connection ID in CESR CLI)
wise Autodiscovery: The VPN ID is used for BGP
unique signaling.
pattern The attribute is initialized by default to the
(other value of LSNExt_L2VPN_ID. Same attirubute
than the is initializes by default in MS-PW, per each
S-PE, to a unique ID. Anyhow, the user can
LSNExt_L
overide all defaultly selected VPN IDs and
2VPN_ID) set the numbers manually at create service.
In such a case, NMS should validate that all
numbers are unique per all the existing VPN
IDs.
LSNExt_VSI_Name FlowDomainFragment_T "LS_<LSN string No R/W Routing Instance Name” in CLI. A NE-unique EMS-LS LSv12
FDFrCreateData_T Ext_VPN name for this VSI, for accessing this service
FDFrModifyData_T _ID>" via CLI . At Create Service NMS should send
for this parameter a default value which is
based on LSNExt_VPN_ID in a string format.
That is, "LS_<LSNExt_VPN_ID>".

10.3 Termination Point

Name Default Possible Values AVC Comment EMS-LS Version
when not or Data Type LS-OSS Information
provided empty=both
LSNExt_MESignature ME signature value No used only during Fast Recovery Upload from EMS to LightSoft, EMS-LS
when requested by LightSoft, or when object is sent with an OCN
LSNExt_EMSSignature EMS signature value No used only when object is sent with an OCN EMS-LS
LSNExt_TimestampSignature current LightSoft No used only when object is sent with an OCN LS-OSS
timestamp
LSNExt_LOSwitchCapable True Boolean No The CTPs contained by the PTP support LO SNCP or 1+1.
LSNExt_HOSwitchCapable True Boolean No HO CTPs contained by the PTP support HO SNCP or 1+1.
LSNExt_VirtualConcatCapable False Boolean No Whether the PTP supports virtual concatenation (e.g. of its AU4
CTPs).
LSNExt_GroupInfo NULL - i.e. no (<GroupType>, No For connectivity management in ECI NMS.

connectivity <VC4InstanceList>), For codes, see Group Info Codes document.
limitations. [(<GroupType>,
<VC4InstanceList>), ...]
LSNExt_TechnologyLayer {OTN, SDH, ETH} No LightSoft places a PTP in the correct technology layer according EMS-LS
to this parameter. When not provided, placement is according to
the Topology application rules. For IP/MPLS port the value should
be ETH.
LSNExt_SnkSrcPartner NULL The DN of the No Used any place where a sink TP's corresponding source TP, or
corresponding TP. vice versa, must be explicitly presented.
LSNExt_LineRate NULL String No These values are used by LightSoft to determine a trail's Payload
Type.


provided empty=both
LSNExt_LEUnit NULL String No When a set of ports is defined as a Logical Element, this is the
unique LE name. When this attribute is set for a PTP, it indicates
that the PTP belongs to the LE.
LSNExt_OchLegCount 1 number (byte) No The number of SNC legs that a contained OCH CTP can be the
source of. Multiple legs can be for SNCP or for
point-to-multipoint use. "1" means support only for unprotected
point-to-point.
LSNExt_LegCount 0 number (byte) No The number of SNC legs that a contained CTP can be either the EMS-LS V9
source or sink of. Multiple legs can be for SNCP or for
point-to-multipoint use. "1" means support only for
point-to-point."0" means don’t care.Note: the number of OCH
SNC legs is defined by LSNExt_OchLegCount
LSNExt_NMSRate none a number which No The mapping from number to rate and GUI Rate Name is LS to OSS LSv6SP1
represents the rate of the provided in a separately supplied document. Note that this is
port NOT the Layer Rate listed in the Layer Rates supporting
document.
LSNExt_SourceMACAddr none MAC address form: Yes Source MAC address of the CES service endpoint. LSv7
6-octet hex format AVC - since
LSv9.1
LSNExt_ConfiguredPayload none NxVC12 or NxVT1.5 Yes For CES: The number of CES enabled VC12 CTPs in CES STM1 or LS to OSS
(N=1-84) E1 port, or VT1.5 CTPs in CES OC3 or DS1 port. Any change in the
number of the existing CTPs port in the EMS will be followed with
upload of the port LO CTPs.From LSv7.
LSNExt_PassiveEntity NotPassive Passive, NotPassive No Indicates if port belongs to a passive equipment, i.e. does not LSv8
have Alarms, PM, maintenance
LSNExt_PortBehavior Bidirectional Uni-In, Uni-Out, Uni-Both, Yes Unidirectional for ports with Uni-In and Uni-Out Direction, LSv8
Bidirectional Bidirectional otherwise. Can be edited in bidirectional port only.


provided empty=both
LSNExt_InterworkingGroups Empty List list of strings: "OMLT", No Affects trail creation rules in LS. Standard rules for Apollo and LSv8
"MSPP", "TRP", "AOC", XDM ports that are interoperable with Apollo, Classic rules for
"CMBR" XDM-to-XDM trails.
"OMLT" - interoperable with Apollo platform
"MSPP" - interoperable with XDM platform
"TRP" - interoperable with any card of TRP(not regenerator)
group
"AOC" - interoperable with any card of AoC(XDM mode) group
"CMBR" - interoperable with any card of AoC(not XDM mode)
group
The format of the list is defined by “eNI Structure and Data
Mapping” document.
LSNExt_UsageAndCapabilitySet Empty List list of strings: "AG1",... No Defines a set of capabilities and functions that can be applied on LSv8, LSv12.1
this port.
“AG1” - port belongs to Apollo platform
“AG2” - port belongs to :
- The non-OTN colored ports that supports acquiring of ONCP
parameters
- The non-OTN colored ports that supports RX configuration
- OTU/non-OTN colored ports that support `Set to Zero`
functionality
- data ports of NPB cards residing in Apollo NEs that support
download of data links from LS
“AG2_skipRx”- extension of “AG2” capability. Reported on a port
that does not support RX configuration.
Note : AG2_skipRx is supported since LSv11.1
“AG3” - allows to distinguish between incompatible service ports
that have same port mapping but use different mapping methods
.Relevant only for FC200 & HDSDI1485 client ports


provided empty=both
"AG4" - port belongs to OPT99xx Apollo platform
The format of the set is defined by “eNI Structure and Data

Mapping” document
Note : AG3 is supported since LSv10
LSNExt_PacketPortType type must be {EoS, ETY, ETY1, MoT, Yes Indicates to NMS for the port type of a PTP. The IP_MPLS port is a LS-EMS MoF and PSI –
computed MoE, CES_SONET, multi purpose port which has LIFs, where each LIF used for since V9,
CES_SDH, Virtual_CES, service endpoint or L3 families. MoG since V9.1
MoE, IC-MoE, MoF, PSI,
MoG, IP_MPLS }
LSNExt_TMCoreID NA 1, 2 No The core to which the PTP is associated LS-EMS V12
LSNExt_PacketPortType type must be {EoS, ETY, ETY1, MoT, Yes Indicates to NMS for the port type of a PTP. The IP_MPLS port is a LS-EMS MoF and PSI –
computed MoE, CES_SONET, multi purpose port which has LIFs, where each LIF used for since V9,
CES_SDH, Virtual_CES, service endpoint or L3 families. MoG since
MoE, IC-MoE, MoF, PSI, V9.1. IP_MPLS
MoG, since v12
IP_MPLS,OTDR,OTDRTap OTDR/OTDRTap
} since v12.2
Indicates whether or not the physical or logical interface is

LSNExt_Capability_NfvBackplane NA "true", "false", “NA” No connected to an NFVG card via NPT back plane . LS-EMS LSv12.5

10.4 Managed Element

Name Possible Values AVC Comment EMS-LS Version
or Data Type LS-OSS Information
empty=both
LSNExt_MESignature ME signature value No used only during Fast Recovery Upload from EMS to LightSoft, when requested EMS-LS
by LightSoft.
LSNExt_EMSSignature EMS signature value No used only when object is sent with an OCN EMS-LS
LSNExt_TimestampSignature current LightSoft No used only during Fast Recovery Upload from LightSoft to OSS, when requested LS-OSS
timestamp by OSS, or when object is sent with an OCN
LSNExt_ControlPlaneNeIPAddr String No Read Only from EMS - specifiy the control plane IP address in the control plane.
ACPs negotiate through this IP address.
LSNExt_AsonHeadEndCount Integer Yes Read Only from EMS - specifiy the number of ASON Head-Ends. The EMS will not
pass this attribute for Managed Elements which do not have ASON capability.
LSNExt_DCC_Subnet Free format Yes The Subnet mask used in DCC communications of the NE.
LSNExt_IsAGateway boolean Yes ME is considered as gateway if the MTNM parameter LSNExt_IsAGateway = true
LSNExt_MaintenanceStatus {ON, OFF} Yes Whether there are active maintenance operations in the NE according to the
EMS criteria.
LSNExt_NetworkAddress Free format Yes Normally, the mainIPAddress of the NE in dotted decimal notation. Updated in V12
The IP Address type (IPv4, IPv6) is per LSNExt_IPAddrType.
LSNExt_ASON_LowPriorityDelay 1-60 (seconds) Yes ASON Low Priority Delay value. Used only when relevent. LS-OSS ,
since LSv8
LSNExt_MapCoordinates pair of numbers Yes Coordinates on map. LightSoft to OSS only.
LSNExt_Comment text Yes User comment about the ME. LightSoft to OSS only.


empty=both
LSNExt_MEGroup DN Yes Points to the innermost ME Group to which this NE belongs. Empy if ME is not in
a group. LightSoft to OSS only.
Manufacturer string Yes
LSNExt_Capability_UpdateNeIDSup "supported" or No Indicates if NE ID can be updated.

ported "unsupported"
(default)
LSNExt_NE_Public_Key String or empty yes The parameter is empty (by default) if the related ME does not support the data EMS-LS LSv11
(default) encryption feature. Otherwise, it reflects the “NE Public Key” of the ME.
LSNExt_AsonTELinkMode “AutoSingleBundled”, Yes Allows to define if the ASON TE-links will be bundled or unbundled.Unbundling LSv8.1
“AutoUnbundled”; (Northb the TE-links is required in order to allow association SRLGs with a specific link
default : NA ound instead of lumping together all the SRLGs of all the DLs in the TE-link.
only)
Additional Info parameters for Timing Map
Applies both between EMS (server) and LS (client) and between LS (server) and OSS (client).
Name Possible Values AVC Comment

{INTERNAL,
LSNExt_ActiveTimingSrcType No This attribute is valid for all NEs. A given NE may support only part of the EMS-LS LSv11, revised in
EXTERNAL,
clock-source types. LSv12.3
TRIBUTARY, LINE,
Behavior for LightSoft Timing Map:
Holdover, NA,
if (LSNExt_ActiveTimingSrcType == Holdover) then, depending on
IEEE1588V2, PTP}
LSNExt_ActiveTimingQuality value, NE is either Yellow or Red on map.
Else the NE is green on map


empty=both
LSNExt_ActiveTimingSrc PTP DN, "External", No This attribute is valid for all NEs. A given NE may support only part of the EMS-LS LSv11
"Internal", clock-source types.
"Holdover", "NA", IP If ActiveTimingSrcType is LINE or TRIBUTARY then ActiveTimingSrc is the RdN
Address identifying the PTP (last element of the PTP distinguished name) acting as the
active timing source of the (East) NE Timing Generator.
If ActiveTimingSrcType is IEEE1588V2 then ActiveTimingSrc is the IP Address
identifying the master clock of the (East) NE Timing Generator.
LSNExt_ActiveTimingQuality {"PRC", "SSUT", No Attribute is valid for all NEs. A given NE may support only part of the Quality EMS-LS LSv11
"SSUL", "SEC", values.
"DNU", "PRS", "STU", Behavior for LightSoft Timing Map: Color of link is based on this quality if LINE,
"ST2", "TNC", "ST3E", or IEEE1588V2 is the timing source type. In such a case, the PTP DN of the
"ST3", "SMC", "DUS", ActiveTimingSrc is the sink of the link.
"NA", “EEC”} If ActiveTimingSrcType is INTERNAL, EXTERNAL, TRIBUTARY or Holdover color of
clock-source indication may be based on this quality.
LSNExt_ConfiguredTimingSrcType {INTERNAL, No Attribute is valid for all NEs. However, a given NE may support only part of the EMS-LS LSv11
EXTERNAL, clock-source types.
TRIBUTARY, LINE,
Holdover, NA,
IEEE1588V2}
LSNExt_ConfiguredTimingSrc PTP DN, "External", No This attribute is valid for all NEs. A given NE may support only part of the EMS-LS LSv11
"Internal", clock-source types.
"Holdover", "Dual", IP If ConfiguredTimingSrcType is LINE or TRIBUTARY then ConfiguredTimingSrc is
Address the RdN identifying the PTP (last element of the PTP distinguished name) acting
as the active timing source of the (East) NE Timing Generator.
If ConfiguredTimingSrcType is IEEE1588V2 ConfiguredTimingSrc is the IP Address
identifying the master clock of the (East) NE Timing Generator.


empty=both
LSNExt_ConfiguredTimingQuality {"PRC", "SSUT", No Attribute is valid for all NEs. A given NE may support only part of the Quality EMS-LS LSv11
"SSUL", "SEC", values.
"DNU", "PRS", "STU", When ConfiguredTimingSrcType is LINE or IEEE1588V2 then quality is per SSM
"ST2", "TNC", "ST3E", unless overridden by operator. (If user over-rides SSM then the override quality
"ST3", "SMC", "DUS", supplied will be used.)
"NA", "SSM", "EEC"}
LSNExt_ActiveTimingSrcTypeWest {INTERNAL, No This attribute is valid for all NEs that support multiple clock sources. A given NE EMS-LS LSv11
EXTERNAL, may support only part of the clock-source types.
TRIBUTARY, LINE, E.g., when the “West” set is used for “Path & ToD Synchronization” then this
Holdover, NA, field is expected to solely hold the value IEEE1588V2.
IEEE1588V2}
LSNExt_ActiveTimingSrcWest PTP DN, "External", No This attribute is valid for all NEs that support multiple clock sources. A given NE EMS-LS LSv11
"Internal", may support only part of the (West) clock-source types.
"Holdover", "NA", If ActiveTimingSrcTypeWest is LINE, or TRIBUTARY then ActiveTimingSrcWest is
IP Address the RdN identifying the PTP (last element of the PTP distinguished name) acting
as the active timing source of the (West) NE Timing Generator.
If ActiveTimingSrcTypeWest is IEEE1588V2 then ActiveTimingSrc is the IP
Address identifying the master clock of the (West) NE Timing Generator.
LSNExt_ActiveTimingQualityWest {"PRC", "SSUT", No This attribute is valid for all NEs that support multiple clock sources. A given NE EMS-LS LSv11
"SSUL", "SEC", may support only part of the Quality values.
"DNU", "PRS", "STU", Behavior for LightSoft Timing Map: Color of link is based on this quality if LINE,
"ST2", "TNC", "ST3E", or IEEE1588V2 is the timing source type. In such a case, the PTPdn of the
"ST3", "SMC", "DUS", ActiveTimingSrc is the sink of the link.
"NA", “EEC”} If ActiveTimingSrcType is INTERNAL, EXTERNAL, TRIBUTARY or Holdover color of
clock-source indication is based on this quality.
LSNExt_ConfiguredTimingSrcTypeW {INTERNAL, No This attribute is valid for all NEs that support multiple clock sources. A given NE EMS-LS LSv11
est EXTERNAL, may support only part of the clock-source types.
TRIBUTARY, LINE, E.g., when the “West” set is used for “Path & ToD Synchronization” then this
Holdover, NA, field is expected to solely hold the value IEEE1588V2.
IEEE1588V2}


empty=both
LSNExt_ConfiguredTimingSrcWest PTP DN, "External", No This attribute is valid for all NEs that support multiple clock sources. A given NE EMS-LS LSv11
"Internal", may support only part of the clock-source types.
"Holdover", "Dual", IP If ConfiguredTimingSrcTypeWest is LINE, or TRIBUTARY then
Address ConfiguredTimingSrcWest is the RdN identifying the PTP (last element of the
PTP distinguished name) acting as the active timing source of the (West) NE
Timing Generator.
If ConfiguredTimingSrcTypeWest is IEEE1588V2 ConfiguredTimingSrcWest is the
IP Address identifying the master clock of the (West) NE Timing Generator.
LSNExt_ConfiguredTimingQualityW {"PRC", "SSUT", No This attribute is valid for all NEs that support multiple clock sources. A given NE EMS-LS LSv11
est "SSUL", "SEC", may support only part of the Quality values.
"DNU", "PRS", "STU", When ConfiguredTimingSrcTypeWest is LINE or IEEE1588V2 then quality is per
"ST2", "TNC", "ST3E", SSM unless overridden by operator. (If user over-rides SSM then the override
"ST3", "SMC", "DUS", quality supplied will be used.)
"NA", "SSM", "EEC"}
Note regarding LightSoft Timing Map: The NMS should be able to handle partial support of the attributes.
If attributes such as Quality or Configured values do not exist (e.g. when the EMS is v4 or EMS-Syncom v1) then the NMS will use whatever attributes it has to
present a partial picture.
Additional Info parameters for ASON OTN and WSON:
LSNExt_ASTNType “None”(default), Yes Specify GMPLS Mode: either WSON or ASON EMS-LS V11.2
”OTN_ASON”,”WSO
N”
LSNExt_MetricType ‘NA’ (Not Applicable), Yes ASON OTN and WSON:Metric type EMS-LS V11.2
‘HopCount’, ‘Cost’,
‘Length’, ‘OSNR’


empty=both
LSNExt_ReversionTime {<hours>;< minutes Yes ASON OTN and WSON: Specify the reversion time EMS-LS V11.2
>},
where hours and
minutes are
integers(short) in
range:
hours 0-23
minutes 0-59
LSNExt_MaxCost integer Yes ASON OTN and WSON: specifies cost condtrains of CP path computation ; the EMS-LS V11.2
computed path should has the cost less than provided maximum value.
LSNExt_MaxLength integer Yes ASON OTN and WSON: specifies length condtrains of CP path computation ; EMS-LS V11.2
the computed path should has the length less than provided maximum value.
LSNExt_MaxHopCount integer Yes ASON OTN and WSON: specifies hop condtrains of CP path computation ; the EMS-LS V11.2
computed path should has the number of hops less than provided maximum
value.
LSNExt_MasterClkIpAddr {<string yes The IP address assigned to the IEEE1588 Master Ordinarty Clock, if such is EMS-LS V12
AddressType>; specified for this ME.
<string IpAddress>} The format of this attribute is:
"{<AddressType>;<IpAddress>}" where:
 AddressType is a string, e.g., "[4]IPv4"
 IpAddress is a string, e.g., "[12]17.11.22.101"
For example: {"[4]IPv4";”[11]17.11.22.98”}

10.5 Topological Link

Name TopologicalLink_T Default when not Possible Values AVC Comment EMS-LS Version
TLCreateData_T provided or Data Type LS-OSS Information
empty=both
LSNExt_EMSSignature TopologicalLink_T last EMS signature No used only when object is sent EMS-LS
with an OCN
LSNExt_TimestampSignature TopologicalLink_T current LightSoft timestamp No used only when object is sent LS-OSS
with an OCN
LSNExt_LinkType TopologicalLink_T EMS_PERSISTENT "EMS_PERSISTENT" No Indicates to the caller to mark the LSv6
"EMS_DISCOVERED_LINK" link as a link under its control
"ASON_LDL" (when discovered). By doing so
"VIRTUAL_RADIO_LINK" the caller should not expect to
receive this link when retrieving
the links that are stored in the
server's dB using
getAllTopLevelTopologyLinks().
Also used to indicate that the link
is an ASON LDL
LSNExt_LinkDistance TopologicalLink_T 0 integer; units are the units used No the distance spanned by the link , LSv5 ,
TLCreateData_T by NMS; The value `-1` indicates conflict LS-EMS from
between ports LSv8
according to
EPs capability
LSNExt_UnderlyingTrail TopologicalLink_T String RDN of the underlying trail; No Only appears for virtual links. LS-OSS
TLCreateData_T points to lightpath or EoS trail or
ASON LDL trail

empty=both
LSNExt_SRLG_List TopologicalLink_T empty list of strings No the list of SRLGs traversed by the LS-OSS LSv5
each string is a SRLG ID link
LSNExt_LinkCost TopologicalLink_T 0 integer Yes the value of the cost function or LS-OSS LSv5
TLCreateData_T cost evaluation associated with
the link
LSNExt_LinkRingName TopologicalLink_T empty string Yes The Ring Name of the link LS-OSS
TLCreateData_T
LSNExt_LinkCapacity TopologicalLink_T none number No The capacity of the link LS-OSS
LSNExt_LinkProtectionType TopologicalLink_T NONE {"MSP", "EXT", "NONE"} No The protection type of the link: LS-OSS
linear, external, none.
LSNExt_LinkQuality TopologicalLink_T 0 0-5 No The quality value of the link. LS-OSS

TLCreateData_T
LSNExt_Comment TopologicalLink_T empty string Yes A user comment about the link. LS-OSS
TLCreateData_T
LSNExt_RemainingBW TopologicalLink_T empty number Yes calculated by LS; difference LS-OSS

between total link capacity and
actual used capacity
LSNExt_ConnectivityType TopologicalLink_T "Internal" No Indicates if the link is Internal or LSv8,

TLCreateData_T "External" External LS-EMS
according to
EPs capability
LSNExt_ExpectedFiberLossAe TopologicalLink_T 0 float (-1,0-100, ±0.1) Yes Input fiber loss to be configured LSv8,
nd TLCreateData_T (in dB) LS-EMS
The value `-1` indicates conflict according to
between ports EPs capability

empty=both
LSNExt_ExpectedFiberLossZe TopologicalLink_T 0 float (-1,0-100, ±0.1) Yes Input fiber loss to be configured LSv8,
nd TLCreateData_T (in dB) LS-EMS
LSNExt_FiberType TopologicalLink_T G.652 N/A, Yes Type of Fiber LSv8,

TLCreateData_T G.651-Multimode, Conflict value indicates for LS-EMS
G.652 (default) conflict between ports according to
G.653, EPs capability
G.654,
G.655-Leaf,
G.655-TW-RS,
G.655-TW-Reach,
Conflict
LSNExt_AllowedFiberLossMar TopologicalLink_T 0 float (-1,0-7, ±0.1) Yes the allowed margin before LSv8,
gin TLCreateData_T generating power alarm (in dB). LS-EMS
LSNExt_ConfiguredPMD TopologicalLink_T 0 float (-1,0-40, ±0.1) Yes Polarization Mode Dispersion LSv8,
TLCreateData_T (in ps). LS-EMS
LSNExt_ConsistencyStatus TopologicalLink_T Consistent Consistent, Yes Links’ computed consistency state LSv8,
Inconsistent, in the EMS LS-EMS
Incomplete_Unspecified, according to
Incomplete_Unmanaged, EPs capability
Incomplete_Unconfigured
LSNExt_DownloadLinksCapab TopologicalLink_T unsupported "supported" , "unsupported" No Indicates if EMS supports LSv8

ility downloading links from NMS

10.6 Protection Group

empty=both
LSNExt_EMSSignature last EMS signature No used only when object is sent with an OCN EMS-LS
LSNExt_MESignature last ME signature No used only during Fast Recovery Upload from EMS to LightSoft, when EMS-LS
requested by LightSoft, or when object is sent with an OCN
LSNExt_TimestampSignature current LightSoft timestamp No used only when object is sent with an OCN LS-OSS
LSNExt_MSPRingId Decimal format Yes Uniquely identifies the MSPRing in the domain of the EMS.
ServiceState {"IN_SERVICE", "OUT_OF_SERVICE"} Yes Whether the ring is active or inactive.

SC
LSNExt_NutAllocation "([", number of NUT streams, "]", streamID1, Yes The number and identity of streams in an MS-SPRing which do not
",", streamID2, ",", ..., ",", streamIDn, ")" participate in the shared Protection.
i.e., ([number of NUT streams] "Number of NUT streams" is always an even number and includes all
streamID1,streamID2, ...,streamIDn) the NUT streams. E.g., in SDM16, if stream 1 is a NUT stream, then
stream 9 must also be a NUT stream, and both are counted in
e.g, ([4]stream1, stream9, stream7, "number of NUT streams". They are listed as pairs, i.e., streamID1 and
stream15) streamID2 are a pair, streamID3 and streamID4 are a pair, and so on.
LSNExt_RadioProtection {None(default), HOTSB, Space, Freq} Yes Protection Scheme for radio ports.
LSNExt_WTR integer in range 0,1 to 12 No Specifies the Wait to Restore time(WTR) in minutes which required to LS LSv11.1
wait before the revertive switch can go back to the primary TP of
protection group(PG).
0 - means unspecified WTR
The LSNExt_WTR is used for configuration of WTR only .
Note :The retrieving of WTR in PG is performed via retrieving PG
attributes (see wtrTime attribute of
ProtectionGroup_T::pgpParameters in SD1-29_PGPParameters.pdf )


empty=both
LSNExt_ReversionMode “Revertive”, “NonRevertive”, “NA” No Defines whether the Protection scheme is revertive or not.The LS LSv11.1
LSNExt_ReversionMode is used for configuration of reversion mode
only.
Note :The retrieving of reversion mode of PG is performed via
retrieving PG attributes(see ProtectionGroup_T::reversion Mode)
10.7 Cross Connection

Name Possible Values Comment EMS-LS Version
empty=both
OrderNumber list of 4-tuples, one 4-tuple for each a-z each 4-tuple includes:
pair (leg) of the cross-connect trail component number of a Main path (-1 if leg is not part of a Main path),
position of the leg in the component (-1 if leg is not part of a Main path),
trail component number of a Protection path (-1 if leg is not part of a Protection path),
position of the leg in the component (-1 if leg is not part of a Protection path)
PathType 1,2,3 Main=1, Protection=2, Both=3
XC_type "START", "STOP", "MID", "STARTSTOP", leg is at trail start, leg is at trail stop, leg is in the middle, leg is at the start of a branch, leg is at
"BRANCHSTART", "BRANCHSTOP", the end of a branch, leg is the only cross-connect in the branch
"BRIDGE"

10.8 EMS
provided empty=both
LSNExt_EMSSignature last EMS signature No used only during Fast Recovery Upload from EMS to LightSoft, when EMS-LS
requested by LightSoft.
LSNExt_SubnetName Subnetwork name No used only during Fast Recovery Upload from EMS to LightSoft, when EMS-LS
During Fast Recovery Upload, for each subnetwork there will be a pair of
attributes, LSNExt_SubnetName and LSNExt_SubnetSignature.
LSNExt_SubnetSignature Subnetwork signature No used only during Fast Recovery Upload from EMS to LightSoft, when EMS-LS
value requested by LightSoft.
see LSNExt_SubnetName
LSNExt_MEName ME name No used only during Fast Recovery Upload from EMS to LightSoft, when EMS-LS
During Fast Recovery Upload, for each ME there will be a pair of
attributes, LSNExt_MEName and LSNExt_MESignature.
LSNExt_MESignature ME signature value No used only during Fast Recovery Upload from EMS to LightSoft, when EMS-LS
see LSNExt_SubnetName
LSNExt_TimestampSignature current LightSoft No used only during Fast Recovery Upload from LightSoft to OSS, when LS-OSS
timestamp requested by OSS.
LSNExt_NetworkAddress Free format No Usually the hostname of the sender's workstation. The receiver should
be able to map the host name to the applicable IP address.
LSNExt_EMSTrafficConsistency TC_CONSIST {TC_CONSISTENT, Yes Indicates that the network's connections and the receiving system's
ENT TC_INCONSISTENT} connections may currently be inconsistent. ("Red Flag").


provided empty=both
LSNExt_EMSPGProvisiningCapability NO {YES,NO} No Indicates if the EMS support top down provisioning of PG. EMS-LS
LSNExt_DownloadLinksCapability unsupporte {"supported" , No Indicates if EMS supports downloading links from NMS LSv8
d "unsupported"}
LSNExt_EMSMigrationStage
"NA" "NA", yes The stage of the currently executed migration process. The following EMS-LS LSv12.3
"PrepareSwitchover", values are supported (some are written top-down, marked as "NMS",
"PrepareSwitchoverP and other are bottom-up, marked as "EMS"):
assed", "NA" (default), "PrepareSwitchover" (NMS), "PrepareSwitchoverPassed"
"PrepareSwitchoverF (EMS), "PrepareSwitchoverFailed" (EMS)
ailed", "Switchover", "Switchover" (NMS), "SwitchoverPassed" (EMS), "SwitchoverFailed"
"SwitchoverPassed", (EMS)
"SwitchoverFailed"
LSNExt_EMSMigrationTunnelLabel empty list List of interface DNs no The list of interfaces that are subject for migration, i.e., EMS has to EMS-LS LSv12.3
([0]) (i.e., PTP, LIF) modify the out-label of tunnels outgoing from those interfaces.
This attribute is being used by "PrepareSwitchover" and "Switchover"
commands (LSNExt_EMSMigrationStage)
10.9 Subnetwork
provided empty=both
LSNExt_MEName RdN No RdN identifying the managed element contained by this Subnetwork. EMS-LS
This attribute applies to singleton subnetworks (or any subnetwork
contained in a single ME).
LSNExt_SubnetSignature last subnetwork signature No used only during Fast Recovery Upload, from EMS to LightSoft, when EMS-LS

LSNExt_TimestampSignature current LightSoft No used only during Fast Recovery Upload from LightSoft to OSS, when LS-OSS
timestamp requested by OSS.

10.10 MFD
Name Default when Possible Values AVC Comment EMS-LS Version
not provided or Data Type LS-OSS Information
empty=both
LSNExt_MESignature ME signature value No used only during Fast Recovery Upload from EMS EMS-LS
to LightSoft, when requested by LightSoft, or
LSNExt_TimestampSignature current LightSoft timestamp No used only when object is sent with an OCN LS-OSS
LSNExt_Capability_MaxCapaPerProfType empty list ([<ListSize>]{<ProfileType>;<Capacity>},..,{}) Yes Maximum capacity per profile-type. A list which EMS-LS V12
([0]) indicates, per profile type, the maximum number
of profiles the PE can store. The profile types are
per LSNProfileType_T enumeration.
The format of this attribute is
([<ListSize>]{<ProfileType>;<Capacity>},..,{})
Where:
 ListSize is a number.
 ProfileType is a value from LSNProfileType_T
 Capacity is a number, e.g., 14
Here is an example with two profile types:
([2]{OutPcpToTc;14},{TcDpToOutExp;10})

10.11 Equipment
Name Default when not Possible Values AVC Comment EMS-LS Version
provided or Data Type LS-OSS Information
LSNExt_TimestampSignature current LightSoft No used only during Fast Recovery Upload from LightSoft to OSS, LS-OSS
timestamp when requested by OSS.
Equipment Holder
timestamp when requested by OSS.
LSNExt_SlotName string No The displayable slot name, such as I7.

10.12 TCProfile
Name TCProfileCreateData_T, Comment Possible Values Default when not AVC EMS-LS Version
TCProfile_T or Data Type provided LS-OSS Information
LSNExt_TimestampSignature Used only during Fast Recovery Upload from current No LS-OSS
LightSoft to OSS, when requested by OSS. LightSoft
timestamp
LSNExt_ProfType TCProfileCreateData_T Profile type for a top-down created profile. string no LS-EMS V12
LSNExt_ProfTarget TCProfileCreateData_T The target MFD DN for a top-down created string no LS-EMS V12
profile
LSNExt_PriToCos_ToCos TCProfileCreateData_T, This object provides the mapping from the List of 8 integer ([8]0,0,0,0,0,0,0,0) yes LS-EMS V12
TCProfile_T (implicit) 8 ingress priority values (in the range values (in the
0 to 7) to CoS values (range: 0..7). range 0..7).
The value in position i (i=1..8) in the list is the
CoS value for ingress priority i-1. E.g.: If the list
is ([8]0,1,1,2,4,5,7,7) then ingress priority 0 is
mapped to CoS 0 and both ingress priority 1
and 2 are mapped to CoS 1.
LSNExt_PriDeiToCosCol_ToCo TCProfileCreateData_T, This object provides the "to" CoS value for an List of 16 ([16]0,0,0,0,0,0,0,0, yes LS-EMS V12
s TCProfile_T implicit combination of ingress priority and DEI integer values 0,0,0,0,0,0,0,0)
value. (in the range
The value in position i (i=1..16) in the list is the 0..7).
CoS value for ingress priority=i/2 and
DEI(color)=Green (if i is even) or Yellow (if i is
odd)
E.g.: If the list is
([16]0,1,1,1,2,2,3,4,4,5,5,5,6,6,7,7,7) it means
ingress priority 0/Green is mapped to CoS 0,
ingress priority 0/Yellow is mapped to CoS 1,
and ingress priority 1 (Green or Yellow) is also
mapped to CoS 1.

LSNExt_PriDeiToCosCol_ToCo TCProfileCreateData_T, This object provides the "to" Color value for an List of 16 ([16]0,0,0,0,0,0,0,0, yes LS-EMS V12
l TCProfile_T implicit combination of ingress priority and DEI integer values 0,0,0,0,0,0,0,0)
value. (in the range
Practically, a '0' means Green color and '1' 0..1).
means Yellow color.
Color value for ingress priority=i/2 and DEI
(color)=Green (if i is even) or Yellow (if i is odd)
([16]0,1,1,1,0,0,0,1,0,1,1,1,1,1,1,1,1) it means
ingress priority 0/Green is mapped to Green
(0), ingress priority 0/Yellow is mapped to
Yellow (1), and ingress priority 1 (Green or
Yellow) is mapped to Yellow (1).
LSNExt_DscpToCos_ToCos TCProfileCreateData_T, This object provides the mapping from the List of 64 ([64]0,0,0,0,0,0,0,0 yes LS-EMS V12
TCProfile_T (implicit) 64 DSCP values (in the range 0 to 63) integer values ….,0,0,0)
to CoS values (range: 0..7). (in the range
CoS value for DSCP value of i-1. E.g.: If the list
is ([64]0,1,1,2,4,5,…,7,7,7) then DSCP 0 is
mapped to CoS 0, DSCP=1 is mapped to CoS 1
and DSCP=63 is mapped to CoS 7.
LSNExt_DscpToCosCol_ToCos TCProfileCreateData_T, This object provides the "to" CoS value for an List of 64 ([64]0,0,0,0,0,0,0,0 yes LS-EMS V12
TCProfile_T implicit DSCP value. integer values ….,0,0,0)
The value in position i (i=1..64) in the list is the (in the range
CoS value for DSCP value of i-1. 0..7).
E.g.: If the list is ([64]0,1,1,2,4,5,…,7,7,7) then
DSCP 0 is mapped to CoS 0, DSCP=1 is mapped
to CoS 1 and DSCP=63 is mapped to CoS 7.

LSNExt_DscpToCosCol_ToCol TCProfileCreateData_T, This object provides the "to" Color value for an List of 64 ([64]0,0,0,0,0,0,0,0 yes LS-EMS V12
TCProfile_T implicit DSCP value. integer values ….,0,0,0)
Practically,a '0' means Green color and '1' (in the range
means Yellow color. 0..1).
Color value for DSCP value of i-1.
([64]0,1,1,1,0,0,0,1,0,1,1,1,1,1,1…,1,1) it
means DSCP 0 is mapped to Green (0), DSCP 1
is mapped to Yellow (1), and DSCP=63 is
mapped to Yellow (1).
LSNExt_ExpToCosCol_ToCos TCProfileCreateData_T, This object provides the "to" CoS value for an List of 8 integer ([8]0,0,1,1,2,2,3,4) yes LS-EMS V12
TCProfile_T implicit EXP value. values (in the
The value in position i (i=1..8) in the list is the range 0..7).
CoS value for EXP value of i-1.
E.g.: If the list is ([8] 0,0,1,1,2,2,3,4) then EXP=0
and EXP=1 are mapped to CoS 0, and EXP=2 or
3 are mapped to CoS 1.
LSNExt_ExpToCosCol_ToCol TCProfileCreateData_T, This object provides the "to" Color value for an List of 8 integer ([8]0,1,0,1,0,1,0,0) yes LS-EMS V12
TCProfile_T implicit EXP value. values (in the
Practically, a '0' means Green color and '1' range 0..1).
means Yellow color.
Color value for EXP value of i-1.
E.g.: If the list is ([8]0,1,0,1,0,1,0,0) it means
EXP=0 is mapped to Green (0), EXP=1 is
mapped to Yellow (1), and EXP=7 is mapped to
Green (0).

LSNExt_DscpToDscp_ToDscp TCProfileCreateData_T, This object provides the egress ("to") DSCP List of 64 ([64]0,1,2,3,…60,61, yes LS-EMS V12
TCProfile_T value for an implicit ingress DSCP value. integer values 62,63)
egress DSCP value for ingress DSCP value of 0..63).
i-1.
E.g.: If the list is ([64]0,1,2,3,,…,63,63,63) then
it means last ingress DSCP values (at least 61,
62 and 63) are mapped to egress DSCP=63.
LSNExt_ExpToDscp_ToDscp TCProfileCreateData_T, This object provides the egress ("to") DSCP List of 8 integer ? yes LS-EMS V12
TCProfile_T value for an implicit ingress EXP value. values (in the
The value in position i (i=1..8) in the list is the range 0..63).
egress DSCP value for ingress EXP value of
i-1.
E.g.: If the list is ([8]0,1,2,3,4,63,63,63) then it
means last ingress EXP values (5, 6 and 7) are
mapped to egress DSCP 63.
LSNExt_CosGroup TCProfileCreateData_T, This object defines a group of CoS values (in List of up to 8 ([0]) yes LS-EMS V12
TCProfile_T the range 0..7) . A CoS value must appear only integer values
in one of the CoS groups. in the range
References to these CoS group profile-names 0..7.
are made from the "CoS to Policer" mapping
(per service endpoint)
Example: ([3]0,1,2)
LSNExt_CosToPri_ToPri TCProfileCreateData_T, This object provides the mapping from the List of 8 integer ([8]0,1,2,3,4,5,6,7) yes LS-EMS V12
TCProfile_T (implicit) 8 CoS values (in the range 0 to 7) to values (in the
egress priority values (range: 0..7). range 0..7).
egress priority value for CoS i-1. E.g.: If the list
is ([8]0,1,1,2,4,5,7,7) then CoS 0 is mapped to
egress priority 0 and both CoS 1 and 2 are
mapped to egress priority 1.

LSNExt_CosColToPriDei_ToPri TCProfileCreateData_T, This object provides the mapping from the List of 16 ([16]0,0,1,1,2,2,3,3, yes LS-EMS V12
TCProfile_T (implicit) 8 CoS values (in the range 0 to 7) to integer values 4,4,5,5,6,6,7,7)
egress priority values (range: 0..7). (in the range
LSNExt_CosColToPriDei_ToDe TCProfileCreateData_T, This object provides the mapping from the List of 16 ([16]0,1,0,1,0,1,0,1, yes LS-EMS V12
i TCProfile_T (implicit) 8 CoS values (in the range 0 to 7) to integer values 0,1,0,1,0,1,0,1)
egress priority values (range: 0..7). (in the range
LSNExt_CosColToExp_ToExp TCProfileCreateData_T, This object provides the "to" EXP value for an List of 16 ([16]0,1,2,3,4,5,6,0, yes LS-EMS V12
TCProfile_T implicit combination of CoS and Color values. integer values 7,0,0,0,0,0,0,0)
EXP value for CoS=i/2 and Color=Green (if i is 0..7).
even) or Yellow (if i is odd)
([16]0,1,2,3,4,5,6,0,7,0,0,0,0,0,0,0) it means
CoS 0/Green is mapped to EXP=0, CoS 0/Yellow
to EXP=1, CoS 1/G to EXP=2, CoS 1/Y to 3, etc.

LSNExt_DscpColToExp_ToExp TCProfileCreateData_T, This object provides the "to" EXP value for an List of 128 ? yes LS-EMS V12
TCProfile_T implicit combination of DSCP and Color values. integer values
The value in position i (i=1..128) in the list is (in the range
the EXP value for DSCP=i/2 and Color=Green (if 0..7).
i is even) or Yellow (if i is odd)
([128]0,1,2,3,4,5,6,0,7,0,…,0,0,0) it means
DSCP 0/Green is mapped to EXP=0, DSCP 0/Y
to EXP=1, DSCP 1/G to EXP=2, DSCP 1/Y to
EXP=3, etc.
LSNExt_DscpColToDscp_ToDs TCProfileCreateData_T, This object provides the "to" egress DSCP value List of 128 ([128]0,0,1,1,2,2,3,3 yes LS-EMS V12
cp TCProfile_T for an implicit combination of internal DSCP integer values ,4,4,…,61,61,62,62,
and Color values. (in the range 63,63)
The value in position i (i=1..128) in the list is 0..63).
the egress DSCP value for internal DSCP=i/2
and Color=Green (if i is even) or Yellow (if i is
odd)
([128]0,1,2,3,4,5,6,0,7,0,…,63,63,63) it means
internal DSCP 0/Green is mapped to egress
DSCP=0, DSCP 0/Y to DSCP=1, DSCP 1/G to
DSCP=2, DSCP 1/Y to DSCP=3, etc.
LSNExt_Policer_Cir TCProfileCreateData_T, This object provides the Committed Unsigned32 0 yes LS-EMS V12
TCProfile_T Information Rate (CIR) in units of value in the
64Kbits/second. It allows expressing the range range
between 64Kbps and 300Gbps. [0..4687500]
By default the parameter is set to 0. units of
64Kbit/sec

LSNExt_Policer_Cbs TCProfileCreateData_T, This object provides the Committed Burst Size Unsigned32 0 yes LS-EMS V12
TCProfile_T (CBS) in units of 64bits/second. It allows value in the
expressing the range between 64bps and range
4Mbps. [0..62500] units
By default the parameter is set to 0. It should of 64bit/sec
also be 0 if the CIR is 0.
LSNExt_Policer_Eir TCProfileCreateData_T, This object provides the Excessive Information Unsigned32 0 yes LS-EMS V12
TCProfile_T Rate (EIR) in units of 64Kbits/second. It allows value in the
expressing the range between 64Kbps and range
300Gbps. [0..4687500]
64Kbit/sec
LSNExt_Policer_Ebs TCProfileCreateData_T, This object provides the Excessive Burst Size Unsigned32 0 yes LS-EMS V12
TCProfile_T (EBS) in units of 64bits/second. It allows value in the
4Mbps. [0..62500] units
also be 0 if the EIR is 0.
LSNExt_Policer_Cm TCProfileCreateData_T, This object defines the Color Mode. That is, it "false", "true" FALSE yes LS-EMS V12
TCProfile_T defines whether the policer should ignore the
ingress packet's color ("false") or refer to it
("true").
By default the parameter is set to "false".

LSNExt_Policer_Cf TCProfileCreateData_T, This object defines the Coupling Flag. When set "disabled", disabled yes LS-EMS V12
TCProfile_T to "disabled" the volume of the "enabled"
yellow-colored packets admitted to the
network can not exceed EIR.
When set to "enabled" yellow-colored
packets can utilize unused tokens in green
bucket and the volume of the yellow-colored
packets admitted to the network is bounded
by CIR + EIR.
In any case the burst size of the
yellow-colored packets admitted to the
network is bounded by EBS.
By default the parameter is set to
"disabled". It should also be "disabled" if
the CM="false".
LSNExt_Policer_HPolicy TCProfileCreateData_T, This object defines H Policy Flag. When "disabled", disabled yes LS-EMS V12
TCProfile_T CoS-groups hierarchy exists and this parameter "enabled"
is "enabled" it allows unused tokens in a
higher CoS-group be utilized for a lower
CoS-group packet.
By default the parameter is set to
"disabled".
LSNExt_BscPolicer_Cir TCProfileCreateData_T, This object provides the Committed Unsigned32 0 yes LS-EMS V12
TCProfile_T Information Rate (CIR) in units of value in the
64Kbits/second. It allows expressing the range range
between 64Kbps and 300Gbps. [0..4687500]
64Kbit/sec
LSNExt_BscPolicer_Cbs TCProfileCreateData_T, This object provides the Committed Burst Size Unsigned32 0 yes LS-EMS V12
TCProfile_T (CBS) in units of 64bits/second. It allows value in the
4Mbps. [0..62500] units
also be 0 if the CIR is 0.

LSNExt_VlanIdRange_FirstVid TCProfileCreateData_T, The lowest VLAN ID in the values-range. Integer (0-4096) 0 yes LS-EMS V12
TCProfile_T
LSNExt_VlanIdRange_LastVid TCProfileCreateData_T, The highest VLAN ID in the values-range. Integer (0-4096) 0 yes LS-EMS V12
TCProfile_T
LSNExt_QosVop_Version TCProfileCreateData_T, This object indicates the QoS VoP structure Integer 1 yes LS-EMS V12
TCProfile_T version.
For example: Version 1 is the collection of
profiles with types: "PriToCos", "DscpToCos",
"ExpToCosCol", "CosToPri", and
"CosColToExp".
LSNExt_QosVop_UseDscpExp TCProfileCreateData_T, This object defines whetehr ('enabled') or not "disabled", disabled yes LS-EMS V12
TCProfile_T ("disabled") DSCP/EXP is being used for ACs. "enabled"
LSNExt_QosVop_RemarkDei TCProfileCreateData_T, This object defines the DEI bit remarking "disabled", enabled yes LS-EMS V12
TCProfile_T behavior for the S-Tag of AC over E-NNI "enabled"
interface. When enabled, the DEI bit will be
remarked according to the packet color
(yellow=1, green=0); when disabled, will fix the
DEI bit to 0.

LSNExt_QosVop_PriClass TCProfileCreateData_T, This object provides the profile type and name String NA yes LS-EMS V12
TCProfile_T used for 802.1p priority-based classification.
The object value is a portion of the profile DN
that includes both profile type and name. E.g.,
"ProfType~~PriToCos@@ProfName~~Profile1"
. Expected profile-type depends on
LSNExt_QosVop_Version.
The profile name, in top-down configuration, is
NMS profile name. The NMS should replace it
with the matching EMS profile name (not the
full DN) prior to communicating the profile
to the EMS.
Similarly, in bottom-up direction EMS profile
names are being used, and the NMS should
look for the corresponding NMS profile name.
LSNExt_QosVop_DscpClass TCProfileCreateData_T, This object provides the profile type and String NA yes LS-EMS V12
TCProfile_T name used for DSCP-based classification. The
object value is a portion of the profile DN that
includes both profile type and name. E.g.,
"ProfType~~DscpToCos@@ProfName~~Profile
1". Expected profile-type depends on
full DN) prior to communicating the profile to
the EMS.

LSNExt_QosVop_ExpClass TCProfileCreateData_T, This object provides the profile type and name String NA yes LS-EMS V12
TCProfile_T used for EXP-based classification. The object
value is a portion of the profile DN that
includes both profile type and name. E.g.,
"ProfType~~ExpToCosCol@@ProfName~~Profi
le1". Expected profile-type depends on
the EMS.
LSNExt_QosVop_PriMark TCProfileCreateData_T, This object provides the profile type and name String NA yes LS-EMS V12
TCProfile_T used for priority marking. The object value is a
portion of the profile DN that includes both
profile type and name. E.g.,
"ProfType~~CosToPri@@ProfName~~Profile1"
. Expected profile-type depends on
the EMS.

LSNExt_QosVop_ExpMark TCProfileCreateData_T, This object provides the profile type and name String NA yes LS-EMS V12
TCProfile_T used for EXP marking. The object value is a
portion of the profile DN that includes both
profile type and name. E.g.,
"ProfType~~CosColToExp@@ProfName~~Profi
le1". Expected profile-type depends on
the EMS.
LSNExt_VFib_Quota TCProfileCreateData_T, This object indicates the virtual Forwarding Integer 100 yes LS-EMS V12
TCProfile_T Information Base (vFIB) quota.
LSNExt_Mtu_Size TCProfileCreateData_T, This object indicates the MTU size. Integer 1500 yes LS-EMS V12
TCProfile_T (40..9152)
LSNExt_Tpid_Value TCProfileCreateData_T, This object indicates a TPID value that can be Unsigned16 yes LS-EMS V12
TCProfile_T used by VLAN tags on any device that uses the value (Hex
profile. format).
LSNExt_PortTpid_OuterValue TCProfileCreateData_T, This object indicates the TPID field's value in Unsigned16 NNI PIF: 0x88A8, yes LS-EMS V12
TCProfile_T the outer VLAN tag. The object setup is valid if value (Hex Vlan-Tagged PIF:
the related device supports it. format). 0x8100
LSNExt_PortTpid_InnerValue TCProfileCreateData_T, This object indicates the TPID field's value in Unsigned16 0x8100 yes LS-EMS V12
TCProfile_T the inner VLAN tag. The object setup is valid if value (Hex
the related device supports it. format).

10.13 Switch Data

Name Possible Values Comment EMS-LS Version
empty=both
LSNExt_ManualReason "SR_LOCKOUT", The caller uses these values in the Applied Command column if the switch reason is
"SR_FORCE", Manual. If the caller provides the additionalInfo value then the switch Reason values
"SR_MANUAL" (default) will be displayed instead, using user friendly strings LOCKOUT and FORCE.
LSNExt_ExerciseResult {"Success", "Fail"} This attribute is used to indicate either an exercise was performed successfully.
Relevant for PC_EXERCISER command only.
10.14 Maintenance Ops

Name Relevant Maintenance Possible Values Comment EMS-LS Version
Operation or Data Type LS-OSS Information
empty=both
probableCause ACKNOWLEDGE_ALARM MTNM probable cause or An entry from the list of MTNM probable causes supported
(for alarm) "UNIDENTIFIED" by LSN.
probableCauseQualifier ACKNOWLEDGE_ALARM Free format Uniquely identifies the alarm when the other field are
(for alarm) insufficient (for example when one or more alarms emitted
by the same object are "UNIDENTIFIED").
LSNExt_AckUser ACKNOWLEDGE_ALARM Free format The user name of the user that has acknowledged the alarm
(for alarm) in the NMS.
pmParameterName ACKNOWLEDGE_ALARM MTNM pmParameterName or An entry from the list of MTNM PM parameters supported
(for TSA) free format by LSN.
pmLocation ACKNOWLEDGE_ALARM PMLocation_T

(for TSA)


empty=both
granularity ACKNOWLEDGE_ALARM Granularity_T

(for TSA)
thresholdType ACKNOWLEDGE_ALARM PMThresholdType_T

(for TSA)
LSNExt AckUser ACKNOWLEDGE_ALARM Free format The user name of the user that has acknowledged the alarm
(for TSA) in the NMS.
LSNExt_BackupDirFileName "RESTORE_DB", "BACKUP_DB" Free format File or directory name including the path.
LSNExt UserGroup CREATE_USER, EDIT_USER, {"Admin", "Maintenance", The user will be created with the default capabilities
DOWNLOAD_USER "Provision","Configuration", assigned to the given user group.
"Minimum","Level1","Level2"}
userid CREATE_USER, EDIT_USER, Free format The user name to be created/edited/deleted in the server.
DOWNLOAD_USER,
DELETE_USER
password CREATE_USER, EDIT_USER, Free format Encrypted password according to bilateral agreement.
DOWNLOAD_USER
LSNExt_ExpiryDate CREATE_USER, EDIT_USER, Time_T

DOWNLOAD_USER
LSNExt_SNCId ADD_SQUELCH_ENTRY Free format The SNC identifier of an SNC potentially created over the EMS-LS
REMOVE_SQUELCH_ENTRY MSPRing.
The NMS will provide the path of the newly created HO trail
in the following format (repeating this attribute several
times within the additionalInfo Name Value list):
<Multilayer Subnetwork name>;<Subnetwork Connection
name>
(the <> are shall not be provided over the interface)
The EMS will ignore SNCs that do not involve an MSPRing.


empty=both
LSNExt_OAM_Ping_COS performMaintenanceOperation 0-7 (default: 0) Specifies the MPLS Traffic Class (TC) field in the MPLS EMS-LS LSv11,
(MPLS_LSP_PING/MPLS_LSP_TR, header for an MPLS echo request/reply. Valid values are updated
MOM_OPERATE) from 0 to 7. Default is 0 LSv12
getActiveMaintenanceOperations
(MPLS_LSP_PING/MPLS_LSP_TR)
LSNExt_OAM_Ping_TTL performMaintenanceOperation 1-255 (default: Ping- 255, TR- 1) time-to-live (TTL) EMS-LS LSv11,
(MPLS_LSP_PING/MPLS_LSP_TR, updated
MOM_OPERATE) LSv12
LSNExt_OAM_Ping_REPEAT performMaintenanceOperation 1 to 100 (default: 5) Number of MPLS echo requests (pings) to send. EMS-LS LSv11,
(MPLS_LSP_PING, updated
MOM_OPERATE) LSv12
(MPLS_LSP_PING)
LSNExt_OAM_Ping_INTERVAL performMaintenanceOperation 1-100 (default: 1) Specifies the time, in milliseconds (ms), between successive EMS-LS LSv11
(MPLS_LSP_PING, MPLS echo requests. This parameter pace the transmission
MOM_OPERATE) of packets so that the receiving router does not drop
getActiveMaintenanceOperations packets.
(MPLS_LSP_PING) The value is in the range 1-100, using units of 100
milliseconds. I.e., 100 to 10,000ms. (default: 1 [1000ms])
LSNExt_OAM_Ping_TIMEOUT performMaintenanceOperation 1 to 60 (default: 2) Specifies the timeout interval in seconds for an MPLS echo EMS-LS LSv11,
(MPLS_LSP_PING/MPLS_LSP_TR, request packet. The range is from 1 to 60. The default is 2 updated
MOM_OPERATE) seconds LSv12
LSNExt_OAM_Ping_PAD_SIZE performMaintenanceOperation 0-1000 (default: 0) This attribute specifies the size of the Pad TLV in the packet. EMS-LS LSv11,
(MPLS_LSP_PING/MPLS_LSP_TR, 0: Means no Pad TLV updated
MOM_OPERATE) 1-1000: means length of Pad TLV LSv12


empty=both
LSNExt_OAM_Ping_REPLY_PA performMaintenanceOperation “Yes” (default), “No” This attribute specifies the first octet of value field of Pad EMS-LS LSv11,
D (MPLS_LSP_PING/MPLS_LSP_TR, TLV. updated
MOM_OPERATE) It is set to “No” if the sender wants the receiver to drop Pad LSv12
getActiveMaintenanceOperations TLV from reply which means no Pad TLV in reply message
(MPLS_LSP_PING) It is set to “Yes” if the sender wants the receiver to copy
Pad TLV to reply which means there is Pad TLV in reply
message
LSNExt_OAM_Ping_VALIDATE performMaintenanceOperation “Yes”, “No” (default) This attribute specifies the V (Validate FEC Stack) flag of EMS-LS LSv11,
_FEC (MPLS_LSP_PING, Global flags. updated
MOM_OPERATE) It is set to “Yes” if the sender wants the receiver to perform LSv12
getActiveMaintenanceOperations FEC Stack validation; if V is “No”, the choice is left to the
(MPLS_LSP_PING/MPLS_LSP_TR) receiver.
The V flag MAY be set in the echo response when
reverse-path connectivity verification is being performed.
LSNExt_OAM_Ping_VALIDATE performMaintenanceOperation “Yes”, “No” (default) This attribute specifies the R flag of Global flags. When EMS-LS LSv11,
_R (MPLS_LSP_PING/MPLS_LSP_TR,, Validate Reverse Path (R) flag in the echo request is set to updated
MOM_OPERATE) “Yes”, the responder SHOULD return reverse-path FEC LSv12
getActiveMaintenanceOperations information.
(MPLS_LSP_PING/MPLS_LSP_TR,)
LSNExt_OAM_Ping_PKT_TX getActiveMaintenanceOperations integer A read-only parameter. Indicates total number of packets EMS-LS LSv11
(MPLS_LSP_PING) transmitted
LSNExt_OAM_Ping_PKT_RX getActiveMaintenanceOperations integer A read-only parameter. Indicates total number of packets EMS-LS LSv11
(MPLS_LSP_PING) received
LSNExt_OAM_Ping_FLR getActiveMaintenanceOperations 0-10000 A read-only parameter. Indicates packet loss ratio in the EMS-LS LSv11
(MPLS_LSP_PING) range 0-10000 units of 0.01%. I.e., 0 to 100%
LSNExt_OAM_Ping_RT_MIN getActiveMaintenanceOperations integer A read-only parameter. Indicates the minimum round trip EMS-LS LSv11
(MPLS_LSP_PING) time in units of microseconds.
LSNExt_OAM_Ping_RT_AVG getActiveMaintenanceOperations integer A read-only parameter. Indicates the average round trip EMS-LS LSv11


empty=both
LSNExt_OAM_Ping_RT_MAX getActiveMaintenanceOperations integer A read-only parameter. Indicates the maximum round trip EMS-LS LSv11
LSNExt_OAM_Ping_Text_Res getActiveMaintenanceOperations string A read-only parameter. The detailed operation results in EMS-LS LSv11,
ults (MPLS_LSP_PING) textual format. updated
Each Echo Request message is described by: Sequence LSv12
number (0-100), Packet size (0-1000), Round Trip Time
(RTT) unsigned32, Return Code (string, "0"-"13" or "TO"
[timeout]) and Label stack depth (0-4)
LSNExt_OAM_Operation_Stat performMaintenanceOperation “Waiting”, “Running”, “Failed”, A read-only parameter. The status of a related maintenance EMS-LS LSv11,
us (MPLS_LSP_PING/MPLS_LSP_TR, “Done” operation. This is an enumeration type parameter with the updated
MOM_OPERATE) following values: LSv12
getActiveMaintenanceOperations Waiting – The request is in a queue, waiting to run. Note:
(MPLS_LSP_PING/MPLS_LSP_TR) Currently, this value is never reflected to LS.
Running – execution started at the NE
Failed – execution failed
Done – execution ended successfully
sessionID getActiveMaintenanceOperations string A read-only parameter. Indicates the locally unique EMS-LS LSv11,
(MPLS_LSP_PING/MPLS_LSP_TR) identifier associated with the entity that is subject to the updated
maintenance operation. LSv12
LSNExt_OAM_ReplyMode performMaintenanceOperation “IPv4”, “RouterAlert”, “ALCC” This attribute specifies the Reply mode for Echo Reply EMS-LS LSv12
(MPLS_LSP_PING/MPLS_LSP_TR, (default: LDP LSP- IPv4, FEC128- packet.
MOM_OPERATE) IPv4, Static LSP/PW: ALCC) For static LSP/PW only ALCC (Application Level Control) is
getActiveMaintenanceOperations supported.


empty=both
LSNExt_OAM_TR_Text_Result getActiveMaintenanceOperations string A read-only parameter. The detailed operation results in EMS-LS LSv12
s (MPLS_LSP_TR) textual format.
Each Echo Request message is described by: Sequence
number (0-100), Packet size (0-1000), Round Trip Time
(RTT) unsigned32, Return Code (string, "0"-"13" or "TO"
[timeout]), Label stack depth (0-4), TTL (1-255), LSR IP
Address Type ("IPv4" or "IPv6"), LSR IP Address (per address
type), Interface Address Type ("IPv4", "IPv6", "Num"),
Interface Address (per address type), Labels-Stack (list of
labels), and Protocol Type ("Unknown", "Static", "BGP",
"LDP", " RSVP-TE")
10.15 ME Group
timestamp when requested by OSS, or in the object sent with an OCN.

10.16 Configure Protection Group

empty=both
LSNExt_MSPRingId integer format (for NMS-EMS only) No Uniquely identifies the MSPRing in the domain of the receiver.
Essential for each request which handles MS-SPRING PGs
LSNExt_WTRTime integer format (seconds) or "-1" that No An optional parameter that specifies time required to wait before
indicates an unknown value or the the revertive switch can go back to the primary TP.
parameter is not applicable.
10.17 MaintenanceAssociation
Name Type Default when Possible Values or Data Type AVC Comment EMS-LS Version
not provided LS-OSS Information
empty=both
LSNExt_FDThresholdList LSN_OAM_MaModifyData_T, not relevant list of integers, each from 0 up to yes Used for defining the EMS-LS LS v9
LSN_OAM_MaintenanceAssociation_T 1000000 FrameDelay thresholds in
-1 is used for ‘empty’ entries in us (microseconds).
the list
LSNExt_FDTCAThreshold LSN_OAM_MaModifyData_T, not relevant Float in the range from 95.0 to yes Used for defining the EMS-LS LS v9
LSN_OAM_MaintenanceAssociation_T 99.99(steps of 0.01) FrameDelay threshold
LSNExt_FDVThresholdList LSN_OAM_MaModifyData_T, not relevant list of integers, each from 0 up to yes Used for defining the EMS-LS LS v9
LSN_OAM_MaintenanceAssociation_T 1000000 FrameDelay Variation
threshold in us
(Microseconds)

Name Type Default when Possible Values or Data Type AVC Comment EMS-LS Version
not provided LS-OSS Information
empty=both
LSNExt_FDVTCAThreshold LSN_OAM_MaModifyData_T, not relevant Float in the range from 95.0 to yes Used for defining the EMS-LS LS v9
LSN_OAM_MaintenanceAssociation_T 99.99(steps of 0.01) FrameDelay Variation
threshold
LSNExt_DMOffset LSN_OAM_MaModifyData_T, not relevant integer in the range from 1 to 10 yes DMOffset EMS-LS LS v9
LSN_OAM_MaintenanceAssociation_T
LSNExt_AvailabilityThreshold LSN_OAM_MaModifyData_T, not relevant integer in the range from 1 to yes AvailabilityThreshold EMS-LS LS v9
LSN_OAM_MaintenanceAssociation_T 100
LSNExt_UnavailabilityThreshold LSN_OAM_MaModifyData_T, not relevant integer in the range from 1 to yes Unavailability Threshold EMS-LS LS v9
LSN_OAM_MaintenanceAssociation_T 100
LSNExt_SLMResponder LSN_OAM_MaModifyData_T, not relevant Enabled, Disabled, NA yes Specify if SLM responder is EMS-LS LS v9
LSN_OAM_MaintenanceAssociation_T enabled NA – when
responder role is defined
for each MEP
LSNExt_SlmAvailabilityWindow LSN_OAM_MaModifyData_T, not relevant integer in the range from 1 to 10 yes EMS-LS LS v9
LSN_OAM_MaintenanceAssociation_T

10.18 Call
Name SubnetworkConnection_T Default when Possible Values AVC Comment EMS-LS Version
SNCCreateData_T not provided or Data Type LS-OSS Information
SNCModifyData_T empty=both
LSNExt_AEndCPControllerId Call_T, CallCreateData_T, no default String, see Yes ASON OTN: Indicates the location of the HeadEnd – EMS-LS LSv10,
CallModifyData_T comment Call A EP . LSv11.2
WSON : Indicates the ME IP(not CP IP) of the Call’s (WSON)
A-EP
The format of HeadEnd is following:<IP adress>
LSNExt_ZEndCPControllerId Call_T, CallCreateData_T, no default String, see Yes ASON OTN: Indicates the location of the Control EMS-LS LSv10,
CallModifyData_T comment Plane controller of call’s zEnd. LSv11.2
WSON: Indicates the ME IP(not CP IP) of the Call’s (WSON)
Z-EP
The format of string is following:<IP adress>
LSNExt_ProtectAEnd
Call_T, CallCreateData_T no default DN No ASON OTN: the name of the TP at the A-end of the EMS-LS LSv12.2
call. It is used as the A-EP of the Protection
top-level connection
LSNExt_ProtectZEnd Call_T, CallCreateData_T no default DN No ASON OTN: the name of the TP at the Z-end of the EMS-LS LSv12.2
call. It is used as the Z-EP of the Protection
top-level connection
LSNExt_TrailId Call_T, CallCreateData_T, {Trail ID} Yes NMS trail ID.Same as LSNExt_TrailId EMS-LS LSv10
CallModifyData_T SubnetworkConnection_T additional info
LSNExt_Customer Call_T, CallCreateData_T, Empty string string Yes Specify the customer name EMS-LS LSv10
CallModifyData_T
SNC_REVERTIVE Call_T, CallCreateData_T, FALSE Boolean Yes Takes value “True”, i.e. the Connection is revertive, EMS-LS LSv10
CallModifyData_T when the connection can be switched back to its
original route

LSNExt_ASON_Protection Call_T, CallCreateData_T not relevant {"1+R","1++", Yes Specifies ASON/WSON Restoration Scheme EMS-LS LSv10,
"1+1+R", “1+0”, Note: In north bound direction the names of LSv11.2
“1+1”,”ExtraTraffi protection scheme would be mapped to numeric (ExtraTraffic)
c” } values: "1+R" ->1 ,"1++" ->2,
"1+1+R"->3,”ExtraTraffic”->4 “1+0” ->9,
“1+1”->10
LSNExt_AEndTributarySlots Call_T, CallCreateData_T empty list List of integers Yes The list specifies tributary slots(TSs) which were EMS-LS LSv10
occupied by the call’s aEnd that supports payload
type PT0x21;otherwise a list should be empty
Relevant for ASON OTN only.
LSNExt_ZEndTributarySlots Call_T, CallCreateData_T empty list List of integers Yes The list specifies tributary slots(TSs) which were EMS-LS LSv10
occupied by the call’s zEnd that supports payload
type PT0x21; otherwise a list should be empty.
Relevant for ASON OTN only.
LSNExt_MainCurrentConne Call_T not relevant string in format of Yes ID of the main current connection. EMS-LS LSv10
ctionID ConnectionID
LSNExt_ProtCurrentConnec Call_T not relevant string in format of Yes ID of the protection current connection. EMS-LS LSv10
tionID ConnectionID
LSNExt_LinkDiversityLevelO CallModifyData_T String, see No Specifies if strictly disjoint restoration is requested EMS-LS LSv10
fEffort comment (MANDATORY) or not(NONE).The values are
:“MANDATORY”, “NONE”
LSNExt_EMSSignature Call_T last EMS No used only when object is sent with an OCN EMS-LS LSv10
signature
LSNExt_SubnetSignature Call_T last subnetwork No used only during Fast Recovery Upload, from EMS to EMS-LS LSv10
signature LightSoft, when requested by LightSoft, or used only

LSNExt_IsDeleted Call_T boolean No used only during Fast Recovery Upload, EMS-LS LSv10
True if uploaded call were deleted
LSNExt_ASON_WTR Call_T, CallCreateData_T, 5 integer in range Yes ASON OTN and WSON: Wait To Restore Time is the EMS-LS LSV11.2
CallModifyData_T 0,1 to 12 stabilization delay in minutes when recovering from
a failure.
LSNExt_PayloadBW Call_T, CallCreateData_T, not relevant ODUk, see No WSON:Specify the bandwidth (i.e. the traffic rate) of EMS-LS LSv11.2
comments Call payload.
The format is defined by MTNM
transmissionParameters: LayerRate_T type.
LSNExt_FrequencyChanging Call_T, CallCreateData_T not relevant “Changeable”, No WSON:Specifies the ability of the CP to change the EMS-LS LSv11.2
Capability “Unchangeable” frequency of the connection during restoration.
LSNExt_ASTN_HoldOffTime Call_T, CallCreateData_T, 0 integer No ASON OTN: indicates the time, in seconds, between EMS-LS LSv11.2
CallModifyData_T signal degrade/signal fail, and the initialization of
restoration
LSNExt_ReversionMode
Call_T, CallCreateData_T, “NA” “Revertive”, YES ASON OTN :Relevant for protected SNCs managed by EMS-LS LSv12.3
CallModifyData_T “NonRevertive”, transport plane, specifies if the SNC is revertive or
“NA” not
LSNExt_ReversionType Call_T, CallCreateData_T, not relevant “Auto”,”Schedule Yes ASON OTN and WSON: specify the type of the EMS-LS LSv11.2
CallModifyData_T d” reversion. Relevant only for revertive Call( i.e.
SNC_REVERTIVE = true). The values are:
“Auto” - the nonscheduled reversion is specified.
“Scheduled”- the scheduled reversion according to
ME configuration is specified.
LSNExt_AEndType CallCreateData_T no default String, see No WSON:Specifies the port type of a A-end points of EMS-LS LSv11.2
comment the Call
LSNExt_ZEndType CallCreateData_T no default String, see No WSON:Specifies the port type of a Z-end points of EMS-LS LSv11.2
comment the Call

LSNExt_RestorationPriority Call_T, CallCreateData_T, -1 Integer -1(NA),0-7 Yes ASON/WSON:Specifyes priority of the preemption EMS-LS LSv11.2
CallModifyData_T 0-highest,7- lower
10.19 Top Level SNC

ConnectionId SNC, SNCCreateData Not relevant String No This is the identifier of the connection specified by EMS-LS LSv10
control plane.
LSNExt_CallID SNC Not relevant String No the attribute represents the control plane identifier EMS-LS LSv10
of the Call that has given connection
UsingHomeRoute SNC,SNCCreateData True.False Yes Indicates whether the connection is using the EMS-LS LSv10
home(provisioned) route or not
LSNExt_PathType SNC,SNCCreateData ”U” “M”,“P”,“B”,“U” Yes Indicates the path type of the top-level connection: EMS-LS LSv10
“M” - Main ,
“P” - Protection ,
“B” - Both ,
“U” - Undefined

LSNExt_AEndCPControllerId_List SNC,SNCCreateData no default List of strings, Yes ASON OTN and restorable WSON connection: The list EMS-LS LSv10,
see comment is parallel to aEnd list.The list of the strings where LSv11.2
each entry indicates the location of the Control Plane (WSON)
controller for top-level connection’s aEnd.
WSON Non-restorable connections:
Each entry in the list specifies IP address of ME (non
CP) where non-restorable top-level connection’s
aEnds are located
The format of HeadEnd is following:
<IP adress>
LSNExt_AEndTributarySlots_List SNC, SNCCreateData List of empty List of lists of Yes List of lists of integers. Outer list is parallel to A-End EMS-LS LSv10
lists. integers list. Each inner list specifies tributary slots(TSs) which
were occupied by the appropriate aEnd that
supports payload type PT0x21;otherwise an inner list
should be empty.
Each entry of the inner list is an index of TS used by
SNC A-EP.
Relevant for ASON only.
LSNExt_ASON_Protection SNCCreateData not relevant {"1+R","1++", No Specifies ASON Restoration Scheme for edited top EMS-LS LSv10
"1+1+R", “1+0”, level connection
“1+1” }
LSNExt_EditSNCName SNCCreateData_T empty empty value means that the route of the edited SNC EMS-LS LSv10
was not changed
LSNExt_SubnetSignature SNC last subnetwork No used only during Fast Recovery Upload, from EMS to EMS-LS LSv10
signature LightSoft, when requested by LightSoft, or used only
LSNExt_IsDeleted SNC boolean No used only during Fast Recovery Upload, EMS-LS LSv10
True if uploaded top level connection were
deleted

LSNExt_AEndExclusionCPIP_List SNC,SNCCreateData no default List of strings, Yes ASON OTN and WSON restorable connection: EMS-LS LSv11.2
see comment The list is parallel to neTpSncExclusions list. Each
entry in the list specifies IP address of Control Plane
controller that manage a XC associated for exclusion
and presented in neTpSncExclusions as
cross-connect A-EP .The format of each entry is
following: <IP address>
LSNExt_Associated4ExclusionCPIP SNC, SNCCreateData Not relevant List of strings, Yes ASON OTN and restorable WSON connection: Each EMS-LS LSv11.2
_List see comment entry in the list specifies Control Plane controller IP
address of the NEs where the head end of the
associated for exclusion trails resides.
The format of each entry is following: <IP address>
LSNExt_Associated4ExclusionTrail SNC, SNCCreateData Not relevant List of strings, Yes WSON: List of the NMS Trail IDs of associated for EMS-LS LSv11.2
ID_List see comment exclusion OCH trails managed by head ends
specifyed by controller IP from
LSNExt_Associated4ExclusionCPIP_List.
The list is parallel to
LSNExt_Associated4ExclusionCPIP_List.
The format of the list is following:
->([n]{<Workstation Id> ; <trail Id1 (long)>}
,{<Workstation Id> ; <trail Id2 (long)>}
,…,{<Workstation Id> ; <trail Idn (long)>})
LSNExt_TLConnectionType SNC, SNCCreateData not relevant “NonRestorable No WSON:Identify the type of the top-level connection : EMS-LS LSv11.2
HESide”, “NonRestorableHESide” - it is none restorable
“NonRestorable WSON connection that resides ahead of the
TESide”,“Restor HeadEnd
able”, “NonRestorableTESide” - it is none restorable WSON
connection that resides beyond the TailEnd
“Restorable” - it is restorable WSON connection
LSNExt_AEndOSNRThreshold SNC, SNCCreateData not relevant decimal Yes WSON restorable connection:Minimum allowed EMS-LS LSv11.2

OSNR in the HeadEnd.
LSNExt_ZEndOSNRThreshold SNC, SNCCreateData not relevant decimal Yes WSON restorable connection:Minimum allowed EMS-LS LSv11.2
OSNR value in the TailEnd
LSNExt_AEndInitialOSNR SNC, SNCCreateData not relevant decimal Yes WSON restorable connection:OSNR value received EMS-LS LSv11.2
by HeadEnd
LSNExt_ZEndInitialOSNR SNC, SNCCreateData not relevant decimal Yes WSON restorable connection:OSNR value received EMS-LS LSv11.2
by TailEnd
LSNExt_TunedFrequency SNC, SNCCreateData not relevant nnn.nn Yes WSON:Applicable to tunable and non-tunable WSON EMS-LS LSv11.2
frequency in THz OCHs.Decimal notation of the frequency in THz.
LSNExt_PreemptionStatus SNC NA Working Yes WSON/ASON EMS-LS LSv11.2

Preempted, Specify the Preemption status of the top-level(TP)
Preempting[futu connection:
re] Working – the connection is provisioned and not
,NA preempted
Preempted - the connection is provisioned and
preempted by other connection
Preempting - the rerouted connection preempting
the resources of other preempted
connection[future]
NA –the status if the rerouted connection is
preempting is not applicable.

10.20 Logical Interface

Name LSN_CTPData_T, Default when not Possible Values AVC Usage Comment EMS-LS Version
TerminationPoint_T provided or Data Type LS-OSS Information
empty=both
LSNExt_AdminState CTP (LIF) “Disabled” “Enabled”, “Disabled” yes R/W The administrative status of the LIF. EMS-LS V12
LSN_CTPData_T,
TerminationPoint_T
LSNExt_Capability_NfvBackplane
TerminationPoint_T NA "true", "false", “NA” No R/O Indicates whether or not the LS-EMS LSv12.5
physical or logical interface is
connected to an NFVG card via NPT
back plane .

5 Supported MTNM PM Operations
 EnablePMData – to enable PM monitoring on a specific TP or ME (operation of ME is

not recommended). The EMS turns monitorActive to On.
 DisablePMData – to disable PM monitoring on a specific TP or ME (operation on ME is
not recommended). The EMS turns monitorActive to Off.
 EnableTCA – to enable reporting of TCAs. In EMS-XDM, TCA cannot be enabled if alarm
reporting or monitoring is currently disabled, i.e., if alarmMasterMask is NMON or
MASK. Otherwise, it should be set to MON.
 DisableTCA – to disable reporting of TCAs. In EMS-XDM, TCA cannot be disabled if
alarm reporting or monitoring is currently disabled, i.e., if alarmMasterMask is NMON
or MASK. Otherwise, it should be set to QOS_MASK.
 GetAllCurrentPMData – to get the current PM data for a list of TPs.
Get ONCP (Optical Network-Controlled Parameters) data and ONCP thresholds via
GetAllCurrentPMData operation:
The GetAllCurrentPMData method gets ONCP data if the list of input parameters
(pmParameters) includes LSNEXT_OPT_ONCP measurement name. In case if
LSNEXT_OPT_ONCP and PM counters are requested the invalid input exception will be
raised.
The layer rates (layerRateList parameter of PMTPSelect_T), locations (pMLocationList
parameter of PMTPSelect_T) and interval (granularityList parameter of PMTPSelect_T)
which apply to selected measurement points may not be specified. No exception will
be raised if any of described above parameters was specified.
The following ONCP data will be retrieved for TPs specified in list of measurement
points (pmTPSelectList):
No Type TP Type data

1 OTS PTP ONCP Port data parameters(See section 3.2)
2 OTUk/OCHP PTP ONCP Channel data parameters(See section
3.3)
3 OCH CTP of OTS PTP ONCP Channel data parameters(See section
3.3)
4 OMS CTP of OTS PTP ONCP Port data parameters(See section 3.2)
5 OMS CTP of OTS PTP with ONCP Channel data parameters(See section
specified frequency 3.3)
(See 4. below)
If ONCP Channel data parameters (See 3.3) were requested for OMS CTP the CTP should
specify a frequency for which ONCP data will be retrieved. The last component of the OMS
CTP name should be:”/frequency=nnn.nn”, where nnn.nn frequency number, decimals in
THz.

The ONCP data (pmMeasurementList parameter of PMData_T) retrieved for a measurement
point (tpName parameters of PMData_T) include values of ONCP parameters, their locations
and units. The status (intervalStatus parameter of PMMeasurement_T) of retrieved ONCP
data should be obtained for each measurement point.
The value for LSNEXT_OPT_SIGNAL_TYPE ONCP parameter (See section 3.3) is specified as a
unit (unit parameter of PMMeasurement_T).
Layer rate (layerRate parameter of PMData_T) is specified for collected ONCP data of each
measurement points.
The getAllCurrentPMData method should return ONCP data specifying result status for each
ONCP parameter. The EMS should mark PMParameterName_T::intervalStatus of each ONCP
parameter as: Valid - for valid ONCP data; Invalid - for invalid ONCP data .In all other cases
the ONCP data should be marked as invalid as well
The GetAllCurrentPMData method gets ONCP thresholds (See sections 3.4 and 3.5) if the list
of input parameters (pmParameters) includes LSNEXT_OPT_ONCP_MINMAX measurement
name. Both LSNEXT_OPT_ONCP and LSNEXT_OPT_ONCP_MINMAX input parameters may be
requested.
The following ONCP thresholds will be retrieved for TPs specified in list of measurement
points (pmTPSelectList):
No Type TP Type data
1 OTS PTP ONCP thresholds of port data parameters

(See section 3.4 )
2 OTUk/OCHP PTP ONCP thresholds of channel data
parameters (See section 3.5)1
3 OCH CTP of OTS PTP ONCP thresholds of channel data
parameters (See section 3.5)1
4 OMS CTP of OTS PTP ONCP thresholds of port data parameters
(See section 3.4)
5 OMS CTP of OTS PTP with ONCP thresholds of channel data
specified frequency parameters (See section 3.5)1
(See 4. below)
1
The ONCP thresholds of channel data parameters supported only for OTU and OCHP Alien
Lambda ports.
 GetAllHistoryPMData – to request historic PM measurements for a specified list of
TPs/MEs/EMS and time interval, to be provided by the EMS via FTP to a server
designated by the NMS.
 GetHoldingTime – the minimum guaranteed amount of time historic measurements
are maintained.
 GetTCATPParameter – to retrieve a configured value of a threshold. Setting of
parameters is not supported since profile mechanisms (as in the XDM) are not
supported in MTNM v2.

6 PM support in EMS-Syncom
GetAllCurrent PMData and GetHistoryPMData, when applied to Syncom trails endpoints
(where a VC sink is connected to a PI of the same rate), should return the EP PM data which
is associated with the PI object.
GetAllCurrent PMData, GetHistoryPMData, and GetTCATPParameter, when applied to
Syncom VC4, should return, in addition to the regular PM data, also TCM PM data, but only if
the VC4's tcmMode is Sink or Bidirectional. The TCM PM counters are labeled with labels
that begin with PMP_TCM, as defined in MTNM. The mapping of TCM counters depends on
the value of PMLocation_T. For Near_End_Rx, the TC_NE counters are mapped into the
PMP_TCM set, for Far_End_Rx, the TC_FE counters are mapped into the PMP_TCM set, for
Near_End_Tx, the TC_ON counters are mapped into the PMP_TCM set, and for Far_End_Tx,
the TC_OF counters are mapped into the PMP_TCM set.
The DisablePM command, when applied in Syncom, should return all of the TPs in the
failedTPSelectList. The EnablePM command should always succeed (but nothing is actually
done).
The DisableTCA command, when applied to Syncom TPs, should act as follows, per TP: if the
TP's alarmsMasterMask is maskAllAlarms or maskNearEndAlarms, the command succeeds
(but nothing is actually done), else the TP is returned in the failedTPList. The EnableTCA
command, when applied to Syncom TPs, should act as follows, per TP: if the TP's
alarmsMasterMask is dontMask or maskFarEndAlarms, the command succeeds (but nothing
is actually done), else the TP is returned in the failedTPList.
Some cards in Syncom and μADM have optical parameters, which will be displayed by EMS-
Syncom when requested using the Optical Parameters menu item under Maintenance. Cards
that provide any of these parameters should return them, together with SPI PM counters,
mapped according to the table in section 3.

7 PM Record Fields
Field Type/Value Description
Status Valid If not one of the following conditions
Incomplete When
MonitoredTime < 15x60 for 15min data.
MonitoredTime < 24x60^2 for 24hr data.
Invalid NA.
For Ethernet data may be used when counter exceeds 32 bits
that can be provided in MTNM (i.e. this may be used in the
future for Ethernet PM).
Unavailable When forceUpload is specified as false and the requested
record is not available in the EMS.
Zero-suppressed For records that have been zero-suppressed. Multiple periods
that have been zero suppressed in sequence can be repeated
using <NumberOfPeriods>.
NumberOfPeriods Integer The number of periods the given record values are repeated.
StartTime String MTNM/UTC format as follows: "yyyyMMddhhmmss.s[Z|{+|-
}HHMm]" where:
yyyy "0000".."9999" year
MM "01".."12" month
dd "01".."31" day
hh "00".."23" hour
mm "00".."59" minute
ss "00".."59" second
.s ".0"..".9" tenth of second (set to ".0" if EMS or ME cannot
support this granularity)
Z "Z" indicates UTC (rather than local time)
{+|-} "+" or "-" delta from UTC HH "00".."23" time zone
difference in hours
Mm "00".."59" time zone difference in minutes
Unit String For counters this field shall be NULL.
For gauges such as optical parameters this field shall provide
the units as defined in the above and/or as displayed in EMS
GUI.

The complete PM history record is in the format:
<UserLabel>,<EMSNameValue>,<EMSNativeNameValue>,<MENameValue>,
<MENativeNameValue>,<PTPNameValue>,<PTPNativeNameValue>,<CTPNa
meValue>,<CTPNativeNameValue>,<LayerRate>,<Granularity>,<Start
Time>,<MonitoredTime>,<PMParName>,<Location>,<Value>,<Unit>,<S
tatus>,<NumberOfPeriods>
Example:
I5-RS Snk-2, EMS_XDM_1, Saturn, 101, MyXDM_100.40, 22:3, I5-
OPS Snk-2, /section192_rs64=1, I5-RS Snk-2,
LR_Section_OC192_STS192_and_RS_STM64, 15min,
20031106210000.3Z, 11, 900, PMP_UAS, PML_NEAR_END_Rx, 0, ,
Zero-suppressed, 2, 11, 900, PMP_ES, PML_NEAR_END_Rx, 0, ,
Zero-suppressed, 2, 11, 900, PMP_SES, PML_NEAR_END_Rx, 0, ,
Zero-suppressed, 2, 2, 11, 900, PMP_BBE, PML_NEAR_END_Rx, 0, ,
Zero-suppressed, 2,

Table of Contents
1 Introduction .......................................................................................................................2
1.1 Scope.............................................................................................................................. 2
1.2 References ..................................................................................................................... 2
1.3 Abbreviations, Naming Conventions ............................................................................... 2
2 eNI Specification for ASON/WSON .................................................................................3
2.1 Introduction ..................................................................................................................... 3
2.2 Objects and Entities ........................................................................................................ 4
2.3 ASON objects ................................................................................................................. 5
2.3.1 Multi-Layer Routing Area(MLRA) ................................................................................. 5
2.3.2 Call............................................................................................................................... 6
2.3.2.1 callSNC::Call_T structure ......................................................................................... 6
2.3.2.2 callSNC::CallCreateData_T structure ....................................................................... 7
2.3.2.3 callSNC:: CallModifyData_T structure ...................................................................... 8
2.3.2.4 Additional info of Call_T , CallCreateData_T and CallModifyData _T ................... 9
2.3.3 Top Level Connection ................................................................................................ 13
2.3.3.1 subnetworkConnection::SNCCreateData_T structure ............................................ 13
2.3.3.2 subnetworkConnection:: SubnetworkConnection_T ............................................... 16
2.3.3.3 Additional info of SubnetworkConnection_T and SNCCreateData_T ..................... 17
2.3.3.4 The types of the top-level connection ..................................................................... 22
2.4 eNI operations .............................................................................................................. 23
2.4.1 General ...................................................................................................................... 23
2.4.2 Operations supported by eNI for ASON purpose ...................................................... 25
2.4.3 Establish Call ............................................................................................................. 25
2.4.4 Release Call .............................................................................................................. 32
2.4.5 Modify Call ................................................................................................................. 33
2.4.6 addConnections ......................................................................................................... 34
2.4.7 removeConnections ................................................................................................... 39
2.4.8 getAllMLRAs .............................................................................................................. 40
2.4.9 getAllCallsAndTopLevelConnections ......................................................................... 41
2.4.10 getConnectionsAndRouteDetails ............................................................................... 43
2.4.11 Edit and reconnect Call .............................................................................................. 45
2.5 Data Plane Resources .................................................................................................. 47
2.5.1 TP layer parameters .................................................................................................. 47
2.5.2 ME additional info ...................................................................................................... 51
2.5.3 SNC additional info – relevant for current protected SNC without ASON/WSON...... 52
2.6 Attributes and Life Cycles of Objects and Entities ........................................................ 53
2.7 Restoration and/or reversion of ASON OTN/WSON top-level connection.................... 56
2.8 Naming of Objects ........................................................................................................ 57
2.8.1 MLRA Object naming ................................................................................................. 57
2.8.2 Call - Object naming .................................................................................................. 57
2.8.3 Top Level Connection – Object Naming .................................................................... 58
2.8.4 Proxy ODUk CTP – Object Naming ........................................................................... 58
2.8.5 Proxy OCH CTP – Object Naming ............................................................................. 59
2.8.6 Proxy PTP - WSON Call EP – Object Naming .......................................................... 59
2.9 PM ................................................................................................................................ 59
2.9.1 PM ............................................................................................................................. 59
2.10 Alarms ........................................................................................................................... 59
2.11 Maintenance ................................................................................................................. 59
2.12 GCT .............................................................................................................................. 61
2.13 Limitation ...................................................................................................................... 61
2.14 Fast Recovery Upload .................................................................................................. 61
2.15 Open issue.................................................................................................................... 61
3 Appendix A: eNI ASON(WSON) arcitecture ...................................................................62
eNI for ASON/WSON

page 1 of 63
1 Introduction
1.1 Scope
This document specifies the eNI support OTN ASON (LS v10) and WSON (LS v11.2) features.
The specification extends eNI interface, and is based on MTNM v3.5 of the TM Forum.
1.2 References
[1] Architecture for the automatically switched optical network (ASON), ITU-T, G.8080/Y.1304,
02/2012
[2]Terms and definitions for Automatically Switched Optical Networks (ASON),ITU-T,
G.8081/Y.1353, 09/2010
[3]SD1-45 ASON CONTROL PLANE MANAGEMENT - PRIMER
[4]SD1-45 ASON Control Plane Management – scenarios
[5]Apollo ASON Functional Requirements, Yechiel Rosengarten
[6]ASON OTN Requirements for LS V10, Amir Bar-Sever
[7]GMPLS Trail Manager EDD, Ofira Burstein
[8]eNI Structure and Data Mapping, Oleg Khristyuk
[9] LSN_Fast_Recovery.doc, Menachem Malkosh
[10] 26E_notificationServiceUsage_with_ECI_extensions
[11] WSON Requirements for LSv11.docx, Amir Bar-Sever
[12] WSON R2 SRQ, Yechiel Rosengarten
[13] WSON Requirements for STMS.docx, Nataly Malamud, Orly Bachar
[14] eNIPMInterface.doc, Oleg Khristyuk
1.3 Abbreviations, Naming Conventions
ASON Automatically Switched Optical Network
WSON Wavelength Switched Optical Networks
CP Control Plane
I-NNI Internal Network to Network Interface
XC Cross-Connection
MLSN Multi-Layer Subnetwork
MLRA Multi-Layer Routing Area
HeadEnd HeadEnd CP controller that manages a call and supporting top level
connections
TailEnd The end of the call and supporting top level connections
SNCP Subnetwork Connection protection. Implements 1+1 protection scheme.
ASTN Automatic Switched Transport Network
OSNR Optical Signal to Noise Ratio
DL Data link
WSON domain Wavelength Switched Optical Networks domain
BFD Bidirectional Forwarding Detection
LDI Link Down Indication
Table #1.3.1 Abbreviations, Naming Conventions
eNI for ASON/WSON

page 2 of 63
2 eNI Specification for ASON/WSON
2.1 Introduction
The eNI implements the extensions to the MTNM interface release 3.5 which have been developed to
allow the NMS/OSS to set up of ODU/OCH services in a Control Plane network.
Note: The ODU/OCH services are the services from control plane point of view and could be servers
for other ODU services.
The eNI supports the ASON(WSON) architecture that were described in Appendix A. Pic #1 “eNI
architecture of ASON Management”
This architecture provides a separation between the call (which represents the
OTN service offered to the user) and the connections that deliver the service.
The request for a call can be originated by a customer via appropriate eNI request to the server which
transfers it to the HeadEnd Control Plane controller. The Control Plane initiates signaling to establish
the required connections. The Control Plane can also perform automatic reroute in the event of a traffic
failure; when the failure has been repaired the control plane may perform restoration of traffic to the
originally provisioned (home) route.
The operator may control the routing of the connections by providing an
explicit route or routing constraints or allow the control plane freedom to compute the route.
The MTNM interface can be used to discover the network and to set-up and
configure OTN services:
- Discover the Control Plane infrastructure (not implemented in eNI)
Note: the eNI uses the data plan network
- Discover existing Calls and Connections that are in place under the control of the
Control Plane
- Set up and release Calls and Connections
- Configure signaling parameters
Some aspects of the setup of the control plane are outside the scope of the interface and should be
done via EMS:
- Control plane capacity, structure and partitioning.
- The configuration and set-up of the communications infrastructure.
- Routing Area arrangement.
- etc.
The eNI implements new MTNM object types (See section 2.2 below) and the MTNM operations which
are required for establishing, acquiring, monitoring and maintenance ODU/OCH services in a Control
Plane network.
All proprietary changes of MTNM interface is specified in this document.
eNI for ASON/WSON

page 3 of 63
2.2 Objects and Entities
This section describes the objects and entities which are used in the eNI.

to be supported
Multi-Layer Routing RA, ASON Domain A routing area is the routing domain
Area(MLRA) managed by Control Plane controller.
The routing area is defined by a subnetwork.
The distinction between routing area and
subnetwork is that, the links are visible from
inside a routing area, whereas inside a
subnetwork only connection points can be
seen.
Call ASON Component A control plane component which represents
the service offered to the user.
Note: In case of ECI Call is a part of NMS
ASON protected trail
Top Level Connection Represents a connection supporting a call in
the Control Plane. A Top Level Connection
is defined by SNC.
Table #2.2.1 The MTNM objects and entities supported in the eNI
The following term mapping simplify the using of different terminology by Control Plane, EMS, NMS
and eNI actors
No NMS MTNM Control plane
1 ASON Component Call Trail
2 Trail ( not ASON SNC(in northbound direction) N/A
protected) Note: in southbound direction –
list of SNCs
3 Trail 1+R which contains list of SNCs and Call/s Trail/s (1+R)
data and control plane Note: the data plain
components cross-connects are not
seen in CP
4 Trail Route Top Level Connection(SNC) with LSP(Path)
(provisioned, pre- cross-connects
planned,
restoration/rerouted)
5 ASON Domain Multi-Layer Routing Area(MLRA) ASON Domain
Note: represented by MLSN
Table #2.2.2 The mapping of terms used by different actors
eNI for ASON/WSON

page 4 of 63
2.3 ASON objects
2.3.1 Multi-Layer Routing Area(MLRA)
1) eNI supports two levels of the routing area hierarchy:
1.1 Top level RA – The Routing Area specifies the entire control plane domain. The top-level Routing Area is a unique instance of top-level Routing Area
1.2 Routing Node - the lowest level Routing Area which corresponds to the entire routing capability of an ME and represented by regular (data plan)
singleton subnetwork. There is always a 1:1 relationship between a Managed Element and a Routing Node.
2) MLRA(MLSN) additional info attributes:

No Name Applicable eNI Default when not Possible Values AVC Comment EMS-LS Version
Types/Structures provided or Data Type LS-OSS Information
empty=both
RoutingAreaLevel MultiLayer TopLevelRA TopLevelRA No It indicates in the level of EMS-LS LSv10
Subnetwork_T the MLRA.
Table #2.3.1 MLRA(MLSN) additional info attributes
eNI for ASON/WSON

page 5 of 63
2.3.2 Call
The call structure is the abstraction of a call. G.8080 defines a call as the association between
endpoints that supports an instance of an ASON service.
2.3.2.1 callSNC::Call_T structure

1) The eNI uses MTNM callSNC::Call_T structure in order to specify the Call:
Field Type Details

callName globaldefs::Naming The name of the Call provided by NMS.See
Attributes_T Table #2.7.2 Call Object naming
userLabel string The user label of Call
owner string ECI implementation: not used in eNI, should
be ignored
networkAccessDomain string ECI implementation: not used in eNI, should
be ignored
nativeEMSName string The name represents how the Call is referred
to on EMS displays
callId string This attribute represents the identifier of the
Call. It is provided by Control Plane.
callState1 CallState_T The state of the call . For ECI implementation
See Notes2 below.
aEnd CallEnd_T The end point (EP) of the Call. ECI
implementation: EP is represented by CTP/PTP
ASON OTN: The EP is ODUk CTP
WSON: The EP is either OTUk PTP3 or OCH
CTP4 contained by OTS port.
zEnd CallEnd_T The end point (EP) of the Call. ECI
WSON: The EP is either OTUk PTP 2 or OCH
CTP3 contained by OTS port.
callParameters CallParameterProfile ECI implementation: not used in eNI
_T
callDiversity Diversity_T ECI implementation: only
linkDiversityLevelOfEffort::Diversity is used.
ASON and WSON OTN :It specifies if strictly
disjoint restoration were requested
(“MANDATORY”) or not(“NONE”)
diversitySynthesis string ECI implementation: not used in eNI, should
be ignored
1
ECI implementation: callState has following states:
"ESTABLISHED_IN_SERVICE": All the supporting Connections have been created successfully
“IN_PROGRESS”: A Call has been either created or modified through the addition of Connections and
not all new Connections have been successfully created yet.
“LSNEXT_FAILED_TO_ESTABLISH” – Creation of at least one connection has been failed and retrying
was stopped
2 The OTUk PTP is an EP of WSON Call if it contains restorable and non-restorable connection. See Table
#2.3.3.4-2
3 The OCH CTP contained by OTS PTP is EP of WSON Call if it contains only restorable top-level connection.
See Table #2.3.3.4-2
eNI for ASON/WSON

page 6 of 63
Field Type Details
linkDiversityViolations DiversityInfo_T ECI implementation: not used in eNI, should
be ignored
nodeDiversityViolation DiversityInfo_T ECI implementation: not used in eNI, should
s be ignored
linkPartialDiversityList DiversityInfoList_T ECI implementation: not used in eNI
nodePartialDiversityLis DiversityInfoList_T ECI implementation: not used in eNI, should
t be ignored
callAdditionalInfo globaldefs::NVSList See Table #2.3.2.4 The Call additional info
_T attributes
Table #2.3.2.1 The fields of the Call_T
2.3.2.2 callSNC::CallCreateData_T structure

1) The eNI uses MTNM callSNC::CallCreateData_T structure in order to specify the
configuration of an established Call:
Field Type Details

callName globaldefs::Naming The name of the Call provided by NMS. See
Attributes_T Table #2.7.2 Call Object naming
forceUniqueness boolean ECI implementation: always False,
otherwise "unable to comply" exception is
raised
owner string ECI implementation: not used in eNI, should
be ignored
networkAccessDomain string ECI implementation: not used in eNI, should
be ignored
aEnd CallEnd_T The end point (EP) of the Call. ECI
WSON: The EP is either OTUk PTP1 or OCH
CTP 2 contained by OTS PTP.
zEnd CallEnd_T The end point (EP) of the Call. ECI
WSON: The EP is either OTUk PTP 1 or OCH
CTP 2 contained by OTS PTP.
callParameters CallParameterProfile ECI implementation: not used in eNI
_T
callDiversity Diversity_T ECI implementation: only
linkDiversityLevelOfEffort:: Diversity is used.
ASON OTN and WSON : It specifies if strictly
disjoint restoration were
requested(MANDATORY) or not(NONE)
1
The OTUk PTP is EP of WSON Call if it contains restorable and non-restorable connection.
2
The OTS PTP is EP of WSON Call if it contains only restorable top-level connection. See Table #2.3.3.4-2
eNI for ASON/WSON

page 7 of 63
Field Type Details
additionalCreationInfo globaldefs::NVSList See Table #2.3.2.4 The Call additional info
_T attributes
Table #2.3.2.2 The fields of the CallCreateData_T
2.3.2.3 callSNC:: CallModifyData_T structure

1) The eNI uses MTNM callSNC:: CallModifyData _T structure in order to modify the Call
parameters:
Field Type Details
forceUniqueness boolean ECI implementation: always False
owner string ECI implementation: not used in
eNI, should be ignored
networkAccessDomain string ECI implementation: not used in
eNI, should be ignored
additionalModificationIn globaldefs::NVSList_T See Table #2.3.2.4 The Call
fo additional info attributes
Table #2.3.2.3 The fields of the CallModifyData_T
eNI for ASON/WSON

page 8 of 63
2.3.2.4 Additional info of Call_T , CallCreateData_T and CallModifyData _T
1) Additional Info attribute of Call_T , CallCreateData_T and CallModifyData _T types.
Name Applicable Default Possible Values AVC Comment EMS-LS Version

eNI Types/ when not or Data Type LS-OSS Information
Structures provided empty=both
LSNExt_AEndCPContr Call_T, no default String, see Yes ASON OTN: Indicates the EMS-LS LSv10
ollerId CallCreateData_T, comment location of the HeadEnd – Call
CallModifyData_T A EP
WSON : Indicates the ME
IP(not CP IP) of the Call’s A-EP
The format of string is
following:<IP address>
LSNExt_ZEndCPContr Call_T, no default String, see Yes ASON OTN: Indicates the EMS-LS LSv10
ollerId CallCreateData_T, comment location of the Control Plane
CallModifyData_T controller of call’s zEnd
WSON: Indicates the ME IP(not
CP IP) of the Call’s Z-EP
The format of string is

LSNExt_TrailId Call_T, {Trail ID} Yes NMS trail ID LSv10
CallCreateData_T, .Same as LSNExt_TrailId
CallModifyData_T SubnetworkConnection_T
additional info
LSNExt_Customer Call_T, Empty string Yes Specify the customer name LSv10
CallCreateData_T, string
CallModifyData_T
LSNExt_ASON_WTR Call_T, 5 integer in range Yes ASON OTN and WSON: Wait To LSV11.2
CallCreateData_T, 0,1 to 12 Restore Time is the
CallModifyData_T stabilization delay in minutes
when recovering from a failure.
SNC_REVERTIVE Call_T, False Boolean Yes ASON OTN and WSON: Takes LSv10,LSv11
CallCreateData_T, value “True”, i.e. the .2(WSON)
CallModifyData_T Connection is revertive, when
the connection can be switched
back to its original route
eNI for ASON/WSON

page 9 of 63
LSNExt_ASON_Protec Call_T, not {"1+R","1++", Yes Specifies ASON/WSON LSv10,LSv11
tion CallCreateData_T, relevant "1+1+R", “1+0”, Restoration Scheme .2
CallModifyData_T “1+1”, Note: In north bound direction
”ExtraTraffic” } the names of protection
scheme would be mapped to
numeric values: "1+R" ->1
,"1++" ->2, "1+1+R"-
>3,”ExtraTraffic”->4 “1+0” -
>9,
“1+1”->10
LSNExt_AEndTributary Call_T, empty list List of integers Yes The list specifies tributary LSv10
Slots CallCreateData_T, slots(TSs) which were occupied
by the call’s aEnd that supports
payload type PT0x21;otherwise
a list should be empty.
Relevant for ASON only
LSNExt_ZEndTributary Call_T, empty list List of integers Yes The list specifies tributary LSv10
Slots CallCreateData_T, slots(TSs) which were occupied
by the call’s zEnd that supports
payload type PT0x21;
otherwise a list should be
empty
LSNExt_MainCurrentC Call_T not relevant string in format of Yes ID of the main current LSv10
onnectionID ConnectionID connection.
LSNExt_ProtCurrentCo Call_T not relevant string in format of Yes ID of the protection current LSv10
nnectionID 5 ConnectionID connection.
LSNExt_EMSSignature Call_T TBD TBD TBD TBD TBD TBD

(TBD)
5
Not relevant for WSON Call in LS v11
eNI for ASON/WSON

page 10 of 63
LSNExt_SubnetSignat Call_T TBD TBD TBD TBD TBD TBD
ure
(TBD)
LSNExt_LinkDiversityL CallModifyData_T String, see No Specifies if strictly disjoint EMS-LS LSv10
evelOfEffort comment restoration is requested
(MANDATORY) or not(NONE).
The values are :
“MANDATORY”,
“NONE”
LSNExt_PayloadBW Call_T, not ODUk, see No WSON:Specify the bandwidth EMS-LS LSv11.2
CallCreateData_T, relevant comments (i.e. the traffic rate) of Call
payload.
The format is defined by MTNM
transmissionParameters:
LayerRate_T type.
LSNExt_FrequencyCha Call_T, not “Changeable”, No WSON:Specifies the ability of EMS-LS LSv11.2

ngingCapability CallCreateData_T, relevant “Unchangeable” the CP to change the frequency
of the connection during
restoration.
LSNExt_ASTN_HoldOff Call_T, 0 integer No ASON: indicates the time, in EMS-LS LSv11.2

Time CallCreateData_T, seconds, between signal
CallModifyData_T degrade/signal
fail, and the initialization of
restoration
LSNExt_ReversionTyp Call_T, not “Auto”, Yes ASON OTN and WSON: specify EMS-LS LSv11.2
e CallCreateData_T, relevant ”Scheduled” the type of the reversion
CallModifyData_T Relevant only for revertive
Call( i.e. SNC_REVERTIVE =
true)
The values are:

“Auto” - the nonscheduled
eNI for ASON/WSON

page 11 of 63
reversion is specified.
“Scheduled”- the scheduled
reversion according to ME
configuration is specified.
LSNExt_AEndType CallCreateData_T no default String, see No WSON:Specifies the port type EMS-LS LSv11.2
comment of a A-end points of the Call
LSNExt_ZEndType CallCreateData_T no default String, see No WSON:Specifies the port type EMS-LS LSv11.2
comment of a Z-end points of the Call
LSNExt_RestorationPri Call_T, -1 Integer - Yes ASON/WSON:Specifyes priority EMS-LS LSv11.2

ority CallCreateData_T, 1(NA),0-7 of the preemption
CallModifyData_T
0-highest,7- lower
Table #2.3.2.4 The Call additional info attributes
eNI for ASON/WSON

page 12 of 63
2.3.3 Top Level Connection
2.3.3.1 subnetworkConnection::SNCCreateData_T structure

1) The eNI uses MTNM subnetworkConnection::SNCCreateData_T structure in order to configure a created Top Level Connection of established
Call:
Field Type Details
userLabel string userLabel may be specified by client. May be empty
forceUniqueness boolean Specifies whether uniqueness of the userLabel is required amongst SNCs of
the server
In ECI implementation, always False,
otherwise "unable to comply" exception is raised
owner string owner may be specified by the client. May be empty
direction globaldefs::ConnectionDirection_T Specifies the direction of the connection must be specified by the client
staticProtectionLevel StaticProtectionLevel_T ECI implementation: is not supported, should be ignored
protectionEffort ProtectionEffort_T ECI implementation: only EFFORT_WHATEVER is valid. otherwise
"unable to comply " exception is raised
rerouteAllowed Reroute_T indicates if the Control Plane are allowed to reroute this SNC
ECI implementation :should be RR_YES, otherwise "invalid input" exception
is raised
networkRouted - to specify NetworkRouted_T indicates if the route must be or is computed and implemented at the
prov/pre-planned/rerouted and network level
ECI implementation :Should be NR_NO for provisioned/preplanned top–
level connection ,otherwise "invalid input" exception is raised
sncType SNCType_T ECI implementation: should be ST_EXPLICIT , otherwise "invalid input"
exception is raised
layerRate transmissionParameters::LayerRate_T Identifies the layer at which the SNC is to be made
ECI implementation: should be ODUk rates for ASON
and OCH for WSON protected SNC
ccInclusions CrossConnectList_T Specifies a list of cross-connects that must be used by the SNC
ECI implementation: should be empty list, otherwise "invalid input"
exception is raised. The cross-connects are specified by a list of aEnd and
zEnd pairs
neTpInclusions ResourceList_T ECI implementation: is not supported, should be ignored
fullRoute boolean Indicates if the specified constraints describe the full route of the top-level
connection.
ECI implementation: should be True only, otherwise "unable to comply"
exception is raised
eNI for ASON/WSON

page 13 of 63
Field Type Details
neTpSncExclusions ResourceList_T ECI implementation:

ASON OTN : not supported- should be empty, otherwise "unable to comply"
exception is raised – LSv10
ASON OTN(LSv11.2) and WSON: A-EPs of OCH cross-connects that

specifies associated for exclusion restorable WSON top-level connection. It
should be filled if rerouted path of established WSON top-level connection
calculated by control plane should exclude the resources of associated
WSON top-level connection.
Note: For instance when created 1++ WSON trail in scope of NMS which
contains two 1+R calls -the connection of both calls should be associated for
exclusion in order to diverse the restoration routes of both calls.
6
aEnd globaldefs::NamingAttributesList_T ECI implementation:
-ASON OTN and WSON restorable connection: A list of A-EPs of cross-
connects that specify a route of the top-level connection including top-level
connection A-EP. The order of A-EPs in the list is defined according to the
route path: starting from the AEnd to the zEnd of the top-level connection.
- WSON Non-restorable connections:
A list of A-EPs of cross-connects that specify a route of the connection and
does not include Call EPs and EPs managed by HeadEnd/TailEnd. The order
of A-EPs in the list is defined according to the route path: starting from the
AEnd to the zEnd of the top-level connection. The list is parallel to zEnd list.
zEnd globaldefs::NamingAttributesList_T ECI implementation:
ASON OTN: An empty list for top-level connection
WSON restorable connection:
Last entry specifies the TailEnd Z-EP
the following behaviors are possible:
1. The list contains Z-EPs of cross-connects that specify a full route of the
restorable connection. The list is parallel to aEnd list.
2. Contains only one entry - TailEnd Z-EP
Note : The CP IP of the Z-EP TailEnd is defined by last entry in
6
For WSON restorable connection: the A-EP may specify the “long cross-connect”. This is logical cross-connect composed of more than one OCH cross-connects resides in the
different cards on the same NE. The “long cross-connect” is transparent entity for eNI and should be handled by caller(NMS) and server(EMS)
eNI for ASON/WSON

page 14 of 63
Field Type Details
LSNExt_AEndCPControllerId_List
- WSON Non-restorable connection:
A list of Z-EPs of cross-connects that specify a route of the connection and
does not include Call EPs and EPs managed by HeadEnd/TailEnd. The list is
parallel to aEnd list.
additionalCreationInfo globaldefs::NVSList_T See Table #2.3.3.3 Top Level connection additional info attributes
Table #2.3.3.1 The fields of the SubnetworkConnection::SNCCreateData_T
eNI for ASON/WSON

page 15 of 63
2.3.3.2 subnetworkConnection:: SubnetworkConnection_T
1) The eNI uses MTNM subnetworkConnection:: SubnetworkConnection_T structure for specifying Top Level Connection of the Call:
Field Type Details

name globaldefs::NamingAttributes_T The name represents the name of the SubnetworkConnection
userLabel string The user label of the subnetwork connection is client data
nativeEMSName string The name represents how the SNC is referred to on server displays
owner string The owner is provisioned by the client
sncState SNCState_T ECI implementation: is not supported
TODO: verify if the sncState should be supported
direction globaldefs::ConnectionDirection_T Specifies the direction of the subnetwork connection
rate transmissionParameters::LayerRate_T Identifies the layer rate of the SNC
ECI implementation: should be OTUk rates for ASON OTN
And OCH for WSON
staticProtectionLevel StaticProtectionLevel_T ECI implementation: is not supported, should be ignored
sncType SNCType_T ECI implementation: should be ST_EXPLICIT
aEnd TPDataList_T ECI implementation: A list of A-EPs of cross-connects that specify a route of
the top-level connection. Should be synchronized with zEnd list.
The same as SNCCreateData_T::aEnd
zEnd TPDataList_T ECI implementation: A list of Z-EPs of cross-connects that specify a route of
the top-level connection. Should be synchronized with aEnd list.
The same as SNCCreateData_T::zEnd.
rerouteAllowed Reroute_T indicates if the Control Plane are allowed to reroute this SNC
ECI implementation :should be RR_YES
networkRouted NetworkRouted_T indicates if the route must be or is computed and implemented at the network
level
ECI implementation: Should be NR_NO for provisioned/preplanned top–level
connection and NR_YES for rerouted connection.
additionalInfo globaldefs::NVSList_T See Table #2.3.3.3 Top Level connection additional info attributes
Table #2.3.3.2 The fields of the SubnetworkConnection:: SubnetworkConnection_T
eNI for ASON/WSON

page 16 of 63
2.3.3.3 Additional info of SubnetworkConnection_T and SNCCreateData_T
1) Additional Info attribute of SubnetworkConnection:: SubnetworkConnection_T and SNCCreateData_T
Name Applicable Default when Possible AVC Comment EMS-LS Version
eNI Types/ not provided Values LS-OSS Information
Structures or Data Type empty=both
ConnectionId SNC, Not relevant String No This is the identifier of the LSv10
SNCCreateData connection specified by control
plane.
LSNExt_CallID SNC Not relevant String No the attribute represents the control LSv10
plane identifier of the Call that has
given connection
UsingHomeRoute SNC, True.False Yes Indicates whether the connection is LSv10
SNCCreateData using the home(provisioned) route
or not
LSNExt_PathType SNC, ”U” Yes Indicates the path type of the top- LSv10
SNCCreateData “M”,“P”,“B”,“ level connection
U” “M” - Main
“P” - Protection
“B” - Both
“U” - Undefined
LSNExt_AEndCPCo SNC, no default List of Yes The list is parallel to aEnd list. EMS-LS LSv10
ntrollerId_List SNCCreateData strings, see ASON OTN and restorable WSON LSv11.2(W
comment connection: The list of the strings SON)
where each entry indicates the
location of the Control Plane
controller for top-level connection’s
aEnd.
WSON Non-restorable connections:

Each entry in the list specifies IP
address of ME (non CP) where non-
restorable top-level connection’s
aEnds are located
The format of each entry is
eNI for ASON/WSON

page 17 of 63
LSNExt_AEndExclu SNC, no default List of Yes ASON OTN and WSON restorable EMS-LS LSv11.2
sionCPIP_List SNCCreateData strings, see connection:
comment The list is parallel to
neTpSncExclusions list. Each entry
in the list specifies IP address of
Control Plane controller that manage
a XC associated for exclusion and
presented in neTpSncExclusions as
cross-connect A-EP .
LSNExt_Associated SNC, Not relevant List of Yes ASON OTN and restorable WSON EMS-LS LSv11.2
4ExclusionCPIP_Lis SNCCreateData strings, see connection: Each entry in the list
t comment specifies Control Plane controller IP
address of the NEs where the head
end of the associated for exclusion
paths reside
LSNExt_Associated SNC, Not relevant List of Yes WSON: List of the NMS Trail IDs of EMS-LS LSv11.2
4ExclusionTrailID_ SNCCreateData strings, see associated for exclusion OCH trails
List comment managed by head ends specified by
controller IP from
LSNExt_Associated4ExclusionCPIP
_List.
The list is parallel to
LSNExt_Associated4ExclusionCPIP
_List.
The format of the list is following: -
>([n]{<Workstation Id> ; <trail Id1
(long)>} ,{<Workstation Id> ; <trail
Id2 (long)>} ,…,{<Workstation Id> ;
<trail Idn (long)>})
eNI for ASON/WSON

page 18 of 63
LSNExt_AEndTribut SNC, List of empty List of lists of Yes List of lists of integers. Outer list is LSv10
arySlots_List SNCCreateData lists. integers parallel to A-End list. Each inner list
specifies tributary slots(TSs) which
were occupied by the appropriate
aEnd that supports payload type
PT0x21;otherwise an inner list
should be empty
.Each entry of the inner list is an
index of TS used by SNC A-EP.
LSNExt_EMSSignatu last EMS No used only when object is sent with EMS-LS LSv10
re SNC signature an OCN
SNC No used only during Fast Recovery EMS-LS LSv10

LSNExt_SubnetSign last Upload, from EMS to LightSoft,
ature subnetwork when requested by LightSoft, or
signature used only when object is sent with
an OCN
LSNExt_ASON_Prot SNCCreateData not relevant {"1+R","1+ No Specifies ASON Restoration LSv10
ection +", Scheme for edited top level
"1+1+R", connection
“1+0”, Note: In north bound direction the
“1+1” } names of protection scheme would
be mapped to numeric values:
"1+R" ->1 ,"1++" ->2, "1+1+R"-
>3, “1+0” ->9, “1+1”->10
LSNExt_EditSNCNa SNCCreateData_T empty OTN ASON :empty value means that EMS-LS LSv10
me the route of the edited SNC was not
changed
LSNExt_TLConnecti SNC, not relevant “NonRestora No WSON:Identify the type of the top- EMS-LS LSv11.2
onType SNCCreateData bleHESide”, level connection :
“NonRestora “NonRestorableHESide” - it is none
bleTESide”,
restorable WSON connection that
“Restorable”,
resides ahead of the HeadEnd
“NonRestorableTESide” - it is none
restorable WSON connection that
eNI for ASON/WSON

page 19 of 63
resides beyond the TailEnd
“Restorable” - it is restorable WSON
connection
LSNExt_AEndOSNR SNC, not relevant decimal Yes WSON restorable connection: EMS-LS LSv11.2
Threshold SNCCreateData Minimum allowed OSNR in the
HeadEnd.
LSNExt_ZEndOSNR SNC, not relevant decimal Yes WSON restorable connection: EMS-LS LSv11.2
Threshold SNCCreateData Minimum allowed OSNR value in the
TailEnd.
LSNExt_AEndInitial SNC, not relevant decimal Yes WSON restorable connection: EMS-LS LSv11.2
OSNR SNCCreateData OSNR value received by HeadEnd
LSNExt_ZEndInitial SNC, not relevant decimal Yes WSON restorable connection: EMS-LS LSv11.2
OSNR SNCCreateData OSNR value received by TailEnd
LSNExt_TunedFreq SNC, not relevant nnn.nn Yes WSON:Applicable to tunable and EMS-LS LSv11.2
uency SNCCreateData frequency in non-tunable WSON OCHs
THz Decimal notation of the frequency in
THz.
LSNExt_Preemption SNC NA Working Yes WSON/ASON EMS-LS LSv11.2
Status Preempted, Specify the Preemption status of the
Preempting[f top-level(TP) connection:
uture] Working – the connection is
,NA provisioned and not preempted
Preempted - the connection is
provisioned and preempted by other
connection
Preempting - the rerouted
connection preempting the
resources of other preempted
connection[future]
NA –the status if the rerouted
eNI for ASON/WSON

page 20 of 63
connection is preempting is not
applicable.
Table #2.3.3.3 Top Level connection additional info attributes
eNI for ASON/WSON

page 21 of 63
2.3.3.4 The types of the top-level connection
1) eNI should distinguish three types of the ASON and WSON top-level connection according to
its proposal and trigger of its creation : provisioned, preplanned and rerouted.
No Type of the top- The additional info parameters of Description
level connection SNCCreateData_T/
SubnetworkConnection_T which
specify the type of Top-Level
connection
Provisioned networkRouted = NR_NO The Call’s permanent top-level
UsingHomeRoute=True(additional connection whose creation was
info attribute) triggered by management request and
established in the transport plane.
Preplanned networkRouted = NR_NO The Call’s top-level connection whose
UsingHomeRoute=False(additional creation was triggered by
info attribute) management request. The
preplanned connection is not
established on the transport plane
until it is required.
Rerouted networkRouted = NR_YES The top-level connection that was
UsingHomeRoute=False(additional created by Control Plane request.
info attribute)
Table #2.3.3.4-1 The types of Top Level connection
2) eNI should distinguish three types of the WSON top-level connection according to its location
in relation to WSON domain. See Table #2.3.3.4-2
No Type of the Location The value of Description

WSON top- LSNExt_TLConnectionType
level additional info parameter of
connection SNCCreateData_T/Subnet
workConnection_T
Restorable in WSON “Restorable” The WSON top-level connection for
domain which the CP performs automatic
reroute in the event of a traffic
failure. The Restorable connection
may be Provisioned, Preplanned
(not supported) or Rerouted. See
Table #2.3.3.4-1
Non- external to “NonRestorableHESide” The WSON top-level connection for
restorable WSON which the CP doesn’t perform
ahead of domain, automatic reroute in the event of a
the resides ahead traffic failure. The non-restorable
HeadEnd of the connection supports an update of its
HeadEnd frequency by CP based on Call’s
capability. See
LSNExt_FrequencyChangingCapabi
lity.. See Table #2.3.3.4-1
. See Table #2.3.3.4-1
eNI for ASON/WSON

page 22 of 63
No Type of the Location The value of Description
WSON top- LSNExt_TLConnectionType
level additional info parameter of
connection SNCCreateData_T/Subnet
workConnection_T
Non- external to “NonRestorableTESide” The WSON top-level connection for
restorable WSON which the CP doesn’t perform
beyond the domain, automatic reroute in the event of a
TailEnd resides traffic failure. The non-restorable
beyond the connection supports an update of its
TailEnd frequency by CP based on Call’s
capability. See
LSNExt_FrequencyChangingCapabi
lity.. See Table #2.3.3.4-1
Table #2.3.3.4-2 the restorable and non-restorable Top Level connection
2.4 eNI operations

The operations supported by eNI.
2.4.1 General
1) According to the rules of MTNM, only an operation which fails can raise an exception, and when
an operation fails, no change can have happened to the system. Therefore, if some failures
occur after the system has begun to be changed, either the system servicing the operation must
roll back to the pre-operation state, or the operation succeeds and specific failures are returned
to the caller.
1.1 A thrown exception or an operation reply should have error reason (errorReason) which
contains a list of the errors in the following format: ([number of errors]{ error },{ error
},…).
1.1.i. Each error should have the following format: {òbject`, èrrorCode`, èrrorText`},
where
1. òbject` is one of the following :
a. DN of the error object(as string)
b. "Total" - for general error description
2. "NMS" – for NMS error description
3. "EMS" - for EMS error description
4. èrrorCode`: integer representation of the error
5. èrrorText`: the text displayed in the GUI.
Note #1:The format of the errorReason is specified according to “eNI Structure and Data
Mapping” doc. See REF [8].
Note #2The of errorReason has the same structure as LSNExt_Reply_Codes contained
reply codes of createAndActivateSNC eNI operation
2) If no exceptions were raised, the server should perform the operation and reply with
2.1 success indication in case of succeeded operation.
2.2 failure indication if the operation were failed or partially succeeded.
eNI for ASON/WSON

page 23 of 63
3) The following exceptions will be raised in case of eNI operation failure:
3.1 The EXCPT_NOT_IMPLEMENTED exception is raised when server does not support
the requested operation.
3.2 The EXCPT_INTERNAL_ERROR exception is raised in case of non-specific server
internal failure.
3.3 The server checks the syntax of the request. If the request is not valid, the
EXCPT_INVALID_INPUT exception is raised.
3.4 If any of the mandatory input parameters cannot be satisfied, an
EXCPT_UNABLE_TO_COMPLY exception is raised: " At least one of the mandatory
input parameters cannot be satisfied". Mandatory parameters are parameters which are
marked “not best effort”.
3.5 The EXCPT_NE_COMM_LOSS exception is raised when server is unable to
communicate with any Control Plane component and communications is required to
complete the request.
4) If the caller provides transmission parameters for the involved TPs(tpsToModify), then it is up to
the server to provision the parameters on these TPs before or after the performing requested
operation, as appropriate. If a given entry in the list of transmission parameters specified in the
TPData_T cannot be successfully applied to the TP, for any reason, then the errorReason field is
appended with an appropriate reason text. Applying transmission parameters is best-effort and
the resulting values of the transmission parameters are provided in the updated tpsToModify
parameter
5) The creation, deletion or/and modification of the calls, top-level connections and their cross-
connects in Control Plane should not be duplicated in Data Plane. For instance the creation of
cross-connect which specifies the route details of top-level connection should not trigger creation
of SubnetworkConnection and sending the OCN notification in Data Plane.
5.1 The Data Plane resources (the CTP/PTP) should be updated as a result of the Control
Plane operation.
eNI for ASON/WSON

page 24 of 63
2.4.2 Operations supported by eNI for ASON purpose
1) The following is the list of MTNM operations should be supported.
Each operation is supported both for EMS-LS and LS-OSS, unless otherwise noted.
1.1 getAllMLRAs [future]
1.2 getAllCallsAndTopLevelConnections
1.3 getConnectionsAndRouteDetails
1.4 establishCall
1.5 releaseCall
1.6 modifyCall
1.7 addConnections
1.8 removeConnections
2.4.3 Establish Call
void multiLayerSubnetwork::MultiLayerSubnetworkMgr_I::establishCall (
in callSNC::CallCreateData_T callCreateData,
in subnetworkConnection::SNCCreateDataList_T connectionCreateDataList,
in string routeGroupsNumber,
inout subnetworkConnection::TPDataList_T tpsToModify,
out callSNC::CallAndTopLevelConnectionsAndSNCs_T
callAndTopLevelConnectionsAndSNCs,
out subnetworkConnection::SNCCreateDataList_T sNCsNotCreated,
out subnetworkConnection::SubnetworkConnectionList_T partialSNCs,
out string callErrorReason
) raises (globaldefs::ProcessingFailureException)
1) The operation establishes a point to point bidirectional Call with one or more top level
connections .The Control Plane will create the Call ,set up the requested top level Connection
, set any necessary TP Data(if requested) , and send appropriate notifications to the caller.
1.1 In case when the call were created the following notification/s should sent to the
caller:
1.1.i. OCN for the created top-level connections.
1.1.ii. OCN for the successfully created Call.
1.1.iii. SC on callState parameter of the established Call. See 2.4.3.1.6.ii.
Note: the order of the sent notifications is not defined by eNI.
1.2 The caller (NMS) should specify the part of the name(CallCreateData_T::callName)
of the created call. The provided name should contain whole call name according to
Table #2.7.2 Call Object naming except < CallId ={o}> part ,which would be
specified by server(EMS) . The server is responsible for guaranteeing the
uniqueness of the name within the caller context
eNI for ASON/WSON

page 25 of 63
1.3 The server (EMS) should specify the names(SubnetworkConnection_T::name)of the
created top level connection according to Table #2.7.3 Top Level Connection Object
naming. The server is responsible for guaranteeing the uniqueness of the name
within the server context.
1.3.i. The created top level connection should have connection ID –which is the
control plane identifier of the connection. See ConnectionId of
SubnetworkConnection_T additional info attribute.
1.4 At least one end point of the Call has to be within the EMS domain that manages
HeadEnd CP controller.
1.4.i. ASON OTN: The caller (NMS) should specify the HeadEnd and TailEnd via
LSNExt_AEndCPControllerId and LSNExt_ZEndCPControllerId Call’s
additional info attributes respectively .
1.4.ii. WSON OTN: The caller(NMS) should specify the location of the Call’s A-EP
and Z-EP Nodes IP(not CP IP) via LSNExt_AEndCPControllerId and
LSNExt_ZEndCPControllerId Call’s additional info attributes respectively
1.5 The server (EMS) should specify the callID (Call_T::callID) of the created Call - the
attribute which represents the control plane identifier of the established Call.
1.6 The server (EMS) should specify the state of the established Call. See callState::
callSNC::Call_T parameter in the Table #2.3.2.1.The Call state should be:
1.6.i. “ESTABLISHED_IN_SERVICE” – if all top-level connections were configured
and signaled by control plane
1.6.ii. “IN_PROGRESS” – if some top-level connection were configured but not
signaled by the control plane. In case if the control plane completes signaling
of all Call’s top-level connection SC notification should be sent.
1.6.iii. “LSNEXT_FAILED_TO_ESTABLISH” – if some of top-level connection were
configured but failed to be signaled by the control plane and the control plane
stopped signaling.
2) The call cannot be created without providing the supporting top-level connections. The
EXCPT_INVALID_INPUT exception should be raised in this case. See 7.4.v
2.1 In case if the creation of all provided top-level connection were failed, the empty Call
should not be created. The EXCPT_UNABLE_TO_COMPLY exception is raised.
2.2 WSON: The call cannot be created without providing the restorable (See Table
#2.3.3.4-2 ) top-level connection. The EXCPT_INVALID_INPUT exception should be
raised in this case
3) If no exceptions were raised, the server establishes Call, and replies with a success
indication. See item #1.1 in the 2.4.1 General section
3.1 If only some of provided top level connection were created successfully, the server
establishes Call and replies with failure indication.
3.1.i. ASON OTN: The state of the Call(callState:: callSNC::Call_T) should be
“IN_PROGRESS”
3.1.ii. WSON: The state of the Call(callState:: callSNC::Call_T) should be
“IN_PROGRESS” if control plane retry to create failed top level connection;
eNI for ASON/WSON

page 26 of 63
or “LSNEXT_FAILED_TO_ESTABLISH” if control plane stopped creation of
failed top level connection.
4) The following parameters should be provided as input parameters of the operation:

4.1 callCreateData - describes the call to be created
4.1.i. The parameters of callCreateData should be specified according to Table
#2.3.2.2 The fields of the CallCreateData_T
1. The caller (NMS) should specify full DN of the call’s aEnd and zEnd
TPs.
4.1.ii. The additional info attributes of callCreateData Table # Table #2.3.2.4 Call
additional info attributes
4.2 connectionCreateData -Set of connections requested to support the call.

Note: In case of WSON connectionCreateData may contain restorable and non-
restorable connections. See Table #2.3.3.4-2
4.2.i. The parameters of each ASON OTN and WSON restorable top level
connection should be specified according to Table #2.3.3.1 The fields of the
SubnetworkConnection::SNCCreateData_T
eNI Implementation :
1. The caller (NMS) should specify full DNs of A-EPs of cross-connects
(SNCCreateData_T::aEnd) that define a route of the top-level
connection including top-level connection A-EP.
2. The order of A-EPs in the list(SNCCreateData_T::aEnd) is defined
according to the route path starting from the AEnd to the zEnd of the
top-level connection.
3. The caller (NMS) should specify aEnd only in a forward direction
(from the AEnd to the zEnd) of the top-level connection route. The
backwards direction should be co-routed with forward and use the
same resources(e.g. TP, tributary slots etc.)
4. The SNCCreateData_T::zEnd parameter:
a. ASON OTN: should be ignored.
b. WSON restorable connection: all entries except last one that
specifies Z-EP of TailEnd should be ignored.
5. For WSON restorable connection: The caller (NMS) should specify
a. LSNExt_TLConnectionType as “Restorable”.
b. neTpSncExclusions and LSNExt_AEndExclusionCPIP_List,
LSNExt_Associated4ExclusionCPIP_List addition info
parameters if the association for exclusion were required. See
Table #2.3.3.1 and Table #2.3.3.3 correspondingly
c. OSNR initial and threshold values for HeadEnd and TailEnd.
See LSNExt_AEndOSNRThreshold,
LSNExt_ZEndOSNRThreshold, LSNExt_AEndInitialOSNR
eNI for ASON/WSON

page 27 of 63
and LSNExt_ZEndInitialOSNR additional info parameters,
Table #2.3.3.3
d. Frequency of the connection. See LSNExt_TunedFrequency
,Table #2.3.3.3
4.2.ii. The parameters of each WSON non-restorable top level connection should
be specified according to Table #2.3.3.1 The fields of the
SubnetworkConnection::SNCCreateData_T
eNI Implementation :
1. The caller (NMS) specifies full DNs of A-EPs and Z-EPs
(SNCCreateData_T::aEnd and SNCCreateData_T::zEnd
respectively) that define a route of the non-restorable top-level
connection. See SNCCreateData_T::aEnd and
SNCCreateData_T::zEnd in the table #2.3.3.1
a. The order of A-EPs and Z-EPs in the list should be
synchronized and be defined according to the route path
starting from the AEnd to the zEnd of the non-restorable top-
level connection.
b. The A-EPs and Z-EPs are specified only in a forward
direction (from the aEnd to the zEnd) of the top-level
connection route. The backwards direction should be co-
routed with forward and use the same resources (e.g. TP,
frequency etc.)
c. LSNExt_AEndCPControllerId_List should be specified in
parallel to aEnd list. See Table #2.3.3.3
2. The caller (NMS) should specify:
a. LSNExt_TLConnectionType as “NonRestorableHESide” if the
WSON non-restorable top level connection resides ahead of
the HeadEnd; and “NonRestorableTESide” if the WSON non-
restorable top level connection resides beyond of the TailEnd
b. Frequency of the connection. See LSNExt_TunedFrequency
,Table #2.3.3.3
4.2.iii. a connection route specified by a list of aEnd and zEnd pairs and their path
type parameter.
4.2.iv. The additional info attributes of top level connection specified by the table
#2.3.3.3 Top Level connection additional info attributes
4.3 routeGroupsNumber – eNI implements only "NA" value means that this parameter
can be ignored.
4.4 tpsToModify -The TPs to modify . In eNI implementation should be empty, otherwise
would be ignored.
4.4.i. The resulting values of the configured transmission parameters are provided
in the updated tpsToModify output parameter.
eNI for ASON/WSON

page 28 of 63
5) The following parameters will be returned as the output parameters:
5.1 callAndTopLevelConnections - the call and list of supporting top-level connections
that were created
eNI implementation:
5.1.i. The server(EMS) should specify call’s aEnd and zEnd according to following:
1. The full DN should be specified for call’s aEnd.
2. The proxy DN should be specified for call’s zEnd.
a. ASON OTN: See Table #2.7.4 Proxy ODUk CTP Object
naming
b. WSON: See Table #2.7.6 Proxy PTP - WSON Call EP –
Object Naming
5.1.ii. In eNI implementation the created ASON and WSON restorable top-level
connection contains the list of cross-connects that specifies the connection
route. The cross-connects are described by a list of cross-connects A-
EPs(SubnetworkConnection_T::aEnd ).
1. The order of A-EPs in the list is defined according to the route path
starting from the AEnd to the zEnd of the top-level connection.
2. The server (EMS) should specify AEnd only in a forward direction
backwards direction is co-routed with the forward direction and uses
the same resources (e.g. TP, tributary slots etc.)
3. Each connection’s aEnd should be specified by proxy DN.
a. ASON: See Table #2.7.4 Proxy ODUk CTP Object naming
b. WSON : See Table #2.7.5 Proxy OCH CTP Object naming
4. The SubnetworkConnection_T::zEnd parameter
a. ASON: should be ignored.
b. WSON restorable connection: all entries except last one that
specifies Z-EP of TailEnd should be ignored.
5.1.iii. The created WSON non-restorable top-level connections contain the list of
cross-connects that specifies the connection route. The cross-connects are
described by a list of their A-EPs(i.e. SubnetworkConnection_T::aEnd) and
Z-EPs( i.e. SubnetworkConnection_T::zEnd ) pairs.
1. The order of A-EPs and Z-EPs in the list is defined according to the
route path. See Table #2.3.3.2.
2. The server (EMS) should specify A-End and Z-EPs only in a forward
direction of the top-level connection route. The backwards direction is
co-routed with the forward direction and uses the same resources
(e.g. TP, frequency etc.)
eNI for ASON/WSON

page 29 of 63
3. Each connection’s aEnd and zEnd may be specified by proxy DN
when server (EMS) doesn’t manage specified TP. See Table #2.7.5
that describe the format of proxy DN.
5.1.iv. The server(EMS) should specify :
1. all other call’s parameters that were not specified by 6.1.i according to
Tables #2.3.2.1 and Table #2.3.2.4
2. all other top level’s parameters that were not specified by 6.1.ii and
6.1.iii according to Tables #2.3.3.2 and Table #2.3.3.3
5.2 connectionsNotCreated- empty list, is not supplied by MTNM.
5.3 partialSNCs – empty list, is not supplied by MTNM.
5.4 errorReason - specifies the error(s) if any. See item #1.1 in the 2.4.1 General section
6) The following exceptions will be raised in case of the operation failure:
6.1 All exceptions that are defined by item #3 in 2.4.1 General section
6.2 The EXCPT_OBJECT_IN_USE exception is raised, if the TPs at the aEnd and the
zEnd which specify cross connects of top level connection are already in use by
another top level connection of a different call. The exception should be raises only if
none of the top-level connection were created.
6.2.i. If at least one of the top level connection were created successfully the
server should reply with specifying the reason of failure in the format
specified by item #1.1 in the 2.4.1 General section: ”The Call is not managed
in given EMS “
6.3 The EXCPT_INVALID_INPUT exception is raised if the provided call parameters
are:
6.3.i. Empty or invalid CallCreateData_T::callName.
6.3.ii. Empty or invalid CallCreateData_T::aEnd.
6.3.iii. Empty or invalid CallCreateData_T::zEnd.
6.3.iv. Empty or invalid LSNExt_AEndCPControllerId and/or
LSNExt_ZEndCPControllerId CallCreateData_T additional info parameters
6.4 The EXCPT_INVALID_INPUT exception is raised if the following invalid parameters
of top level connection are provided:
6.4.i. If the directionality of the added top level connection provided by `direction`
parameter is inconsistent with a directionality of the connection’s cross-
connects specified by the list of aEnd and the zEnd TP pairs.
6.4.ii. If the directionality of the added top level connection is inconsistent with the
existing top level connection.
6.4.iii. If the provided SNCCreateData::ccInclusions were not empty.
6.4.iv. If the provided SNCCreateData::sncType is not ST_EXPLICIT
6.4.v. Empty connectionCreateDataList.
eNI for ASON/WSON

page 30 of 63
6.4.vi. WSON: If the LSNExt_TLConnectionType does not match to the type of the
WSON top-level connection ( See LSNExt_TLConnectionType Table
#2.3.3.3) :
1. WSON restorable top-level connection were specified as either
“NonRestorableHESide” or “NonRestorableTESide”
2. WSON non-restorable top level connection were specified as
“Restorable”
6.4.vii. WSON :If the following WSON top-level connection’s parameters were not
specified:
1. LSNExt_TunedFrequency
2. LSNExt_AEndOSNRThreshold, LSNExt_ZEndOSNRThreshold,
LSNExt_AEndInitialOSNR and LSNExt_ZEndInitialOSNR additional
info parameters for WSON restorable top-level connection.
6.5 The EXCPT_UNABLE_TO_COMPLY exception is raised:
6.5.i. If the provide operation routeGroupsNumber parameter are different from
“NA”
Note: eNI doesn’t support specifying route groups.
6.5.ii. If the provided layer rate of top level connection layerRate is different from:
1. ODUk, for ASON
2. OCH, for WSON
6.5.iii. In the EMS-LS case: If the operation were requested on EMS that doesn’t
manage control plan provided by the given call .The exception should contain
the following error reason in the format specified by item #1.1 in the 2.4.1
General section: ”The Call is not managed in given EMS “
6.5.iv. If the Control Plane failed to create all top level connection. The exception
should contain an appropriate error reason in the format specified by item
#1.1 in the 2.4.1 General section.
6.5.v. If the operation requests the user label uniqueness. In this case
forceUniqueness was True.
Note: eNI doesn’t support the user label uniqueness
6.5.vi. If the operation requests rearranged of the existing top-level connections. In
this case connectionRouteReArrangementAllowed is True.
Note: eNI doesn’t support creation of provisioned and pre-planned top-level
connection of call which can be rearranged in order to meet the request.
6.5.vii. If the value of the requested protectionEffort is different from
EFFORT_WHATEVER.
6.5.viii. If the Control Plane does not allow rerouting of added top-level connection
upon failure. In this case the SNCCreateData_T::rerouteAllowed parameter
had RR_NO value.
6.5.ix. If the Control Plane is requested to compute and implemented top-level
connection at the network level. In this case the
SNCCreateData_T::networkRouted parameter had NR_YES value
eNI for ASON/WSON

page 31 of 63
Note: The route of provisioned and pre-planned top-level connection should be
computed by the caller (NMS).
6.5.x. If the specified route is not full route of the top-level connection and control
plan is required to compute the route. In this case the
SNCCreateData_T::fullRoute is False.
Note: eNI doesn’t support creation of provisioned or pre-planned top-level
connection of call that does not have full route.
6.5.xi. ASON OTN:If the neTpSncExclusions list is not empty.
Note: eNI doesn’t support exclusion list for ASON OTN at this stage
6.5.xii. WSON: If the SNCCreateData:: LSNExt_ASON_Protection WSON
restoration scheme was specified as either "1++" or "1+1+R".
7) The EXCPT_USER_LABEL_IN_USE exception should not be raised. The eNI does not
support user label uniqueness.
2.4.4 Release Call
void multiLayerSubnetwork::MultiLayerSubnetworkMgr_I:: releaseCall (

in globaldefs::NamingAttributes_T callName,
out subnetworkConnection::SubnetworkConnectionList_T remainingSNCs,
out string errorReason
1) The operation releases a given call. The control plane will remove the connections from the
network, delete the connection objects, remove the call, delete the call object and send
appropriate notifications to the caller
1.1 In case when the call were released the following notification/s should sent to the
caller:
1.1.i. ODN for the successfully deleted connections.
1. It Includes ODN for the restorable and non-rerouted top-level
connections (if were exist) of WSON call. See Table #2.3.3.4-2
1.1.ii. ODN for the successfully released Call
Note: the order of the sent notifications is not defined.
2) The operation is performed successfully even if the provided call does not exist in the
network. In this case no error should be returned and EXCPT_ENTITY_NOT_FOUND
exception should not be thrown.
3) The following parameters should be provided as an input parameters of the operation:
3.1 callName -the name of the call to be released. The format of the call name is defined
according to Table #2.7.2 Call Object naming
eNI for ASON/WSON

page 32 of 63
3.2 tpsToModify -The TPs to modify In eNI implementation should be empty, otherwise
would be ignored
3.2.i. The resulting values of the configured transmission parameters are provided
in the updated tpsToModify output parameter.
4.1 remainingSNCs- empty list in eNI implementation: The parameter is not supported
4.2 errorReason - specifies the error(s) if any. See item #1.1 in the 2.4.1 General
section.
5) The operation is partially succeeded if only part of the top-level conation were deleted. The
call is not deleted.
5.1 The ODN of successfully deleted connections should be sent to the caller
5.2 Open Issue :In this case the state of the call shall be changed to “IN_PROGRESS”
and control plane retrieve deletion of the remained connections.
6) The following exception will be raised:
6.2.i. If the Control Plane cannot release the route. The top level connections were
not deleted in this case. The exception should contain an appropriate error
reason in the format specified by item #1.1 in the 2.4.1 General section.
6.2.ii. In the EMS-LS case: If the operation were requested on EMS that doesn’t
manage control plan which established the given call .The exception should
contain the following error reason in the format specified by item #1.1 in
the 2.4.1 General section : ”The Call is not managed in given EMS “
2.4.5 Modify Call
void multiLayerSubnetwork::MultiLayerSubnetworkMgr_I::modifyCall (
in callSNC::CallModifyData_T callModifyData,
out callSNC::Call_T modifiedCall
1) The operation allows the caller to modify the following attributes of a Call in accordance with the
caller provided parameter list. The modified parameters are specified below:
1.1 The modified parameters are specified by CallModifyData_T.See Table #2.3.2.3 The
fields of the CallModifyData_T.
1.2 The modified Call additional info attributes(See Table #2.3.2.4 The Call additional info
attributes) are specified below:
1.2.i. LSNExt_AEndCPControllerId and LSNExt_ZEndCPControllerId
1.2.ii. LSNExt_TrailId
eNI for ASON/WSON

page 33 of 63
1.2.iii. LSNExt_Customer
1.2.iv. WSON: LSNExt_ASON_WTR
1.2.v. SNC_REVERTIVE
1.2.vi. LSNExt_LinkDiversityLevelOfEffort
1.3 Only changed additional info attributes should be specified in CallModifyData_T.
2) In case when the call were modified the AVC notification/s should sent to the caller.
3.1 callName - the attribute represents the control plane identifier of the Call. See
Call_T::callId
4.1 modifiedCall- the modified call with all its parameters. See Table #2.3.2.1 The fields of
the Call_T
5.2 The EXCPT_ENTITY_NOT_FOUND exception is raised when the input parameter
references a Call that does not exist.
5.3 The EXCPT_UNABLE_TO_COMPLY exception is raised if the server cannot comply
with the request, and cannot determine the reason it could not comply
6) The EXCPT_USERLABEL_IN_USE should not be raised. The user label uniqueness constraint is
not supported in eNI
2.4.6 addConnections
void multiLayerSubnetwork::MultiLayerSubnetworkMgr_I::addConnections (
in subnetworkConnection::SNCCreateDataList_T connectionsToAdd,
in boolean connectionRouteReArrangementAllowed,
out subnetworkConnection::SubnetworkConnectionList_T connectionList,
out subnetworkConnection::SubnetworkConnectionList_T partialSNCs,
1) The operation adds/updates(eNI implementation) one or more supporting top level connections
to/in an existing call and set any necessary TP Data(if requested). The Control Plane will either
set up the entire top level Connection or will fail the entire top level Connection; there is no partial
top level Connection state.
1.1 In case when the top level connection were created the appropriate OCN notification/s
should sent to the caller.
eNI for ASON/WSON

page 34 of 63
1.2 In case when the top level connection were changed the appropriate AVC notification/s
should sent to the caller.
1.2.i. WSON: It Includes AVC for the restorable and non-rerouted top-level
connections ( if were exist) of WSON call. See Table #2.3.3.4-2
1.3 The server(EMS) should specify the name(SubnetworkConnection_T::name)of the
created top level connection according to Table #2.7.3 Top Level Connection Object
naming. The server is responsible for guaranteeing the uniqueness of the name within
the server(EMS) context.
1.4 The state of the Call (See callState:: callSNC::Call_T) should be changed to
“IN_PROGRESS” if added/updated connection were configured by were not signaled
yet by control plane.
1.4.i. In case if the control plane completes signaling of all added/updated top-level
connection SC notification should be sent.
Note: In eNI implementation addConnections allows editing existing top-level connection. Please
see 2.4.11.
2.1 callName -the name of the call for which the specified connections will be added. The
format of the call name is defined according to Table #2.7.2 Call Object naming
2.2 connectionsToAdd-the list of the names of top level connections to be added.
2.2.i. The parameters of each top level connection should be specified according to
the Table #2.3.3.1 “The fields of the SubnetworkConnection::SNCCreateData_T
“
2.2.ii. a connection route of :
1. ASON OTN and WSON restorable top level connection is specified by a
list of SNCCreateData_T::aEnd of cross-connects and their parameters.
eNI implementation:
a. Each aEnd should be specified by full DN.
b. The order of A-EPs in the list is defined according to the route
path: starting from the AEnd to the zEnd of the top-level
connection.
c. The caller (NMS) should specify aEnd only in a forward direction
same resources(e.g. TP, tributary slots etc.)
d. The SNCCreateData_T::zEnd parameter:
i. ASON OTN: should be ignored.
ii. WSON restorable top level connection: all entries except
last one that specifies Z-EP of TailEnd should be ignored.
eNI for ASON/WSON

page 35 of 63
2. WSON non-restorable top level connection is specified by a list of
SNCCreateData_T::aEnd and SNCCreateData_T::zEnd of cross-
connects and their parameters.
a. The caller (NMS) specifies full DNs of A-EPs and Z-EPs
(SNCCreateData_T::aEnd and SNCCreateData_T::zEnd
respectively)
b. The order of A-EPs and Z-EPs in the list should be synchronized
and be defined according to the route path starting from the AEnd
to the zEnd of the non-restorable top-level connection.
c. The A-EPs and Z-EPs are specified only in a forward direction
(from the aEnd to the zEnd) of the top-level connection route. The
same resources (e.g. TP, frequency etc.)
2.2.iii. The SNCCreateData additional info attributes of top level connection specified
by Table #2.3.3.3 “Top Level connection additional info attributes”
2.2.iv. The connectionID (See ConnectionId additional info parameter in
SNCCreateData_T ,Table #2.3.3.3 Top Level connection additional info
attributes) should be provided only in case when addConnections is used for
editing/reconnect of existing top-level connection/s. See 2.4.11
2.2.v. The ÀSON Restoration Scheme` (See LSNExt_ASON_Protection,Table
#2.3.3.3) should be provided be caller(NMS) for each top level connection( i.e.
SubnetworkConnection::SNCCreateData_T) only if ASON Restoration Scheme
is changed.
2.2.vi. In case if the ASON Restoration Scheme is changed either from “1++” to
“1+1+R” or vice versa and there are no updates in provisioned
LSNExt_EditSNCName with empty value (See Table #2.3.3.3).
Note: Any other changes of ASON Restoration Scheme require adding/

removing top level connections (e.g. Update "1+R" to "1+1+R" requires adding
new provisioned top level connection.)
2.3 connectionRouteReArrangementAllowed - Indicates whether any existing connections of
call can be rearranged in order to meet the request. eNI implements: only False value is
supported.
2.4 tpsToModify -The TPs to modify - In eNI implementation should be empty, otherwise
would be ignored.
2.4.i. The resulting values of the configured transmission parameters are provided in
the updated tpsToModify output parameter.
3.1 connectionList– the List of top-level connections that were created and added to the call.
The successfully created top level connection should contain :
3.1.i. eNI implementation :a connection route of ASON OTN and WSON restorable top
level connection is specified by a list of aEnd of cross-connects.
1. The order of A-EPs in the list is defined according to the route path:
eNI for ASON/WSON

page 36 of 63
2. The server (EMS) should specify aEnd only in a forward direction (from
the AEnd to the zEnd) of the top-level connection route. The backwards
direction should be co-routed with forward and use the same
resources(e.g. TP, tributary slots etc.)
3. Each aEnd should be specified by proxy DN:
a. ASON: See Table #2.7.4 Proxy ODUk CTP Object naming
b. WSON: See Table #2.7.5 Proxy OCH CTP – Object Naming
4. The SubnetworkConnection_T::zEnd :
a. ASON OTN: should be ignored
b. WSON restorable top level connection: all entries except last one
that specifies Z-EP of TailEnd should be ignored. The Z-EP
should be specified by proxy DN.
3.1.ii. The parameter specified by Table #2.3.3.2 The fields of the
SubnetworkConnection:: SubnetworkConnection_T
3.1.iii. The additional info attributes specified by Table #2.3.3.3 “Top Level connection
additional info attributes”
3.1.iv. eNI implementation :a connection route of WSON non-restorable top level
connection is specified by a list of aEnd and zEnd of cross-connects.
1. The order of A-EPs and Z-EPs in the list is defined according to the route
path. See Table #2.3.3.2..
direction of the top-level connection route. The backwards direction is co-
routed with the forward direction and uses the same resources (e.g. TP,
frequency etc.)
3. Each connection’s aEnd and zEnd may be specified by proxy DN when
server (EMS) doesn’t manage specified TP. See Table #2.7.5 that
describe the format of proxy DN
3.2 partialSNCs – empty list in eNI implementation: The parameter is not supported.
3.3 errorReason - specifies the error(s) if any. See item #1.1 in the 2.4.1 General section.
4.3 The EXCPT_OBJECT_IN_USE exception is raised, if the TPs at the aEnd and the zEnd
which specify cross connects of top level connection are already in use by another top
level connection.
eNI for ASON/WSON

page 37 of 63
4.4.i. If the provided layer rate of top level connection layerRate is different from:
1. ODUk, for ASON
2. OCH, for WSON
4.4.ii. In the EMS-LS case: If the operation were requested on EMS that doesn’t
manage control plan that established the given call .The exception should
contain the following error reason in the format specified by item #1.1 in the 2.4.1
General section: ”The Call is not managed in given EMS “
4.4.iii. If the Control Plane cannot establish the requested route. The top level
connection is not created in this case. The exception should contain an
appropriate error reason in the format specified by item #1.1 in the 2.4.1 General
section.
4.4.iv. If the operation requests the user label uniqueness. In this case
forceUniqueness was True.
Note: eNI doesn’t support the user label uniqueness
4.4.v. If the operation requests rearranged of the existing top-level connections. In this
case connectionRouteReArrangementAllowed is True.
Note: eNI doesn’t support creation of provisioned and pre-planned top-level
connection of call which can be rearranged in order to meet the request.
4.4.vi. If the value of the requested protectionEffort is different from
EFFORT_WHATEVER.
4.4.vii. If the Control Plane does not allow rerouting of added top-level connection upon
failure. In this case the SNCCreateData_T::rerouteAllowed parameter had
RR_NO value.
4.4.viii. If the Control Plane is requested to compute and implemented top-level
connection at the network level. In this case the
SNCCreateData_T::networkRouted parameter had NR_YES value
Note: The route of provisioned and pre-planned top-level connection should be
computed by the caller (NMS).
4.4.ix. If the specified route is not full route of the top-level connection and control plan
is required to compute the route. In this case the SNCCreateData_T:: fullRoute
is False.
Note: eNI doesn’t support creation of provisioned or pre-planned top-level
connection of call that does not have full route.
4.4.x. ASON OTN:If the neTpSncExclusions list is not empty.
Note: eNI doesn’t support exclusion list for ASON OTN at this stage
4.4.xi. WSON: If the SNCCreateData:: LSNExt_ASON_Protection WSON restoration

scheme was specified as either "1++" or "1+1+R".
eNI for ASON/WSON

page 38 of 63
4.5 The EXCPT_INVALID_INPUT exception is raised :
4.5.i. If the directionality of the added top level connection provided by `direction`
parameter is inconsistent with a directionality of the connection’s cross-connects
specified by the list of aEnd and the zEnd TP pairs.
4.5.ii. If the directionality of the added top level connection is inconsistent with the
existing top level connection.
4.5.iii. If the provided SNCCreateData::ccInclusions were not empty.
4.5.iv. WSON: If the LSNExt_TLConnectionType does not match to the type of the
WSON top-level connection ( See LSNExt_TLConnectionType Table #2.3.3.3) :
1. WSON restorable top-level connection were specified as either
“NonRestorableHESide” or “NonRestorableTESide”
2. WSON non-restorable top level connection were specified as
“Restorable”
4.5.v. WSON :If the following WSON top-level connection’s parameters were not
specified:
1. LSNExt_TunedFrequency
2. LSNExt_AEndOSNRThreshold, LSNExt_ZEndOSNRThreshold,
LSNExt_AEndInitialOSNR and LSNExt_ZEndInitialOSNR additional info
parameters for WSON restorable top-level connection.
4.6 The EXCPT_CAPACITY_EXCEDEED is raised if the provisioning of additional
connection were failed due to network capacity constraints.
4.7 The EXCPT_UNSUPPORTED_ROUTING_CONSTRAINTS if the route of the additional
top-level connection can be created only with violation of the routing constraints.
Note: eNI support only ‘strictly disjoint restoration’ routing constraints were established
connection should be fully diverse from already provisioned /preplanned /rerouted top-level
connection.
5) The EXCPT_USER_LABEL_IN_USE exception should not be raised. The eNI does not support
user label uniqueness.
2.4.7 removeConnections
void multiLayerSubnetwork::MultiLayerSubnetworkMgr_I::removeConnections (
in globaldefs::NamingAttributesList_T connectionNamesList,
out subnetworkConnection::SubnetworkConnectionList_T
sNCsNotDeleted,
eNI for ASON/WSON

page 39 of 63
1) This operation removes one or more top level connections from an existing call and to set any
necessary TP Data (if requested). As a consequent action, the control plane removes the top
level connections from the network, delete the top level connection objects
1.1 If the top level connections were removed the appropriate ODN notification/s should
sent to the caller
1.1.i. WSON: It Includes ODN for the restorable and non-rerouted top-level
connections (if were exist) of WSON call. See Table #2.3.3.4-2
2) The following parameters should be provided as input parameters of the operation :

2.1 callName -the name of the call from which the specified connections will be removed
2.2 connectionNamesList -the list of the names of top level connections to be removed
2.3 tpsToModify -The TPs to modify - In eNI implementation should be empty, otherwise
would be ignored.
2.3.i. The resulting values of the configured transmission parameters are provided in
the updated tpsToModify output parameter.
3.1 sNCsNotDeleted – empty list. eNI doesn’t support it.
3.2 errorReason - specifies the error(s) if any. See item #1.1 in the 2.4.1 General section.
4) The operation is performed successfully even if top level connection/s which was/were specified
for deletion does not exist. In this case the error/s should not be returned.
5) The following exception will be raised:
5.2 The EXCPT_INVALID_INPUT exception is raised, if the empty list of the top level
connection names (connectionNamesList) were provided as input parameters of the
operation.
5.2.i. WSON: The EXCPT_INVALID_INPUT exception is raised, if WSON trail has
restorable and non-restorable top-level connection but only some of them were
listed in connectionNamesList
5.3 In the EMS-LS case: The EXCPT_UNABLE_TO_COMPLY exception is raised, if the
operation were requested on EMS that doesn’t manage control plan. The exception
should contain the following error reason in the format specified by item #1.1 in
the 2.4.1 General section : ”The Control Plan controller is not managed in given EMS “
5.4 The EXCPT_ENTITY_NOT_FOUND exception is raised, if the requested call does not
exist. The exception should contain the following error reason in the format specified by
item #1.1 in the 2.4.1 General section: “The Call does not exist. “
2.4.8 getAllMLRAs
void emsMgr::EMSMgr_I::getAllMLRAs ( in unsigned long how_many,
out multiLayerSubnetwork::SubnetworkList_T mLRAList,
out multiLayerSubnetwork::SubnetworkIterator_I sIt
) raises (globaldefs::ProcessingFailureException);
eNI for ASON/WSON

page 40 of 63
1) The getAllMLRAs should not be supported by eNI.
2) The eNI supports top level MLRA only. NMS may create the MLRA name according to the
Table #2.7.1 Multi-Layer Routing Area(MLRA) Object naming.
2.4.9 getAllCallsAndTopLevelConnections
void multiLayerSubnetwork::MultiLayerSubnetworkMgr_I::getAllCallsAndTopLevelConnections(
in globaldefs::NamingAttributes_T subnetName,
in unsigned long how_many,
out callSNC::CallAndTopLevelConnectionsList_T callAndTopLevelConnectionsList,
out callSNC::CallAndTopLevelConnectionsIterator_I callAndTopLevelConnectionsIt
1) The operation allows retrieve all details of the Calls and associated Top Level Connections in
the scope of a specified MLSN which:
1.1 Represents a top level MLRA. A server (EMS) should only return the Calls and top
level Connections that were established by Control Plane which managed by the
EMS.
1.2 In eNI implementation: represents a routing node (Managed Element). In this case
only Calls and Top Level Connections with HeadEnd that located in the given routing
node(ME) should be retrieved.
Note: The location of Control Plane controller is specified by
LSNExt_AEndCPControllerId additional info attribute of retrieved Call’s .
2) The reply can be an empty list, if there are no Calls were established in the given MLRA
3.1 subnetName -the name the top level MLRA which contains the Calls to be retrieved.
The name should be provided according to the Table #2.7.1 Multi-Layer Routing
Area(MLRA) Object naming
3.2 how_many - maximum number of CallAndTopLevelConnections to report in the first
batch
4.1 callAndTopLevelConnectionsList - first batch of retrieved calls and top level
connections
eNI implementation:
4.1.i. The server(EMS) should specify call’s aEnd and zEnd for each theCall entry
in the callAndTopLevelConnectionsList parameter according to following:
1. The full DN should be specified for call’s aEnd.
2. The proxy DN should be specified for call’s zEnd.
a. ASON OTN: See Table #2.7.4 Proxy ODUk CTP Object
naming
eNI for ASON/WSON

page 41 of 63
b. WSON: See Table #2.7.6 EP of a WSON Call – Object
Naming of Proxy PTP
4.1.ii. The retrieved top-level connection in each topLevelConnectionsList in

callAndTopLevelConnectionsList contains the list of cross-connects that
specifies the ASON or WSON connection route.
The cross-connects are described by a list of SubnetworkConnection_T::
aEnd specify the route of ASON or WSON restorable top-level connection.
the same resources(e.g. TP, tributary slots etc.)
3. Each connection’s aEnd should be specified by proxy DN. See Table
#2.7.4 Proxy ODUk CTP Object naming
4. The SubnetworkConnection_T::zEnd parameter should be ignored.
4.1.iii. In case of WSON Call each retrieved topLevelConnectionsList in
callAndTopLevelConnectionsList òut` parameter may contain WSON non-
restorable top-level connections. The cross-connects are described by a list
of SubnetworkConnection_T::aEnd and SubnetworkConnection_T::zEnd
pairs specify the route of WSON non-restorable top-level connection.
1. The order of aEnd and zEnd pairs in the list is defined according to
the route path: starting from the AEnd to the zEnd of the top-level
connection.
when server (EMS) doesn’t manage specified TP. See Table #2.7.5
and Table #2.7.6
4.2 CallAndTopLevelConnectionsIt - Iterator to retrieve the remaining
CallAndConnections
5.2 The EXCPT_TOO_MANY_OPEN_ITERATORS is raised when maximum number of
iterators that the server can support has been reached
eNI for ASON/WSON

page 42 of 63
2.4.10 getConnectionsAndRouteDetails
void multiLayerSubnetwork::MultiLayerSubnetworkMgr_I::getConnectionsAndRouteDetails(
in string callID,
in globaldefs::NamingAttributes_T mLRAName,
in string sNPOrSNPPID,
in boolean mLSNPPLinkRequested,
in callSNC::RouteType_T routeType,
out callSNC::SNCAndRouteList_T connectionAndRouteList
1) The server (EMS) should return the top level connections supporting the call and their
detailed routes.
1.1 The caller may obtain the different types of routes(See section 2.3.3.4The types of
the top-level connection) filtered appropriately by routeType:
1.1.i. For routeType = “BOTH” - all provisioned, pre-planned and rerouted routes
should be retrieved .
1. All restorable and non-restorable (if exist) top-level connections of the
WSON Call should be retrieved.
1.1.ii. For routeType = “ACTUAL/CURRENT” - The caller may request retrieving
of only actual/current routes
1. Only restorable and non-restorable (if exist) top-level connections of
the WSON Call should be retrieved.
1.1.iii. For routeType = “HOME/INTENDED” - The caller may request retrieving of
only provisioned and pre-planned routes
1. All restorable and non-restorable (if exist) top-level connections of the
WSON Call should be retrieved.
2) If the Call had the SNCP protection the operation should return at least two provisioned top-
level connections. Each of the acquired top-level connection should include cross-connections
that represent either main or protection routes in SNCP.
3.1 callID - the attribute represents the control plane identifier of the Call. See
Call_T::callId
3.2 sNPOrSNPPID – is not implemented in eNI. Should be skipped
3.3 mLSNPPLinkRequested - is not implemented in eNI. Should be skipped
3.4 routeType -indicates whether the response should include provisioned, preplanned,
and actual or all routes. See section 1.1 above.
4) The connectionAndRouteList parameter will be returned as the output parameter:
eNI for ASON/WSON

page 43 of 63
4.1 Each retrieved top level connections supporting the call and their detailed routes
described by callSNC::SNCAndRoute_T structure :
4.1.i. The retrieved ASON or WSON top-level connection contains the list of cross-
connects that specifies the connection route.
aEnd specify the route of ASON or WSON restorable top-level connection
the same resources (e.g. TP, tributary slots etc.)
3. Each connection’s aEnd should be specified by proxy DN. See Table
#2.7.4 Proxy ODUk CTP Object naming
4. The SubnetworkConnection_T::zEnd parameter should be ignored.
aEnd specify the route of WSON non-restorable top-level connections:
5. The order of aEnd and zEnd pairs in the list is defined according to
the route path: starting from the AEnd to the zEnd of the top-level
connection.
when server(EMS) doesn’t manage specified TP. See Table #2.7.5
and Table #2.7.6
4.1.ii. connectionRoutes – should be empty in eNI implementation. The route

details contained in the retrieved top-level connection.
4.1.iii. edgeMLSNPPLinks - should be empty in eNI implementation
4.1.iv. internalMLSNPPLinks - should be empty in eNI implementation
4.1.v. routeType - indicates whether the acquired top-level connections are
provisioned/preplanned(HOME/INTENDED) or
actual/current(ACTUAL/CURRENT).
4.2 In the eNI implementation the detailed routes should be specified by the top-level
connection. Therefore the connectionRoutes parameter of structure should be
empty.
eNI for ASON/WSON

page 44 of 63
2.4.11 Edit and reconnect Call
1) There is no general MTNM operation which allows editing of an existing Call. The editing of
the Call will be provided by the performing following operations: modifyCall,
removeConnections and addConnections. It is responsibility of the caller to perform all
necessary operations required for appropriate call editing.
1.1 In case when the existing top-level connection should be updated or new connection
should be added the caller should perform addConnections operation. Only
new/updated connection routes should be provided as input parameters of the
operation. See 2.4.6
1.1.i. In case when the existing top-level connection should be updated the caller
should provide ID of edited connection obtained from control plane. See
ConnectionId additional info parameter in SNCCreateData_T ,Table #2.3.3.3
Top Level connection additional info attributes
1.1.ii. In case when the editing operation requires update restoration scheme the
top-level connection protection scheme (i.e. LSNExt_ASON_Protection) should
be specified. See 2.4.6-2.2.v.1
1.2 If the deletion of a top-level connection were requested the caller should perform
removeConnections operation. See 2.4.7
1.2.i. As a result of the top-level connection deletion the server (EMS) should
recalculate the ASON Restoration Scheme. The AVC of
LSNExt_ASON_Protection on edited Call should be produced.
1.3 If the configuration of Call parameters should be updated the caller should perform
the modifyCall operation. See 2.4.5
The changes of ASON restoration scheme should be done by MTNM operations that
specified in the table below. See Table #2.4.11
To restoration 1+R 1+1+R 1++
scheme
From restoration
scheme
1+R Call addConnections that: Call addConnections that:
1. Add a new top-level 1. Add a new top-level
connection connection
2. Specifies “1+1+R” 2. Specifies “1++”
protection scheme in new protection scheme in the
top-level connection new top-level connection
eNI for ASON/WSON

page 45 of 63
To restoration 1+R 1+1+R 1++
scheme
From restoration
scheme
1+1+R Call Call addConnections that

removeConnections specifies “1++” protection
that deletes one top- scheme in the dummy top-
level connection 7 level connection .See 2.4.6-
2.2.v.1
1++ Call Call addConnections that

removeConnections specifies “1+1+R”
that deletes one top- protection scheme in the
level connection dummy top-level connection
.See 2.4.6-2.2.v.1
Table #2.4.11 The changes of ASON restoration scheme

1) As a result of performing addConnections and/or removeConnections operation/s the server
(EMS) should recalculate the ASON Restoration Scheme (i.e. LSNExt_ASON_Protection,
Table #2.3.2.4).The AVC of LSNExt_ASON_Protection on edited Call should be produced.
2) The reconnect call is provided by the performing modifyCall and addConnections operations.
It is responsibility of the caller to perform all necessary operations required for appropriate call
reconnect.
2.1 See 1.1 above
2.2 See 1.1.i above
2.3 See 1.3 above
3) The order of performing MTNM operations which implements edit and reconnect Call
functionality is not significant.
7
As a result of deletion a top-level connection the restoration route (if exist) would be deleted
eNI for ASON/WSON

page 46 of 63
2.5 Data Plane Resources
2.5.1 TP layer parameters
1) The following layered parameters should specify the Data Plane resources managed by Control Plane :
AVC (or
SC)
Potentially
Objec notificatio
ParameterName Layers Legal values settable ECI Usage Comment / Example
ts n raised if
from
value
changes?
LSNExt_ControlPlaneMember RS PTP Boolean yes EMS Used, Indicates if the specific layer is part of the control plane.
layers;OTU; LSv10(OTU)
Note :rename current LSNExt_IsControlPlaneMember to
OTS LSv11.2(OTS)
LSNExt_ControlPlaneMember
The following layers are relevant to the following ASON /WSON
types
ASON SDH - RS layers
ASON ODU – OTU
WSON - OTS
LSNExt_ASON_Capability OTU,OTS PTP “Unsupported” (default), yes EMS LSv10, Indicates if the TP potentially support ASON in case of OTU and
“Supported” LSv11.2(OTS) WSON in case of OTS layer.
InterfaceType LR_ PTP, Supported values for LR_ yes EMS, from This parameter shall indicate the type of interface which is
Ethernet, FTP Ethernet are: NMS(for LS v4.15 modeled by this TP.
OTU,OTS OTU) LSv10(OTU), Default value is “unconfigured”.
“UNI” all cards LSv11.2(OTS)
"NNI" used in eNI
"E-NNI" MCS
"I-NNI" all cards
"Unconfigured" not used
in eNI
Supported values for

OTU/OTS are:
“UNI”,"NNI",”NNI-F",
Unconfigured"(default)
LSNExt_DL_DiscoveryMode OTU, PTP “Managed”, “Auto”, yes EMS,NMS LSv10, Indicates the discovery mode of ASON data link
”NA”(default)
LSNExt_DL_PeerCPControllerId OTU,OTS PTP string yes Indicates the IP address of the control plane controller of the
EMS,NMS LSv10, peer port on the ASON/WSON(OTS) data link.
LSv11.2(OTS)
eNI for ASON/WSON

page 47 of 63
AVC (or
SC)
Potentially
Objec notificatio
ts n raised if
from
value
changes?
LSNExt_DL_PeerPortId OTU,OTS PTP string yes Indicates the RDN of the peer TP of the ASON/WSON(OTS)
EMS,NMS LSv10, data link
LSv11.2(OTS)
LSNExt_SourcePathType LR_STS3c_ CTP, M - Main Yes NMS Used, Optional transmission parameter for the NMS to save the path
and_AU4_V PTP(O P - Protection LSv11.2(OSC) type of terminated & mapped VC4. Normally this is 'B'.
C4 , SC) B - Both (This is used when a CTP is T&M at the end of a Link
ODU,OSC U - Undefined Connection without an SNC that can hold the Path Type).
OSC PTP: The path type of the associated WSON data link
LSNExt_DL_AssociatedAEnd_CPI OSC PTP string, NA yes WSON:Indicates the NE control plane IP address of the
P see comment NMS LSv11.2 associated A-EP of the WSON data link
The format of string is following:<IP address>
Note: required for configuration of failure detection via LDI
session of WSON data link
LSNExt_DL_AssociatedAEnd_Por OSC PTP DN, NA yes WSON: Indicates the DN of the associated A-EP of the WSON
tId NMS data link
LSv11.2
LSNExt_DL_AssociatedZEnd_CPI PTP string, NA yes NMS WSON:Indicates the NE control plane IP address of the
P OSC see comment LSv11.2 associated Z-EP of the WSON data link
The format of string is following:<IP address>
LSNExt_DL_AssociatedZEnd_Port PTP DN, NA yes NMS WSON:Indicates the DN of the associated Z-EP of the WSON
Id OSC data link
LSv11.2
LSNExt_DL_AssociatedOSCList OTS PTP List of DNs yes NMS WSON: List of DNs of OSC ports that are associated to the
WSON data link EP.
LSv11.2
Note: required for configuration of failure detection via BFD
LSNExt_DL_OperationalState OTS,OCH PTP “Down”, “Up_Free”, no EMS ASON and WSON:Indicates operational state of WSON data
“Up_Allocated”, “NA”(default) LSv11.2 link.
ASON: Relevant for OCH layer of the OTU PTP
LSNExt_LDL_Member OTS PTP “True", "False", "NA" (default) yes NMS WSON:Indicates that the port belong to Long Data Link(i.e. LDL)
LSv11.2
LSNExt_PeerPortId OTS PTP string. See comments no EMS WSON : indicates the DN of the peer TP predetermined by
LSv11.2 equipment constraints .
eNI for ASON/WSON

page 48 of 63
AVC (or
SC)
Potentially
Objec notificatio
ts n raised if
from
value
changes?
LSNExt_PortType OCH PTP String, see comment no EMS V11 WSON: Specifies the port type of a PTP
LSNExt_ReservationType OCH CTP “Provision”, “Restoration”, yes NMS V11 WSON: Indicates if the specific frequency of the OCH CTP is
”All”, ”NA”(default) reserved for management, control or both planes.
The values are :
“Provision” – used for management plane only
“Restoration” – used for control plane only
“All” – used for both management and control planes( meaning
the frequency is unreserved)
“NA” – not relevant
LSNExt_LinkMetric RS,OTU, PTP list of integers, each up to yes EMS, NMS, LSv6, The link metric which should be used for ASON/WSON path-
9999 OSS LSv10(OTU), finding, and by any other process who wants to use it.
For RS layer only:
th
the lists are in parallel, i.e., the n member of each list belongs to
th
the n LDLP of the PTP.
How LS sets it:
1. LSNExt_LinkMetric will be sent always together with
LSNExt_LDLP_Name in the same setTPData.
2. In the same setTPData command, other LDLP attributes (such as
LSNExt_LDLP_StmLevelList, etc…) will be ignored, since they are
set in a separate designated command.
3. No other attributes (non-LDLP) will be included in this setTPData.
When setting the metric for RS (regular DL), LSNExt_LinkMetric will
be sent using setTPData which does not include LSNExt_LDLP_Name
with it. This will distinguish between DL and LDL.
For OTU layer only:
Only first list entry is used.
LSNExt_LinkCost OTS,OTU PTP integer yes NMS LSv11.2
ASON OTN and WSON: indicates the cost of the data link;used
by ASON/WSON path-finding as an optimization criteria
deprecates LSNExt_LinkMetric since LS v11
LSNExt_LinkLength OTU PTP integer yes NMS LSv11.2
ASON OTN : indicates the length of the data link;used by ASON
path-finding as an optimization criteria.
deprecates LSNExt_LinkMetric since LSv11.2
LSNExt_SRLG_Names OTU,OTS PTP list of strings, yes NMS,EMS LS v10, The SRLG values of an ASON data link connected to the port.
default: empty LSv11.2(OTS)
eNI for ASON/WSON

page 49 of 63
AVC (or
SC)
Potentially
Objec notificatio
ts n raised if
from
value
changes?
LSNEXT_OPT_CHANNEL_OSNR OCH PTP, decimal yes EMS LSv11.2 WSON:Specifies optical signal to noise ratio , units dB/0.1nm
CTP
LSNEXT_OPT_CHANNEL_OSNR OCH PTP, decimal yes EMS LSv11.2 WSON:Specifies minimum OSNR threshold
_MIN CTP
LSNExt_DL_OSNR OTS PTP decimal yes EMS LSv11.2 Indicates optical signal to noise ratio( i.e. OSNR) for WSON data
Link
OTS PTP OSChannel port ID (DN) or No EMS LSv8 Contains OSChannel port ID, which adds/drops the OSC to/from
LSNExt_OSC_PeerID NULL OTS port
Note: WDON uses existed eNI parameters
LSNExt_ConnectivityBlocked VC4 CTP "BLOCKED", yes EMS used
"NOT_BLOCKED", Used for CTPs that exist in the card but are not able to be
connected (typically all the other XCs are fixed XCs).
MPT platform: Used to indicate the blocked CTPs of a CMBR
cards (for VC4 CTPs).
OCH CTP yes EMS used
"BLOCKED", Used for CTPs that exist in the card but are not able to be
"NOT_BLOCKED"; or connected (typically all the other XCs are fixed XCs).
”True”, ”False” MPT platform: Used to indicate the blocked CTPs of a GOADM
(for OCH CTPS). In this case "BLOCKED" and
"NOT_BLOCKED" values are reported.
Apollo platform : Used to indicate the blocked CTPs of a
FOADM(for OCH CTPS). In this case ”True”, ”False” values are
reported.
Table #2.5.1 TP Layer parameters
eNI for ASON/WSON

page 50 of 63
2.5.2 ME additional info
2) The following additional info parameters should specify the Data Plan resources managed by Control Plane :
ManagedElement_T:
No Name Possible Values AVC Comment EMS-LS Version
empty=both
LSNExt_ControlPlaneNeI String No Read Only from EMS - specify the control plane IP
PAddr address in the control plane. ACPs negotiate
through this IP address.
LSNExt_ASTNType “None”(default),”OTN_ASON Yes Specify GMPLS Mode: either WSON or ASON EMS-LS V11
”,”WSON”
LSNExt_MetricType ‘NA’ (Not Applicable), Yes ASON OTN and WSON:Metric type EMS-LS V11
‘HopCount’, ‘Cost’, ‘Length’,
‘OSNR’
LSNExt_ReversionTime {<hours>;< minutes >}, Yes ASON OTN and WSON: Specify the reversion time EMS-LS V11
where hours and minutes
are integers(short) in range:
hours 0-23
minutes 0-59
LSNExt_MaxCost integer Yes ASON OTN and WSON: specifies cost constrains of EMS-LS V11
CP path computation ; the computed path should
has the cost less than provided maximum value.
LSNExt_MaxLength integer Yes ASON OTN and WSON: specifies length constrains EMS-LS V11
of CP path computation ; the computed path
should has the length less than provided maximum
value.
LSNExt_MaxHopCount integer Yes ASON OTN and WSON: specifies hop constrains of EMS-LS V11
CP path computation ; the computed path should
has the number of hops less than provided
maximum value.
Table #2.5.2 ManagedElement_T additional info

Table Note: The LSNExt_ControlPlaneNeIPAddr is existing eNI parameter.
eNI for ASON/WSON

page 51 of 63
2.5.3 SNC additional info – relevant for current protected SNC without ASON/WSON
Name SubnetworkConnection_T Default when not Possible Values AVC Comment EMS-LS version
SNCCreateData_T provided or Data Type LS-OSS information
LSNExt_WTR SubnetworkConnection_T 5 integer in range 0,1 Yes Relevant for protected EMS-LS LSv11.2
SNCCreateData_T to 12 SNCs,
Specifies the time of Wait
to Restore
0 - means :
- unspecified WTR
- not relevant for not
protected SNCs
LSNExt_ReversionMode SubnetworkConnection_T “NA” “Revertive”, YES Relevant for protected EMS-LS LSv11.1
SNCCreateData_T “NonRevertive”, “NA” SNCs, when the reversion
mode is known and can be
set for the specific SNC
(independent of the
general setting for the
NE).
In the LightSoft-to-OSS
direction, can be sent by
LS when known for the
entire SNC, and can be set
by the OSS if LightSoft
supports it.
Table #2.5.3 SNC additional info
eNI for ASON/WSON

page 52 of 63
2.6 Attributes and Life Cycles of Objects and Entities
In the following descriptions, in the EMS-LS interface, the server is the EMS and the caller is LS,
1) The following object lifecycle notifications that are necessary for the caller to maintain
synchronization with server are supported:
1.1 Object Creation(OCN) – Call ,top-level connection
1.2 Object Deletion(ODN)- Call ,top-level connection
1.3 Attribute Value Changed(AVC) – from all Call and top-level connection, for all
attributes (incl. additionalInfo), and for all layered parameters which have "yes" in the
AVC column
1.4 State Change(SC) -eNI implementation: on callState::callSNC::Call_T. The
supported states are specified in the Note to the Table #2.3.2.1 “The fields of the
Call_T”
1.5 Route Change Notification – eNI implementation :is supported for WSON only
2) ObjectType and objectTypeQualifier notification’s attributes
The type of object reporting a notification is specified by objectType and objectTypeQualifier
attributes. See table below:
Object type
Notification attribute SubnetworkConnection_T (top-
Call_T
level connection)
objectType OT_AID OT_AID
objectTypeQualifier OT_CALL OT_CONNECTION
Table #2.6.2 Definition of type of object reporting a notification.
eNI for ASON/WSON

page 53 of 63
3) MTNM attributes sending AVC/SC Notifications
Attributes sending
No Object type Attributes sending Attribute Value
State Change
(objectTypeQualifier) Change Notifications (AVC)
Notifications (SC)
sncState(not supported
SubnetworkConnection_ aEnd ,
in eNI)
T (OT_CONNECTION)
zEnd(only for WSON Top Level connections)
additionalInfo .See Table #2.3.3.3 Top Level

connection additional info attributes
Not supported in eNI:

userLabel,
nativeEMSName,
owner ,
direction,
staticProtectionLevel sncType
zEnd
Call_T(OT_CALL) userLabel, callState
callDiversity (eNI implementation AVC only

for linkDiversityLevelOfEffort:: Diversity)
callAdditionalInfo - See table #2.3.2.4 “The
Call additional info attributes”
AVC not supported in eNI for following :

owner ,
nativeEMSName,
networkAccessDomain,
diversitySynthesis,
linkDiversityViolations,
nodeDiversityViolations,
linkPartialDiversityList,
nodePartialDiversityList
Table #2.6.3 Definition of type of object reporting a notification.
eNI for ASON/WSON

page 54 of 63
4) The following object lifecycle notifications should be sent as a result of :
No Triggers Notification object
Call Connection
Establish call (via establishCall ) OCN ASON OTN: OCN

Note: It is management request WSON: OCN for restorable and
non-restorable (if exist)
connections. See Table
#2.3.3.4-2
First reroute in the event of a traffic AVC ASON OTN: OCN

failure
WSON :OCN for restorable
connections .The AVC for non-
restorable (if exist). See Table
#2.3.3.4-2
Following reroute as a result of a - ASON OTN: ODN,OCN

traffic failure or maintenance
operation WSON:AVC relevant for
restorable connections. The
AVC for non-restorable (if exist).
Revert to provisioned traffic AVC ODN

WSON: ODN relevant only for
restorable connections. The
AVC for non-restorable (if exist)
Delete(release) call ( via ODN ASON OTN: ODN

releaseCall )
WSON: ODN relevant for
restorable and non-restorable (if
exist) connections. See Table
#2.3.3.4-2
Modify call parameters(via AVC -

modifyCall )
Edit provisioned route (via AVC ASON OTN: ODN and OCN
addConnections ).For instance:
WSON: ODN and OCN relevant
- ASON OTN: change route for restorable and non-
of the provisioned top-level restorable (if exist) connections.
connection See Table #2.3.3.4-2
- WSON: change route and
frequency of the
provisioned top-level
connections
Table #2.6.4 Mapping of object lifecycle notifications
eNI for ASON/WSON

page 55 of 63
2.7 Restoration and/or reversion of ASON OTN/WSON top-level
connection.
1) The server (EMS) should send NT_ROUTE_CHANGE notification when a restoration or
reversion was started for ASON OTN/WSON top-level connection.
1.1 The following parameters of NT_ROUTE_CHANGE event should be specified by
EMS according to table below:
Name Type Description
"objectName" globaldefs::NamingAttributes_T Identifies the SNC object reporting a route

change.
In the ECI implementation, can also identify an
FDFr object.
ASON OTN and WSON: Identifies CTP -
ingress A-EP of the HeadEnd’s cross-connect
“objectType" notifications::ObjectType_T Identifies the SNC object reporting a route

change.
In the ECI implementation, can also contain the
value OT_AID, and the Object Type Qualifier
field will contain
OT_FLOW_DOMAIN_FRAGMENT.
ASON OTN and WSON: should identify
OT_AID
"objectTypeQualifier" string When objectType=OT_AID and this field

contains OT_FLOW_DOMAIN_FRAGMENT,
indicates that the route change is being reported
for an FDFr.
The use of this field in this notification is
proprietary to ECI.
ASON OTN and WSON: should identify
OT_CONNECTION_TERMINATION_POINT
"routeChangeEvent" subnetworkConnection:: This identifies which state the notification is

RerouteChangeEvent_T emitted against.
ASON OTN and WSON:
- "RerouteStarted“ value should be
specifyed in case of restoration
- "RouteRemoved“ value should be
specifyed in case of reversion
"route" subnetworkConnection::Route_T This identifies the new route that is chosen, if

any.
In the ECI implementation, this field is left

empty. If the OSS wants to know the new
route, it should call getRoute (for an SNC) or
getFDFrRoute (for an FDFr).
ASON OTN and WSON: should be empty
Table #2.7.4 Mapping of NT_ROUTE_CHANGE notification
eNI for ASON/WSON

page 56 of 63
1.2 All other parameters of NT_ROUTE_CHANGE should be filled by server(EMS)
according to definition of NT_ROUTE_CHANGE notification, See [10]
26E_notificationServiceUsage_with_ECI_extensions
2.8 Naming of Objects

2.8.1 MLRA Object naming
ObjectName – ObjectName - Comment nativeEMSName Object in

Name Value example of the given
object in the level as it
given level appears in
the eNM
Alarm Log
EMS ECI/ EMS_STMS_ - the name of - -
EMS_STMS_{u EMS that manage control plan
} specified by HeadEnd.
u – integer which makes the

LSN/EMS_STMS EMS name
unique in the NMS Naming
Service.
MultiLayerSubn TLRA The top level Routing Area is TLRA -
etwork not a
named entity in the ASON
Control Plane
as a consequence the
EMS/NMS must fabricate
a name
Table #2.7.1 Multi-Layer Routing Area(MLRA) Object naming
2.8.2 Call - Object naming
ObjectName ObjectName - Comment nativeEMSN Object in

– Name Value ame the given
example of level as it
object in the appears in
given level the eNM
Alarm Log
EMS ECI/EMS_STMS_ EMS_STMS_ - the name of EMS "Saturn"
{u} that manages control plan specified
by HeadEnd.
u – integer which makes the

LSN/EMS_STMS EMS name unique
in the NMS Naming Service.
Call <MLRA={n}>/<Ca Specified by two-tuple and

llId={o}> includes:<MLRA={n}> - defines
eNI for ASON/WSON

page 57 of 63
the Routing Node (subnetwork of
Managed Element) that manages
HeadEnd
<CallId={o}> - an unique identifier
of the Call provided by control plane
Table #2.7.2 Call Object naming
2.8.3 Top Level Connection – Object Naming
ObjectName – Name ObjectName - Value Comment nativeE Object in

MSNam the given
e level as it
example appears
of object in the
in the eNM
given Alarm
level Log
EMS ECI/EMS_STMS_{u} EMS_STMS_ - the name "Saturn"
of EMS that manage
control plan specified by
HeadEnd.
u – integer which makes

the LSN/EMS_STMS
EMS name unique in the
NMS Naming Service.
MLRA {n} {n} - unique identifier in

scope of EMS ; defines
the Routing Node(
subnetwork of ME) that
manages HeadEnd
SubnetworkConnection <CallId={n}>/<Id={o Specified by two-tuple

}> and includes:
<CallId={n}> - an unique
identifier of the Call
supported by the
connection; CallId is
provided by control plane
<Id={o}>- - unique
identifier specified by
`ConnectionId`
Table #2.7.3 Top Level Connection Object naming
2.8.4 Proxy ODUk CTP – Object Naming

Note: The proxy DN is used when server (EMS) doesn’t manage specified ODUk TP and
therefore the data regarding to “EMS” and “ManagedElement” is not applicable
eNI for ASON/WSON

page 58 of 63
ObjectName – ObjectName - Value Comment
Name
EMS NA EMS is not applicable
ManagedElement NA ME is not applicable
PTP The same value as for Represents the unique position of the PTP
regular ODUk CTP with respect to the managed element
CTP The same value as for Represents the unique location of
regular ODUk CTP ODUk CTP and its hierarchy:
/ODUk=1/ODUl=[1..i]/ODUm=[1..j]
Table #2.7.4 Proxy ODUk CTP Object naming
2.8.5 Proxy OCH CTP – Object Naming

Name
PTP The same value as for Represents the unique position of the PTP
regular OCH CTP with respect to the managed element
CTP The same value as for Represents OCH CTP with appropriate
regular OCH CTP frequency
Tunable OCH CTP :/frequency=tunable-
number={i}
Non-tunable OCH CTP: /frequency=nnn.nn
Table #2.7.5 Proxy OCH CTP Object naming
2.8.6 Proxy PTP - WSON Call EP – Object Naming

Name
PTP The same value as for
Represents the unique position of the PTP
regular OTUk/OTS
with respect to the managed element
PTP
Table #2.7.6 Proxy PTP - WSON Call EP – Object Naming
2.9 PM
2.9.1 PM
TBD
2.10 Alarms
2.10 TBD
2.11 Maintenance
eNI supports ASON maintenance operations via existing methods of lsn::
LSNMultiLayerSubnetworkMgr_I manager. All described below maintenance operations are already
implemented for ASON SDH. The document specifies only differences which are required in order to
support maintenance operation for ASON ODU.
eNI for ASON/WSON

page 59 of 63
2.11 The operation revertControlPlaneTrailPath performs Revert operation (Force or
Manual) on the Main and Protection paths
void revertControlPlaneTrailPath ( in LSNControlPlaneRoutingActionData_T trail,

out LSNControlPlaneRoutingActionDataResult_T resultInfo
2.11.1. The caller(NMS) should specify the following input parameters:

i. LSNControlPlaneTrailKeyParam_T::meDN – the name of the call to be
reverted. The format of the call name is defined according to Table #2.7.2
Call Object naming
ii. LSNControlPlaneTrailKeyParam_T::nmsTrailId, asonTrailBuffer, xcSetId –
empty, should be ignored
2.11.2. The LSNControlPlaneRoutingActionDataResult_T:: resultInfo is the
output parameter which specify the result status of the performed operation
2.12 The operation forceRerouteControlPlaneTrail performs reroute operation (Force or

Manual) on the Main and Protection paths
void forceRerouteControlPlaneTrail (
in LSNControlPlaneRoutingActionData_T trail, out
LSNControlPlaneRoutingActionDataResult_T resultInfo)
raises (globaldefs::ProcessingFailureException)

i. LSNControlPlaneTrailKeyParam_T::meDN – the name of the call to be
rerouted. The format of the call name is defined according to Table #2.7.2
Call Object naming
2.12.3. The EXCPT_UNABLE_TO_COMPLY exception is raised if Force reroute

operation were requested (e.g. LSNControlPlaneRoutingActionData_T::force is
true).
2.13 The operation retreiveControlPlaneData retrieve the status of Inhibit/Allow of the

Reroute and Revert operations
void retreiveControlPlaneData (
in LSNControlPlaneTrailKeyParam_T trail,
out LSNControlPlaneMaitenanceData_T maitenanceData
,out LSNControlPlaneRoutingActionDataResult_T resultInfo)
raises (globaldefs::ProcessingFailureException)

i. LSNControlPlaneTrailKeyParam_T:: meDN – the name of the call whose
Inhibit/Allow status to be retrieved. The format of the call name is defined
according to Table #2.7.2 Call Object naming
eNI for ASON/WSON

page 60 of 63
2.14 The operation performControlPlaneMO Inhibit or Allow performing the Reroute and
Revert operations on the Main and Protection paths
void performControlPlaneMO (
in LSNControlPlaneRoutingActionData_T trail,
in LSNControlPlaneMOCommand_T command,
out LSNControlPlaneRoutingActionDataResult_T
resultInfo) raises (globaldefs::ProcessingFailureException)

i. LSNControlPlaneTrailKeyParam_T::meDN – the name of the call for which
Inhibit or Allow of the Reroute/Revert operations to be performed. The
format of the call name is defined according to Table #2.7.2 Call Object
naming
2.12 GCT
NA
2.13 Limitation
1) Only bidirectional P2P Calls are supported. Therefore the 1++ protection scheme should be
implemented as two calls with appropriate association which prevents using resources of main
and protected components of provisioned NMS trail
2) The eNI does not support the following ASON features:

2.1 traffic localization (administrative groups)
2.2 Extra Traffic (pre-emptible) trails
2.3 trail priority
2.4 configuration of parameters of GMPLS protocols
2.5 association for exclusion of top level connection
2.6 multiple contiguous ASON domains
3) The Fast Recovery Upload for top level MLRA is not supported. Only full upload is supported for
getAllCallsAndTopLevelConnections which was requested for top-level MLRA.
2.14 Fast Recovery Upload

1) Fast Recovery Upload Mechanism should be supported for new object types: top level connection
(OT_CONNECTION) and call (OT_CALL). See LSN_Fast_Recovery.doc [9]
2.15 Open issue

NA
eNI for ASON/WSON

page 61 of 63
3 Appendix A: ENI ASON(WSON) ARCITECTURE
Note: The top level Multi-Layer Routing Area(MLRA) include all EMS domains. All parts of MLRA are
covered by EMS domains
Pic #1 eNI architecture of ASON Management
eNI for ASON/WSON

page 62 of 63
Pic #2 eNI model of a Call
eNI for ASON/WSON

page 63 of 63

LightSOFT NBI V14.0 Explanatory Documents

Uploaded by

Copyright:

Available Formats

LightSOFT NBI V14.0 Explanatory Documents

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 Explanatory Documents

Uploaded by

Copyright:

Available Formats

LightSOFT NBI

ECI's NPT-1200, NPT-1020, and NPT-1010 are CE2.0 certified.

ECI's NPT-1600 complies with the MEF9 and MEF14 standards.

ECI's management applications run on VMWare virtualization hypervisors.

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

ABO - Alarm Bearing Object

The document contents is consists of the following.

3. SDH Object Mapping

3.1 SDH Adaptations

MTNM ITU / Lightscape EMS

E i=1,2,3 P12 for framed E1

EMS Implementation Issues:

Alarm Reporting. A single value is sufficient. It will be "on" whenever at

MTNM LSN EMS

Optical Section VC4 TTP

Includes ports of ATRE, TRSE, and SIO1_8E cards

3.3 Optical SDH PTP

Includes ports of (non-colored) TRSO, ATRO, ASF, SIO1_16, SIO4_4, SIO16_1,

TUG3 LR_STS48c_and_VC4_16c [n/48]

Terminated and Mapped

LR_VT1_5_and_TU11_VC11 LR_VT2_and_TU12_VC12 LR_VT6_and_TU2_VC2

EMS Implementation Issue:

NMS Implementation Issues:

5. Managed Element SDH Extension Attributes

6. Protection Group Attributes

• LSNExt_MSPRingId - decimal format. Uniquely identifies the MSPRing in the

H. Termination Point Attributes

See the Appendix IV for the complete set of rules.

AU4 CTP TUx CTP

HO SDH/SONET Path Termination

LSNExt_TerminationMode tpMappingMode (MTNM standard attribute)

DCC Termination (LSN Proprietary Support of DCC CTPs)

5. SDH Transmission Parameters

All AVCs emit AVC unless noted otherwise.

"Physical Optical" & "Physical Electrical" Layers

The following is an example for a PTP Location:

• LSNExt_EquipmentProtected – Enabled / Disabled

• ServiceState (See Appednix III)

• LSNExt_DCCMode - possible values are "TERMINATED_IN_COM" /

• TrailTraceExpectedRx - read/write (by NMS) 16 character string.

• TrailTraceActualRx - read only

• TrailTraceMonitor – read/write {on ,off}

CTP 1 - 34M/VC3 CTP in PDH tributary CTP6 - AU4_VC4 CTP

TU3_VC3 Subnetwork 2 Subnetwork 3

MTNM V2 provides a limited scope of fault management configuration. Alarm

Transmission Object Alarm Reporting

TP Transmission Parameter AlarmReporting - values possible:

• "On" when the master mask is off / MON.

• "Off" when the master mask of the object is switched on / "NMON" /

Equipment Object Alarm Reporting

Equipment_T::alarmReportingIndicator - values possible {true, false}

The state can take on the following 3 values:

Faulty or non-actual/installed equipment may cause the equipment and/or

Provided when there is no sufficient information to provide the exact service

The ITU-MTNM mapping is defined in MTNM as follows:

ITU ITU MTNM Service State

locked or Port OUT_OF_SERVICE_BY_MAINTENANCE

Whenever the operational state is disabled the Service State is

MSB LSB Hex code Interpretation MTNM / Decimal Code

G.707 Notes on the above table: