LightSoft NMS General Description PDF

1Net
End to End
Management Suite

General Description
December 2010
432006-2006-023-A00

1Net End to End Management Suite General Description

Catalog No: X38458
December 2010
1st Edition

Copyright by ECI Telecom, 2002-2010. All rights reserved worldwide.
This is a legal agreement between you, the end user, and ECI Telecom Ltd. (ECI Telecom). 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.
The information contained in the documentation and/or disk is proprietary and is subject to all relevant copyright,
patent, and other laws protecting intellectual property, as well as any specific agreement protecting ECI Telecom's
rights in the aforesaid information. Neither this document nor the information contained in the documentation and/or
disk may be published, reproduced, or disclosed to third parties, in whole or in part, without the express prior
written permission of ECI Telecom. In addition, any use of this document, the documentation and/or the disk, or the
information contained therein for any purposes other than those for which it was disclosed, is strictly forbidden.
ECI Telecom reserves the right, without prior notice or liability, to make changes in equipment design or
specifications. Information supplied by ECI Telecom is believed to be accurate and reliable. However, no
responsibility whatsoever is assumed by ECI Telecom for the use thereof, nor for the rights of third parties, which
may be affected in any way by the use and/or dissemination thereof.
Any representation(s) in the documentation and/or disk concerning performance of ECI Telecom product(s) are for
informational purposes only and are not warranties of product performance or otherwise, either express or implied.
ECI Telecom's standard limited warranty, stated in its sales contract or order confirmation form, is the only warranty
offered by ECI Telecom.
The documentation and/or disk is provided AS IS and may contain flaws, omissions, or typesetting errors. No
warranty is granted nor liability assumed in relation thereto, unless specifically undertaken in ECI Telecom's sales
contract or order confirmation. Information contained in the documentation and in the disk is periodically updated,
and changes will be incorporated in subsequent editions. If you have encountered an error, please notify ECI
Telecom. All specifications are subject to change without prior notice.
The documentation and/or disk and all information contained therein is owned by ECI Telecom 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 the documentation and disk, 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 Telecom.
All trademarks mentioned herein are the property of their respective holders.
ECI Telecom 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 this documentation and/or disk, the information contained
therein, its use, or otherwise. 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 the documentation and/or disk and/or the information 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 and that such instructions were understood by them.
It is hereby clarified that ECI Telecom 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 failed to fulfill
in whole or in part the "Before You Start/Safety Guidelines" instructions.

432006-2006-023-A00 ECI Telecom Ltd. Proprietary i

Contents
Introduction ............................................................................ 1-1
Network Management in a Multitechnology Environment ................................ 1-1
Managing a Moving Target with LightSoft ....................................................... 1-3
Layered Management Concept ....................................................................... 1-5
LightSoft's Clear Advantages ........................................................................ 1-10
Intelligent Management for Intelligent Networks ............................................ 1-13
Topology Management .......................................................... 2-1
Overview ........................................................................................................ 2-1
LightSoft Main Window ................................................................................... 2-3
Multilayer Topology Views .............................................................................. 2-6
Network Elements, Logical Elements, and Managed Elements ...................... 2-8
Functional Topology Maps .............................................................................. 2-9
Tunnel and Service Management ................................................................. 2-14
GCT to EMS ................................................................................................. 2-15
Optical Topology Management ..................................................................... 2-16
NE Configuration .................................................................... 3-1
Overview ........................................................................................................ 3-1
Creating NEs and PEs .................................................................................... 3-2
NE and Card Configuration ............................................................................. 3-8
NE Timing and Synchronization .................................................................... 3-13
Automatic Discovery Functions ..................................................................... 3-16
Configuring Gateway Protection ................................................................... 3-16
Downloading/Uploading NE Software ........................................................... 3-17
Unmanaged Elements .................................................................................. 3-18
DCC Cross Connections ............................................................................... 3-20
OSPF ........................................................................................................... 3-21
IS-IS ............................................................................................................. 3-22
BFD Protocol Support in STMS .................................................................... 3-22
Fault Management .................................................................. 4-1
Overview ........................................................................................................ 4-1
Active Alarm Notification ................................................................................. 4-2
Alarm and Event Filters .................................................................................. 4-7
Bidirectional Drill-Down ................................................................................... 4-9
CFM Alarms ................................................................................................. 4-10
Alarm Correlation .......................................................................................... 4-11
Alarm and Event Logs .................................................................................. 4-13
Exporting and Forwarding Alarms ................................................................. 4-14
Suggested Corrective Actions ....................................................................... 4-17
Alarm Management at the EMS Level .......................................................... 4-17
Contents 1Net End to End Management Suite
Fehler! Verwenden Sie die Registerkarte
'Start', um Subtitle dem Text
zuzuweisen, der hier angezeigt werden
soll.

ii ECI Telecom Ltd. Proprietary 432006-2006-023-A00

Trail, Tunnel, and Service Provisioning and
Management ........................................................................... 5-1
Overview ........................................................................................................ 5-1
SDH/SONET Trails ......................................................................................... 5-2
ASON Network Management ........................................................................ 5-10
DWDM Trails ................................................................................................ 5-16
Ethernet Services ......................................................................................... 5-25
MPLS Tunnels over MoT or MoE .................................................................. 5-45
NMS/EMS Synchronization........................................................................... 5-53
Importing Traffic Configuration Files ............................................................. 5-54
Inventory and Accounting ..................................................... 6-1
Overview ........................................................................................................ 6-1
Inventory Trees and Windows ........................................................................ 6-2
Optical Availability Tables ............................................................................... 6-2
MPLS Link Availability .................................................................................... 6-4
Inventory Reports ........................................................................................... 6-6
Printing and Exporting to CSV ........................................................................ 6-7
Inventory Management at the EMS Level ....................................................... 6-7
Performance Monitoring ........................................................ 7-1
Overview ........................................................................................................ 7-1
Current Performance Monitoring ..................................................................... 7-2
Historical Performance Monitoring .................................................................. 7-3
Performance Monitoring at the EMS Level ...................................................... 7-6
Maintenance ........................................................................... 8-1
Overview ........................................................................................................ 8-1
Trail Maintenance ........................................................................................... 8-2
CFM Maintenance for Ethernet Services ........................................................ 8-3
Protection Switching ....................................................................................... 8-5
Maintenance at the EMS Level via GCT ......................................................... 8-6
Embedded Software Management .................................................................. 8-8
User Management and System Security ............................... 9-1
Overview ........................................................................................................ 9-1
User Security .................................................................................................. 9-2
Central User Administration ............................................................................ 9-6
Customer Network Management .................................................................... 9-7
System Security .............................................................................................. 9-9
High Availability Clustering Solution .............................................................. 9-12
Geographic Redundancy for Disaster Recovery Plans ................................. 9-12
Client/Server Architecture ............................................................................. 9-15
1Net End to End Management Suite
soll.
Contents

432006-2006-023-A00 ECI Telecom Ltd. Proprietary iii

Secure UNIX Environment ............................................................................ 9-16
Management Interfaces ........................................................ 10-1
Overview ...................................................................................................... 10-1
MTNM-Compliant CORBA Interfaces ........................................................... 10-2
MTOSI Northbound Interface ........................................................................ 10-3
SNMP Gateway ............................................................................................ 10-4
SQL Database Access .................................................................................. 10-5
XML Interfaces ............................................................................................. 10-6
Alarm Interfaces ........................................................................................... 10-6
Interfaces and Management Transparency at the EMS Level ....................... 10-6
Java RMI ...................................................................................................... 10-7
Element Management Systems ........................................... 11-1
Overview ...................................................................................................... 11-1
EMS-XDM .................................................................................................... 11-2
STMS ........................................................................................................... 11-4
EMS-BGF ..................................................................................................... 11-9
EMS-ATS ................................................................................................... 11-12
Generic EMS .............................................................................................. 11-16
Local Craft Terminals ........................................................... 12-1
Overview ...................................................................................................... 12-1
LCT-XDM ..................................................................................................... 12-2
LCT-BGF ...................................................................................................... 12-3
LCT-ATS ...................................................................................................... 12-4
Reference Documents ............................................................ A-1
Glossary .................................................................................. B-1
Index ......................................................................................... I-1

Contents 1Net End to End Management Suite
soll.

iv ECI Telecom Ltd. Proprietary 432006-2006-023-A00

432006-2006-023-A00 ECI Telecom Ltd. Proprietary v

List of Figures
Figure 1-1: Multiple technologies in a typical SP network ............................................. 1-2
Figure 1-2: Layered management approach .................................................................. 1-4
Figure 1-3: ECI Telecom's layered architecture management concept ......................... 1-5
Figure 1-4: One management system ........................................................................... 1-6
Figure 1-5: Carrier class Ethernet requirements .......................................................... 1-11
Figure 1-6: Managing MP2MP MPLS-based Ethernet services through LightSoft...... 1-12
Figure 1-7: BroadGate product portfolio ...................................................................... 1-14
Figure 1-8: BroadGate family solutions ........................................................................ 1-15
Figure 1-9: Carrier Ethernet 9000 family ...................................................................... 1-16
Figure 1-10: Converged metro Ethernet transport network ......................................... 1-17
Figure 1-11: XDM integrated multiservice/multitechnology network solution .............. 1-19
Figure 1-12: XDM products portfolio ............................................................................ 1-20
Figure 2-1: LightSoft main window ................................................................................. 2-3
Figure 2-2: Link List table ............................................................................................... 2-4
Figure 2-3: Enhanced zoom capabilities ........................................................................ 2-6
Figure 2-4: MPLS layer .................................................................................................. 2-7
Figure 2-5: Optical layer ................................................................................................. 2-8
Figure 2-6: Availability Map window ............................................................................. 2-10
Figure 2-7: Timing Map window ................................................................................... 2-11
Figure 2-8: RSTP map view ......................................................................................... 2-12
Figure 2-9: ERP map view ........................................................................................... 2-13
Figure 2-10: Geographical map ................................................................................... 2-14
Figure 2-11: GCT example (LightSoft to EMS-XDM) ................................................... 2-15
Figure 2-12: APC chain model ..................................................................................... 2-17
Figure 2-13: FuN topology map ................................................................................... 2-18
Figure 2-14: PELES chain model ................................................................................. 2-21
Figure 2-15: PELES for mesh topology ....................................................................... 2-22
Figure 3-1: Automatic PE insertion on MPLS network ................................................... 3-3
Figure 3-2: Move NE window ......................................................................................... 3-4
Figure 3-3: Adding new route for XDM window ............................................................. 3-5
Figure 3-4: Chassis view for SR9705 ............................................................................ 3-9
Figure 3-5: EMS-BGF slot assignment ........................................................................ 3-10
Figure 3-6: NE attribute configuration .......................................................................... 3-11
Figure 3-7: EMS-BGF internal attributes configuration ................................................ 3-12
Figure 3-8: EMS-BGF synchronous timing configuration ............................................ 3-13
Figure 3-9: XDM Timing Configuration window ........................................................... 3-14
List of Figures 1Net End to End Management Suite
soll.

vi ECI Telecom Ltd. Proprietary 432006-2006-023-A00

Figure 3-10: Timing Map window ................................................................................. 3-15
Figure 3-11: STMS software code report ..................................................................... 3-17
Figure 3-12: STMS software audit ............................................................................... 3-17
Figure 3-13: UME Image window ................................................................................. 3-19
Figure 3-14: DCC configuration ................................................................................... 3-20
Figure 3-15: OSPF configuration ................................................................................. 3-21
Figure 3-16: BFD configuration .................................................................................... 3-23
Figure 4-1: Current Alarms window ............................................................................... 4-2
Figure 4-2: Defining Alarm Severity profiles .................................................................. 4-3
Figure 4-3: EMS-BGF alarm filtering options ................................................................. 4-4
Figure 4-4: Alarm counter bar ........................................................................................ 4-4
Figure 4-5: Alarm Indicator window ............................................................................... 4-5
Figure 4-6: Customizable alarm colors .......................................................................... 4-6
Figure 4-7: Alarms window with user note ..................................................................... 4-7
Figure 4-8: Filter Selection dropdown list ....................................................................... 4-8
Figure 4-9: Filter criteria in Filter panel .......................................................................... 4-8
Figure 4-10: Drilling down from alarms to services ........................................................ 4-9
Figure 4-11: Drilling down from services to alarms ........................................................ 4-9
Figure 4-12: LightSoft drilldown to STMS alarms ........................................................ 4-10
Figure 4-13: Connectivity loss alarm list ...................................................................... 4-10
Figure 4-14: Reducing the number of alarms displayed by using Alarm
Correlation .................................................................................................................... 4-12
Figure 4-15: Event Log History window ....................................................................... 4-13
Figure 4-16: Event Log Configuration window ............................................................. 4-14
Figure 4-17: Alarm notification options ........................................................................ 4-14
Figure 4-18: SMS alarm message filter ....................................................................... 4-16
Figure 4-19: Suggested Corrective Actions window .................................................... 4-17
Figure 4-20: EMS-BGF current alarms window ........................................................... 4-18
Figure 5-1: Point-and-click trail provisioning .................................................................. 5-3
Figure 5-2: Fine-tuning Pathfinder criteria ..................................................................... 5-4
Figure 5-3: Single path SRLG minimization ................................................................... 5-5
Figure 5-4: ME selected at trail splitting point ................................................................ 5-6
Figure 5-5: Trail List window .......................................................................................... 5-8
Figure 5-6: Trails pane showing Alarm State indication column (far right) .................... 5-8
Figure 5-7: Resource Tree pane showing diverse routing ............................................. 5-9
Figure 5-8: Create Filter window .................................................................................... 5-9
Figure 5-9: Show ASON Domain ................................................................................. 5-10
soll.
List of Figures

432006-2006-023-A00 ECI Telecom Ltd. Proprietary vii

Figure 5-10: Blend of protection mechanisms ............................................................. 5-13
Figure 5-11: Physical layer view .................................................................................. 5-15
Figure 5-12: SDH/SONET layer view ........................................................................... 5-16
Figure 5-13: Main and protection trails highlighted ...................................................... 5-18
Figure 5-14: Frequency availability table ..................................................................... 5-18
Figure 5-15: Availability map: after additional trails added .......................................... 5-19
Figure 5-16: DNI protection example ........................................................................... 5-20
Figure 5-17: DRI classic protection model ................................................................... 5-21
Figure 5-18: DRI enhanced protection model .............................................................. 5-22
Figure 5-19: Multiroute OCH with 16 routes each in both main and protection
paths ............................................................................................................................. 5-23
Figure 5-20: Combining multiroute OCH and DRI ....................................................... 5-24
Figure 5-21: User Preferences - Service Management window .................................. 5-27
Figure 5-22: Create Service window ............................................................................ 5-27
Figure 5-23: Endpoints tab ........................................................................................... 5-28
Figure 5-24: VPLS network configuration .................................................................... 5-29
Figure 5-25: Typical H-VPLS topology ......................................................................... 5-29
Figure 5-26: H-VPLS domain example ........................................................................ 5-30
Figure 5-27: ETH Service List window ......................................................................... 5-31
Figure 5-28: CFM configuration ................................................................................... 5-32
Figure 5-29: CFM tool button in E-LAN properties window ......................................... 5-33
Figure 5-30: Dual Homing for access network or internetwork connections ............... 5-34
Figure 5-31: Two methods for closing an RSTP ring ................................................... 5-35
Figure 5-32: Ethernet ring protection ........................................................................... 5-36
Figure 5-33: Layer 2 VPN provisioning ........................................................................ 5-38
Figure 5-34: STMS: E-Line operational status view .................................................... 5-39
Figure 5-35: E-LAN operational status view in STMS ................................................. 5-40
Figure 5-36: E-LAN Split Horizon Group creation in STMS ......................................... 5-41
Figure 5-37: E-LAN peer properties in STMS .............................................................. 5-42
Figure 5-38: Conceptual overview of QoS ................................................................... 5-43
Figure 5-39: Configuring QoS per device .................................................................... 5-44
Figure 5-40: Applying QoS template to multiple NEs .................................................. 5-44
Figure 5-41: QoS service definition creation ................................................................ 5-45
Figure 5-42: E-LSP ...................................................................................................... 5-46
Figure 5-43: Bypass tunnel creation ............................................................................ 5-47
Figure 5-44: Assigning service endpoints to an MPLS-TP tunnel ............................... 5-50
Figure 5-45: Creating dynamic RSVP LSPs ................................................................ 5-51
Figure 5-46: Load sharing across unequal paths ........................................................ 5-52
soll.

viii ECI Telecom Ltd. Proprietary 432006-2006-023-A00

Figure 5-47: Trail Consistency Indicator window ......................................................... 5-54
Figure 6-1: Topology Tree .............................................................................................. 6-2
Figure 6-2: Single availability tables for 32-channel OMS trail ...................................... 6-3
Figure 6-3: Optical availability table - sublambda view .................................................. 6-4
Figure 6-4: Availability for Link window based on CAC ................................................. 6-5
Figure 6-5: Availability Map window - ETH/MPLS ......................................................... 6-6
Figure 6-6: Viewing NE inventory through the EMS-XDM ............................................. 6-7
Figure 7-1: Trail Performance Monitoring window ......................................................... 7-2
Figure 7-2: MPPM tabular report ................................................................................... 7-4
Figure 7-3: MPPM report for MoT trail ........................................................................... 7-4
Figure 7-4: MPPM wizard ............................................................................................... 7-5
Figure 7-5: EMS-XDM Current Performance window .................................................... 7-7
Figure 7-6: XDM Performance History window .............................................................. 7-8
Figure 7-7: EMS-XDM PM Setup window ...................................................................... 7-9
Figure 7-8: EMS-XDM Thresholds Profile window....................................................... 7-10
Figure 7-9: XDM Optical PM Current/History window .................................................. 7-11
Figure 7-10: STMS Performance Output counter ........................................................ 7-13
Figure 7-11: Filtering PM data in the EMS-BGF .......................................................... 7-14
Figure 7-12: Setting PM thresholds in the EMS-BGF .................................................. 7-15
Figure 8-1: Maintenance Operations window ................................................................ 8-2
Figure 8-2: Requesting CFM for a specific service ........................................................ 8-3
Figure 8-3: CFM loopback request ................................................................................ 8-4
Figure 8-4: Path Protection Switch window ................................................................... 8-5
Figure 8-5: XDM Optical Parameters window ................................................................ 8-6
Figure 8-6: CFM configuration ....................................................................................... 8-7
Figure 8-7: Embedded version management................................................................. 8-8
Figure 8-8: Managing two different versions of the embedded software ....................... 8-9
Figure 9-1: Resource Domain Partitioning ..................................................................... 9-3
Figure 9-2: Security Configuration window .................................................................... 9-4
Figure 9-3: Add Resource Domain window ................................................................... 9-5
Figure 9-4: Typical CNM configuration .......................................................................... 9-8
Figure 9-5: Security Configuration window (Preferences tab) ..................................... 9-10
Figure 9-6: Activity Log window ................................................................................... 9-11
Figure 9-7: System redundancy ................................................................................... 9-14
Figure 9-8: RDR Shadow backups .............................................................................. 9-14
Figure 10-1: SNMP GW included in network configuration ......................................... 10-5
Figure 11-1: EMS: three network perspectives ............................................................ 11-2
soll.
List of Figures

432006-2006-023-A00 ECI Telecom Ltd. Proprietary ix

Figure 11-2: Layered management system ................................................................. 11-5
Figure 11-3: STMS GUI features ................................................................................. 11-6
Figure 11-4: STMS typical use: viewing operational status per service ...................... 11-7
Figure 11-5: Platform view as displayed in the EMS-BGF ........................................... 11-9
Figure 11-6: NE Simulator .......................................................................................... 11-10
Figure 11-7: FE utilities on the EMS-BGF .................................................................. 11-11
Figure 11-8: EMS-ATS main window ......................................................................... 11-12
Figure 11-9: EMS-ATS via LightSoft: seamless integration ....................................... 11-13
Figure 11-10: Creating an ATM VC connection ......................................................... 11-14
Figure 11-11: Event log window ................................................................................. 11-15
Figure 11-12: Generic EMS main screen ................................................................... 11-16
Figure 11-13: AccessWave management system view ............................................. 11-17
Figure 11-14: Generic EMS in the Current Alarms window ....................................... 11-18
Figure 12-1: LCT-XDM main window ........................................................................... 12-2
Figure 12-2: LCT-XDM shelf view ................................................................................ 12-2
Figure 12-3: Platform view as displayed in the LCT-BGF ............................................ 12-3
Figure 12-4: LCT-ATS main window ............................................................................ 12-4

soll.

x ECI Telecom Ltd. Proprietary 432006-2006-023-A00

432006-2006-023-A00 ECI Telecom Ltd. Proprietary 1-1

In this chapter:
Network Management in a Multitechnology Environment ............................. 1-1
Managing a Moving Target with LightSoft ..................................................... 1-3
Layered Management Concept ........................................................................ 1-5
LightSoft's Clear Advantages ........................................................................ 1-10
Intelligent Management for Intelligent Networks ......................................... 1-13
Network Management in a
Multitechnology Environment
Today's telecommunications market has grown increasingly complex, requiring
service providers (SPs) to offer a wide range of consumer services through a
mixture of sophisticated technologies. SPs must maintain their current TDM
and HSI services while gradually adding the triple play services of VoIP, IPTV,
and VoD, as well as providing other Ethernet-based service for business
(Virtual Private LAN Service or VPLS), 3G Ethernet-based mobile
aggregation, wholesale services, and more, all in a single unified network.
Many carriers are currently migrating from legacy SDH/SONET-only
networks. The first stage is to establish next generation (NG) networks that
support Carrier Ethernet traffic over pluggable data cards within existing
XDM
MultiService Provisioning Platforms (MSPP) platforms. LightSoft

provides smooth integration for SDH/SONET MSPP and packet-based CESR
platforms. The ultimate goal is to establish packet-optical Ethernet-over-WDM
networks.
This transition poses many challenges to Network Management Systems
(NMSs). The NMS must monitor the network while correlating alarms from
different logical layers and providing end-to-end (E2E) provisioning of
SDH/SONET trails and optical Ethernet services.
1
Introduction
'Start', um Heading 1 dem Text
soll.
soll.

1-2 ECI Telecom Ltd. Proprietary 432006-2006-023-A00

Due to the evolution of network design and the gradual introduction of
different technologies, implementation and provisioning of services can be
quite complicated. It is not uncommon for several technologies, often residing
in different network elements (NEs), to work together to deliver a service.
The following figure illustrates the layers in a network with Ethernet,
SDH/SONET, and optical technologies, highlighting some of the intricacies of
network management.

Figure 1-1: Multiple technologies in a typical SP network
soll.
soll.


In this example, a Layer 2 Ethernet service is provisioned on an MPLS-TP
tunnel, which, in turn, is configured on an MPLS over Transport (MoT)
low-order (LO) SDH VC-3 client connection that resides on a high-order SDH
VC-4 server connection. This VC-4 link is deployed on a LightPath (LP) trail,
the client of an Optical Channel (OCH) trail, which, in turn, is a client of an
Optical Multiplex Section (OMS) trail. Finally, the OMS trail needs to be
configured on top of a physical fiber that is in a shared-link risk group (SLRG).
Successful provisioning and monitoring of the Ethernet service requires correct
management of all infrastructure layers below it - obviously a definite
challenge to the network manager.
Managing a Moving Target with
LightSoft
ECI Telecom offers SPs a unique value proposition: a single NMS that
provides seamless E2E service while ensuring smooth migration from legacy to
NG networks. For example, NG platforms optimally suit areas requiring dense
data services, while existing XDM platforms efficiently provide low volumes
of data services at the distant peripheries. Data traffic offload from one to the
other can easily be managed by ECIs multidimensional multilayered
1

LightSoft
NMS.
LightSoft pioneered a new concept in network managementmultidimensional
managementenabling users to manage multiple technologies (SDH/SONET,
ASON, DWDM-based optical, ROADM, Carrier Ethernet, and MPLS)
independently of the physical layer. LightSoft simultaneously provisions,
monitors, and controls many network layers with multiple transmission
technologies. It does this from one application, using the same software
platform and database.

1
ECIs multilayer technology is a registered patent.
soll.
soll.


The entire range of ECI Telecom's transport solutions can be managed easily
and reliably. LightSoft's innovative approach, illustrated in the following
figure, allows carriers to add management layers as they add new technologies.

Figure 1-2: Layered management approach
A carrier that starts with an SDH/SONET network can manage the network
topology using LightSoft's SDH/SONET layer. When Carrier Ethernet services
are added, all that has to be done is to activate the Ethernet/MPLS layer already
built into LightSoft. The next stage, typically, is to acquire additional capacity
via WDM technologies using the same physical infrastructure. Again,
LightSoft is ready, with an optical management layer that manages the
DWDM, CWDM, LP, ODU, OCH, and OMS trails. LightSoft also supports
full ASON protection, smoothly integrated into the SDH layer.
soll.
soll.


Layered Management Concept
ECI Telecom's management concept is based on a layered architecture in
accordance with the ITU-T M.3010 standard for compliant layer architecture.
Separate layers make up the management structure. The lowest level, the
Network Element Layer (NEL), constitutes the embedded agent software of the
NEs. The second layer, the Element Management Layer (EML), controls many
individual NEs, while the third layer, the Network Management Layer (NML),
controls the main network management functions.

Figure 1-3: ECI Telecom's layered architecture management concept
LightSoft functions at the NML, while a variety of different Element
Management Systems (EMSs) controlled through the LightSoft umbrella
function at the EML. Each EMS (EMS-XDM, EMS-BGF, etc.) is tailored to a
specific type of NE. A northbound interface connects either the EMS or
LightSoft to your Operations Support System (OSS). In addition, the platforms
are equipped with LCT applications, providing fast connectivity to the NE and
enabling installation, configuration, and management functions.
soll.
soll.


LightSoft provides crystal-clear management control of the physical,
SDH/SONET, data, and optical layers:
Physical layer: sites, equipment racks, NEs, fibers, and electrical or radio
connections.
SDH/SONET layer: ADMs, cross connects (XCs), terminals, and service
trails from 2 Mbps to STM-256/OC-768, including ASON protection and
recovery capabilities integrated seamlessly into the rest of the network.
Data layer: Ethernet services, logical topologies between cards and data
bridges, MPLS- and Provider Bridge (PB)-based Carrier Ethernet services.
MPLS tunnels may be configured over Ethernet (MoE) or SDH/SONET
(MoT) connections. Rapid Spanning Tree Protocol (RSTP) and Ethernet
Ring Protection (ERP) mechanisms are available, as well as the structured
design advantages of hierarchical VPLS (H-VPLS) domains and logical
administrative groups.
Optical layer: DWDM Muxes, DeMuxes, amplifiers, and optical ADMs.
E2E optical trails can be configured over ODU and OCH interfaces, with
optical DRI and multiroute OCH providing robust protection options.
LightSoft makes navigation between the physical and service layers
transparent. You can easily perform all monitoring, maintenance, and
management operations via the GUI or standard CORBA interfaces.
This layered architecture concept provides comprehensive control of all
transport equipment in your network.

Figure 1-4: One management system
soll.
soll.


The network management suite includes comprehensive configuration, fault
management, PM, administration, maintenance, and security tools for all the
technologies in your network, ensuring efficient resource control, streamlined
operation, and high QoS. You can view all aspects of the network at a glance
and fully control all elements. In addition, multiple users can simultaneously
configure the network without causing access conflicts.
Network configuration and provisioning tasks for SDH/SONET links, optical
trails, MPLS-TP tunnels, and Ethernet services are native to LightSoft. The
intuitive point-and-click interface facilitates LP, ODU, and OCH provisioning,
as well as MoT/MoE tunnel configuration and top-down provisioning. E2E
trail provisioning utilizes a sophisticated Pathfinder algorithm. Downtime is
significantly reduced due to fast alarm handling, online reports, flexible
management, and comprehensive logs. Failsafe database backup and disk
mirroring ensure uninterrupted operation and data integrity.
LightSoft provides a holistic solution for your network management
challenges: simple, smart, scalable, and centralized. Its intuitive front-end GUI
is backed up by sophisticated server engines. Its on-demand service
provisioning and pinpoint bandwidth allocation dramatically reduce equipment
and operating costs usually incurred by multiple management systems.
With ECI Telecom's hierarchical approach to network management, LightSoft
serves as a global E2E management 'umbrella' for the entire network. Every
family of products has its own EMS. LightSoft provides a completely scalable
solution by managing thousands of NEs via their respective EMSs. When you
look at the whole picture, it's obvious that LightSoft is truly a carrier class act!
Powerful Set of Features
LightSoft's feature set includes:
Totally GUI-based management system: Operational teams can perform
network and element management through graphical interfaces, thereby
dramatically reducing the use of CLI.
LightSoft is designed to provide the same look and feel when managing
Carrier Ethernet/MPLS, DWDM, or SDH/SONET. This philosophy is
implemented for all Fault, Configuration, Accounting, Performance, and
Security (FCAPS) modules. For example, the GUI for provisioning an
Ethernet service and an SDH/SONET circuit are the same, although the
underlying technology and equipment are very different.
The rich user-friendly GUI provides many advanced features, including
sortable tables, customizable columns and counters, nested groups, and
color-coded links. Point-and-click functionality is available at all levels,
both physical and logical.
soll.
soll.


Multilayer topology views: The topology of each logical layer is displayed
independently of the physical layer. LightSoft automatically recognizes the
relationships between layers. The displayed layer shows its own objects
and links, as well as "virtual" representations of trails from an underlying
technological layer.
Fast and flexible fault management: Effective alarm handling, online
event reporting, and current/history fault logs all lead to reduced downtime.
Alarm displays include links to alarm troubleshooting tips. Each logical
layer shows its own alarms. An alarm correlation feature enables you to
quickly identify the root cause of a problem without having to check a long
chain of secondary alarms.
E2E trail, tunnel, and service definition: Comprehensive definition of
SDH/SONET and optical trails, MPLS tunnels, and Ethernet services for
primary and protection paths. Support for all types of trails and links (MoT,
MoE, EoS, ETY, SDH/SONET, optical), protection schemes, and user
constraints. Simply point and click to connect any two endpoints, even in
the most complex topology. LightSoft provides powerful trail
reconstruction options to reconcile discrepancies between different layers,
as well as batch traffic management capabilities. LightSoft provides
smoothly integrated management for optical, MSPP, and CESR platforms.
Complete network scalability for services and bandwidth, ranging from
megabits to terabits with variable granularity and hundreds of thousands of
trails and services. LightSoft gives you total control over network
scalability.
Simple operation and fast learning: Designed to simplify day-to-day
operations, LightSoft's GUI facilitates enhanced navigation, network
monitoring with easy fault localization, and simple deployment of new
services.
Multiple users and configurators: LightSoft provides E2E provisioning
over an entire transmission network. Many users can configure the network
simultaneously, with no conflict or confusion, ensuring productivity and
efficiency.
Full E2E Operations, Administration, and Management (OAM) of
Ethernet links and MPLS-TP tunnels, for efficient fault localization,
performance information, and data and diagnosis functions across optical,
MSPP, and CESR platforms.
soll.
soll.


Integration in TNM environments: LightSoft complies with all relevant
ITU-T standards and TeleManagement Forum (TMF) recommendations for
northbound and southbound interfaces. The TMF MultiTechnology
Network Management (MTNM) standard interface between LightSoft and
the EMSs enables LightSoft to integrate easily with OSSs. Your system can
perform operations such as fault handling, service provisioning, inventory
management, and billing for ECI Telecom NEs. Management via
standardized interfaces means that existing equipment can still be used, a
considerable CAPEX saving.
Convenient simple network management across different networks:
LightSoft enables point-and-click service creation and management across
MPLS, PB, and unmanaged element (UME) third-party device networks.
LightSoft uses preprovisioned Connection Admission Control (CAC) to
check for resource availability on service provisioning. You can also define
SRLGs to enhance and guarantee protection.
Comprehensive security: LightSoft runs in a hardened UNIX operating
system environment to protect against hacking and intrusions, unauthorized
access to sensitive customer data, and damage to normal system
functionality, intentional or unintentional. See User Management and
System Security (on page 9-1).
Fail-safe database backup: Additional hardware may be deployed as
standby to assume full control of the network if the active site fails,
ensuring uninterrupted operation and data integrity.
Comprehensive configuration, maintenance, and PM tools: A
comprehensive tool set enables full efficient control of network resources,
resulting in streamlined operation and superior QoS. Multiperiod PM offers
complete network visibility through historical reports for trails, tunnels, and
services according to user parameters and settings. The carrier can monitor
network performance and quickly identify changes, trends, and
inefficiencies, ensuring that SLAs are met.
Sophisticated Resource Domain Partitioning (RDP) and Customer
Network Management (CNM): RDP is the ability to divide a network into
many different resource domains, or logical regions, each with its own
capability and resources profile. CNM is the ability to partition a managed
network's resources (domains) amongst various users (CNM clients) and
assign them different capabilities (profiles). SPs can lease ports, cards, or
entire NEs to CNM clients and operators can functionally partition their
network amongst their own subdivisions for organizational reasons.
LightSoft offers an extremely fine-grained selection for both capabilities
and domains.
soll.
soll.


LightSoft's Clear Advantages
Managing physical, SDH/SONET, data, and optical networks through a single
NMS offers several valuable benefits:
Significant reduction in OPEX: Total Cost of Ownership (TCO) is
reduced by fewer servers and systems and less staff that needs to be trained
and employed.
Streamlined operations and enhanced efficiency: LightSoft can easily
automate tasks in a way that is not possible with multiple standalone
NMSs. For example, with a single click of a button, LightSoft can drill
down from an Ethernet service to the associated SDH/SONET or optical
trail. Many similar functions in LightSoft save valuable time and effort and
allow for quicker resolution of network failures, resulting in lower OPEX
and higher QoS. To achieve the same functionality with separate NMSs,
possibly from different vendors, would require complicated and costly
integration. LightSoft supports the tightest level of integration between
Carrier Ethernet, SDH/SONET, and optics.
Single point of integration towards external systems, such as the
carrier's OSSs or Base Station Systems (BSSs). LightSoft interfaces with
external systems using a standard CORBA-based TMF-814 MTNM
interface.
Intuitive easy-to-use GUI offers a consistent look and feel across all
technologies, equipment, and applications. This means a short learning
curve, lower integration costs to the OSS level, and efficient use of staff
resources.
Flexible multilayered approach allows you to navigate quickly between
physical, SDH/SONET, optical, and Ethernet views of the same network,
making it much easier to visualize the different logical strata.
Efficient user and security management through controlled user access
according to the carrier's organizational needs.
Fast fault resolution with short mean time to repair (MTTR).
Migration to Carrier Ethernet/MPLS (or other NGN) at your own pace.
LightSoft's single user interface and familiar look and feel allow you to
start managing additional networks quickly with minimal training.
Typically, a LightSoft user is able to perform full management, monitoring,
and provisioning for the SDH/SONET, Carrier Ethernet/MPLS, and
DWDM domains of the network. Supported Carrier Ethernet/MPLS
network types include:
Hierarchically organized MPLS network, using VPLS logical elements
(LEs) organized into logical domains connected by MPLS tunnels.
Ethernet Access Hierarchical VPLS (EAH-VPLS) networks.
soll.
soll.


PB networks, using Bridge LEs and VPLS LEs connected by Ethernet
I-NNI (Internal Network to Network Interface) links.
Easy implementation of additional new technology layers.
New revenue potential by leveraging architecture through CNM.
LightSoft's integrated approach and flexibility allow you to configure the
security scheme according to logistical and organizational needs without
the complexities of dealing with several different NMSs.
In today's competitive telecommunications market, consumers require
guaranteed carrier class service delivery from access to core. The classic
definition of carrier class service includes rigorous standards for QoS,
reliability, security, scalability, multiprotocol support, and E2E service
management.
ECI Telecom's powerful, field-proven LightSoft meets and exceeds market
expectations for a carrier class NMS. It is indeed the management system for
today's as well as tomorrow's networks.

Figure 1-5: Carrier class Ethernet requirements
soll.
soll.


Flexible Tailor-Made Configuration
LightSoft allows you to commission and configure services in local and remote
networks. NEs can be deployed in a wide range of topologies, including
combinations of mesh, single or multiple rings, chains, and composite
topologies incorporating terminal multiplexers. With LightSoft, you can build
your transmission network, configure NEs, and monitor alarms using real-time
information, including user-generated notes.

Figure 1-6: Managing MP2MP MPLS-based Ethernet services through LightSoft
You can partition the managed network by NE groups, individual NEs, or even
individual ports, enabling you to open sessions and manage/monitor all or parts
of the network simultaneously. LightSoft lets you move intuitively from an
overall survey of the network landscape to detailed status and control views of
the layers, elements, transmission levels, ports, or trails. You can create and
work with administrative groups and nested groups in each layer.
LightSoft provides you with E2E top-down provisioning capabilities of carrier
class Ethernet services and automatically configures all the required network
parameters.
You can use LightSoft to export management data to other systems. You can
also choose to manage trails by third-party applications via a CORBA-based
TMF-814 standard interface.

NOTE: Unless otherwise noted, the information in this
document applies to both SDH and SONET network
configurations. Specifications that are relevant for one type of
configuration only are indicated.

soll.
soll.


Intelligent Management for
Intelligent Networks
In our cost-conscious era, intelligent management systems are essential for
telecom profitability. ECI Telecom's innovative management solutions give
you the critical advantages necessary to succeed.
ECI Telecom product families provide a comprehensive selection of platforms.
These products come with powerful field-proven management systems
centrally managed by LightSoft. You are assured of consistently superior
network performance. The product families include:
The XDM All-Native MSPP/P-OTS family for metro and cellular
networks, intelligently integrating the capabilities of multiple technologies
in a single shelf-size element. XDM platforms are managed by the
EMS-XDM.
The 9000 family of Carrier Ethernet Switch/Routers (CESR), delivering
E2E access-to-core, carrier class Ethernet services and bringing the
qualities of transport networks to a scalable packet platform. The CESR
9200, 9600, and 9700 series are managed by the STMS (on page 11-4).
The BroadGate
family of All-Native and All Packet Multiservice

platforms, an integrated access solution carrying voice and Ethernet over
optical fiber and licensed microwave radio to customer premises.
BG-20/30/64/9300 platforms are managed by the EMS-BGF (on page 11-
9).
The BG-Wave multiservice radio node (MRAN) provides integrated
microwave transport with full networking and multiservice capabilities.
The BG-Wave supports native Ethernet microwave radio or hybrid native
Ethernet and native TDM microwave radio service, providing optimized
delivery for any mixture of services. BG-Wave platforms are also managed
by the EMS-BGF.
The AccessWave WDM portfolio enables high bandwidth transport
services over WDM in metro, access, and smaller regional networks.
AccessWave platforms, Ceragon, and other private label OEM and
multivendor equipment networks are managed by the Generic EMS (on
page 11-16).
The Artemis passive optical series is a compact high-density low-cost
solution that provides multiplexing and dispersion compensation
capabilities for all ECI Telecom optical platforms. Artemis is managed
directly by LightSoft.
ATS cards are ATM switches that aggregate and concentrate 3G ATM
traffic within XDM platforms. They are managed by the EMS-ATS (on
page 11-12).
soll.
soll.


SYNCOM
family of multiplexers at the STM-1, STM-4, and

STM-16 layers, managed by the EMS-SYNCOM.
Third-party equipment such as the Ceragon FibeAir wireless systems.
ECI Telecom network equipment smoothly integrates with external
networks, interfacing through the Generic EMS application. Management
information flows freely between SDH/SONET and other complimentary
access, radio, and switching products.
BroadGate Family
The BroadGate family provides All-Native and All-Packet multiservice
products for RAN, metro-access, and access applications. BroadGate products
are deployed as CPE at customer locations, as CLE in cell towers, and as
cost-effective metro aggregation devices.

Figure 1-7: BroadGate product portfolio
BroadGate platforms provide a full set of MPLS-TP and Native Ethernet
Layer 2 capabilities combined with an entire range of Ethernet over
SDH/SONET (EoS), MPLS over SDH/SONET (MoT), MPLS over Ethernet
(MoE), Ethernet over PDH (EoP), Pulse Code Modulation (PCM), PDH, and
SDH/SONET services, for both optical and microwave radio physical media.
The BroadGate product line MPLS and Layer 2 Ethernet capabilities offer
carriers a crystal clear migration path from pure TDM-based legacy services to
new value-added Ethernet-based services. The platforms enable optimized
traffic-handling in a mixed traffic environment, skillfully dealing with both
TDM and Ethernet natively and independently via dedicated switching fabrics.
This prevents one traffic type from adversely affecting the other.
The BroadGate MPLS cards support full triple play services, IPTV, VoD,
VoIP, and HSI for residential NGN applications. This comprehensive set of
capabilities allows carriers to leverage their legacy SDH/SONET installed base
while offering an attractive mix of PCM and carrier class Ethernet services to
their customers.
soll.
soll.


The BroadGate family also optimizes as an access aggregator and as a
MultiService Aggregation Gateway (MSAG) CLE. BroadGate platforms
support enhanced video handling and P2MP multicast tree connectivity,
enabling highly efficient bandwidth savings for broadcast TV/IPTV services, as
well as star VPLS for IPTV and IGMP control messages.

Figure 1-8: BroadGate family solutions
For more information about BroadGate platform capabilities, see the
BroadGate Product Line General Description.
CESR 9000 Family
ECI Telecoms Carrier Ethernet 9000 family was designed from the ground up
to bring the qualities of transport networks to a scalable packet platform. The
Carrier Ethernet 9000 family enables a smooth migration from TDM to Carrier
Ethernet networks, offering a complete suite of E2E Carrier Ethernet and IP
services and transport for business, residential, and mobile networks. ECI
Telecom platforms offer carrier grade solutions tailored to the expectations of
each client, including:
Advanced QoS
Guaranteed QoE
MPLS-based control plane including IP/MPLS, MPLS-TP, and IP/MPLS to
MPLS-TP gateway functionality
PW technology for delivering legacy traffic
soll.
soll.


Advanced synchronization mechanisms
The unified infrastructure with E2E management capabilities supports an
efficient convergence of multiple services over multiple technologies,
simplifying network planning, implementation, and management, and lowering
expenses considerably.

Figure 1-9: Carrier Ethernet 9000 family
The group of sophisticated Carrier Ethernet switch routers, aggregation
switches, and demarcation units meet or exceed all relevant MEF, IEEE,
NEBS, ITU-T, and IETF standards. ECI Telecom's 9000 family is a set of high
performance, high density carrier class multiservice platforms for access and
metro networks. They are part of ECI Telecom's comprehensive metro Ethernet
offering, optimized across multiple transport/service layers to provide seamless
provisioning and operation.
The full range of Layer 2 and Layer 3 features, combined with delivery of
legacy services over packet infrastructure, make the Carrier Ethernet 9000
family ideal for:
Broadband residential triple play enabling deployment of a single
infrastructure for residential and business voice, video, and data services
supporting per-subscriber QoS. Services include:
Digital Broadcast and Multicast TV (DBTV/IPTV)
HSI over broadband access
IP multicast for video distribution
Voice and Video over IP (V2oIP)
soll.
soll.


Broadband business/enterprise services supporting a smooth transition
from leased line to packet services, including Ethernet private line,
Ethernet LAN (E-LAN), and IP VPNs in a single platform. The 9000
family provides sophisticated QoS capabilities. For Layer 2 services, the
H-QoS model includes all the policing, metering, and scheduling
hierarchies necessary to support triple/multiplay or business application.
The H-QoS model supports the per-subscriber queuing necessary for a
flexible and fair mix of guaranteed and best effort services and service
components, in terms of bandwidth, delay, delay-variation, and loss
probabilities.
Mobile aggregation and backhaul services supporting a gradual evolution
of cellular networks to Ethernet-based networks. Synchronous Ethernet
(SyncE) and IEEE 1588v2 Precision Time Protocol (PTP) are native to the
platform and management system, enabling even the most complex hybrid
network configurations to function smoothly and flawlessly. The 9000
family enables growth in personalized services, meeting the demand for
converged service offerings.
ECI Telecoms Carrier Ethernet 9000 family provides a cost- and
performance-optimized solution for multiple layers of transport and service
delivery with a unified management system that provides simplified service
provisioning and monitoring. The high adaptability and build-as-you-grow

architecture leads to considerable savings in OPEX and CAPEX.

Figure 1-10: Converged metro Ethernet transport network
For more information, see the complete set of Carrier Ethernet 9000 Family
General Descriptions.
soll.
soll.


XDM Family
ECI Telecom's XDM is a family of All-Native multiservice transport platforms
that integrates all the transport functions of a complete Point of Presence (POP)
in a single shelf-size element. The XDM accommodates the growing demand
for data bandwidth while maintaining cost-efficient flexible support for all
types of traffic, including voice, data, and video.
The XDM combines the high manageability, fast protection time, and multiple
topology support of TDM with the enhanced connectivity and availability of
XCs, C/DWDM bandwidth, and the efficient transport of MPLS, Ethernet, IP,
and ATM. The result is a powerful, flexible, and reliable platform with
unparalleled functionality.
The XDMs All-Native nature enables optimized traffic handling in a mixed
traffic environment, skillfully dealing with both TDM and Ethernet natively
and independently via dedicated switching fabrics. This prevents one traffic
type from adversely affecting the other. The native handling of both TDM and
Ethernet assures the lowest TCO for transporting all types of traffic while
supporting a smooth transition path from TDM-centric to data-centric
networks.
The XDM's exceptional grooming capabilities and high-order/low-order
granularity make it extremely adaptable to traffic changes. Its outstanding
performance reduces line resources and eliminates bottlenecks in metro sites.
The modular design features universal I/O slots and hot-swappable cards and
modules. This flexibility enables the provisioning of multiple combinations of
topologies, bitrates, protection schemes, and ports or protocols.
soll.
soll.


Designed to accommodate network growth, the XDM provides multi-degree
WDM ROADM, OTN support, and high-capacity optical interfaces, thereby
eliminating the need for additional external WDM equipment.

Figure 1-11: XDM integrated multiservice/multitechnology network solution
XDM platforms are organized in two groups:
XDM-100 product line, All-Native MSPP for metro aggregation networks:
XDM-100, compact All-Native MSPP with CWDM for metro-access
and aggregation
XDM-300, high capacity All-Native MSPP with CWDM for metro
aggregation
XDM-900, high capacity, compact, All-Native MSPP for metro
aggregation
XDM-1000 product line, converged All-Native MSPP and all-range
P-OTS:
XDM-40, WDM OTN for metro-access and CPE
XDM-450, ROADM extension shelf
XDM-500, compact core All-Native MSPP with ROADM
XDM-1000, metro-core All-Native MSPP with ROADM
XDM-2000, high capacity All-Native WDM
XDM-3000, high capacity metro-core All-Native MSPP
soll.
soll.


For more information about XDM platform capabilities, see the XDM Product
Line General Description.

Figure 1-12: XDM products portfolio

soll.
soll.



In this chapter:
Overview ......................................................................................................... 2-1
LightSoft Main Window .................................................................................. 2-3
Multilayer Topology Views ............................................................................. 2-6
Network Elements, Logical Elements, and Managed Elements ...................... 2-8
Functional Topology Maps .............................................................................. 2-9
Tunnel and Service Management .................................................................. 2-14
GCT to EMS .................................................................................................. 2-15
Optical Topology Management ..................................................................... 2-16
Overview
The LightSoft GUI provides a powerful yet easy-to-use tool for managing your
network. It combines security, configuration, maintenance, and performance
management tools with fault handling, E2E trail definition, and fail-safe
database backups for uninterrupted and reliable network operation. LightSoft's
powerful tools and capabilities are easily accessed through the main window
(see "LightSoft Main Window" on page 2-3).
The LightSoft GUI features multilayer topology views (on page 2-6). A single
physical layer view is correlated with multiple logical views. Logical views
may be for a specific technology, such as all SDH/SONET, ASON, optical, or
data nodes and links, or for a specific logical context, such as all ODU or OCH
nodes and links, or all components included in a CNM. Multilayer views
enable you to display the topology of each logical layer independently of the
topology of the physical layer.
2
Topology Management
soll.
soll.


You can display logical views of NEs, organized and presented according to a
particular context. For example, if you wish to work on Ethernet services in the
network, you can select a logical Ethernet view that includes only the network
components relevant for Ethernet services. (See Network Elements, Logical
Elements, and Managed Elements (on page 2-8).)
Networks today are larger and more complicated than ever before, often
including thousands or even tens of thousands of elements and components.
Managing these complicated networks is a difficult challenge. A clear
user-friendly GUI with intuitive functionality, detailed online help, and
extensive report functions, while certainly nice, is simply not enough.
Therefore, LightSoft provides a sophisticated set of intelligent management
tools and features to help cut down your management tasks to a more
manageable size.
LightSoft's intelligent sorting and filtering functionality helps you focus on
the network components relevant to the task at hand. You can sort and filter
by any field, displaying or hiding any table column(s) for any table or list in the
system. It is almost impossible to locate a specific element in a very large
network, and LightSoft's sophisticate functionality helps you do just that. The
system's ease of use has many benefits: it cuts down training time, simplifies
complex configurations and actions, and significantly reduces response time.
Each operator can open a LightSoft configuration customized for their
personal working mode. You can save specific sorting or filtering criteria
settings and customize each layer's view to reflect its site hierarchy and the way
its corresponding network is administered. Customized views enable you to see
only the most pertinent information and provide streamlined access to the
functionality you need most.
soll.
soll.


LightSoft Main Window
The LightSoft main window contains everything needed for uninterrupted and
reliable network operation, including configuration, maintenance, performance
and fault management tools, and E2E trail definition. Optionally, it can also
contain a background map of your network topology. Items can be bookmarked
to allow easy location.
The following figure shows the LightSoft main window accessed after logging
in to the system. When the application is active and not minimized, the main
window is displayed as active or as background.

Figure 2-1: LightSoft main window
You can simultaneously open multiple windows showing different views of the
network with selected topology groups or objects. Each view can display a
different topology layer independent of other layers and allow different
operations. The views can be cascaded or tiled on the screen as required.
LightSoft main window components include:
Navigator: As LightSoft can manage thousands of NEs, it is essential to
navigate very complex topologies in the user interface. The Navigator
provides a convenient thumbnail representation of the entire topology in a
small window on top of the main window. You can quickly zoom in and
out, bringing a sense of order and control to even the largest and most
complex topologies.
soll.
soll.


Topology Links: Working with links in LightSoft is quick and simple. On
the system map, links are represented by lines connecting two elements.
They are color-coded for alarms. A topology link indicates the actual
number of links represented between any two elements and may be created
in any topology view (physical, SDH/SONET, ASON, Ethernet/MPLS, or
optical). Link widths vary according to rate.
Topology links may be physical links, created manually or acquired from
an EMS through a discovery process, or virtual links. In logical views,
virtual links are representations of trails, tunnels, services, or other links in
an underlying technology or logical layer. For example, if you define a
LightPath in the optical layer that carries Ethernet traffic, LightSoft
automatically creates a corresponding virtual link on the Ethernet layer.
This virtual link can then be used to configure Ethernet services over the
optical LightPath link. See Multilayer Topology Views (on page 2-6).
Once created, topology links can be edited or modified. A convenient Link
List table displays an organized inventory of the topology links and
simplifies link location and management. Links can be sorted and filtered
for clarity and focus. The Link List makes it simple to edit link attributes,
enabling attribute changes to multiple links simultaneously.

Figure 2-2: Link List table
Link attributes such as cost, distance, and quality are used by the Pathfinder
(on page 5-3) algorithm for optimizing routes. For example, Pathfinder
takes into account situations where links in a network share a common
physical attribute and associated vulnerabilities (SRLG). Pathfinder by
default prefers potential single path routes that minimize the number of
separate SRLGs amongst the path segments, so minimizing the risk
involved in the route itself.
soll.
soll.


Topology Groups: Multiple NEs can be combined into a single
administrative group, represented by a single icon in the topology view.
Groups may represent physical sites, geographic regions, or even logical
subnetwork units. You can also define groups that are nested within other
groups.
A group can easily be expanded to display all component NEs and their
connections, or collapsed to the single group icon. The group icon always
displays the propagated alarm status within that group.
At the physical layer, groups are composed of sites and managed elements
(MEs). At the technology level (SDH/SONET, ASON, Ethernet/MPLS,
and optical) LE groups can be formed. In the Ethernet/MPLS layer, groups
are automatically formed for logical MPLS and PB networks.
Multilink Expansion: Multiple physical and logical links may exist
between two nodes (MEs, LEs, UMEs, and/or groups) and are shown as
thick labeled lines called multilinks that run between objects.
Focus on a multilink to expand the single link line and display the actual
topology or internal links between/within elements and their port endpoints.
Specific NEs at the link endpoints can be shown, even when they are within
nested groups, regardless of the depth of nesting that may apply. You can
also access additional information and functions for each link.
NEs, LEs, and MEs: Networks consist of groups of network elements
(NEs) that may be viewed on many different levels or layers (LightSoft
offers multiple views of the same network). The physical layer view
displays the physical elements and their connections. The various logical
layers display logical connections between logical elements that all belong
to a specific logical or technological category, such as the optical layer or
the Ethernet services layer. Logical elements are user-controlled and can
represent optical or data components, such as transponders, combiners,
Ethernet switches, etc. Special maps are used to focus on specific network
aspects such as RSTP, ERP, or timing topology (Functional Topology
Maps (on page 2-9)).
An NE may be a managed element (ME) or unmanaged element (UME).
LightSoft makes it simple to add MEs and/or UMEs into an existing link.
An inserted UME can be useful for maintaining accurate network topology.
If the inserted object is an ME, the relevant XC changes are downloaded to
the actual NE via its EMS. The procedure automatically creates new links,
properly configures the trails on the new link, and deletes the old link.
There is no need to manually delete or edit trails. (Working with LEs, MEs,
and UMEs is explained in greater detail in Network Elements, Logical
Elements, and Managed Elements (on page 2-8).)
soll.
soll.


Enhanced Zoom Capabilities: LightSoft supports enhanced zoom
capabilities. A cloud makes it easy to spot islands of connected nodes.

Figure 2-3: Enhanced zoom capabilities
Inventory Tree, described in Inventory and Accounting (on page 6-1).
Alarm Counters, described in Fault Management (on page 4-1).
Trail and Tunnel Segment Inconsistency Counters, described in Trail
Consistency Indicator and Tunnel Segment Consistency Counters.
Multilayer Topology Views
As a multidimensional NMS, LightSoft can manage many types of equipment
and technologies. Advanced topology map design multilayer topology views
greatly facilitates this management.
You can display logical layers independently of the topology of the physical
layer. The displayed layer shows its own objects and links, as well as "virtual"
link representations of trails from an underlying technological layer.
Each layer contains its own alarm indicators, enabling separate fault
management of each technology. You can choose which layer to view from a
list displayed in the LightSoft main window.
The physical views display the network infrastructure, that is, the physical
topology of the NEs and the physical connections between them. Each icon
represents a physical element (e.g., XDM, BG, or CESR platform). This view
is used for adding, configuring, deleting, and defining the connections between
NEs.
LightSoft uses a convenient GUI Cut Through (GCT) to access EMSs directly
(see "GCT to EMS" on page 2-15). The EMS topology view displays all
elements represented by the respective EMS workstation whose icon is shown
on the network map. You can easily add, configure, and monitor the EMSs in
the EMS view.
soll.
soll.


The logical views display logical topologies within the context of the various
technologies or subnetwork groups within the network, regardless of the NE on
which the ports are located. Each icon represents a card (e.g., data card or
optical combiner) within a platform.
In the physical view a single XDM platform is represented by a single icon. In
the corresponding logical view, cards within that single XDM platform are
portrayed as separate icons, including the logical links between them. Logical
views may be per technology, such as the optical technology view, or per
logical context, such as the ODU or OCH topology within the optical layer, or
the SDH/SONET server trail topology for CNMs within the SDH/SONET
layer.
LightSoft automatically recognizes the relationships between logical layers.
The logical view shows only the objects and links pertaining to the displayed
view, as well as virtual link representations of trails from an underlying
technological layer.
In the optical layer, you may create an LP running from point A to point B
passing through a few different NEs. When you create the LP on the optical
layer, LightSoft automatically creates the corresponding virtual links between
the endpoints on the Ethernet/MPLS layer. You can now start to provision
traffic along the virtual Ethernet/MPLS link. The following figures portray two
views of the same network, the Ethernet/MPLS data layer and the
corresponding optical layer.

Figure 2-4: MPLS layer
soll.
soll.


Figure 2-5: Optical layer
Network Elements, Logical
Elements, and Managed
Elements
NEs can be deployed in a wide range of topologies, including single or multiple
rings with appendages and composite mesh topologies. You do not have to
specify the type of topology in advance: simply define and add NEs and
LightSoft creates the appropriate network plan. You move intuitively from an
overall survey of the network to detailed status and control views of any NE,
transmission level, system card, or trail.
LightSoft makes it possible to manage NEs at multiple layers. It distinguishes
between the managed elements (MEs) that make up the network and the logical
elements (LEs) these MEs represent. You can:
Focus on MEs when creating and deleting NEs (physical layer).
Focus separately on the logical topology available at each technology level
(SDH/SONET, optical, or Ethernet/MPLS) when managing traffic
(technology layer).
Whenever an ME is added to the network at the physical layer, an LE is
automatically projected into the relevant technology layer. If an ME contains
ports that belong to multiple technologies (e.g., in XDM platforms), LEs are
created at each technology layer containing only the ports relevant to that layer.
Nested groups are supported and can be defined differently in the various
layers.
soll.
soll.


Automatic and Manual LE Creation
LightSoft supports automatic LE creation, with relevant internal objects
immediately split out into multiple secondary LEs. LightSoft also supports
manual LE creation, with specific internal objects selected from a source LE.
Automatic LE creation saves valuable time while manual LE creation enables
you to customize the topology views. Automatic LE creation is available in the
ETH/MPLS and optical layers, as follows:
By Ethernet switch: PB and Provider Edge (PE) LEs are created
automatically according to the assigned card without any user intervention.
Ethernet objects uploaded from the EMS are automatically discovered and
a representative LE is created. The process automatically assigns special
attributes to the LEs, such as RSTP-essential L2 attributes enabling the LEs
to be visible in the RSTP map.
By optical component: For optical LEs, automatic secondary LE creation is
user-triggered by setting a checkbox in the Create LE process. According
to the type of card, either multiple secondary LEs are created or all ports
are assigned to a single secondary LE. Automatic LE creation is applied
according to EMS-defined optical object groupings.
Functional Topology Maps
LightSoft provides functional topology maps that focus on specific types of
information or functionality and enhance effective network management. They
include:
soll.
soll.


Availability Map
The Availability Map window displays the available resources for each link at
various rates, with customizable ranges and colors. You can see where there is
unused available capacity and where overloaded links are potential bottleneck
risks and enjoy immediate savings by simply balancing the traffic load more
evenly around the network. Availability maps are displayed for the physical,
optical, SDH/SONET, and Ethernet/MPLS layers. See Inventory and
Accounting (on page 6-1).

Figure 2-6: Availability Map window
soll.
soll.


Timing Map
The Timing Map window enables you to monitor the network's timing
topology using a convenient color-coding scheme. The map identifies timing
sources (primary and secondary), timing directionality, and timing source
quality and is important for monitoring and troubleshooting network
functionality.
Timing sources for each NE are configured via the respective EMS in the
Timing Configuration window of each NE. You can choose between a variety
of timing sources. You can use LightSoft to manually select (force) a specific
timing source, even if the system has automatically made a different selection
based on the quality of the sources and the priorities assigned by the user. This
action is performed from the EMS or via GCT from LightSoft. See NE Timing
and Synchronization (on page 3-13).

Figure 2-7: Timing Map window
RSTP and ERP Maps
A bridged Ethernet network must operate in a loop-free fashion even when the
Ethernet topology itself contains loops to provide redundancy. RSTP and ERP
are two methods used to prevent unintentional looping.
soll.
soll.


Rapid Spanning Tree Protocol (RSTP) automatically creates a loop-free
"spanning" tree of links connecting all the bridges (when possible). Links in the
tree are active (used by Ethernet traffic), while those not in the tree are inactive.
As network changes occur, RSTP dynamically updates the spanning tree. The
Ethernet layer may have several unconnected Ethernet networks, each with its
own RSTP tree.
Ethernet Rings Protection (ERP) is a series of mechanisms intended to provide
sub-50 msec protection for Ethernet traffic for P2P, P2MP, and MP2MP
connectivity over ring or interconnected ring topologies, while ensuring that
there are no loops formed at the Ethernet layer. ERP is robust enough to work
for unidirectional failure and multiple link failure scenarios in a ring topology.
It also supports a mechanism to force a switch to be activated for maintenance
purposes.
The RSTP/ERP Map window shows the current traffic state of RSTP or ERP
services - which links are active/non-active (RSTP) or which links are
forwarding or blocking traffic (ERP). Clicking either RSTP or ERP in the
dropdown list displays information for the required protocol.
The following map shows the parts of an RSTP tree used by traffic between
Ethernet service endpoints and enables you to understand current traffic flow.
You see the elements and links participating in the RSTP tree, RSTP route and
directionality, and whether a link is active or not.

Figure 2-8: RSTP map view
soll.
soll.


LightSoft's ERP map view indicates the relevant objects of an ERP protected
topology. ERP-relevant objects are color coded yellow, blue, and purple for
enhanced clarity. Non-participating links are colored gray. This is illustrated in
the following figure. Note that the color scheme is user-configurable.

Figure 2-9: ERP map view
soll.
soll.


Geographical Map
LightSoft supports the display of customer-provided geographical background
maps in standard Shape (.SHP) format. ECI Telecom Customer Support can
load your .SHP geographic maps to be displayed as a background to
LightSofts topology map.

Figure 2-10: Geographical map
Tunnel and Service Management
You can view all of the services, parameters, endpoints, and paths of tunnels
belonging to MPLS networks via the Tunnel List and Service List windows.
Each MPLS, PB, and combination EAH-VPLS network is shown as a single
group icon on the ETH/MPLS topology map. Nodes within an MPLS network
can be organized into logical administrative groups, with each group
represented separately in the GUI, to simplify management of large, complex
network configurations. Click a specific icon to view individual nodes within
that network.
To streamline Ethernet/MPLS service creation processes, new services with
similar parameters and path details can be set up using global service templates
stored in the database. Once created, template details can be applied when
creating a new service and specific parameters can be changed.
soll.
soll.


GCT to EMS
You can use the GCT to easily access functions performed at the EMS level
without actually launching it, including:
Setting, changing, and propagating NE attributes
Configuring platforms and cards
Changing alarm severities
Setting NE timing sources
Activating performance management functions on NEs
Performing maintenance functions on NEs or their objects
EMS windows are displayed on top of the LightSoft main window. This
seamless transparency creates a truly comprehensive and multilayered
management system.
The following figure illustrates a GCT from LightSoft to the EMS-XDM.

Figure 2-11: GCT example (LightSoft to EMS-XDM)
soll.
soll.


Optical Topology Management
The following features implemented at the LightSoft and EMS-XDM levels
provide excellent intuitive management of the optical layer:
Enhanced Automatic Power Control (APC (on page 2-16))
Functional Node (FuN) Topology Map (on page 2-18)
Power Equalization for Lightwave Enabled Servers (PELES (on page 2-
19))
APC
DWDM networks (optical components and their connecting fibers) are subject
to attenuation changes along the fiber links. These can lead to gain tilt changes.
If not corrected, the associated OSNR degradations can disrupt optical network
operation.
Previously, gain and equalization problems could only be corrected through
manual insertion of fixed attenuators. This placed a heavy burden on optical
network operators. To address this situation, ECI Telecom developed APC.
APC provides the following important functions for DWDM networks:
Responds to attenuation changes and automatically resets the amplifier gain
and the added channels' power.
Increases optical network resilience by keeping per channel power constant
for both expected and unexpected variations in the number of channels.
Compensates for optical network degradation (aging effects).
Generates warnings and alarms as needed.
Enforces built-in limits to prevent unwanted traffic disturbances.
APC functions at the EMS-XDM level and is localized in each card or power
control element. The actual (measured) optical power at the card input is
compared to the expected (calculated) input power. APC is configured
manually through a set of readable parameters, such as the number of input
channels for an element and the number of amplifiers preceding the element.
Only minimal calculations are necessary.
soll.
soll.


The following diagram illustrates the operational concept of APC. In this
optical chain, power levels are monitored and analyzed, leading to effective
power equalization along the length of the chain.

Figure 2-12: APC chain model
The OADM in the middle of the optical chain, with channels arriving from two
different types of sources, suffers from unequal power levels that result in gain
tilt. Channels from earlier in the chain have lost power due to attenuation.
Channels being added locally are at a higher fixed power level since they are
first entering the chain at this point.
APC adjusts the power of the added channels to the power level of the
passthrough channels. Note that channels coming out of the OADM are all at
the same lower level, reducing OSNR at the end of the trail. Therefore, the
amplifier located after the OADM in this chain increases its gain to compensate
for the lower levels, restoring the channels to peak power and recovering the
OSNR.
APC is designed to compensate for changes in fiber attenuation that may cause
unwanted gain tilt. However, APC also reacts to changes in the number of
channels. Automatic APC reactions are limited to prevent traffic disturbances
when inappropriate reactions occur. PELES (on page 2-19) was designed to
prevent inappropriate reactions to changes in the number of channels as well as
to ease network setup and configuration, especially in large or complex
network topologies.
soll.
soll.


FuN Topology Map
The FuN Topology Map (FTM) utility, accessed through the EMS-XDM,
assists the set up and management of XDM optical sites. An optical site (also
called an Optical Network Element (ONE)) is a loose collection of cards
residing on one or more XDM shelves in one location collectively performing a
specific function. FTM enables users to build optical networks using intuitive
graphic icons and an easy drag-and-drop process. FTM works with an intuitive
logical map similar to the 'As Built' documentation.
Many components can be used to implement an optical site, and the
relationships between the shelves, cards, and modules are not always clear in
the NE Shelf View. FTM enables you to view, manage, and monitor optical
sites and connections from a functional perspective. You see a logical view of
the complete optical site and not a purely equipment-centric view.
Events and alarms are color-coded for all network components. Network status
is therefore constantly apparent without having to open another window. FTM
also streamlines operations by providing direct access to the card configuration
screens from its main window.

Figure 2-13: FuN topology map
Once the map has been constructed and the links created, the EMS uploads the
links to LightSoft.
soll.
soll.


PELES
PELES is a network utility that monitors optical chains from end to end,
providing complete APC and equalization in all network topologies, including
chains, rings, and mesh. When triggered by specific types of network events,
PELES measures and analyzes the actual power levels along a path, determines
the nature of the event, and configures the APC in NEs along the optical path
accordingly.
PELES is implemented at the EMS level and utilizes APC (on page 2-16)
within the NE embedded software. The APC detects optical power changes and
notifies PELES. PELES analyzes the data and utilizes the APC mechanism to
restore power equalization and channel levels throughout the link. With
PELES, you can distinguish between changes in power level due to link or span
attenuation or due to changes in the number of channels.
PELES features include:
Monitoring current power levels and channel status:
Measuring actual link attenuation.
Detecting changes in span loss.
Per-span information regarding active channels passing through a
power control element.
Displaying the monitored data in a clear convenient table.
Automatically configuring Power Control Objects (PCOs) in the cards.
Automatically calculating optical link parameters in case of an event,
including:
Actual Number of Channels (NOCs) present at the input of a power
control element.
Actual Number of Amplifiers (NOAs) and the precise Average Gain of
previous amplifiers (AVGpas).
Required gain at each amplifier.
Updating the physical NEs with changes in card configuration through
power control activation.
The XDM uses an intelligent mechanism to provide constant optimized power
per channel (PPC) throughout the link and the system life span. This provides
DWDM networks with the reliability and ready-to-use simplicity they require.
soll.
soll.


PELES, in combination with FTM (on page 2-18), automatically configures
and calibrates the optical chains in a new network, establishing traffic flow in a
single intuitive procedure. FTM and PELES support provisioning operations
(adding and removing channels). You enter the physical topology changes
through the FTM GUI and PELES's 'repair' process updates affected chains
without affecting existing traffic. When completed correctly, the process is
completely transparent to all existing channels, providing perfectly smooth
scalability from the first channel up to the maximum channel count.
PELES offers the following key capabilities:
Detecting span loss change and measuring link attenuation: The real
change in span loss along a single link is detected by comparing changes of
composite power at the input of a controlled element against changes at the
output of the previous element. Power changes can be caused by
attenuation (Span Loss Changes (SLC)), and those caused by changes in
the number of active channels (Channel Changes (ChaCha)).
Measuring active channel change: PELES calculates the actual number of
channels that are present at the input of each Mux/OADM and updates each
controlled element when changes occur. This eliminates the need for a
manual update or readjustment of the various amplifiers, OADMs,
ROADMs, etc. along the link, thereby simplifying adding new channels to
the network.
Calculating and defining the correct gain values needed at each
amplifier: PELES takes into account the power level goals and optical
noise accumulated along the chain. You can control optimum power levels
through the Power Per Channel out parameter, configurable per span.
Increasing optical network resilience by keeping per-channel power
constant for both expected and unexpected variations in the number of
channels.
Providing comprehensive set of indicators such as a map of all active
channels and a table showing all changes in span loss. These easy-to-read
indicators ease network operation, assisting you in monitoring all network
changes closely and providing early warning of problematic fibers.
soll.
soll.


When working with simple chain topologies, PELES uses a simple model
running from the Start of Chain (SoC) to the End of Chain (EoC). The SoC is a
Mux that adds channels to the chain from a set of transmitters. The EoC is a
DeMux that drops channels into a set of receivers. This is illustrated in the
following figure.

Figure 2-14: PELES chain model
In addition to simple chain topologies, PELES can equally effectively monitor,
analyze, and equalize power levels in more complex mesh topologies. For
example, while chains have clear start and end points, a typical mesh topology
consists of a complex interwoven set of links with none obvious. Channel
flexibility required in todays sophisticated optical networks may potentially
involve channel reconfigurations that are repeated and affect power levels.
soll.
soll.


PELES manages complex mesh topologies by breaking them down into
carefully defined independent chains that feed into each other. Channels
traveling through a mesh network may be passed along from one chain to
another as the channels traverse the various NEs. As the channels are passed
from one chain to the next, changes in optical power levels are passed along as
well. This is illustrated in the following figure.

Figure 2-15: PELES for mesh topology

soll.
soll.



In this chapter:
Overview ......................................................................................................... 3-1
Creating NEs and PEs ...................................................................................... 3-2
NE and Card Configuration ............................................................................. 3-8
NE Timing and Synchronization ................................................................... 3-13
Automatic Discovery Functions .................................................................... 3-16
Configuring Gateway Protection ................................................................... 3-16
Downloading/Uploading NE Software .......................................................... 3-17
Unmanaged Elements .................................................................................... 3-18
DCC Cross Connections ................................................................................ 3-20
OSPF .............................................................................................................. 3-21
IS-IS ............................................................................................................... 3-22
BFD Protocol Support in STMS .................................................................... 3-22
Overview
LightSoft enables you to initialize and update the configuration of networks
and network equipment simply and efficiently. You can create and define NEs
which are then displayed on the screen as icons. After setup, you are kept
informed of the actual configuration of all NEs in the network.
Configurable objects include:
Physical objects, such as NEs and cards. When working with MPLS
networks, similar functionality is provided for network PEs.
Transmission objects, such as Termination Points (TPs), Termination Units
(TUs), and Virtual Containers (VCs).
Timing-related objects, such as timing sources.
3
NE Configuration
soll.
soll.


Creating NEs and PEs
LightSoft enables you to perform operations that define and configure the
network topology, including:
Adding an NE
Connecting two NEs
Deleting NEs
Inserting external equipment into the topology
When new NEs are created at the physical layer, LightSoft automatically
creates a primary LE for the ports at each technology layer based on the ME
represented by the NE. Similar functionality is provided for PEs in MPLS
networks. See Network Elements, Logical Elements, and Managed Elements
(on page 2-8).
EMS-XDM and EMS-BGF support batch NE setup using XML files. The
XML files include the information necessary for NE creation and slot
assignment. XML files can be used to interface with a site planning tool,
making NE setup faster and simpler. This is especially helpful with new
networks or extensive network expansions. NE creation and slot assignment
operations can be run overnight as batch files.
NE creation can be coordinated with an external planning tool. Use the tool to
build a configuration and import it into the EMS. The necessary NEs, modules,
and slots assignments are configured automatically. This is useful when
designing new network configurations, since you can rely on the tool to handle
the planning details.
The reverse is also true. Components that are defined in the EMS can be
exported to the planning tool. The tool can then configure a new layer on top of
an existing configuration. This is useful when adding an additional level of
services on top of an existing network. Export the current network
configuration into the planning tool and use the tool to configure the
components necessary to support the new network layer. The new
configuration can then be imported back into the EMS to complete the new
network configuration process.
Once an NE is created at the EMS level, the relevant EMS updates LightSoft so
that data about the new NE (e.g., ports) can be uploaded into the database.
Configuration changes are tracked and you are notified in real-time via an
alarm/event. This results in the system always being up to date.
soll.
soll.


NE/PE Insertion and Removal
An ME or UME is automatically inserted into an existing SDH/SONET link by
the Insert NE feature and into an existing MPLS tunnel by the Insert PE
feature. (An inserted UME can be useful for maintaining accurate network
topology.)
New links are created, trails or tunnels on the new link are properly configured,
and the old link is deleted. If the inserted object is an ME, the relevant XC
changes are downloaded to the actual NE or PE via its EMS. The procedure
automatically creates new links, configures the trails/tunnels on the new link,
and deletes the old link. There is no need to manually delete or edit trails or
tunnels.
This automatically performed features saves time and eliminates the possibility
of human errors.

Figure 3-1: Automatic PE insertion on MPLS network
Similarly, you can seamlessly disconnect an ME from a topology link, either in
preparation for its insertion in some other link or its removal from the network.
All trails/tunnels traversing the element are automatically redefined as direct
trails/tunnels linking the two adjacent nodes.
soll.
soll.


Moving NEs between EMSs
NEs (individually or in a group) can be moved between EMSs operating under
the same NMS. Simply select one or more NEs to move from the source EMS
to the target EMS.

Figure 3-2: Move NE window
NEs are usually moved in one of the following contexts:
NEs are moved between EMSs of the same version to enhance network
efficiency and management. By simplifying NE movement, LightSoft
enables operators to reorganize NEs for optimal arrangement as network
requirements change over time. Different network configurations may
motivate different movement strategies. For example:
NEs that were originally scattered between many different EMSs can
be consolidated into a single EMS to simplify group management.
NEs that were originally all based on a single EMS can be divided
between multiple EMSs to enable better load balancing.
NEs can be organized under each EMS by logical categories or
geographic location.
NEs are moved from one EMS to another EMS of a later version as part of
an NE upgrade. With this approach, there is no need to stop EMS
functioning during the upgrade procedure. Other NEs under the same EMS
are not affected when a group of NEs is upgraded; NEs in the original EMS
and in the new EMS both continue operation as usual.
soll.
soll.


Setting IP Routing for an NE
EMSs send datagrams (or data packets) to SDH/SONET NEs via TCP/IP,
which allows them to be routed over separate LANs. LightSoft supports
user-defined IP routing, defining how these datagrams are routed between the
LANs.
The NE Routing Table defines an NE's destination subnets on the IP network,
and enables system configurations when an NE is used to route datagrams to
other LAN segments (called a Gateway NE (GNE)). The following figure
illustrates adding a new route through the EMS-XDM.

Figure 3-3: Adding new route for XDM window
soll.
soll.


Commissioning 9600/9700 Routers Using
the Commissioning Tool
STMS provides a commissioning tool (CT) that simplifies initial configuration
of core-facing interfaces, routing protocols, and signaling protocols on
9600/9700 CESR platforms. For both newly discovered and existing NEs,
operators can use CT to:
Configure routing and signaling protocols.
Configure OSPF and IS-IS areas and interfaces.
Configure Router IDs and loopback addresses.
Create core interface LAGs if needed.
Select and configure NNI ports.
Create RSVP LSPs between all newly-commissioned elements as well as
any known 9600/9700 elements previously commissioned. You may create
a mesh of bidirectional LSPs between all routers or specific LSPs if
desired.
Single Persistent Session
When CT is launched, a persistent configuration session is created. All
transient information captured using CT is saved while navigating to the next
screen. A persistent session gives users the ability to start where they left off. If
a previously created session exists, then the user has the option to continue with
the previous session, or to delete it and create a new session.
Wizard-like Screens
CT uses a wizard driven approach to take the user from NE selection to
commissioning. Next and Back buttons can be used for forward and backward
navigation. Forward navigation is allowed only if the present screen passes
validation. The user is forced to correct all validation errors before the current
screen information is saved to the session. Note that new information entered
on a screen may be lost if the user navigates back. Tables in the screens can be
sorted or filtered by column values.
Core-Facing Interface Configuration
Using the CT, a user may easily configure all relevant information on core
interfaces or LAGs with one simple screen.
soll.
soll.


Routing and Signaling
CT enables easy set up of key routing and signaling information. A user may
configure a new OSPF or IS-IS area, which is then assigned to all routers in the
commissioning session. Additional information is automatically configured
based on commissioning choices, including all BFD, loopback, MPLS
protocol, and router ID configurations.
Failure Control
CT only configures those routers which can be configured successfully.
Routers which could not be configured successfully are kept in the
commissioning session, while the routers that were configured successfully are
removed.
The session can be maintained until all routers have been successfully
configured. Users may also choose to Force or Skip a commissioning session,
for example, when reconfiguring an existing router. STMS clears the
configuration of interfaces, routing, and signaling information, while leaving
the other configuration areas (such as CoS or system sections) intact.
Scalable
CT makes configuration of larger numbers of new routers easy and scalable.
After configuring the general routing and signaling information once during the
session, a user may apply that configuration information to tens of routers
simultaneously, making the process of bringing new elements online far
simpler than with pure GUI or CLI configuration sessions.
NE Credentials Tool in STMS
The numbers of 9200-series devices is typically far greater than the number of
9700-series devices in a typical network configuration. ECI Telecom has
therefore introduced the concept of an NE Profile, designed to simplify
management of SNMP credentials. The NE Profile addresses the need for
configuring SNMP read/write string associations with the 9200-series devices,
and mapping those devices within STMS so that the correct SNMP string is
used when attempting communication. NE Profiles are configured with the
following information:
CLI admin password (used to initially access a device and configure the
required SNMP information)
Enable password
SNMP read string
SNMP write string
Various timeout settings
soll.
soll.


This information is saved as an NE Profile. The user may map this profile to a
range of IP addresses and apply the profile to that range. STMS then attempts
to connect to each IP address in the stated range, log in to the device, set
approximately 15 lines of CLI configuration involving SNMP, and commit that
information to the device. Once the NE Profile is applied to the device, the
device is ready to be discovered.
NE Profile also handles the following scenarios:
Changing a device's SNMP information (e.g., the read string) is easier
through the NE Profile mechanism as it supports refreshing the IP address
range rather than forcing the user to configure each device individually.
Rescanning a range of IP addresses while omitting any already-discovered
IP addresses (i.e., finding new devices in a range of addresses without
touching the currently-discovered addresses).
Rescanning already-discovered devices that may have been modified and
are no longer reachable by the configured SNMP string (i.e., fixing
configurations that are out of sync with the correct SNMP information).
NE Profile capabilities add value to the user by making it very easy to manage
hundreds of devices SNMP configuration with a single utility.
NE and Card Configuration
You can perform a wide range of configuration functions on your network
NEs, including the attributes of the NE itself, its timing source, the cards
installed (if any), and the internal attributes of both SDH/SONET and optical
cards. Most of these functions are invoked using cut-through functionality,
giving LightSoft both the breadth of an NMS and the depth of multiple EMSs.
You can view either the actual installed card configuration of a shelf or the
types of cards the system expects to find in each slot. You can assign and
unassign cards, and reset a card that is not functioning properly.
soll.
soll.


Use GCT to view the Shelf View of each NE in the LightSoft main window.
The Shelf View shows the cards installed in the NE shelf, together with
relevant information such as alarm status.

Figure 3-4: Chassis view for SR9705
soll.
soll.


The following figure portrays a typical Slot Assignment dialog in the
EMS-BGF.

Figure 3-5: EMS-BGF slot assignment
NE Attributes
You can manage NE attributes, including:
NE type, name, and ID
System location
IP address
Gateway (GW) mode and address
Subnet mask address
Operational state
Data Communications Channel (DCC) subnet address
Holdoff time
Wait to Switch interval
soll.
soll.


The following figure illustrates configuring NE attributes through the
EMS-BGF.

Figure 3-6: NE attribute configuration
Card Configuration Functions
Card configuration functions include the following:
Assignment and configuration: Assignment informs the equipment and
the management system to expect a certain card in a certain slot.
Configuration informs the equipment what the card will do. These
functions can be done manually and automatically:
Manual: You can assign a card manually before installing it. Inserting
the card causes the system to automatically recognize it.
You can also fully or partially provision a card (for example, define
XCs) prior to installation. When the card is installed, any configuration
settings are automatically downloaded.
Automatic: When the card is inserted into a managed NE, the system
can be set to automatically perform card assignment as a background
task according to user-defined tables.
This can be done globally (for the whole network) or for selected NEs.
soll.
soll.


Reassignment: You can reassign a higher capacity card of the same type to
a slot that already has a card assigned. Any XCs provisioned on the old
card are automatically transferred to the new. This process is
non-traffic-affecting.
Batch card assignment: Card assignments can be performed in batch
form. See XML Interfaces (on page 10-6).
Internal Attributes
You can quickly and easily drill down from the shelf view of any NE to the
internal attributes of cards and the objects showing transmission information.
All internal attribute windows display card objects and details of internal
transmission objects.
From the card level, you can drill down further to the object level, such as ports
contained on a card. The types of objects available depend on the type of card.
Where relevant, attributes of objects can be modified (e.g., configuring the
Automatic Laser Shutdown attribute for optical cards).
The following figure illustrates an EMS-BGF internal attribute window.

Figure 3-7: EMS-BGF internal attributes configuration
soll.
soll.


NE Timing and Synchronization
All NEs in the network must be synchronized in order to pass error-free digital
signals among them. Synchronous timing configuration enables an NE to
automatically select and be synchronized with the highest-quality clock source
in the network.
Synchronization is achieved by frequency-locking the multiplexer timing
generator to a signal from a primary reference timing source. The remaining
NEs are then synchronized by the incoming line signal.
Timing configuration and calibration are performed at the system operator
level. For example, the EMS-BGF utilizes a Synchronous Timing table for
each NE. The table specifies the quality and availability of the external
references and enables you to select NE references and customize their
attributes.
Each clock reference has multiple attributes, including the reference ID,
physical location, clock frequency, synchronous status S1 type value, S1
user-defined attributes, priority, availability status, and application status.
Using these attributes, you can identify a reference, specify its quality level,
monitor its availability status, and control its application. The following figure
illustrates synchronous timing configuration in the EMS-BGF.

Figure 3-8: EMS-BGF synchronous timing configuration
soll.
soll.


In XDM NEs, each NE has two TMUs (Timing Units) configured respectively
as active and standby. In SYNCOM NEs, each NE can contain up to two
Timing Generator (TG) sources in a dual-ring configuration with a "hot"
backup mechanism between the two. In SDM-1 NEs, each NE contains a
single TG source.
The following figure illustrates timing configuration in the EMS-XDM.

Figure 3-9: XDM Timing Configuration window
soll.
soll.


NE Timing Sources
The timing sources for each NE are configured via the respective EMS. You
can monitor the network's timing topology using a color-coded Timing Map
window.

Figure 3-10: Timing Map window
Specific Timing Source
LightSoft enables you to manually select (force) a specific timing source
different from that selected by the system. You do this from the EMS or via
GCT from LightSoft.
soll.
soll.


Automatic Discovery Functions
LightSoft provides a range of automatic object and link discovery functions:
Automatic NE recognition: As soon as it is connected an NE is
automatically recognized and immediately appears on the LightSoft screen.
Automatic topology link discovery: This feature is based on applicable
ITU-T recommendations. When activated, bidirectional ASON-enabled
SDH links are automatically identified by the EMS and, as well as optical
links managed through the FuN application (FuN Topology Map (on page
2-18)), can be uploaded to the NMS using the Send Links command of the
EMS XDM. Link data is uploaded to the NMS layer via the MTNM
interface. LightSoft automatically displays such links.
Additional discovery mechanisms are available at the EMS application level.
For example, with the EMS-XDM you can assign cards automatically and
manually, as described in Card Configuration Functions (on page 3-11).
STMS provides multiple element discovery mechanisms:
A command line utility that uploads NEs listed in an appropriately
formatted data file.
A comparable GUI function that uploads NEs from the data file with a
single click on the Discover IP Range by File command.
Using the GUI, the user may enter an IP address range and a particular
model type (e.g., 9700 series) and STMS attempts to discover all 9700
elements within that range.
Configuring Gateway Protection
In a typical configuration, the EMSs are connected to a GNE providing routing
to the DCC subnet. Communication between LightSoft and the GNE is via the
DCC.
A redundant GNE can be configured to act as a secondary channel in case of
primary GNE or communication failure. The protection mechanism works in
one of two ways:
The EMS pings the primary GNE periodically to verify that it is
functioning properly. If no response is received, it switches to the alternate
route via the secondary GNE.
The EMS pings a predetermined NE checkpoint to verify that it is receiving
management information. If the ping request is not received, the EMS
switches to the alternate route via the secondary GNE.
soll.
soll.


The Ping function initiates a signal from the EMS to a selected NE. By
comparing the signal sent with the signal received in return, LightSoft can
evaluate the quality of its network connection to that NE.
Downloading/Uploading NE
Software
NE software resides in the nonvolatile memory (NVM) of an NE's main
processing card. The following figure displays the STMS Software
Management window, in which you can download and update the software of
one or more NEs. You can also upload device configurations from the NE
NVM to its respective EMS for backup purposes.

Figure 3-11: STMS software code report
Using the Software Code Report, you can audit the existing installed base to
determine which systems are running what code. You can also audit for
specific code version compliance, as illustrated in the following figure.

Figure 3-12: STMS software audit
soll.
soll.


The Audit function allows you to specify a SW version. The system highlights
those elements not running the specified version.
STMS supports device snapshots, a valuable backup facility for operators. ECI
Telecom Technical Assistance Center (TAC) recommends that users take a
snapshot of their system before upgrading or downgrading software. The
snapshot can then be used for backup and restore purposes. A typical snapshot
copies the complete partition of information stored on the main file system
(system software as well as configuration settings) to a special /SNAP directory
on the device.
Unmanaged Elements
You can create UMEs representing external equipment which is part of the
network but not managed by an EMS.
UMEs may represent:
Client equipment that acts as a connection to the LightSoft managed
network.
An element or subnetwork that is not integrated with LightSoft and
therefore is unrecognized.
Passive network equipment like multiplexers or splitters (usually part of
optical networks). To see the true topology of the network, you need to
represent them with UMEs.
Trails may pass through UMEs. This is particularly useful for:
A multivendor SDH/SONET network with non-ECI NEs interleaved in the
topology that may represent UMEs.
A network with optical sections from which optical trails are acquired. If
LightSoft is not aware of an ME that acts as an endpoint to an optical trail,
the trail is only partially created. In this case, a UME can be created to
represent the endpoint.
Create a UME by selecting and configuring a template to match your
requirements. LightSoft provides templates for attributes like name, icon, ports
of different rates, and traffic flow pattern (connection between two ports).
soll.
soll.


Each template includes a description of the NE connections for that specific
template type.

Figure 3-13: UME Image window
You can create a UME in any topology layer. You can create multiple UMEs
with the same configuration at the same time, and modify the duplicate
configurations later as required.
Telnet Option for UMEs
Accessing a UME from LightSoft enables you to manage all the devices seen
in the topology. Right-click the UME and select Telnet UME. You connect
directly to the device without switching to a different application or UNIX
station. Access Telnet by typing the IP address in the UME properties.
soll.
soll.


DCC Cross Connections
The DCC allows you to manage the SDH/SONET network through a
communications channel embedded in the SDH/SONET overhead bytes. The
DCC can be assigned to RS or MS objects. Using the XC subsystem, you can
create DCC XCs that specify how the management channel is routed via the
NE.
External DCC XCs allow you to use RS and MS objects in the SIO cards
containing external DCC bytes to implement the transparent DCC feature. The
XDM network transparently routes the management channel of an external
vendor, independent of the payload routing.
The following figure shows BG-40 configuration via the DCC Settings tab.

Figure 3-14: DCC configuration
soll.
soll.


OSPF
EMS applications support DCC functionality with dynamic OSPF routing over
network interfaces to automatically determine the routing table. OSPF support
includes PPP encapsulation of IP packets with HDLC framing over RS-DCC,
MS-DCC, and "Clear Channel" communication channels as defined in ITU
G.7712. Support is also provided for legacy LAN emulation encapsulation,
with full software configurability between all communication modes.
The EMS-XDM can work with combined XDM and legacy equipment
implementing several different DCN methods, including:
DCC with LAN Emulation
DCC with OSPF
Ethernet mode OSPF
DCN OSPF (towards the XDM GWs)
ECI Telecom platforms smoothly integrate multiple DCN modes. A single
platform can function in different DCN modes with different network
components, as described in Network Communication Control.
The following figure portrays the OSPF tab of the IP Networking window in
the EMS-BGF.

Figure 3-15: OSPF configuration
soll.
soll.


IS-IS
STMS supports Intermediate System to Intermediate System (IS-IS) protocol
usage. Protocol settings can be defined globally or configured per interface.
IS-IS is an interior gateway protocol (IGP) that uses link state information to
determine the availability of routes. IS-IS uses an SPF algorithm, such as
Dijkstras, to compute the best path. The International Organization for
Standards (ISO) developed IS-IS as part of the Open Systems Interconnection
(OSI) protocol suite. Other protocols in the suite include End
System-to-Intermediate System (ES-IS) protocol and Interdomain Routing
Protocol (IDRP). The ISO originally developed IS-IS to route data in an ISO
Connectionless Network Protocol (CLNP) network, but a version was
developed that supports both CLNP and IP networks. This version of IS-IS is
referred to as Dual IS-IS or Integrated IS-IS. The 9600/9700 platforms use
Integrated IS-IS.
NOTE: IS-IS is not currently supported in the Commissioning Tool.
BFD Protocol Support in STMS
Bidirectional Forwarding Detection (BFD) is a simple Hello protocol used to
verify connectivity between systems. BFD can be used by the following
protocols in STMS:
IS-IS
OSPF
RSVP
Properties can be configured globally for all BFD sessions. Global
configuration settings can be explicitly overridden at the interface, interface
family, or neighbor level.
soll.
soll.


BFD is configured in STMS using the Network Explorer tab, opening the
Switch Router icon and then opening the Protocols folder, as shown in the
following figure.

Figure 3-16: BFD configuration

soll.
soll.



In this chapter:
Overview ......................................................................................................... 4-1
Active Alarm Notification ............................................................................... 4-2
Alarm and Event Filters ................................................................................... 4-7
Bidirectional Drill-Down ................................................................................. 4-9
CFM Alarms .................................................................................................. 4-10
Alarm Correlation .......................................................................................... 4-11
Alarm and Event Logs ................................................................................... 4-13
Exporting and Forwarding Alarms ................................................................ 4-14
Suggested Corrective Actions ....................................................................... 4-17
Alarm Management at the EMS Level .......................................................... 4-17
Overview
Fault management is a crucial part of LightSoft, allowing administrators to
monitor network and element alarms in real time. LightSoft's powerful ability
to detect, display, and analyze alarms and control system faults enables
uninterrupted system functioning.
Alarms for each NE are included, regardless of layer (physical, SDH/SONET,
ASON, Ethernet/MPLS, or optical). Fault management features include:
Detection of all types of alarms
Alarm correlation enabling intelligent root cause analysis
Bidirectional drill-down capabilities:
Identifying affected services, tunnels, and trails
Identifying active alarms connected to a specific service, tunnel, or trail
Automatic alarm forwarding to email, SMS, or FTP
Suggestions for corrective actions
4
Fault Management
soll.
soll.


Numerous indicator types and alerts
User notes
Ability to filter and sift through numerous alarms with configurable filter
settings
User-definable alarm severity levels
Easy-to-use GUI
Complete logging of all alarms and events
Alarm acknowledgment capability
Customizable counters, audio signals, and pop-ups
Alarm listings, counters, and audio and visual indicators are displayed in the
main window in real time as color-coded icons. You can acknowledge alarms
from the Current Alarms list, post "sticky note"-type messages (User Notes) to
other personnel, and customize your own alarm filters. Click any element in the
network to open status windows listing the alarms for each object, including
NEs, cards, and physical ports.
Active Alarm Notification
The Current Alarms window lists the current alarms by object with probable
cause and timestamp. Alarms from all the NEs managed by LightSoft are
shown.

Figure 4-1: Current Alarms window
To see alarms of specific objects or links, select them in the LightSoft main
window map and open the Current Alarms window. Similarly, first select
trails in the Trail List window to show specific trail alarms in the Current
Alarms window.
soll.
soll.


Alarm details are shown in separate rows. You can customize and sort the
window columns.
An affected trail, tunnel, or service is indicated in the appropriate column
(Affected Trails, Affected Tunnels, and/or Affected Services). If more than
one is affected, Multiple appears. Details are displayed in a Trail List, Tunnel
List, and/or Services List window.
You can acknowledge an alarm that appears in the Current Alarms window.
You can view details of the alarm's source by opening the appropriate view
(depends on type of affected object), or an Information window. After the
problem has been resolved, the alarm is cleared from the window.
Alarm Severity Levels
LightSoft offers great flexibility in alarm and fault management. You can set a
fault's severity level in the Alarm Severity window. The severity level affects
all alarm indicators. You can assign severity levels and/or completely mask or
inhibit individual alarm parameters in specific NEs.
You can define the severity of each potential fault condition in an NE.
Depending on the NE type, you can set all the alarm severity definitions for an
object and then propagate those definitions to other objects in the same NE, or
you can define alarm severity profiles for an NE and propagate those profiles to
other NEs.

Figure 4-2: Defining Alarm Severity profiles
soll.
soll.


The EMS-BGF offers an additional level of alarm filtering. Operators can
configure which severity level is reported up to the NMS and listed in the
Current Alarms window.

Figure 4-3: EMS-BGF alarm filtering options
Visual and Audible Alarm Indicators
You can customize automatic behavior of visual and audible indicators on
receipt of an alarm. For example, you may need to track specific alarms that
must be dealt with differently from other alarm types. A counter on the
LightSoft main window is easily seen when an alarm of this type comes up.
Alarm indicators and counters are multilayered: the appropriate alarm is
shown/heard for each layer (physical, SDH/SONET, Ethernet/MPLS, and
optical). Filtered alarms and events can be counted or notified by sounds or
pop-up windows:
Alarm counters: Display the number of alarms or threshold-crossing alerts
that meet specified criteria either predefined (Critical and Major, Minor
and Warning, or Disconnected MEs) or user-defined special-purpose in
the Counter bar on the LightSoft main window toolbar. The color of alarm
counters can be customized.

Figure 4-4: Alarm counter bar
soll.
soll.


You can share any counter you create with other users in your own user
group or with all users. You can access counters to which you are entitled
from any workstation. Double-clicking any counter opens the Current
Alarms window filtered with that counter's alarms.
Alarm audio notifications: WAV sound files identify specific alarm types.
You can also set a reminder beep at a preset time interval to notify of
unacknowledged alarms in the system.
Alarm visual notifications: Pop-up windows notify of specific alarm
types. This feature is useful for tracking occurrences of certain (or all)
alarms while you are away from the console.

Figure 4-5: Alarm Indicator window
Visual indicators include:
Color of the NE/LE icon
Color of the link
Color of the NE/LE in the Navigator
Color of the NE/LE in the Inventory tree
Alarm counters for each severity level in the LightSoft main window
The color of the group throughout the user interface is based on the
aggregated status of all NEs and groups contained within the group.
soll.
soll.


You can customize the colors for different alarm severities (Critical, Major,
etc.) in the Fault Management Preferences dialog box. These colors are
reflected in all relevant LightSoft windows and indicate the most sever fault
condition involving the object. You can select different colors for
acknowledged and unacknowledged alarms, making it easy to identify new
alarms.

Figure 4-6: Customizable alarm colors
soll.
soll.


User Notes
User notes are comments that are attached to alarm or event notifications, for
example, to inform other users. More than one user note can be attached to a
single notification, and a single note can be attached to more than one
notification.

Figure 4-7: Alarms window with user note
Alarm and Event Filters
A strong filter mechanism is crucial for large networks that may have many
different transmission layers. LightSoft provides tools that allow you to sift
through alarms in the Current Alarms and Alarms Log windows quickly and
easily.
Specific alarms can be counted or notified by sounds or pop-ups. Filters can
have a name and description and be saved for use. Predefined filters can show
only specific alarm notifications (e.g., only critical or major, only
equipment-related, only unacknowledged, etc.).
Available filter criteria include:
Time: Alarms that occurred between particular dates or during a predefined
number of hours/days.
Severity: Alarms that meet a specific severity level.
Event: Alarms related to certain types of events (exceeded threshold,
deleted object, etc.).
Equipment: Only equipment-related alarms.
Optical: Only optical-related alarms.
soll.
soll.


SDH/SONET: Only SDH/SONET-related alarms.
Unacknowledged: Only notifications not yet acknowledged.
User-defined: Filters tailored to specific requirements, which can be
created from scratch or from a predefined or existing filter.
The following figures show LightSoft's filter selection dropdown list and some
filter criteria.

Figure 4-8: Filter Selection dropdown list

Figure 4-9: Filter criteria in Filter panel
The filters you create can be private or shared with other users, as follows:
Public: Accessible to all users.
User Group: Accessible only to members of the same user group.
Private: Accessible only to the user who created it.
You can access filters from any workstation. Access privileges depend on
security settings.
soll.
soll.


Bidirectional Drill-Down
LightSoft provides several drill-down perspectives. You can focus on specific
alarm data, drilling down from the NMS level to the EMS level. You can also
focus on an alarm context, drilling down from the alarm to the affected
services, trails, or tunnels. You can check in the opposite direction, beginning
with a specific service, trail, or tunnel and drilling down to see which currently
active alarms affect them.
Drilling down from an alarm to the affected services, tunnels, or trails is a
powerful cross-technology tool, immediately informing you how, for example,
an Ethernet service or MPLS tunnel is affected by an underlying SDH/SONET
trail alarm. The following figure illustrates this.

Figure 4-10: Drilling down from alarms to services
Drilling down in the opposite direction (from services/tunnels/trails to alarms)
is another powerful cross-technology tool. This immediately highlights, for
example, what alarms require immediate attention due t o their impact on a
high-priority service. The following figure illustrates this.

Figure 4-11: Drilling down from services to alarms
soll.
soll.


The following figure illustrates the advantages of fault management that
includes drilling down from the LightSoft NMS level to different EMS
applications. In this figure, alarms were triggered in the STMS.

Figure 4-12: LightSoft drilldown to STMS alarms
CFM Alarms
LightSoft alarms include connectivity loss alarms triggered by built-in
Connectivity Fault Management (CFM (on page 5-32)) capabilities for
Ethernet services. CFM implementation is based on IEEE standard 802.1ag.
With CFM, you can view connectivity loss alarms in the current alarms
window and use Show Affected Services to indicate affected services.

Figure 4-13: Connectivity loss alarm list
soll.
soll.


Alarm Correlation
LightSoft offers an alarm correlation add-on for the SDH/SONET layer that
automatically identifies the root cause of a fault. Alarm Correlation is a
powerful tool. By correlating primary and secondary alarms, you can quickly
pinpoint the fault and fix or bypass it, so ensuring quick resolution with
minimal service downtime and significantly improved QoS.
In some NEs, a specific alarm can cause a chain of correlated alarms. For
example, a Loss of Data (LOD) alarm on an Optical Physical Section (OPS)
object can cause alarms on related GEoS ports. The alarm correlation feature
saves OPEX by decreasing clutter in fault management windows.
When a group of alarms is triggered, the alarm correlation function considers
all alarms and attempts to find their real root cause. It assigns the category of
secondary alarm to those with common root causes, referred to as single
parent primary alarms. For example, a Loss of Signal (LOS) alarm at an
object may set off an Alarm Indication Signal (AIS) alarm on a downstream
transmission object. In this case, the LOS alarm is the root cause (parent alarm)
referred to as the primary alarm, and the resulting AIS alarm is the secondary
alarm.
By classifying the alarms and displaying only the primary alarms in the
Current Alarms window, LightSoft enables you to focus on the initial cause
of the fault without having to sort through the secondary alarms as well. This
improves efficiency, speeds up response time, and provides significant OPEX
savings.
soll.
soll.


In addition to evaluating and classifying primary and secondary alarms,
LightSoft intelligently detects and displays link or duct failure alarms where
appropriate:
Link failure - multiple LOS alarms involving both link endpoints,
suggesting a fiber cut.
Duct failure - same link failure alarm on all the links associated with a duct.
The following figure illustrates how the number of displayed alarms can be
reduced using alarm correlation.

Figure 4-14: Reducing the number of alarms displayed by using Alarm Correlation
soll.
soll.


Alarm and Event Logs
The Alarm and Event Logs display thousands of recent network alarms and
events.

Figure 4-15: Event Log History window
LightSoft periodically exports the contents of Event logs in ASCII format to
disk as backup records. You can configure historical log records to your
requirements:
Set the maximum number and age of records for viewing in the Event Log
window (kept in the active Event Log database).
Specify when to export excess/older records from the active database to
XML files for storage. Additional exports of excess records can be
triggered manually.
Delete older history files from a specified path, according to a schedule
and/or manually. Deleted files are no longer accessible from the Event Log
History window.
soll.
soll.


Figure 4-16: Event Log Configuration window
Exporting and Forwarding
Alarms
In today's competitive environment of cutbacks, SPs look to integrate most of
their equipment as transparently as possible into their existing OSS structure.
As shown by several implementations with leading OSS suppliers, LightSoft's
open interfaces and useful Alarm Forwarder feature enable the seamless export
and/or correlation of alarms with external systems. Managers receive critical
alarms via email, SMS, or FTP directly to their PC, PDA, or cell phone. The
alarm level and communications method is user-configurable.

Figure 4-17: Alarm notification options
soll.
soll.


LightSoft's alarm notification options include:
Real-time alarm notification to OSS using CORBA-MTNM and/or
MTOSI and/or SNMP: ECI Telecom's suite of management products uses
the northbound CORBA-MTNM, MTOSI, and/or SNMP interfaces for
real-time alarm notification. The LightSoft SNMP GW application supports
both SNMP V2c and V3. Alarms may be sent to either an upper-level
management system or to an external alarm collection system.
SNMP alarms can be filtered by NE, equipment, severity, and probable
cause. Alarm-related events are forwarded in a clear textual format with all
the information necessary to understand and handle the alarm.
Alarm export via FTP: Network-wide current alarms can be exported to
remote FTP servers, providing a seamless interface with external fault
monitoring systems.
The export uses an ASCII format compatible with alarm export
applications of legacy EMS systems.
At periodic intervals, alarm details are automatically exported to target
files at one or more FTP remote host systems. The file contents include
regular alarm notifications as well as "Clear" indications on reported
alarms (not normally visible in the Current Alarms window).
Periodic back up or "snapshot" of all notifications in the Current
Alarms window. Snapshot exports are useful for redundancy and data
consistency. For example, users can resynchronize the remote database
with the present alarm situation in the network.
Real-time sampling: The EMS-XDM and EMS-BGF offer a real-time
alarm sampling capability. This feature is useful in multivendor
environments with common alarm collection systems. Alarms are
continuously written to an ASCII file, which may then be sampled by an
external fault management system. The file is restarted every day at
midnight.
Alarm notifications by SMS and email: Email or text messages to
operators' PCs, cell phones, and PDAs. SMS messages are sent via
email-to-SMS or HTTP-to-SMS GWs. Messaging services are especially
useful if there is no network operations center (NOC) manned 24 hours a
day.
soll.
soll.


The system can be programmed with fine granularity. You can configure
exactly which alarms are reported per user, which notifications should be
sent by email, which by SMS, and how alarms should be filtered. Messages
can be sent per alarm, or as a statistical summary of the total number of
alarms received (according to a number-of-alarms threshold). Separate
thresholds can be set for SMS or email purposes. The Alarm Forwarder can
be configured to send only primary alarm notifications, significantly
reducing the number of alarms that need to be handled by the remote user.
A log of the messages sent is available for reference. The following figure
illustrates a typical set of SMS alarm message filter options.

Figure 4-18: SMS alarm message filter
soll.
soll.


Suggested Corrective Actions
Right-click an alarm in a fault management window or the associated info
dialog box to show a description of the problem and the recommended
corrective action. The Suggested Corrective Actions window is accessed for
one notification at a time. Dialog boxes accessed consecutively can be left open
for easy reference.

Figure 4-19: Suggested Corrective Actions window
Alarm Management at the EMS
Level
The EMSs provide exceptionally powerful tools for viewing and analyzing
alarms. You can access the following types of alarms:
Equipment
Communication
Service quality
Processing error
Environment
Current alarms are displayed in the Current Alarms windows of the various
EMS applications. Alarm logs, network-wide alarm counters, and color-coding
make it easy and quick to view current and past alarms.
soll.
soll.


Current alarms are represented in the EMS window as LEDs on an NE icon.
The color of the LED corresponds to the most severe alarm affecting the NE.
Alarms can be viewed per NE, per card, or per object. The following figure
illustrates a Current Alarms window for an NE in the EMS-BGF.

Figure 4-20: EMS-BGF current alarms window
Point-and-click drill-down options enable you to identify and resolve problems
rapidly. Unlike systems that simply display a running list of alarms, EMSs can
be configured to automatically remove resolved conditions, keeping operators
focused on open items. Intelligent fault aggregation correlates logical alarms,
preventing a single physical interface that supports hundreds or thousands of
logical interfaces from triggering the type of event storms that occur in less
sophisticated systems. Alarm management functions include filtering, sorting,
severity assignment, printing, and exporting via FTP.
Through the various EMSs, you can assign severity levels to individual alarm
parameters in specific NEs. This means that remote NEs can screen out
low-level alarms, while you use LightSoft to analyze prefiltered and sorted
daily alarm logs.


In this chapter:
Overview ......................................................................................................... 5-1
SDH/SONET Trails ......................................................................................... 5-2
ASON Network Management........................................................................ 5-10
DWDM Trails ................................................................................................ 5-16
Ethernet Services ........................................................................................... 5-25
MPLS Tunnels over MoT or MoE ................................................................ 5-45
NMS/EMS Synchronization .......................................................................... 5-53
Importing Traffic Configuration Files ........................................................... 5-54
Overview
One of LightSoft's most important functions is creating, deleting, and
modifying LightSoft SDH/SONET and ASON trails, MPLS tunnels, and
carrier Ethernet and DWDM optical services for optimal utilization of available
resources. LightSoft supports E2E MPLS-TP service and tunnel creation and
acquisition for BroadGate, CESR, and XDM family platforms. Trails, tunnels,
and services can be built automatically based on user-defined endpoints and
segments, or manually, with full resource control down to the tributary unit
level.
LightSoft offers a suite of advanced service configuration tools. The Explicit
Route tool is used to create services manually and the Pathfinder tool to create
them automatically. Via its advanced patent-pending route selection algorithm,
Pathfinder automatically searches for and selects optimal E2E primary and
protection paths across complex topologies. Depending on the context, you can
specify optimization criteria such as cost, number of nodes, link quality,
distance, shared risk (common ducts), and so on.
5
Trail, Tunnel, and Service
Provisioning and Management
soll.
soll.


A powerful synchronization function polls the entire network, keeping the
LightSoft topology model up to date. The system also provides full traffic
restoration via contingency traffic plans. Through LightSoft's powerful
traffic-configuration tools, a detailed definition of trails, tunnels, services, and
XCs gives administrators precise control of the system's structure, guaranteeing
uninterrupted services and maximized use of bandwidth.
The EMSs in the network constantly update LightSoft, keeping its network
resource usage model up to date. LightSoft provides numerous protection and
traffic reconfiguration schemes, ensuring full traffic restoration in case of
service disruption.
SDH/SONET Trails
The XDM is equipped with a high-capacity nonblocking matrix that supports
HO and LO connectivity, eliminating bottlenecks and reducing the number of
NEs. This matrix simplifies the network, eases operation, increases reliability,
and reduces OPEX. Consequently, it enables you to build an extremely flexible
and transparent optical network.
LightSoft supports both virtual and contiguous concatenation for the transport
and cross connection of VC-4 signals. This is used for high-bitrate Ethernet
services that require transport of payloads exceeding a single VC-4 capacity.
Concatenation associates multiple VC/STSs together, resulting in a combined
capacity that can be used as a single container across which bit sequence
integrity is maintained.
Highly sensitive data networks can rely on LightSofts link protection
capabilities supporting a variety of schemes, including MSP/APS 1+1,
MS-SPRing/BLSR, and several advanced bridge protection options.
The following bitrates are supported:
E1
E3 (34 Mbps)
DS-3 (45 Mbps)
STS-1 (52 Mbps)
STM-1/OC-3 electrical interface (155 Mbps); STM-1/OC-3 optical
interface (155 Mbps)
STM-4/OC-12 (622 Mbps); STM-4c/OC-12c
STM-16/OC-48 (2.5 Gbps); STM-16c/OC-48c
STM-64/OC-192 (10 Gbps); STM-64c/OC-192c
EoS and MoT trails are created as VC-4-X, VC-3-X, VC-12-X, STS-3c-X,
or STS-1-X, where X represents the VCAT size.
soll.
soll.


When upgrading the port rate on an XDM line card (e.g. from STM-1 to
STM-4 or from STM-16 to STM-64), LightSoft automatically detects and
updates this information, eliminating the need for manual actions (e.g., to
reprovision services). See the LightSoft User Manual for more details.
Pathfinder
LightSoft's Pathfinder algorithm provides automatic E2E provisioning of
SDH/SONET and Ethernet over SDH/SONET (EoS) trails, including
sophisticated schemes like concatenation, diverse routing, and optical Dual
Node Interface/Dual Ring Interface (DNI/DRI). Automatic provisioning of
optical trails is performed by user-initiated acquisition based on the installed
equipment configuration.

Figure 5-1: Point-and-click trail provisioning
You can configure optimization criteria via Pathfinder, including:
Lowest cost
Minimum distance
Minimum number of nodes
Network utilization (for purposes of load balancing)
Protection specifications (current layer, underlying layer, or both)
soll.
soll.


Figure 5-2: Fine-tuning Pathfinder criteria
Pathfinder offers a high level of flexibility in applying these criteria, using an
"equivalence range" for each criterion. You can also assign a tolerance to
certain criteria to avoid segment selection based on trivial differences.
The Pathfinder algorithm takes into account information about situations where
links in a network share a common physical attribute (such as the same duct)
and associated vulnerabilities (such as in SRLGs). The protection path
selection process uses an iterative calculation that yields a very accurate result.
The higher the number of iterations requested, the greater the accuracy of the
calculation, and the better the solution.
soll.
soll.


Pathfinder by default prefers potential single path routes that minimize the
number of separate SRLGs amongst the segments. In this, the risk involved in
the route itself is minimized.

Figure 5-3: Single path SRLG minimization
After a subset of SRLG-effective paths is identified, the paths are further
checked against user-specified criteria and their associated tolerances until the
optimal path is identified. The system provides feedback if it is unable to create
a trail meeting user-defined criteria.
Extensive MS-SPRing/BLSR protection features are provided, including:
Extra traffic ability to assign traffic to specified preemptable resources
within an MS-SPRing/BLSR
Non-preemptable Unprotected Traffic (NUT) ability to assign traffic to
resources configured as NUT within an MS-SPRing/BLSR as unprotected
LO MS-SPRing use of VC-12/VC-3 granularity within MS-SPRing
Extensive EoS trail support is provided, including:
VC-4/VC-3/VC-12, STS-3c/STS-1 path traffic flow.
Diverse routes for LCAS functionality. An EoS trail can be defined with
several diverse routes through different non-shared fibers, for example,
capacity split between three routes.
Increase or decrease trail bandwidth as required.
Quick Bundle Trail Creation
This feature enables operators to create multiple trails with endpoints on the
same cards in a single GUI operation.
You select the cards and the number of trails (bundle size), and LightSoft
automatically and sequentially creates the corresponding trails without further
operator intervention (unless a card runs out of free ports or a resource runs out
of free capacity). This feature saves time, reduces errors, and simplifies user
tasks.
soll.
soll.


Split Server Trails
Server trails traversing an ME can be split automatically. This complements the
automatic Insert NE functionality and is an important tool for trail management
in general.
You can automatically split a "long" server trail (spanning more than a single
segment) into two server trails. The trail is split at the point where it traverses a
selected ME.
All the LO trails passing through the VC-4 trails are handled, enabling them to
use both server trails. XCs at the LO level are created in both split server trails
via spanned elements.

Figure 5-4: ME selected at trail splitting point
soll.
soll.


SDH/SONET Trail Protection Schemes
LightSoft provides a wide range of protection schemes for all trail types and
complex topologies to ensure continued transmission in the event of failure of a
network resource.
According to its appearance, you can immediately identify which path/circuit
type of a protected trail you are looking at. Three graphical display modes can
appear in the Trail List (trail management) window: Main Path, Protection
Path, and Both (Main and Protection Paths).
Protection mechanisms include:
Subnetwork Connection Protection (SNCP) and Dual Route Path
Protection (Route Diversity)
SNCP is a topology-independent scheme providing independent path
protection. Traffic switches at the service TP or when it leaves a ring or
virtual ring. LightSoft supports SNCP types SNCP/I and SNCP/N in
compliance with the applicable ITU-T recommendations.
Highly efficient advanced algorithms for provisioning ring-over-mesh
topologies are supported. The Route Diversity protection paradigm is a
self-healing path-protection scheme supported by all XDM, SYNCOM, and
BG cards.
Linear Multiplex Section Protection and Automatic Protection Switch
(MSP/APS)
MS line protection is designed to protect single MS links and is available in
all XDM SIO line cards (STM-1/OC-3, STM-4/OC-12, STM-16/OC-48,
and STM-64/OC-192). Both MSP 1+1 and APS 1+1 modes are supported
with protection for fiber and hardware faults.
Multiplex Section Shared Protection Ring/Bidirectional Line Switched
Ring (MS-SPRing/BLSR)
MS-SPRing/BLSR divides the STM-n/OC-n signal into working and
protection capacity per multiplex section. In case of a failure in one
multiplex section of the ring, protection is performed by looping back the
affected traffic at both ends of the faulty section. MS-SPRing/BLSR is
intended for ring applications that demonstrate uniform or adjacent traffic
patterns, and may offer significant capacity advantage compared to other
protection schemes.
Hardware protection
soll.
soll.


LightSoft supports 1+1 protection of all common circuits, traffic card,
control and synchronization units, and power supply in SYNCOM and
XDM shelves. In addition, the system provides 1:n (n = 1-10) protection to
all PDH/Async and SDH/SONET electrical interfaces and hardware
protection to all SDH/SONET optical interfaces via MSP 1+1 or 1:n in
XDM shelves.
Standard transport and data plane protection mechanisms such as linear
MSP/APS 1+1, MS-SPRing/BLSR, and SNCP/UPSR path protection can be
used in conjunction with ASON protection and restoration (on page 5-11),
providing a comprehensive approach to protection that is optimized at every
network level.
Trail Information
The Trail List window supports sophisticated sorting and filtering options.
Select a trail in the Trails pane to display it in the map view and view
additional information in other panes. You can also view current trail
performance, diagnose problems involving connections and ports, and switch
protection paths directly from LightSoft windows without opening the EMS.

Figure 5-5: Trail List window

Figure 5-6: Trails pane showing Alarm State indication column (far right)
soll.
soll.


Trail Resources
Trail resources are shown in tree form with main and protection path branches.
Each route of a concatenated trail with diverse routing has its own branch.

Figure 5-7: Resource Tree pane showing diverse routing
Trail Filters
LightSoft enables you to create detailed filters from a combination of trail
attributes and objects activated from predefined or created filters. Use these
filters to view a subset of trails listed in the Trails window.

Figure 5-8: Create Filter window
Filters can be set by default, edited, and modified. When filtering trails by NE,
you can include those traversing the NE or with endpoints on the NE or both.
Associated client or server trails can also be filtered in.
soll.
soll.


LightSoft supplies a set of predefined filters, including showing only trails of a
specific technology or trails completely empty (when set as default, this filter
makes opening the trail list much quicker).
ASON Network Management
You can configure LightSoft-provisioned trails with ASON protection
schemes. LightSoft graphically displays the ASON domain, providing a variety
of monitoring tools.

NOTE: ASON network management is available for SDH
implementations only.
ASON Management Tools
Use the Show ASON Domain command to visualize the entire ASON domain
by displaying all ASON-based entities on the topology map, as shown in the
following figure.

Figure 5-9: Show ASON Domain
LightSoft supports provisioning of ASON-protected trails, including
Terminated Server Trails (TSTs) that carry LO traffic. This includes:
VC-4 server trails
VC-4 service, VC-4-4c, VC-4-16c, EoS-VC-4 with diverse routing, and
MoT-VC-4 with diverse routing
soll.
soll.


LightSoft supports a convenient ASON Admit Capability that simplifies ASON
trail management. Any ASON-rerouted trail is accepted as permanent and
replaces the previous path in the LightSoft database. The current ASON trail
paths (including rerouted ones) are displayed on the topology map.
LightSoft allows you to easily perform maintenance operations on ASON
trails, including:
Revert the trail path to either the provisioned or protection path.
Reroute the current main or protection path to an alternate route identified
by ASON.
Allow/disallow these actions on the related ASON trails.
LightSofts Availability Map displays the link utilization status in the ASON
domain, allowing you to maintain the spare capacity necessary to handle
multiple concurrent network failures.
ASON Protection and Restoration
LightSoft offers a choice of ASON protection schemes that can be tailored to
match your specific network traffic requirements, significantly increasing
network survivability.
SNCP-based 1+1 protection for the current layer only. With this
configuration, a provisioned trail includes two paths: main and protection.
This configuration protects against a single failure in the main or protection
path, with service recovery in less than 50 msec.
Bronze 1+R restoration for low CoS services. With this configuration, a
provisioned trail includes one path. This configuration protects against
more than one failure as long as there are resources available to support
E2E connectivity, with service recovery within a few seconds.
Silver 1+1+R protection and restoration that combines 1+1 protection
with 1+R restoration. With this configuration, the first failure on a main or
protection path is recovered by means of the 1+1 protection scheme. This
failure and recovery sequence does not trigger any restoration path
computation and signaling. If a second failure occurs affecting the current
active path, the 1+R restoration scheme is applied. Any additional failures
on the restoration path trigger additional restoration recovery attempts.
soll.
soll.


Gold 1++ protection and restoration for the current layer, for very high
CoS services. With this configuration, a provisioned trail includes two
paths: main and protection. This configuration protects against more than
one failure in the main or protection path, with service recovery in less than
50 msec. Service recovery continues for subsequent failures as long as
there are resources available to support E2E connectivity, until the
cumulative failure load reaches the point that insufficient resources are
available to support a full recovery.
A universal dilemma has always been how much time to wait before restoring
traffic to a repaired path. If the system waits too long, resources may be held
unavailable for other trail restorations for a perhaps unnecessarily long period.
But if the system does not wait long enough, then traffic may be restored to the
provisioned path before it is truly stable and the path could fail once more,
ultimately consuming more resources unnecessarily. ECI Telecoms ASON
implementation provides an intelligent reversion mechanism that optimizes
the time to wait before restoring traffic after a path is repaired.
ASON protection and restoration schemes coexist with SDH/SONET trail
protection schemes (on page 5-7) such as linear MSP/APS 1+1,
MS-SPRing/BLSR, and SNCP/UPSR path protection. You can select which
protection and restoration schemes apply to each service.
Since ASON is designed to offer multiple restoration path options, LightSoft
works with a Constrained Shortest Path First (CSPF) methodology when
choosing the restoration path. TE metrics are downloaded, providing a
weighted value for each link in the restoration path. Based on real time
bandwidth and load path computation, the least expensive links are chosen for
the restoration path.
soll.
soll.


The following figure illustrates a typical blend of protection mechanisms. The
quality of the mechanism is tailored to the service. Top priority services, such
as government and military applications, enjoy the strongest protection plans.
Services that must meet a high QoS standard, such as telephony and cellular
service, are similarly assigned robust protection plans. Fewer resources are
reserved for protection of lower priority services, such as high speed Internet.
Basic best effort services are implemented without any additional protection
mechanisms.

Figure 5-10: Blend of protection mechanisms
soll.
soll.


ASON Priority Schemes
ASON supports a system of high and low priority levels that can be configured
to prioritize traffic appropriately when there is not enough bandwidth available
for the current network traffic load. Traffic priority levels determine which
traffic stream is given first shot at the small amount of bandwidth that is
available. Low priority traffic is preempted by higher priority traffic, thereby
ensuring that high priority traffic is able to flow without interruption.
Priority levels are configured in parallel with protection scheme options. This
dual-pronged approach, blending two independent mechanisms, provides great
flexibility, enabling a broad range of CoS levels that can be fine-tuned to match
specific service requirements. Intelligent assignment of priority levels is the
key to smooth traffic throughput, enabling load balancing as well as preventing
bandwidth starvation for services at lower restoration levels.
The following combinations are supported:
Gold 1++ service, high priority
Gold 1++ service, low priority
Silver 1+1+R service, high priority
Silver 1+1+R service, low priority
Bronze 1+R service, high priority
Bronze 1+R service, low priority
SNCP-based 1+1 service
Iron service, with preemption (future)
soll.
soll.


ASON Protection across Non-ASON Domains
Modern networks often include both ASON and non-ASON domains (for
example, third-party SDH networks). In order to enjoy ASON protection in all
networks, the XDM's ASON implementation supports establishment of ASON
links between two ASON nodes even in non-ASON network regions. This is
implemented using Logical Data Links (LDLs) to represent virtual topology
links.
LightSoft portrays the LDLs as topology links in the SDH layer. The LDL is
viewed in the control plane as a regular data link, used at any STM rate. No
special operator trail management is required.
ASON protection across non-ASON domains is illustrated in the following two
figures.

Figure 5-11: Physical layer view
soll.
soll.


Figure 5-12: SDH/SONET layer view
DWDM Trails
LightSoft simplifies provisioning and day-to-day monitoring of optical
services. Information on light paths, wavelengths, channel availability, rates, is
available from optical links and optical trail lists.
LightSoft provides fully automated optical trail provisioning, eliminating
operator intervention at the EMS level. Automatic trail provisioning is also
vital in networks based on ROADMs and multi-rate AoCs that allow creation
of complex mesh and ring network topologies at the lambda and sublambda
levels.
The following features are especially valuable:
Point-and-click functionality for optical trail creation and activation of
optical services for all types of trails, including ODU, OCH, LightPath,
protected and unprotected, P2P, and P2MP (drop-and-continue).
Top-down trail provisioning beginning at the NMS level with LightSoft
(creating trail) and automatically continuing down to the EMS
(implementing details).
soll.
soll.


Rapid trail creation, with a choice of either:
Fully automatic pathfinding, where you specify the endpoints and
LightSoft chooses the optimal path for both main and protection
segments.
Fully manual, where you specify the exact trail path and LightSoft
completes the trail provisioning tasks.
Combination, where you specify the trail endpoints and specific
segments of the path and LightSoft automatically completes the rest of
the path route and provisioning.
GCT split single-card LEs on technology layers (such as the optical layer)
directly opening the internal card view.
Utilization tables showing the state of the channels through a DWDM or
CWDM OMS trail, helping you decide which channel to utilize.
Availability maps and tables and sophisticated maintenance tools enhance
trail provisioning and management.
You can also automatically acquire all OMS, ODU, OCH, LP, and EoS trails in
a single optical trail discovery operation. This is especially useful when the
system is first installed. LightSoft enables you to upload, label, and display
existing optical trails from the optical layer in a form of "bottom-up"
provisioning.
LightSoft supports up to a maximum 80 optical channels with 50 GHz spacing,
or 40 optical channels with 100 GHz spacing.
Optical Trail Provisioning and Management
Different optical components may require specific network management
capabilities. LightSoft provides all the tools necessary for effective network
design, configuration, and management of all components. For example:
LightSoft utilizes specific payload objects (SPOs) when supporting trails
using the multiprotocol AoC or OMCM cards. LightSoft also supports
P2MP LightPaths for AoC and OMCM25 cards.
If a lambda (line port) is connected to a multiplexer or ROADM, LightSoft
provides enhanced validation, preventing mistakes during link creation.
LightSoft displays the reason why an optical trail is classified as a Flex
trail, allowing you to detect and correct it. Flex trails are non-classified
trails with non-standard trail patterns.
soll.
soll.


Route selection for optical trails can be fully automatic using LightSofts
Pathfinder algorithm, fully manual using LightSofts GUI, or partially
automated. Pathfinder selects the optimal main path based on the minimum
hops criterion. You can apply route constraints, such as segments that must be
included. This algorithm takes into consideration lambda switching within the
topology.
For maximum protective value, Pathfinder selects protection path routes that
offer the maximum diversity from the main traffic paths, as illustrated in the
following example.

Figure 5-13: Main and protection trails highlighted
LightSoft verifies the correctness of the endpoints and user-selected trails.
Parameters such as Forward Error Correction (FEC) and line code are checked,
significantly reducing the chance of configuration errors.
Once a path is selected, optical XCs are automatically provisioned on the NEs
along the trail.
LightSoft provides a table with a list of available frequencies across multiple
OMS trails, making it simple to select the frequency used at trail endpoints.

Figure 5-14: Frequency availability table
soll.
soll.


Creating and editing optical trails in single and bulk operations is possible
using the XML file import feature.
LightPath Trail Availability Maps
LightSoft includes enhanced availability maps for OCH via LightPath. These
maps show resource availability, ensuring that link capacity suits the required
services.
First check the area in which you wish to create a new trail to verify that the
links have enough capacity. The following figure shows a simple availability
map for a network fragment after a traffic segment was added.

Figure 5-15: Availability map: after additional trails added
Network availability information can be exported to external applications in
CSV format using a command line. See Optical Availability Tables (on page 6-
2).
soll.
soll.


Optical Protection Mechanisms at the NMS
and EMS Levels
ECI Telecom management applications offer a variety of optical protection
mechanisms that can be combined to achieve the protection mix most
appropriate for your network requirements. Optical protection mechanisms are
provided for OMS, OCH, ODU, and LightPath trails. The method you choose
depends on the network topology.
LightSoft optical protection mechanisms include dual homing, Dual Node
Interface (DNI), Dual Ring Interface (DRI), multiroute OCH trails, and a
combination of multiroute OCH with DRI. LightSoft also offers smooth
integration with SDH/SONET protection mechanisms such as SNCP/UPSR
and Bidirectional Path Switched Ring (BPSR) interworking using both
user-assisted and automatic methods.
DNI
DNI protection uses a single NE to bridge two rings. The following figure
illustrates a topology based on AoC cards in XDM platforms in which a single
connection point is used to close two rings. DNI trails are created automatically
by LightSoft.

Figure 5-16: DNI protection example
soll.
soll.


DRI: Classic Mode
Traditional protection schemes rely upon configuration of two paths, main and
protection. Traffic is simply switched from the main path to the protection path
if there are any (one or more) fiber cuts in the main path. DRI topologies
improve upon the traditional model by protecting against fiber cuts in both the
main and protection paths.
DRI configures additional links between the main and protection paths to
provide multiple alternate route possibilities between the main and protection
paths. This is illustrated in the following figure.

Figure 5-17: DRI classic protection model
The preceding figure portrays two end points linked by main and protection
paths. Two links are configured between the two paths, represented by the
X-shape link topology in the center of the figure. The first fiber cut, on the
main path, (labeled A), triggers a switch at both end points from the main path
to the protection path. A second fiber cut, on the protection path, (labeled B),
triggers a switch at the appropriate points from the protection path back to the
main path. After each fiber cut, the optical equipment used at the
DRI-configured nodes at either end of the DRI links must also switch their
internal Rx/Tx settings accordingly.
soll.
soll.


DRI: Enhanced Mode
Classic DRI configurations require two fiber links between the main and
protection paths. Under certain circumstances, such as complex or distant
topologies, it may be difficult to ensure two fiber connections between the
paths. Therefore, ECI Telecom has designed an enhanced DRI configuration
that can be implemented with a single fiber link between the two paths. This is
illustrated in the following figure.

Figure 5-18: DRI enhanced protection model
With enhanced DRI, a single bidirectional link is configured between the two
paths. The OCH trail is defined as asymmetrical, using a different channel in
each direction. This prevents signal overlapping over the link connecting the
two paths.
Multiroute OCH
Multiroute OCH trails may have defined up to 32 routes, organized into a
logical structure of main and optional protection paths. Each path consists of a
primary route and up to 15 secondary routes. Multiroute OCH protection can
incorporate up to three distinct levels of protection: path protection through the
use of main and protection paths, route protection through the use of multiple
routes, and DRI protection against multiple failures on both the main and
protection paths.
This hierarchical approach enhances protection route planning and adds
robustness to your optical trails.
soll.
soll.


The following figure displays the network map and resource tree for a
multiroute configuration that includes 16 routes each in both main and
protection paths. For each path, one route is designated the primary and the
others are designated secondary routes 1-15. Links in the network map view
are color coded pink, light blue, or purple, indicating their status as main route,
protection route, or both.

Figure 5-19: Multiroute OCH with 16 routes each in both main and protection
paths
soll.
soll.


Multiroute OCH Combined with DRI
Multiroute OCH trail protection can be enhanced with DRI protection
configured between the main and protection endpoints. This adds flexibility
and provides additional protection against multiple fiber cuts. Combining
multiroute OCH with DRI protection provides a powerful multilevel protection
mechanism. The following figure focuses on the DRI aspect of a combination
configuration.
The OCH aspect of this network configuration includes both main and
protection paths, where each path includes one primary route and
multiple secondary routes, color coded as in the preceding figure. The optical
DRI aspect of this network configuration can be seen in the purple X pattern of
links connecting four of the five nodes in the five sided figure at the top of the
network map. The DRI links are highlighted in white on the map pane. The
corresponding bridge is highlighted in the Resource Tree pane on the left side
of the window

Figure 5-20: Combining multiroute OCH and DRI
The EMS-XDM supports the following optical trail protection schemes:
Optical Multiplex Section Protection (OMSP): Line and I/O protection at
the optical level based on a 4-fiber connection. In the case of a fiber cut, an
optical switch in the fiber automatically switches the system to protected
mode. This protection scheme eliminates the need for additional LOS
detection mechanisms and electrical control components.
soll.
soll.


Optical Channel/Optical Data Unit (OCH/ODU) protection: Both path
and hardware protection using a pair of transponder cards with built-in
OCH units to transport each optical channel in two directions. Normally,
traffic traverses the ring or mesh and is received by the main transponder.
In the event of a failure, traffic is received by the protection transponder.
The main benefit of OCH/ODU protection is its ability to choose separate
working paths for each channel. Each fiber carries traffic with both
working and protection signals in a single direction.
Ethernet Services
LightSoft provides you with the E2E and top-down provisioning capabilities of
carrier class Ethernet services. NEs provide various types of MEF certified
Layer 1 and Layer 2 services. All cards use VCG trails with VC-12/3/4 or
STS-1/STS/3c granularity and the appropriate bandwidth allocation as the
physical layer for any Ethernet service type.
Ethernet services are provisioned via a user-friendly procedure that cuts down
on time and effort and reduces human errors. Each interface is configured
separately to provide maximum flexibility. For example, in an MPLS-TP
network, a customers Ethernet traffic is transported over MPLS-TP tunnels
that can either be shared or dedicated. The supported services are P2P (VPWS),
MP2MP (VPLS), hub and spoke (partial VPLS), hierarchical VPLS (H-VPLS),
and rooted MP service (important for IPTV-oriented applications), all of which
utilize advanced QoS and TE mechanisms.
Ethernet services are provided in one of the following configurations:
P2P Ethernet Virtual Circuits (EVCs): Layer 1 EVCs are E-Line
services that run between two Layer 1 Ethernet port endpoints over an
SDH/SONET trail. Ethernet is mapped to a virtual concatenation of
SDH/SONET containers, creating transparent P2P service. Bandwidth
allocation can be full or partial with no traffic-affecting changes. Layer 1
services are provisioned at the EMS level.
A Layer 2 EVC associates two UNIs. This service is implemented by
VPWS on an MPLS-TP or PB network, with Ethernet service traffic shared
among many customers.
LightSoft allows you to configure P2P services simply by selecting the two
required endpoints and configuring CoS, policer, and VLAN parameters.
LightSoft then automatically provisions the service over all required nodes
in the network.
soll.
soll.


P2MP EVCs: These E-LAN services are usually hub and spoke, where
each service endpoint is either a hub or a spoke. One to four hubs are
included. Packets are delivered from spoke to hub and vice versa and not
directly between two spokes. Only supported when all endpoints are on a
single MPLS domain or EAH-VPLS network.
LightSoft allows you to configure P2MP services by selecting one hub and
several spokes (endpoints) and configuring CoS, policer, and VLAN
parameters. LightSoft then automatically provisions the service over all
required nodes in the network.
MP2MP EVCs: E-LAN services in which all points are connected to each
other. In standard MP2MP service, frames from each service endpoint can
be delivered to any other endpoint or can be multicast to a set of multiple
endpoints. A service implemented by VPLS on an MPLS network is a
Layer 2 MP2MP EVC.
LightSoft allows you to select all endpoints to be connected within the
MPLS network and configure CoS, policer, and VLAN parameters.
LightSoft then automatically provisions the service over all required nodes
in the network.
Rooted Multipoint EVCs: A service endpoint is either a root or a leaf.
Packets are delivered from roots to leaves and vice versa. Typically, this
service is used for multicast service between a single root and multiple
leaves. In an MPLS network, this service is used for IPTV or E-Learning
services by configuring a P2MP multicast tunnel between the root and all
leaves.
LightSoft allows you to select one root and several leaf endpoints and
configure CoS, policer, and VLAN parameters. LightSoft then
automatically provisions the service over all required nodes in the network.
Depending on the network context and requirements, Ethernet services are
provisioned across various types of technologies, as described in the following
table.
Table 5-1: Service implementations over various technologies
Service tunnel type PB MPLS EAH-VPLS
P2P
Yes (for direct EoS links) Yes Yes
P2MP
--- Yes Yes
Rooted P2MP
--- Yes ---
MP2MP
Yes Yes Yes
soll.
soll.


Ethernet Services Provisioning
LightSoft offers a powerful set of automatic provisioning tools and
configuration wizards to simplify service and trail provisioning.
The User Preferences (Service Management) window determines how
LightSoft selects tunnels. It also enables selection of RSTP-enabled EoS trails
for P2P services in a PB network for "back door" protection.

Figure 5-21: User Preferences - Service Management window
The Create Ethernet Service window shows all/preselected LEs in the
currently active topology layer and information and configuration panes.

Figure 5-22: Create Service window
soll.
soll.


The Endpoints tab enables configuration of the services endpoints and
associated CoS mapping, policer profile, and multicast parameters. A list of
endpoints defines the service and four sub-panes display endpoint attributes -
CoS Mapping, Endpoint Policers, Endpoint VLANs, and Multicast.

Figure 5-23: Endpoints tab
S-VLAN Registration
To simplify S-VLAN registration, LightSoft offers automatic and manual
processes. Registration information is sent to the PB network ports, enabling all
virtual links to accommodate the service.
S-VLAN registration can also be performed at the trail level. This adds the
S-VLAN registration to the virtual link, downloading it automatically to each
service in the network (you no longer need to register the S-VLAN manually
for each service).
LightSoft supports provisioning and acquisition of P2P and MP2MP Ethernet
services over direct EoS trails in the PB network.
soll.
soll.


Hierarchical VPLS for Scalability
Classic VPLS service creates a full mesh of LSPs and PWs between all PEs in
the network. Under certain circumstances, this may not be the most efficient
use of network resources.

Figure 5-24: VPLS network configuration
With H-VPLS, the network is split into hierarchical VPLS domains. Spoke
nodes are connected only to their hubs, and full mesh is only created between
hub nodes within each domain. Traffic may be routed between tunnels of
different VPLS domains. This efficient approach improves MP2MP service
scaling and allows less powerful devices such as access switches to be used as
spoke nodes, since it removes the burden of unnecessary connections.

Figure 5-25: Typical H-VPLS topology
H-VPLS enables connections between VPLS domains. H-VPLS defines a
hierarchy of VPLS domains and allows MPLS-level connectivity between
them, providing VPLS network scalability, hierarchical partitioning, and
interoperability.
soll.
soll.


Using H-VPLS, network NEs can be organized into logical domains, arranged
in a hierarchical structure that simplifies service management. For example, in
a network with multiple services defined on each NE, the services can each be
configured with separate H-VPLS domains.
H-VPLS domains can be configured for MP2MP and P2MP services. The
LightSoft GUI makes it easy for the user to select NEs and define multiple
domains. LightSoft then automatically completes the rest of the process;
configuring the tunnels that are necessary to support the user's topology design,
defining the split horizon groups (SHGs) required to carry the service traffic
correctly, and automatically activating the new H-VPLS service. You may also
complete the tunnel configuration manually, if you prefer.
The following figure focuses on one section of an H-VPLS configuration.
Domain RingA is selected in the H-VPLS Domains tree, and the corresponding
nodes are highlighted in the network map pane.

Figure 5-26: H-VPLS domain example
soll.
soll.


Ethernet Service Options
LightSoft enables NEs to provide various types of Ethernet, FE, and GbE
Ethernet services via various data cards. All cards with EoS WAN interfaces
support bandwidth management allocation for each GbE/FE connection in
VC-12/VC-3/VC-4/STS-1/STS-3c increments, up to the full GbE/FE rate.
LightSoft supports both dedicated and shared Ethernet/MPLS service, over
both SDH/SONET and DWDM infrastructure.
You can manage Ethernet services in the ETH Service List window (similar to
the Trail List window for SDH/SONET and optical trails). The list aggregates
all NE-level services defined by the EMS into an E2E configuration that can be
sorted and filtered. You can view RSTP maps, display and print the services on
the map, add comments, and modify preset parameters (such as CIR and CBS).
LightSoft conforms to Metro Ethernet Forum (MEF) "Carrier Ethernet"
specifications.

Figure 5-27: ETH Service List window
soll.
soll.


CFM
Connectivity Fault Management (CFM) is the OAM mechanism for Ethernet
services based on IEEE standard 802.1ag. CFM is used to monitor connectivity
in Ethernet networks that encompass multiple administrative domains.
CFM defines proactive and diagnostic fault localization procedures for P2P and
MP services that span one or more links E2E within an Ethernet network. CFM
enables detection, verification, localization, and notification of different defect
conditions and enables SPs to manage each customer service instance on an
individual basis.
CFM is configured in LightSoft per service, as shown in the following figure.

Figure 5-28: CFM configuration
CFM objects are automatically calculated by LightSoft and downloaded to
equipment when creating services. CFM implementation enables maintenance
operations (CFM Maintenance for Ethernet Services (on page 8-3)) and alarm
management (Bidirectional Drill-Down (on page 4-9)).
soll.
soll.


CFM Support in STMS
E-LAN services in STMS can be configured with CFM. The participating
MEPs are by default assumed to all be ShadeTree-based endpoints residing on
9700 series elements.
If a third-party endpoint is participating in the service, STMS supports the
ability, from within the specific E-LAN service, to transmit CFM pings against
the MEP-ID of any MEP in the service. The features must be enabled as part of
the E-LAN configuration.

Figure 5-29: CFM tool button in E-LAN properties window
soll.
soll.


Infrastructure Protection Schemes
LightSoft provides an extensive mixture of protection schemes balancing
bandwidth usage with service restoration time, thereby enabling a balanced
optimization between cost and performance, tailored to customer requirements.
Users typically define the appropriate mixture of infrastructure protection
services, and then define the user services that will utilize that protection
mixture.
This section describes some of the Ethernet-based protection mechanisms and
techniques provided by LightSoft.
BPDU Tunneling Dual Homing
BPDU Tunneling Dual Homing (DH) utilizes pairs of MPLS network PE ports
to provide protection in two contexts:
Access Link Dual Homing, used to provide protection when connecting an
MPLS network to customer network access points which are protected by
RSTP. Access Link DH can also be used in any configuration connecting a
managed MPLS network to unmanaged elements located in an external PB
network.
Internetwork Dual Homing, used to protect all services between an MPLS
network and a PB network protected by RSTP.
The basic configuration comprises:
Two links between two PE ports in the MPLS network and two ports on
the CEs or PB network. The two PE ports function as peer DH ports. One
link is usually active and the second link kept as standby for protection.
The dual homed pair may also be a pair of LAG ports comprising multiple
EoS trail virtual links or ETY physical links.
A dual homed P2P service configured as a pseudowire between the two
participating MPLS PEs. This service carries RSTP Bridge Protocol Data
Unit (BPDU) service frames rather than regular customer service traffic
frames. This service is represented in the following figures by a dashed line
between the two PEs.

Figure 5-30: Dual Homing for access network or internetwork connections
soll.
soll.


If the active link between the MPLS and CE/PB networks fails, traffic can be
diverted across the dual homed service link to the standby link and traffic flow
is not affected.
RSTP Multiple Homing
An Ethernet topology may include rings that provide a protective measure of
redundancy. However, ring topologies carry a risk of unintentionally routing
traffic in inefficient loops.
The Rapid Spanning Tree Protocol (RSTP) prevents these loops by creating a
loop-free "spanning" tree topology of links connecting all bridges (wherever
possible). Ethernet traffic travels only via the active tree links. Links that are
not included in the tree are inactive. All changes in the network topology, such
as new/removed links or elements, or failed/restored links, trigger an automatic
update of the spanning tree, thereby providing dynamic protection for failed
links or nodes.
The ETH/MPLS layer may have several unconnected Ethernet networks, each
with its own RSTP tree. RSTP service provides protection for network
configurations that require use of multiple gateways between one or more PB
and MPLS networks. As an alternative to BPDU tunneling dual homing, RSTP
service features improved failure detection time and protection capabilities.
The following figure shows a simple network topology with two RSTP rings.
Ring A is closed using an RSTP service instance between two PE nodes in an
adjacent MPLS network. Ring B is closed using a BPDU tunneling dual
homing service instance.

Figure 5-31: Two methods for closing an RSTP ring
soll.
soll.


Ethernet Ring Protection
Ethernet Ring Protection Switching (ERPS) is an enhanced protection
mechanism for Ethernet networks, defined by ITU-T G.8032 standard. It
supports improved resiliency, manageability, and reliability of metro Ethernet
networks, offering switching to protection time in less than 50 msec. The
standard has the ability to protect against both link and equipment faults.
Each node in the ring protection network has two ring ports (East and West)
and a number of local ports. One link in the ring is designated as the Ring
Protection Link (RPL) and used only for redundancy. One node, connected to
the RPL, is selected as the RPL owner, and is responsible to block traffic on the
RPL in normal operation (idle state) and unblock it when a failure is detected
(protection state).
When a failure is detected, the nodes adjacent to the failure block the failed
link and report this failure to the ring, using a R-APS Signal Failure (SF)
message. The message triggers the RPL owner to unblock the RPL and all
nodes to perform FDB flushing. The ring is now in protection state.

Figure 5-32: Ethernet ring protection
soll.
soll.


When the failed link recovers, the nodes adjacent to the recovered link transmit
a R-APS No Request (NR) message, indicating they have no local request.
When the RPL owner receives the R-APS message it starts a Wait to Restore
(WTR) timer. Once the WTR expires, the RPL owner blocks the RPL and
transmits a R-APS (NR, RB) No Request, Root Blocked message. The nodes
receiving the message perform a selective FDB flush for the relevant port and
unblock their previously blocked port. The ring returns to normal operation
(idle state).
When working with ERP LightSoft configures participating nodes according to
the following guidelines:
One link in the ring is designated the RPL. As long as there are no failures
in the ring, the RPL is maintained in a closed state. This ensures a loop free
topology.
A node adjacent to the RPL, called RPL Owner, is responsible for
blocking and unblocking the RPL in case of failure (and subsequent
recovery) in the network.
LightSoft's ERP service supports two ERP operating modes:
ERP DH H-VPLS: in MPLS DH topologies
ERP PB Ring: in PB or mixed PB-MPLS topologies
Multiple Element Management via STMS
ECI Telecom NMS and EMS management programs work together using
intelligent methodologies that facilitate efficient system management. For
example, STMS provides extensive OAM capabilities, including Ethernet fault
management, fault isolation, and PM. ShadeTree is designed as an intelligent
IP/MPLS control plane supporting automated provisioning of connections and
traffic flows and BFD for IP and MPLS continuity fault management. The
network is self-healing and self-optimizing.
Layer 2 VPNs provide Layer 2 connectivity between two sites. Standard Layer
2 VPNs were once built over Frame Relay or ATM networks and provided
emulated lease lines (VCs) to customers.
CESR series switch routers implement two types of Layer 2 VPNs:
MPLS encapsulated (E-Line): Provide the same functionality as VPNs
running over Ethernet networks while allowing a provider to converge
these services onto a single IP network. Provide P2P connectivity with the
same service and security as a leased line or standard Layer 2 VPN.
VPLS (E-LAN): Provide Layer 2 P2MP Ethernet services.
soll.
soll.


Ethernet Service Management
STMS simplifies MEF E-Line, E-LAN, and Layer 3 VPN provisioning using
the GUI or the northbound API. Simply choose the endpoints and STMS
creates the complete configuration through an easy-to-use wizard on all
associated 9600/9700 series devices. When services are provisioned, you can
provision OAM protocols such as Ethernet CFM (802.1ag). Service definitions
are selected from a predefined set and individual QoS parameters do not have
to be specified each time a service is provisioned.

Figure 5-33: Layer 2 VPN provisioning
Policer profiles encapsulate all relevant bandwidth parameters used by Ethernet
services.
soll.
soll.


After the service is provisioned, monitoring tools confirm the service is
operational or allow you to troubleshoot any problems.

Figure 5-34: STMS: E-Line operational status view
soll.
soll.


STMS creates multipoint signaled services by selecting the appropriate
endpoints and entering common configuration values. The full mesh feature
allows you to create a fully meshed E-LAN service (without separate steps to
create mesh peers). You can monitor E-LAN services from your NOCs using
the E-LAN operational tool illustrated in the following figure.

Figure 5-35: E-LAN operational status view in STMS
Configuring Split Horizon Groups during
Service Creation
Split horizon groups are used to determine the forwarding behavior of the
E-LAN service. When an E-LAN is configured in 'full mesh' topology mode,
split horizon groups are automatically defined and assigned to peers and
interfaces. Packets can be forwarded from any attachment circuit to any other
attachment circuit in the service. The STMS E-LAN tool makes sure that the
user cannot provision a service that includes a forwarding loop.
Network services naturally grow and expand over time, increasing the number
of elements and their attachment circuits. Having every element connected to
every other element in a classic full mesh topology may not scale well. STMS
offers the option of creating a 'custom' topology in which you have more
control of the forwarding behavior of the service.
soll.
soll.


A hierarchical service can be created whose:
Packets are not forwarded between interfaces within the same split horizon
group.
Packets are forwarded between network peers or interfaces in different split
horizon groups.
Peers or interfaces not assigned to a split horizon group are considered part
of the "null" group. Forwarding is allowed between all null group members
and members of all split horizon groups.
Split horizon groups are configured for an E-LAN service when it is created.

Figure 5-36: E-LAN Split Horizon Group creation in STMS
soll.
soll.


STMS enables cross-device analysis of peers, counters, FIB tables, and so on.
You can view the entire service organization without accessing each NE
independently.

Figure 5-37: E-LAN peer properties in STMS
QoS Management in STMS
QoS is a set of traffic-managing processes used to differentiate and enhance
service for certain types of traffic, including:
Ability to offer differentiated services
Ability to dedicate (and guarantee) bandwidth
Increased control over network resources
Traffic classification and prioritization
Management of network congestion
As SPs expand their product offerings or converge their networks, they look to
achieve greater service differentiation in order to increase their market
coverage and gain additional revenue from the same IP platform. QoS helps
them achieve this.
QoS is a complex methodology encompassing many different elements. These
include:
Classifying and assigning packets to a service class
Policing or marking packets that do not conform to the policing limits of
their service class
soll.
soll.


Queuing packets according to their service class
Scheduling packets to be removed from the queues and forwarded

Figure 5-38: Conceptual overview of QoS
The preceding figure illustrates the conceptual flow of a packet through the
QoS processes. As a packet enters the router through an ingress interface, it is
classified and associated with a service profile.
Incoming interfaces have assigned rate limits (policers). If the packet passes the
rate restrictions, it continues to the next stage. If it does not, it is policed or
marked. Policing discards the packet, while marking (tagging) simply informs
the downstream QoS (on the same or a downstream router). In the 9600/9700
series, marking leads the router to assign a new service profile to the packet.
After the policing/marking stage, the router queues the packet as per its service
profile. Next follows scheduling how quickly the router forwards packets
from the queues. The 9600/9700 series then forwards the packet to its next
destination.
STMS provides three methods to configure QoS on one or more 9600/9700
platforms:
1. Configure individual QoS settings per device.
2. Configure a template of a particular QoS setting and apply it across
multiple elements.
3. Define and configure a complete set of QoS components called a named
service. This is then synchronized across multiple 9600/9700 platforms.
The advantage: you only have to specify the named service and STMS
applies all necessary QoS components. Configuration and service creation
is far simpler.
soll.
soll.


Configuring QoS Elements per Device
You can use the QoS Explorer to configure individual QoS elements, such as
drop profiles, service profiles, and UPCs, for your network NEs.

Figure 5-39: Configuring QoS per device
Configuring Templates per QoS Element
You can create and store QoS templates for each type of element (service
profiles, UPCs, etc.). Use these templates to configure QoS elements on
multiple NEs quickly and efficiently.

Figure 5-40: Applying QoS template to multiple NEs
Configuring Comprehensive QoS Service
Definitions
STMS's Service Definition feature makes it possible to group various QoS
settings into an overall definition identified by name that can be applied to
attachment circuits and logical interfaces across the network. In addition,
STMS monitors service definition consistency and notifies when QoS
definitions change on a device.
The Service Explorer associates NEs into groups. Service definitions can then
be assigned to a group.
soll.
soll.


In addition to grouping QoS definitions and/or firewall settings, the STMS
server remembers which NEs have been configured with a given service
definition.

Figure 5-41: QoS service definition creation
MPLS Tunnels over MoT or MoE
MPLS LSPs are used to tunnel a customers Ethernet traffic through the SP
network. LightSoft provides E2E provisioning of MPLS tunnels, an essential
component of service management. Bandwidth is allocated for MPLS tunnels
by building MoT trails or MoE links whose top down provisioning is done as in
SDH/SONET trails.
LightSoft supports both L-LSP and E-LSP tunnels. CoS mapping depends on
the tunnel type.
L-LSP tunnels are each assigned a single CoS and a single color value.
Packets assigned CoS n can only use tunnels of CoS n.
soll.
soll.


E-LSP tunnels can each work with up to eight CoS values, enabling use of
a single tunnel for multiple types of traffic (VoIP, HSI, etc.). Each CoS is
assigned its own color value (yellow, green, or both).
The following figure illustrates an E-LSP with three CoS values: CoS0/Yellow,
CoS7/Green, and CoS3/Both.

Figure 5-42: E-LSP
The flexibility of the frame classification process enables the user to set
services based on the end customer's traffic.

NOTE: Feature implementation depends on support from the
underlying equipment. For example, MPLS tunnels can
include a mixture of MoT trails and MoE links. However, the
actual configuration depends on the equipment in place at
each NE. MoE links are supported across BG, CESR, and
XDM platforms. MoT trails are supported across BroadGate
and XDM platforms.

Creating trails involves several steps: defining parameters, selecting endpoints,
and assigning resources. You can accept default parameter values or select
specific values. LightSoft allows you to create trails for VC-12-X, VC-3-X,
VC-4-X, STS-1-X, and STS-3c-X, where X represents the VCAT size (MoT
only).
Both P2P and multicast-efficient P2MP tunnels are supported by LightSoft. A
complete set of TE and QoS parameters is provided for each tunnel and each
MPLS network. When creating a tunnel, LightSoft allows you to include or
exclude a specific link or NE.
soll.
soll.


In order to protect a tunnel against failure of a link or node along the tunnel
path, LightSoft uses FRR protection configuration. A backup LSP (bypass
tunnel) is predefined around a failed link or node. The rerouted traffic is sent to
a downstream node, where the bypass path merges with the original path. FRR
protection can be configured for link or node protection or a combination of
both (Dual FRR).

Figure 5-43: Bypass tunnel creation
LightSoft provides several FRR tunnel protection configuration options,
including automatic or manual switching from protected to bypass tunnels or
back from protection to main tunnels, configuration per specific tunnel, the
ability to force switching to protection mode, and to control switching timers.
Automatic user-friendly tools help create a full mesh or hub and spoke
configuration of MPLS tunnels and a complete set of bypass tunnels between
all NEs. FRR link and node protection can rapidly be configured.
soll.
soll.


Tunnel Pathfinding
The tunnel Pathfinder calculates an optimal tunnel path subject to tunnel
constraints (e.g., as bandwidth, explicit path specifications) and topology
constraints (including CAC). Pathfinding occurs when a new tunnel is set up or
parameters of an existing tunnel are changed.
Pathfinder tries to find the shortest explicit path from source to destination
including all nodes and links which the tunnel traverses, taking into account
factors like current network topology, available resources, and required tunnel
parameters (bandwidth or protection requirements).
For example, Pathfinder includes an intelligent approach to SRLG
management. SRLGs refer to situations where links in a network share a
common physical attribute, such as fiber duct or equipment cage, and are
exposed to the same vulnerabilities.
SRLGs have implications for Pathfinder tunnel path selection and tunnel CAC
validity. For example, if the links in a main traffic tunnel and in the
corresponding protective bypass tunnel belong to the same SRLG (e.g., same
fiber duct), the bypass tunnel is of no use if the fiber fails. Pathfinder's bypass
tunnel path selection does not include any links that share SRLGs with the link
they are protecting. If the protected link then fails, the bypass tunnel does not
automatically fail too (assuming single physical failure and no platform
failures).
The "no shared SRLGs" rule can be suspended. In this case, paths that share
SRLGs with the protected path are not automatically disqualified. They are
subject to other optimization criteria, like all prospective paths. If needed, some
impact of SRLGs can then be factored into the Pathfinder decision. If a bypass
tunnel is node-protecting (rather than link-protecting), the protected node and
all its links are automatically disqualified from Pathfinder consideration
regardless of SRLG assignments. See Pathfinder (on page 5-3).
soll.
soll.


MPLS-TP Tunnel Provisioning and
Management in LightSoft
LightSoft provides a set of tools designed to facilitate MPLS-TP tunnel
management, including:
Automatic Insert PE and Remove PE features for easy building and
modifying of MPLS-TP networks.
Dual FRR schemes provide protection for both node and link failures in
MPLS-TP networks.
Connection Admission Control (CAC) for MPLS-TP tunnels ensures
there is enough bandwidth on an MPLS-TP link to provide the expected
QoS for all connections. Tunnel CAC supplements MoT trails and Ethernet
service CAC mechanisms to facilitate effective QoS delivery on MPLS-TP
networks. You can set CAC parameters for each endpoint port of the link to
configure reserved bandwidth and reserved shared bandwidth for specific
ports and each CoS as needed.
Some networks, such as IPTV or P2MP services, work with a hub and
spoke configuration. Others require a full mesh of tunnels between all NEs
to ensure connectivity and resiliency in the MPLS-TP network. The
Automatic Tunnel Creation tool for hub and spoke and mesh
configurations completely automates creation of as many tunnels as needed
with a single user action. You can select tunnel creation downstream,
upstream, or in both directions (over the same or different paths).
In an MPLS-TP network, a large number of bypass tunnels must be
configured for protection. The Automatic Bypass Tunnel Creation tool
automates this task with a single user action.
When creating an NMS tunnel, you can choose to select an MPLS-TP label
explicitly or automatically. Enter the requested label and the system checks
its availability. This lends greater flexibility and efficiency to MPLS-TP
network design.
soll.
soll.


MPLS-TP Tunnel Configuration in STMS
STMS provides a convenient GUI for configuring each segment of MPLS-TP
bidirectional static tunnels, including bypass and FRR components. This is a
decided improvement over the traditionally laborious process of defining the
segments through the CLI.
The STMS Tunnel Editor is the main interface for creating, deleting, or
modifying tunnels across NEs. The editor provides a simple interface for
configuring the ingress, transit, and egress hops. Configuration values for the
NEs and for the entire path can be assigned and then applied across all
participating NEs, thus eliminating the need to access individual elements.
Tunnels can also be created, edited, and viewed via the STMS Java northbound
interface, enabling smooth integration with the northbound OSS/NMS.
Once the tunnels are created, they can be assigned to pseudowires in the STMS
E-Line wizard. Use the wizard to assign E-Line/E-LAN endpoints to MPLS-TP
LSPs.

Figure 5-44: Assigning service endpoints to an MPLS-TP tunnel
soll.
soll.


Note that STMS, as an EMS-level application, focuses on each segment (hop)
of the tunnel. LightSoft, working at the NMS level, allocates path labels and
computes tunnel paths for the complete length of the tunnel.
Dynamic RSVP Tunnel Creation in STMS
Operators can create dynamic LSPs, necessary for the RSVP signaling
protocol, using either the STMS GUI or the Java northbound interface. The
operator designated the originating NE, and STMS automatically configures
the LSP signal accordingly.

Figure 5-45: Creating dynamic RSVP LSPs
When using the Commissioning Tool (see "Commissioning 9600/9700 Routers
Using the Commissioning Tool" on page 3-6), RSVP tunnels may be
automatically created between all participating elements.
Traffic Engineering and QoS
Network TE facilitates the best use of network infrastructure without dedicated
lines by offering QoS guarantees, such as bandwidth and latency. Some TE
aspects supported by LightSoft are described here.
CoS per Tunnel: Each P2P or P2MP tunnel is assigned a user-configurable
CoS value (0 to 7). In general, services traversing a tunnel with a higher
CoS receive better treatment than those with a lower CoS. CoS refers to the
tunnel's throughput and latency performance.
soll.
soll.


Bandwidth Sharing: Each P2P or P2MP tunnel is assigned a
user-configurable bandwidth in the range 1-2560 Mbps. Multiple bypass
tunnels can automatically share bandwidth on common links. The sharing
mechanism is applied either on a best-effort basis or require that the sum of
protected bandwidth not exceed the protecting bypass tunnel bandwidth.
Bandwidth sharing is implemented in the MPLS network properties on a
per-CoS basis.
Bandwidth can be shared without compromising QoS if the bypass tunnels
protect against independent SRLGs, with only one carrying traffic at any
given time.
Load Sharing: In traditional IP routing, the traffic between two points is
always routed over the cheapest or least hop link, even when alternative
links are largely unused. MPLS TE allows load balancing over the low
bandwidth link based on traffic analysis.
For example, in two tunnels (low bandwidth and high bandwidth), router A
can be configured to transmit one flow to B over the low bandwidth tunnel
for each three over the high bandwidth tunnel. Unequal paths are utilized in
relation to their bandwidth.
See the following figure. Large site A and B routers are connected directly
by a high bandwidth link, while small site C is connected to A and B with
low bandwidth links.

Figure 5-46: Load sharing across unequal paths
Similarly, MPLS TE can route flows according to application bandwidth
requirements.
Overbooking and CIR: Statistical multiplexing allows for overbooking
(traffic planned along a tunnel even if greater than its physical capacity).
This is useful, for example, for Internet traffic where customers do not all
demand their BW simultaneously. SPs get a lot more use and profit out of
the same amount of bandwidth.
soll.
soll.


Tunnel OAM: Monitoring of P2P tunnel operational state (connectivity,
availability, and QoS). Tunnel OAM and alarm mechanisms can be enabled
or disabled, giving full control over operations and maintenance.
NMS/EMS Synchronization
Trails and tunnels are either defined by LightSoft or uploaded from the EMSs
via trail or tunnel acquisition. Trail- and tunnel-related data are stored in the
system's database, and corresponding information is sent and stored in the
EMSs and NEs. Discrepancies may occur if, for example, provisioning is
performed via a craft terminal.
It is very important that information in LightSoft's database and the actual trails
in the network are synchronized correctly. If there is a discrepancy, activate the
trail synchronization process to correct it.
LightSoft provides three utilities for verifying trail, tunnel, and service
consistency.
The Trail Consistency Indicator (TCI) counter shows the number of
inconsistencies in existing trails.
The Tunnel Segment Consistency (TSC) counter shows the number of
inconsistencies in existing tunnel segments.
The Ethernet Service Inconsistency (ESI) counter shows inconsistencies
between the Ethernet service definition in the LightSoft database and the
NE configuration at the EMS level.
soll.
soll.


The color of the counter represents the consistency status. A flag icon opens
additional information. Both the icon and counter's presence on the toolbar are
configurable.

Figure 5-47: Trail Consistency Indicator window
LightSofts tunnel synchronization process reconciles differences between
tunnel definitions in LightSoft and in the corresponding EMS for both single
and multiple MPLS domains. Synchronization can be automatic or manual.
Importing Traffic Configuration
Files
You must import traffic configuration files when predefined network traffic is
imposed upon the network or trails are mass-configured in batch mode. This
can happen when an external planning tool is used to define network traffic or
when existing traffic cannot be restored using technology-specific protection
facilities after a network failure, nor automatically redirected to different trail
endpoints. Importing traffic configuration files activates a contingency plan.
This functionality is especially useful when failure occurs in equipment
connected to a tributary or in a link connected to an SDH/SONET NE (for
example, a submerged cable).
File import can be used by LightSoft to edit, add, or delete existing trails of any
type. You can export trails in XML format and edit them offline in any text
editor. They can then be re-imported into the system.
soll.
soll.


LightSoft supports batch creation, editing, and deletion of trails, tunnels, and
services by exporting/importing definitions to/from an XML file. This is useful
for network planning or backup. Import and export records coexist in the same
XML file and specify action commands and parameters. The files can be
created off line and stored on an external drive.
Files can also be created by exporting existing traffic configuration data from
the system and then editing the files as needed. This technique is useful for
advance preparation of a wide array of contingency plans for different NE or
network failure scenarios. LightSoft provides a verify-only mode that allows
operators to run the configurations files without actually downloading
commands to the network. The operators can then check the log files for
possible errors and correct the configuration files as needed.

soll.
soll.



In this chapter:
Overview ......................................................................................................... 6-1
Inventory Trees and Windows ......................................................................... 6-2
Optical Availability Tables .............................................................................. 6-2
MPLS Link Availability .................................................................................. 6-4
Inventory Reports ............................................................................................ 6-6
Printing and Exporting to CSV ........................................................................ 6-7
Inventory Management at the EMS Level ....................................................... 6-7
Overview
LightSoft provides comprehensive support for all Fault, Configuration,
Accounting, Performance, and Security (FCAPS) modules. This includes
powerful inventory and accounting features optimizing network management
efficiency.
6
Inventory and Accounting
soll.
soll.


Inventory Trees and Windows
The Inventory Tree presents information about site and NE components to the
slot and port level in a tree-like hierarchy, and is a concise organized way to
manage NEs. Information includes NE name, alarm status, type, location and
state, and card slot number, type, and version.
The tree displays the MEs/LEs and groups portrayed on the map and the cards
and ports within them. Each object is represented by its own icon. For example,
icons distinguish MPLS , PB , and EA-HVPLS network types.
The following figure shows a small tree section.

Figure 6-1: Topology Tree
An object selected in the tree is highlighted in the topology view and the
navigator. A search function enables you to find any NE quickly and easily (on
both the inventory tree and the topology map) and center it automatically on
the LightSoft topology map.
Each EMS provides an Inventory window listing information about the NEs
managed by it. You can access the window is accessed via the GCT.
Optical Availability Tables
Optical availability tables show the state of channels through a selected
DWDM or CWDM OMS trail. Channels can be occupied (in use), blocked, or
free for adding and dropping at the trail end sites. Tables focus on both lambda
and sublambda utilization.
Optical channel availability can be analyzed for uni- or bidirectional OMS
trails. DWDM tables show cells for the 40 or 80 channels represented in
frequencies, each identified by its channel value from an MD port. CWDM
tables show cells for eight channels, with the channel represented by
wavelength values.
soll.
soll.


When a bidirectional trail (or unidirectional trail with related endpoints) is
selected for analysis, the table shows the intersection set of the channel states in
each direction. When a specific channel has different states in the two
directions, the intersection table indicates a split state for that channel's cell.
The tables offer easy navigation to OMS trails, OCH trails, and alarms.
Lambda Utilization Tables
Optical availability tables provide a graphical view of lambda usage within a
single or multiple optical trails.

Figure 6-2: Single availability tables for 32-channel OMS trail
soll.
soll.


Sublambda Utilization Tables
A sublambda view shows the capacity percentage used by each lambda. This is
in addition to the lambda view which shows lambdas in use or available.

Figure 6-3: Optical availability table - sublambda view
MPLS Link Availability
The Availability for Link window shows the number and percentage of
resources available for building new trails on a selected link based on relevant
parameters, including SDH/SONET resources, optical rates, or source/CoS
combinations for Ethernet/MPLS services.
soll.
soll.


The Ethernet/MPLS tab shows bandwidth availability at the port and CoS
level based on CAC assignments.

Figure 6-4: Availability for Link window based on CAC
soll.
soll.


This window shows availability of MoT links in the Ethernet/MPLS layer
based on selected Source and CoS parameters. EoS links, if any, appear in gray
and are not part of the analysis.

Figure 6-5: Availability Map window - ETH/MPLS
Inventory Reports
The following reports export information from the LightSoft database to
external systems (such as Inventory Management systems):
Equipment Inventory: Essential for efficient daily operations of any
network. Use a UNIX script to print a report from LightSoft, including
information about different combinations of a specific EMS, a specific NE,
or all NEs. For each NE, the ID, name, location, and associated equipment
are listed. The cards listed under an NE can represent the actual cards only
or also those with expected type.
PDH Utilization: Number of used and free ports per PDH card.
Time Slot
Trail Transit CTPs Path Type
Ports Table
Trail Endpoints Path Type
soll.
soll.


Printing and Exporting to CSV
Many LightSoft and EMS windows provide options for printing or exporting
information. You can print to any Postscript network printer or
Postscript-formatted file. You can configure the format of printed documents.
You can export list data to a delimited format file, such as CSV, for import to
Microsoft
Excel
or a relational database application.

Inventory Management at the
EMS Level
Inventory management is an essential part of EMS functionality and overall
maintenance of equipment.
Note that the inventory level of the EMS is deeper than that of LightSoft.
EMS-level inventory management complements that of LightSoft. Together
they provide a comprehensive view of the network.
EMS applications can export NE and card inventory data to an XML file on a
regular basis for report and audit purposes. Inventory reports can be configured
to reflect network operator preferences. The following figure illustrates the
EMS-XDM system inventory window.

Figure 6-6: Viewing NE inventory through the EMS-XDM


In this chapter:
Overview ......................................................................................................... 7-1
Current Performance Monitoring .................................................................... 7-2
Historical Performance Monitoring ................................................................. 7-3
Performance Monitoring at the EMS Level ..................................................... 7-6
Overview
LightSoft stores and analyzes a wealth of performance data, enabling you to
troubleshoot NEs and trails and optimize QoS quickly and efficiently. Data are
measured by counters that monitor parameters relating to the endpoint's QoS,
some of which may be modified by the user.
LightSoft works together with each of the network EMSs to provide
comprehensive PM reporting for current and historical data. Current reports are
provided for 15 minute and 24 hour intervals; historical reports for 24 hour
intervals. LightSoft uses an MTNM interface; EMSs produce ASCII outputs.
Through a combination of LightSoft and EMS-level performance monitoring,
administrators can access current and historical performance data for
transmission objects of each NE, trail, tunnel, and service, detailed per
endpoint, and sorted by logging time.
Default performance parameters and threshold levels are provided in
compliance with accepted ITU-T standards. They can be custom-configured
on-screen to suit individual applications.
7
Performance Monitoring
soll.
soll.


Together, LightSoft and the EMSs enable you to:
Retrieve and display current performance data for each object in either
15-minute or 24-hour intervals
Retrieve and display historical performance data for each object in either
15-minute or 24-hour intervals
Manually reset PM counters for each object
Collect performance data for user-specified endpoints
Graphically display PM data
Display and change PM thresholds for each object
Current Performance Monitoring
LightSoft supports Current Performance Monitoring (PM) for SDH/SONET
and optical trails. EMS monitoring adds PM reports for data tunnels and
services as well. Performance counters for selected trails, tunnels, or services
for the current 15 minutes or 24 hours are shown in the Trail Performance
Monitoring window. Counters include those for endpoints, intermediate TPs,
and traffic coming into the network. Incoming counters reflect the quality of
the signal entering the network.

Figure 7-1: Trail Performance Monitoring window
soll.
soll.


LightSoft PM data are the same as that reported by the EMS but more useful
for network management since it is organized by trail TPs rather than NE TPs.
To further assist in troubleshooting, you can reset counters and enable or
disable PM for TPs.
The Trail Performance Monitoring window lists trail TPs and associated PM
data for selected trails (time and counter information). Each TP has its own
counters. TP records can be filtered according to a variety of criteria. Use GCT
to view a selected TP within the EMS card and access corresponding EMS
windows.
Current PM capabilities are fully G.826-compliant, including 95 counters with
15-minute and 24-hour granularity. Alarms are generated when thresholds are
crossed (Threshold Crossing Alarms or TCAs). Accurate PM reporting helps
troubleshoot performance issues and maintain SLA requirements. PM counters
can be reported to OSSs via CORBA-MTNM.
Historical Performance
Monitoring
LightSoft's MultiPeriod Performance Monitoring (MPPM) provides historical
reports on PM counters for SDH/SONET and optical trails. EMS monitoring
adds historical reports for data tunnels and services. Accurate historical records
pinpoint trends and momentary events that affect network performance over a
period of time. With MPPM, SPs can guarantee network performance in
accordance with SLAs. Counters are available for 24-hour intervals. Results
can be aggregated on a daily, weekly, or monthly basis.
soll.
soll.


Reports are available for 24-hour intervals in graphical or tabular format, and
exported in standard formats such as CSV, PDF, and RTF.
Two typical reports in PDF format (a table and a graph) are shown in the
following figures.

Figure 7-2: MPPM tabular report

Figure 7-3: MPPM report for MoT trail
You can configure several parameters, including the objects (one or more)
whose PM history data are to be collected, the counters, the frequency of
collection (every 15 min. or 24 hrs), and over which dates. You can do this in
LightSoft by selected trails without opening EMS windows and drilling down
to internal objects. Commands are automatically relayed to the appropriate
EMSs. An MPPM wizard helps you configure the report output.
soll.
soll.


Figure 7-4: MPPM wizard
Unavailable (missing) or inapplicable (counter not relevant) data are indicated
where applicable. Report compilation does not fail due to missing data.
Aggregated PM history reports are available in ASCII format, with a row for
each time stamp of each object and columns showing the object's identifier,
time stamp, and associated service.
soll.
soll.


Performance Monitoring at the
EMS Level
Performance data reflects the running quality of the network. Effective PM at
the EMS level enhances QoS for the whole network. For example, EMS
applications automatically collect PM data for the NEs that they manage from
trail and cross-connect endpoints in the network. Data includes the trails
physical endpoints (NE, slot, port), trail label, and other PM data. This
information can serve as the basis for accounting, billing, or SLA applications.
The data is stored in files that may be retrieved remotely in ASCII, CSV, or
XML format or via the EMSs northbound CORBA TMF-814 interface.
Performance Monitoring in the EMS-XDM
The EMS-XDM provides default performance parameters and threshold levels
in compliance with accepted ITU-T standards. Parameters and thresholds can
be configured to suit individual applications. They measure current
performance data for each XDM NE (including optical objects) and trail/circuit
over 15 minute or 24 hour intervals, detailed per TP, and sorted by logging
time. Performance data is available in both tabular and chart form.
The XDM supports all standard SDH/SONET PM counters (for example, BBE,
SES, and UAS) for the different signal levels (e.g., MS, VC-12/3/4, or
STS-1/3c); GFP counters (e.g., a comprehensive set of block counters); data
counters (such as Ethernet Rx/Tx octets, Rx/Tx frames, broadcast and unicast
packets, multicast and IGMP packets); policer counters; MPLS counters, and
more. Each counter has a user-configurable default threshold. PM data is stored
by EMS-XDM in a performance log.
EMS-XDM allows you to:
Define PM collection groups and their characteristics.
Define PM counter thresholds and assign performance profiles to objects.
View historical performance data for XDM transmission objects.
Manually collect PM data for all cross-connect endpoints on a card.
Display and use PM and other types of logs.
Obtain and display PM history reports for optical and Ethernet objects.
soll.
soll.


Current PM Log
The following EMS-XDM window shows current performance data for a
transmission object. The contents of this window depend on the type of object
you select. Performance data is collected separately for each endpoint.

Figure 7-5: EMS-XDM Current Performance window
soll.
soll.


Historical Performance Monitoring
The EMS-XDM Performance History window shows historical performance
data for a transmission object. This window displays information collected by
the PM counters for each object. Each counter is displayed in a separate
column.

Figure 7-6: XDM Performance History window
Setting PM Thresholds
PM thresholds within LightSoft are predetermined by the performance profile
assigned in the EMS.
With XDM objects, up to eight different profiles can be defined for each object
type within the NE. An alarm is activated whenever a value crosses a high
threshold and is deactivated when it drops below a low threshold.
soll.
soll.


Performance Logs
In XDM NEs, flexible PM collection groups can be defined for SDH/SONET,
Ethernet, and optical objects.

Figure 7-7: EMS-XDM PM Setup window
Element Performance Parameters
PDH/SDH/Async/SONET PM Parameters
PDH/SDH/Async/SONET PM parameters, reported in the Thresholds Profile
window, include:
BBEFE: background block error far-end
B_UAS: bidirectional unavailable seconds
CVFE: number of code violations far-end accumulated
CVNE: number of code violations near-end accumulated
ESFE: number of errored seconds far-end accumulated
soll.
soll.


OFS: number of out-of-frame seconds accumulated (the system enters this
state when several consecutive SDH frames are received with errored
framing patterns)

Figure 7-8: EMS-XDM Thresholds Profile window
Optical PM Parameters
The Optical PM Current/History window shows optical parameters for the
optical objects in the network, including:
Expected wavelength
Actual wavelength
Actual power (transmitted and received)
Actual OSNR (Optical Signal Noise Ratio)
Unexpected carrier
Missing carrier
OSNR low
soll.
soll.


Laser bias

Figure 7-9: XDM Optical PM Current/History window
Ethernet PM Parameters
Ethernet PM parameters for Ethernet LAN and WAN objects include:
Rx Octets: total number of octets of data (including those in bad frames)
received on the network (excluding framing bits, including FCS octets)
Rx Pkts: total number of frames received, including bad frames, Broadcast
frames, and Multicast frames
Tx Pkts: total number of packets successfully transmitted by the port
Tx Octets: total number of octets successfully transmitted by the port
Rx Error Pkts: total number of bad frames received
Rx Error Octets: total number of bad octets received
Displaying and Printing Performance History
Charts
Historical performance data can be printed either as is from the Performance
History window, or in chart form from the Performance Chart window. The
chart shows how the PM data changes over time for each counter. Values
below the predetermined thresholds are displayed in blue and those above in
red.
Performance Monitoring in STMS
Using STMS, you can configure accounting options for NEs and view data for
a wide variety of network resources. The following counter types are available:
NPB
soll.
soll.


CoS, including forwarding counters
Logical interface
Monitor interface utilization
Physical interface
Queue
Routing protocol
System
Counters can be organized in a hierarchy of groups according to type. Using
STMS, you can collect and view counters contained within each group.
soll.
soll.


Real-Time and Historical Counter Data
Use STMS to view both real-time and historical counter data. Historical
counter group tabs are specifically labeled 'Historical' and by default are not
displayed until you configure the accounting options to do so.
Real-Time Counter Data: Relevant real-time counter data is displayed on
the real-time counter group tabs within the property sheets for network
objects, such as NPBs, ports, and logical interfaces. This data is particularly
useful for quick troubleshooting (e.g., verifying traffic flow, monitoring
error statistics).
Historical Counter Data: Makes use of the bulk statistics capabilities of
the SR9700 series. At a specified interval, the SR9700 series gathers
requested counter data and transfers it to the STMS server for processing
and storage. The data can then be viewed in the STMS client or accessed
by external applications, such as billing and SLA management software.
Historical counter data enables you to view trends over a longer period of
time and is useful for generating billing and SLA records, troubleshooting
persistent performance problems, and conducting network and capacity
planning.

Figure 7-10: STMS Performance Output counter
soll.
soll.


Performance Monitoring in the EMS-BGF
Within the EMS-BGF, PM tasks include:
Retrieving and displaying current performance data for each NE (15-minute
or 24-hour intervals)
Retrieving and displaying historical performance data for each NE, by
stored time/date or interval (15-minute or 24-hour)
Resetting PM counters
Performing performance threshold configuration
Depending on the context (SDH/SONET, Port, EoS, or DCC), performance
data can be viewed for various monitored objects. After analysis in the
EMS-BGF, the errors at each SDH/SONET section/layer can conveniently be
checked. The EMS-BGF provides a performance curve diagram, which
visually shows equipment performance changes during a specific period and
analyzes the communication link quality over time.
Use the EMS-BGF GUI to select current, recent, or historical PM data for
viewing. Filters can be applied to help focus on specific data elements, as
shown in the following figure.

Figure 7-11: Filtering PM data in the EMS-BGF
soll.
soll.


The EMS-BGF enables you to configure performance attributes, including
thresholds, monitor switches, and resetting counters. A performance threshold
is the allowable upper limit for performance data when a system works
normally. When an indicator crosses a threshold, an event report is generated.
You can obtain and set the performance threshold parameters of a network for
either 15-minute or 24-hour intervals.
The following figure illustrates setting performance thresholds through the
EMS-BGF.

Figure 7-12: Setting PM thresholds in the EMS-BGF


In this chapter:
Overview ......................................................................................................... 8-1
Trail Maintenance ............................................................................................ 8-2
CFM Maintenance for Ethernet Services ........................................................ 8-3
Protection Switching........................................................................................ 8-5
Maintenance at the EMS Level via GCT ......................................................... 8-6
Embedded Software Management ................................................................... 8-8
Overview
You can perform maintenance and protection switching actions on
SDH/SONET and optical trails and Ethernet/MPLS services in LightSoft
without opening EMS windows and drilling down to internal objects. You
simply select the trail or service without having to identify the TPs. Requested
commands are automatically relayed to the appropriate EMSs
8
Maintenance
soll.
soll.


Trail Maintenance
Maintenance operations allow you to diagnose network problems. They can be
applied to specific ports and TPs, either directly or via associated trails and
topology links.
For example, the LightSoft Maintenance Operations window enables you to
manage (view and apply) maintenance operations on SDH/SONET and optical
trails and topology links. It lists the TPs and associated maintenance
information for selected trails or links.

Figure 8-1: Maintenance Operations window
Trail-centric maintenance operations include:
Operating and releasing Terminal (Near-End) and Facility (Far-End)
loopbacks
Forcing AISs and Remote Defect Indications (RDIs)
Other routine maintenance operations are available through the management
applications suite, such as:
Blocking/activating DCC
Viewing maintenance operations
Viewing optical parameters
Traffic-affecting functions are indicated by warning popups.
soll.
soll.


CFM Maintenance for Ethernet
Services
LightSoft supports CFM for Ethernet services OAM. You select the service
you wish to monitor and choose the CFM operation (loopback, link trace, and
connectivity checks), specifying the source and target objects. The following
figure illustrates a CFM request for a specific service.

Figure 8-2: Requesting CFM for a specific service
soll.
soll.


The following figure illustrates a typical CFM loopback request.

Figure 8-3: CFM loopback request
soll.
soll.


Protection Switching
By default, trails switch to a protection path if certain alarm conditions occur
on the active path. You can also force a particular object or tributary endpoint
of a trail to switch to its protection path, for example, for maintenance
purposes. You can do this via the path protection switch feature in the Path
Protection Switch window.

Figure 8-4: Path Protection Switch window
LightSoft views and manages all path switches of a trail, even those not at the
trail endpoints. The functions are those offered by the NE, with the advantage
that they are presented from the trail's perspective.
LightSoft provides several options for protection switching:
Manual: Temporary protection switching from the active to the backup
object. If conditions do not require automatic switching, traffic is restored
to the original object.
Forced: Permanent protection switching from the active to the backup
object, regardless of whether the conditions require automatic switching.
Traffic is restored to the object once the action is released.
Lockout: Protection switching from the active to the backup object is
prevented, even if conditions require automatic switching. Lockout remains
in effect until the action is released.
soll.
soll.


Maintenance at the EMS Level
via GCT
EMS-level maintenance is done directly from the EMS or via LightSoft's GCT.
Capabilities include:
Reset Transmission Card: If a transmission card is not functioning
properly (and you do not suspect hardware problem), you can perform a
"warm" (non traffic affecting) or "cold" (traffic affecting) reset.
View Maintenance Operations: The Maintenance Info window displays
the objects that have had maintenance operations carried out sorted by
operation type. Maintenance parameters are configurable at the EMS level.
View Optical Card Parameters: The Optical Parameters window
displays the optical parameters for selected optical cards in histogram and
numeric forms.

Figure 8-5: XDM Optical Parameters window
Routine EMS maintenance operations may include maintenance of cards,
transmission objects, timing/TMU objects, MSP/APS, MS-SPRing/BLSR, and
SNCP/UPSR, and xMCP/MXC synchronization in the XDM platforms.
CFM at the EMS level includes the following fault management functions:
Continuity Check Protocol messages (CCM): checks for continuity,
incorrect network connections, and other defects.
Loopback Protocol: verifies bidirectional connectivity for MIPs and/or
MEPs.
Link Trace protocol: traces a path to the target MEP, and enables fault
isolation.
soll.
soll.


The following figure illustrates a CFM configuration window in the
EMS-XDM, showing the CoS for Provider, Operator, and Nested Operator
groups in the tree on the left.

Figure 8-6: CFM configuration
soll.
soll.


Embedded Software
Management
Management of equipment-embedded software is a functionality of all the
EMSs and one of their major roles. Management tasks include database
backup, version load, version activation, and correspondence check.
The following figure portrays the Activate Time tab, showing the activation
time retrieved from the NE.

Figure 8-7: Embedded version management
The EMS-BGF offers a backward-compatibility feature. Newer versions of the
EMS-BGF manage embedded software going back two versions. Software
releases can incorporate a comprehensive set of new features together with
revisions to earlier features, and the new software is able to continue working
smoothly with the current embedded software. Minor upgrades to the
EMS-BGF are not traffic affecting.
Backward compatibility in the EMS-BGF minimizes the need for upgrades to
the embedded software. A table of supported versions is provided in the
EMS-BGF release notes. When an upgrade to the embedded software is
necessary, the EMS-BGF provides an EMB Software Upgrade wizard that
simplifies the task.
soll.
soll.


The following figure illustrates two different versions of the embedded
software (V11 and V12) managed by the same EMS-BGF application.

Figure 8-8: Managing two different versions of the embedded software

soll.
soll.



In this chapter:
Overview ......................................................................................................... 9-1
User Security ................................................................................................... 9-2
Central User Administration ............................................................................ 9-6
Customer Network Management ..................................................................... 9-7
System Security ............................................................................................... 9-9
High Availability Clustering Solution ........................................................... 9-12
Geographic Redundancy for Disaster Recovery Plans .................................. 9-12
Client/Server Architecture ............................................................................. 9-15
Secure UNIX Environment ........................................................................... 9-16
Overview
LightSoft provides a full range of support features to keep your network
running smoothly and protected from unauthorized and malicious use. A
completely customizable and highly granular security hierarchy for system
administrators is based on what users can do (capabilities) and where they can
do it (domains). Security functions are in two main categories:
User security
System security
LightSoft supports field-proven redundancy applications and backup schemes
based on database replication. Multiple users can access the same LightSoft
system using its advanced client-server architecture. The system is highly
flexible and ECI Telecom can tailor the network management scheme to your
organizational and logistical needs.
9
User Management and
System Security
soll.
soll.


User Security
User security controls the persons having access to the system (user groups),
which operations these users can perform (capability profiles), and the
elements of the network on which these operations can be performed
(domains). Security features include user passwords, expiration dates,
automatic lockout mechanisms after predetermined inactivity periods or
unsuccessful login attempts, and control of password reuse. Domain granularity
reaches down to the port level, laying the basis for RDP services.
All LightSoft users are assigned to user groups, each of which is then paired
with a capability profile and a defined number of domains.
RDP enables you to divide a network into many different resource domains or
logical regions, each with its own capability and resources profile. You can
partition networks according to their geographical, organizational, or logistical
needs. Privilege allowances can be controlled with fine granularity down to
specific NEs, cards, ports, and HO CTP granularity, and for specific operations.
soll.
soll.


This method provides each client with the appropriate level of operational
control without infringing on the security needs of any other client. There is
less operational risk and controlled visibility - each user sees only relevant
resources. RDR helps reduce the top three sources of data loss: human error,
policy violation, and hacker attacks.

Figure 9-1: Resource Domain Partitioning
Profiles
LightSoft enables you to create profiles that define which operational
categories and specific functions selected users can access. These include
alarm management, trail management, and user creation.
LightSoft also supports resource-only profiles, where privileges apply to a
specific resource, for example, a specific type of element or card. Multiple
resource-only profiles for multiple resource domains can be assigned to the
same user group.
The profile is the sum total of all selected capabilities. Capability profiles are of
precise granularity, enabling exact definition and complete flexibility.
LightSoft provides numerous default capability profiles and you can also create
new profiles with more specific definitions. For example, a profile with limited
access to certain operations except for specific resources. In general, resource
profiles are used to override general user profiles in specific circumstances.
soll.
soll.


Profiles are displayed in the Profiles tab of the Security Configuration
window, as shown in the following figure.

Figure 9-2: Security Configuration window
soll.
soll.


Resource Domains
Each user group is assigned a profile and a number of resource domains.
Members of the group can perform only the functions stipulated in the profile
and only on the assigned resource domains.

Figure 9-3: Add Resource Domain window
Lockouts and Fast Login
If no activity is detected at a client station over a time configurable per user
(timeout period), LightSoft automatically locks the user client session or logs
out the user from the client. The user session at a client can also be locked by
the user manually. Open windows and work-in-progress are then hidden from
view. Users unlock the session by entering their login details.
When a user session is locked, another user who is a member of the same user
group can log in from the same client, in effect forcing logout of the original
user. In this case, a "fast login" process applies, which may reduce the login
time to seconds. In larger networks you can save time by logging in this way.
An authorized user can force another user to log out from a client, for example,
in order to log in a different user. The target user is notified of the action and is
immediately logged out.
soll.
soll.


Concurrent Users
A distributed software architecture, which includes adoption of the
client-server model, allows you to give multiple users the capability to access
LightSoft simultaneously. Combined with a true multiconfigurator feature that
enables users to manage and work on the same NEs in parallel, this greatly
increases LightSoft's availability, scalability, and economic benefits. You can
limit the number of users per group concurrently logged in, thereby controlling
usage of the client license.
Central User Administration
LightSoft offers a centralized user administration functionality that is
especially useful for large enterprises. Complex organizations often incorporate
multiple controlled-access systems that require secure logins. Centralized user
administration systems such as Lightweight Directory Access Protocol (LDAP)
and Remote Authentification Dial-in User Service (RADIUS) greatly simplify
these tasks.
LDAP is a popular protocol for accessing on line directory services. It is
typically used as an enterprise-wide database, providing a single way to add
and remove users in all user programs. LDAP is also effective for enforcing
user security policies.
Instead of the LightSoft server, an LDAP server can be used to add/remove
users and configure authorization levels. LightSoft supports multiple working
configuration options, including the use of a backup LDAP server and fallback
to local authorization as needed.
soll.
soll.


Customer Network Management
With CNM, SPs can lease exclusive network resources to customers for
self-management. This sophisticated scheme allows both the autonomous end
customer and the SP to concurrently manage alarms and performance,
provision services, and handle maintenance operations on the resources.
For example, a CoC can lease out portions of the network to other carriers that
can independently provision and monitor services. The network operator
configures the level of control available to each customer.
CNM offers carriers the revenue-generating opportunity of selling CNM as a
value-added service. Additional revenue is available for carriers, Utelcos, and
SPs via enhanced utilization of network resources, e.g., simple and secure
subleasing of unused bandwidth. In addition, since a significant part of the
network management effort can be offloaded from the SP to its customers,
OPEX is significantly reduced.
Implementing LightSoft's CNM opens up a whole world of possibilities for
network operators, including:
Networks can be partitioned to Resource Domains made up of individual
NEs, ports, or Connection Termination Points (CTPs).
Network operators can be assigned Resource Domains and have their own
User Groups.
Network operator users can belong to User Groups with high-granularity
capabilities, including:
Viewing and navigating the topology within their domain.
Provisioning trails within their domain only.
Viewing alarms and events within their domain only.
PM for their services only.
Encapsulation features include:
No visibility to the rest of the network/users. CNM users see their
domain resources only.
CNM users may be prevented from accessing the EMS.
Resources are visible to the SP but only the CNM user can use them for
provisioning.
soll.
soll.


CNM capabilities yield appreciable cost savings with no compromise on data
security provided by:
Low-cost Windows-based PCs running X-Window emulation software
such as GoGlobal for CNM clients.
Low-cost connectivity via the Internet.
Secure connection via the SP's VPN (and firewall).
Encapsulation of the CNM user using a dedicated host with a specially
restricted UNIX user.

Figure 9-4: Typical CNM configuration
soll.
soll.


System Security
System security is provided through a comprehensive mesh of protective
mechanisms. Operating security includes secure system settings combined with
hardening policies for user authentication and login procedures, for example,
intelligent password restrictions, user action logs, and an optional keyboard
lock feature. Network security mechanisms incorporate integrated protection
on multiple levels, including ICMP protocol, IP layer, and TCP layer. In
addition, security measures are applied at the UNIX level to comply with
system security guidelines of major carriers. System services are carefully
monitored and restricted to minimize vulnerability. Depending on customer
requirements, additional optional measures are available, such as more user
authentication restrictions, FTP service hardening, file and mail restrictions,
and optional filters and locks. Integration with special customer security
policies and infrastructure can be provided upon request.
LightSoft enables you to set certain system defaults for security management.
Parameters include:
Minimal password length: Shortest acceptable length for account
password
Default password expiration: Number of days after which user passwords
expire
Password reuse history: Number of times a user account can use same
password
Default inactivity timeout: Specified length of time (minutes) after which
a user is automatically logged out
Max. unsuccessful login attempts: Number of consecutive invalid login
attempts permissible for each user
Login reactivation: Specified number of minutes after which a user
account is reactivated after being disabled due to unsuccessful login
attempts
Strong password enforcement: Checks, including length, content, and
mixed use of alphanumeric characters
soll.
soll.


Figure 9-5: Security Configuration window (Preferences tab)
Setting the NE Password
Some NEs have an NE Password feature preventing unauthorized configuration
changes via its craft terminal. Users wanting to change the configuration must
first submit the NE password (if assigned).
soll.
soll.


Activity and Security Logs
LightSoft enables you to view the history of actions and configurations
performed from the system. You can monitor user actions via the following
logs:
Activity Log: User operations, including topology (e.g., creating a trail) and
security operations (e.g., creating a user or a resource domain).
Security Log: User system accesses and password definitions.
Log records are accessed directly from LightSoft windows without having to
use Unix commands. They display the time, date, and user name of an
action/occurrence.

Figure 9-6: Activity Log window
You can filter which types of activities to view. Some of the actions listed in
the Activity log include:
Creating and editing trails
Maintenance actions (loopback, reset, send AIS, etc.)
Creating and deleting NEs
Assigning slots (viewable via an EMS)
Once the age or number of log records exceeds a predefined threshold, they are
automatically removed from the database and exported to an XML file.
LightSoft style sheet files allow exported XML log files to be displayed in a
user-friendly format via Microsoft Excel.
The EMS-XDM maintains an Action History file which includes all activity at
both the EMS and NMS levels. Records include timestamp, user name, the
original attribute value, and the new value.
soll.
soll.


The STMS offers a choice of eight NE logging levels, ranging from Notice up
to Emergency, configurable per NE. Logging levels are defined in a hierarchal
structure. All messages of a severity equal to or greater than the selected level
in the hierarchy are displayed.
High Availability Clustering
Solution
The LightSoft cluster solution provides high availability and load balancing,
essential features for large networks and/or mission-critical management.
The load balancing feature automatically divides the load from NMS processes,
EMS interfaces, and client applications between all cluster nodes. High
availability configuration distributes NE management between cluster nodes.
Software resiliency is provided through software process redundancy. In the
event of a software process failure, service is automatically switched without
any traffic interruption.
Geographic Redundancy for
Disaster Recovery Plans
ECI Telecom's management portfolio includes Remote Database Replication
(RDR), a field-proven flexible redundancy mechanism providing full network
management backup capabilities for Disaster Recovery Plans (DRPs). RDR can
be configured in a wide variety of topologies. It provides optimal protection
consistent with geographic infrastructure distribution, security needs, and
available budget for standby mirror hardware. RDR can be used for:
Data protection
Disk protection
Host protection (primary and mirror sites connected via LAN)
Site protection (primary and mirror sites connected via long distance link)
LightSoft and other ECI Telecom EMS applications use duplicate management
hardware with one station serving as the active site (primary server) and the
other as the standby site (backup server and mirror). One standby site can act as
a backup for multiple stations (1:N).
soll.
soll.


RDR performs periodic remote data backups (replication) between primary
stations and the backup server. The backup data can subsequently be restored
(synchronized) on a mirror station (remote redundant station replacing failed or
deactivated primary components). To make the backup process efficient, a
system of incremental backups at three different levels (including only changes
since the last replication) are included.
If a failure occurs in the active site, you quickly switch over to the standby site
and resume management of the network. The LightSoft and EMS-XDM
databases' signature feature intelligently updates the standby site with all NE
configuration data that has changed since the last replication. When the primary
server is restored, you can initiate a replication from the standby site in order to
preserve any changes made while the primary server was down.
A client workstation can be connected over the same LAN to both the active
and standby sites, so a client session can always be initiated on the station
presently managing the network.
RDR offers a combination of security, reliability, and simplified monitoring
capabilities, including the following mechanisms:
Secured Shell-based (SSH) authentication and transport for every
remote operation and transaction.
Application versions automatically compared on restore. If the main
and backup application versions differ, the restore operation stops
automatically.
Restore operations blocked if the application is running. Before
restoring the database, RDR verifies that the application is not running. If
the application is running, the restore operation is automatically blocked.
Backup and restore activity logs maintained to enable tracing of RDR
activity.
Automatic alarm notifications sent to client screens. For example, if a
backup fails, a warning message automatically appears on the client
monitor.
Backup activity monitor window displays backup and transfer status of
the different application instances.
soll.
soll.


Figure 9-7: System redundancy
RDR's shadow feature provides automatic backup of protected applications by
the backup server to several other preassigned backup (shadow) servers
(cascade mode). This ensures continued functioning even when multiple
servers fail.

Figure 9-8: RDR Shadow backups
soll.
soll.


Client/Server Architecture
The LightSoft network management suite implements an advanced
client/server software architecture that supports a large number of processes.
The NMS server can be run on either single or multiple workstations. This
distributed architecture enables you to scale easily, as well as provide high
availability and load balancing. LightSoft supports dozens of concurrent
clients. The multiconfigurator feature of LightSoft gives each operator the
means to initiate sessions and manage the network simultaneously, either in
whole or in part.
Solaris Containers and Zones
LightSoft fully supports the Solaris
10 system, taking advantage of advanced

OS features such as virtual containers, dtrace, predictive self-healing, higher
performance, and built-in security. Moreover, by supporting Solaris 10,
LightSoft can be installed on the most advanced Solaris platforms.
In today's fiercely competitive business environment, it is essential to cut
expenses and improve efficiency. Server consolidation lowers costs by
reducing the hardware and system administration required to run applications.
However, you need to provision applications with the appropriate resources on
a shared system. Solaris containers allow you to prioritize applications and
control resource usage. Computing resources CPUs, physical memory,
network bandwidth, etc. can be dedicated to a single application and then
shared with others in an instant, without moving applications or rebooting the
system.
You can host multiple applications on one system and use expensive
resources to greater effect.
With Solaris containers, your organization can gain control and establish
isolation mechanisms to improve resource utilization.
Each application can run in its own private environment, virtually
eliminating error propagation, unauthorized access, and unintentional
intrusions.
With its fine control granularity, Solaris containers ensure that all
workloads access the appropriate amount of computing resources and
that no workload is able to consume the entire system unless authorized to
do so.
soll.
soll.


Secure UNIX Environment
LightSoft's UNIX operating system environment has been hardened to protect
it from hacking and intrusions, unauthorized access to sensitive data, and
damage to normal system functionality by mistaken or ill-intentioned users.
In order to meet different customer security requirements, the system can be
installed in one of three security levels:
Level 1: Compulsory industry-standard security rules implemented at
installation, including repairs for all known operating system security
flaws, hardening of system and network services, user authentication, and
file systems, as well as logging facilities to detect intrusions. Level 1
elements include kernel security settings, password protection for all
accounts, unique UID for all user accounts, and secured inetd services,
RPC services, network configuration, and file system configuration. It also
contains some restrictions on FTP services and disabling of unnecessary
system services (such as NFS and SNMP).
Level 2: Two sublevels of optional security hardening actions set during
system configuration. Each includes additional user authentication, network
and file system restrictions like password time expirations for all users and
disabling of PPP and sendmail functionalities.
Level 3: Additional optional security measures requiring special tools,
including the implementation of firewalls, IP Tunneling, VPN, RAS, NAT,
etc. These measures are implemented under ECI Telecom supervision.
Network Time Protocol (NTP) is used to synchronize the clocks in computers,
routers, network elements, and network management applications. LightSoft
and the EMSs can be configured as NTP clients, and the EMSs then configure
the time and date to their respective managed NEs. In addition, the STMS
supports symmetric, broadcast server, and broadcast client modes.

soll.
soll.



In this chapter:
Overview ....................................................................................................... 10-1
MTNM-Compliant CORBA Interfaces ......................................................... 10-2
MTOSI Northbound Interface ....................................................................... 10-3
SNMP Gateway ............................................................................................. 10-4
SQL Database Access .................................................................................... 10-5
XML Interfaces.............................................................................................. 10-6
Alarm Interfaces ............................................................................................ 10-6
Interfaces and Management Transparency at the EMS Level ....................... 10-6
Java RMI ....................................................................................................... 10-7
Overview
ECI Telecom's comprehensive network and element management systems
include standard interfaces which enable integration with basically any OSS in
the market. Operations such as fault handling, service provisioning, inventory
management, and billing for ECI Telecom NEs can be performed via interfaces
with external OSSs.
10
Management Interfaces
soll.
soll.


MTNM-Compliant CORBA
Interfaces
LightSoft features both northbound and southbound interfaces to transfer data
externally and to integrate your management system into almost any network
environment.
LightSoft supports the TMF MTNM standard TMF-814 for transferring data
to/from diverse EMSs/OSSs. MTNM is a standard architecture environment
bringing SDH/SONET, Ethernet/MPLS, DWDM, and ATM together into one
management interface. The MTNM protocol is a cooperative effort by member
companies of the TMF, a non-profit global organization providing leadership,
strategic guidance, and practical solutions to improve the management and
operation of communications services.
LightSoft uses MTNM for both its southbound interface (to manage its own
and other vendor equipment) and northbound interface (enabling LightSoft to
be managed by other MTNM systems).
Some of the information transmitted south- and northbound via MTNM
includes:
Fault management, with full alarms, threshold crossing alerts, and event
reporting
Current performance data
Unsolicited information and automatically initiated new network alarms
Topology, with network configuration and discovery capabilities,
including:
Optical trail discovery
SDH/SONET trail provisioning
Ethernet services provisioning
Status information
Equipment inventory
GCT
OAM commands from the upper system
Multitechnology traffic provisioning and management, including E2E
connection display
Protection management
soll.
soll.


LightSofts northbound MTNM compliant CORBA interface allows it to be
integrated under leading network management systems and, according to
commands received from the upper-level manager, to create, edit, and delete
E2E SDH/SONET and Ethernet trails using its Pathfinder algorithm.
LightSoft also uses MTNM for its southbound interface to EMS systems,
allowing top-down management of connectionless Ethernet/MPLS services and
ASON networks. The MTNM IDL Solution Set is an enhanced version of the
TMF-814 standard interface between the NMS and EMS that enables
management of SDH/SONET, DWDM, ATM, Connectionless
(Ethernet/MPLS), and ASON Control Plane-based transport networks. This
interface covers provisioning, current PM data, and trail maintenance
operations, as well as fault and inventory management. The MTNM interface
also provides comprehensive informative alarms fields, including:
Alarm correlation information
ME identification information
Information about affected trails
MTOSI Northbound Interface
LightSoft supports a northbound MultiTechnology Operations Systems
Interface (MTOSI). The LightSoft implementation is based on TMF-854, a
standard protocol for MTOSI Release 1.1. MTOSI is based on XML Web
services, next generation operations support system (NGOSS), and
service-oriented architecture (SOA) design principles. MTOSIs benefits
include improved service delivery across diverse networks, reduced
development and integration costs, faster time to market for new services,
lower deployment risk, reduced integration costs, and easier maintenance and
testing.
In comparison to CORBA-based interfaces, MTOSI reduces development and
integration costs, allows faster implementation, and reduces deployment risks.
The advantages of using Web services enabled through XML SOAP are
particularly clear in the areas of interoperability across platforms and
languages, and in its use of easy-to-understand open standards and protocols.
LightSoft's MTOSI interface supports fault, inventory, and service activation
integration with OSS systems.
soll.
soll.


SNMP Gateway
Simple Network Management Protocol (SNMP) is the most popular fault
management interface due to its simplicity and ease of use. LightSoft supports
an SNMP interface for alarms (both SNMP V2c and SNMP V3) through the
SNMP GW.
SNMP GW is an interface adapter translating CORBA-MTNM alarms into
SNMP traps. This simplifies OSS integration with ECI Telecom applications
like LightSoft or EMS-XDM. Supported features include:
Intuitive GUI for simple SNMP GW configuration.
Alarm filtering according to NE, equipment, severity, and probable cause.
Heartbeat periodic trap (keep-alive daemon, configurable, default 5 min.)
keeps the OSS constantly aware of SNMP GW application status.
OSS synchronization mechanism, based on an incremental TrapID
attribute that enables the OSS to discover any gaps and repeat requests for
all current alarms if necessary.
Basic elements reference database, enables the OSS to map received
alarms to the appropriate objects in the OSS map.
The SNMP GW is a product add-on to LightSoft and is a separate installation
that runs on Solaris platforms. Since it is designed as a simple add-on,
installation is simple and configuration is via a GUI or CLI user interface.
soll.
soll.


It is possible to enter several IP addresses when configuring destination
addresses. The SNMP GW constantly pings the NMS/EMS. If it loses the
connection, it restarts and receives all the active alarms at startup. These alarms
are then sent to any application connected to the GW that is listening for SNMP
traps. (The only information transferred to and from the SNMP GW are
alarms.)

Figure 10-1: SNMP GW included in network configuration
SQL Database Access
LightSoft enables you to use SQL tools to query its databases. Access to the
management databases is provided for customized external applications.
Information tables are created online on the LightSoft disk in response to
external requests.
The information relates to the customers functional needs, such as queries on
equipment inventory, various NE attributes, full topology, trails, tunnels,
services, and customer information. The data is provided in a simple predefined
format. LightSoft provides read-only access, supporting written SQL queries
and a common online connectivity interface via JDBC on Solaris platforms.
soll.
soll.


XML Interfaces
LightSoft enables you to perform batch operations through the GUI or CLI by
importing and/or exporting data from/to XML files. Trails, tunnels, and
services are handled via the CLI. NEs and slot assignments are handled through
the GUI GCT, using the EMSs.
These XML files can be stored as contingency plans and reimported into the
system at any future time. You can select ports and resources occupied by other
trails, since no trails are downloaded to the network at that time. Exported trails
may be appended to an already existing file.
This powerful functionality automates time- and resource-consuming
operations. It can also be used to connect with network planning tools.
Alarm Interfaces
LightSoft provides a variety of alarm interfaces, such as alarm export to OSS
using CORBA-MTNM, MTOSI, and SNMP, as well as alarm export via FTP,
SMS, and email. See Exporting and Forwarding Alarms (on page 4-14).
Interfaces and Management
Transparency at the EMS Level
ECI Telecom's network management solution supports smooth interfacing and
management transparency between LightSoft and the various EMS
applications. As open systems, the EMS applications all support MTNM-based
CORBA TMF-814 northbound interfaces. EMS applications can be integrated
with and managed by any standard-compliant NMS.
Some of the information transmitted via MTNM includes:
Fault management, with full alarms, threshold crossing alerts, and event
reporting
Most current and historical performance data
Unsolicited information and automatically initiated new network alarms
Network configuration and discovery capabilities for cross-connects,
identified NE by NE
Status information
Equipment inventory
Protection management
GCT invocation
soll.
soll.


The EMS applications can all be integrated with third party SNMP-based fault
management systems, sending alarms through an SNMP gateway (on page 10-
4). The EMS-XDM can also export alarms in a flat ASCII file via FTP, thereby
simplifying integration with a higher level alarm management system.
The EMS-XDM and EMS-BGF support NE setup and slot assignments as well
as service and cross-connect creation, editing, and deletion. These tasks can all
be completed individually or using XML batch files. The XML files include
the information necessary, and can be used to interface with an external site
planning tool. This can be a very efficient way of mass configuring a network,
as described in Creating NEs and PEs (on page 3-2).
The EMS-XDM and EMS-BGF collect PM history files at configurable
intervals from ports and objects in the network. Performance data reflects the
running quality of the network. Effective PM at the EMS level enhances QoS
for the whole network. This data can later be retrieved and analyzed, serving as
the basis for network surveillance, accounting, billing, or SLA applications.
The data is stored in files that may be retrieved remotely in ASCII, CSV, or
XML format or via the EMSs northbound CORBA TMF-814 interface.
Java RMI
STMS provides seamless integration with existing OSS applications via an
extensive northbound application programming interface (NB-API) that
supports Java Remote Method Invocation (RMI). NB-API offers access to a
comprehensive set of provisioning and element management functions. Any
action that can be performed by the operator in the STMS GUI can be
programmed through the NB-API.
The STMS event manager is responsible for receiving event messages from
CESR 9000 series switch routers and routing the messages to subscribed client
applications. Messages can pertain to alarms, device trace events, and state
change events. Any northbound OSS/NMS client can subscribe to specific
types of event messages (such as fault integration messages) over JMS.

soll.
soll.



In this chapter:
Overview ....................................................................................................... 11-1
EMS-XDM .................................................................................................... 11-2
STMS ............................................................................................................. 11-4
EMS-BGF ...................................................................................................... 11-9
EMS-ATS .................................................................................................... 11-12
Generic EMS ............................................................................................... 11-16
Overview
As an NMS for large networks, LightSoft acts as an umbrella for multiple
EMSs. Many different EMSs can be managed by one LightSoft application.
The GCT feature (see "GCT to EMS" on page 2-15) enables you to access
EMS information or perform EMS operations on selected objects easily and
efficiently without having to start an individual EMS session. You
communicate with these EMSs via management interfaces (on page 10-1), with
proprietary extensions where relevant. This section provides a quick overview
of the various EMSs available from ECI Telecom.
11
Element Management
Systems
soll.
soll.


EMS-XDM
The EMS-XDM provides full-feature XDM support. It functions at the element
management layer (EML) in ECI Telecom's network management scheme and
can operate directly under the LightSoft network management system.
EMS-XDM has been designed as an open system in compliance with the
CORBA MTNM standard. The EMS-XDM may be colocated in the same
platform, operate as a standalone application, or integrated in a non-ECI
Telecom NMS or TMN umbrella system. It can control hundreds of different
XDM NEs at a time, and supports a wide range of management functions,
including alarms, configuration, inventory, provisioning, and security
management.
The EMS-XDM supports multiple technologies, including:
SDH/SONET and PDH/Async
Optics
Data: ATM, Layer 1 and Layer 2 Ethernet, MPLS
The EMS-XDM's user-centric design has produced a clear, intuitive graphic
user interface that simplifies network management. Network elements can be
viewed from three perspectives; a clear graphic representation of the network
map; a hierarchical tree topology that enables easy Any-to-Any navigation to
any NE or network component, including direct access to shelf and card; and a
shelf view that enables simple management per shelf through a single
context-sensitive configuration window.

Figure 11-1: EMS: three network perspectives
soll.
soll.


Configuration and Provisioning in the
EMS-XDM
You can configure MPLS tunnels and Ethernet/VPLS services, as follows:
Provisioning and monitoring MPLS tunnel segments for Ethernet
service, also known as MPLS XCs. A fully functional traffic-engineered
MPLS tunnel can be formed by provisioning the ingress (head), transit, and
egress (tail) MPLS segments along the tunnel path. This includes tunnel
QoS associations, FRR protection, OAM for tunnel connectivity
verification, and more.
Provisioning and monitoring VPLS VSIs. An Ethernet bridge/switch
instance binding an Ethernet service endpoint with all service parameters to
MPLS. A fully functional VPLS can be formed by configuring its
representative VSIs on the PE endpoint cards, where the customer connects
through Ethernet ports. This includes VLAN to VSI associations, 802.1p to
CoS mappings, per-VPN policing, VSI to MPLS tunnel binding, and more.
Provisioning and monitoring Ethernet services. Accomplished through a
mechanism similar to the VPLS implementation, with no binding to MPLS
tunnels.
A graphic display of the XCs makes editing in the EMS-XDM easy. Simply
point and click at cards and endpoints and activate them. For additional ease of
use, the cross-connection window is intuitive. Mass provisioning is possible via
batch files or an activate series.
Auto-discovery
The EMS-XDM supports the following auto-discovery capabilities:
Automatic card assignment
Automatic NE recognition
Automatic topology link discovery
Automatic card assignment can be done manually and automatically. In
automatic mode, cards and modules inserted into managed NEs in the field are
automatically recognized by the EMS-XDM and assigned as a background task
according to user-defined tables. This feature can also be applied manually to
selected NEs. The end result is the same: you no longer need to assign each
card or module as physical insertion automatically triggers this action.
With automatic NE recognition, each NE appears on the screen, eliminating the
need to create it manually. New NEs are automatically transferred to LightSoft
or any other NMS via the CORBA interface.
soll.
soll.


The automatic topology discovery feature is based on a new implementation of
the J0 byte. When activated, SIO-to-SIO or OSC bidirectional links (in
SDH/SONET networks) are automatically identified by the EMS-XDM and
uploaded to the NMS layer via the MTNM interface. LightSoft automatically
displays such links when managing EMS-XDM, eliminating the need to
manually define topology links at the NMS level. In addition, an EMS-level list
of links is provided for viewing and deleting automatically created links.
STMS
The ShadeTree Management System (STMS) is the enhanced EMS for the
9700 series switch router, the 9600 series router, and the 9200 series
aggregation switches and demarcation devices. STMS is a comprehensive
carrier-class element management system as well as service provisioning and
monitoring solution. The user-friendly GUI offers flexible operator views and
an intuitive interface that simplifies network operator tasks.
STMS reduces the time to provision MEF-based E-Line and E-LAN services
and IP VPN services by providing GUI-based provisioning wizards that
automate the provisioning process and ensure transactionally consistent
provisioning. STMS supports configuration of bidirectional MPLS-TP static
tunnels, including bypass and FRR. STMS also supports configuration of
E-Line and E-LAN services based on the underlying static tunnels. Operators
can also create RSVP dynamic LSPs using either the STMS GUI or the Java
northbound interface. And the Commissioning Tool makes it easy to configure
core side interfaces of SR9700 routers.
STMS offers advanced troubleshooting and OAM tools to detect and resolve
network issues such as Ethernet service failures, inconsistent QoS,
misconfiguration, incorrect software versions, and disconnected interfaces.
STMS provides full support for OSPF, IS-IS, LDP, RSVP, and MPLS
configuration and monitoring. STMS also gathers, processes, and stores
statistical information that is collected by 9600/9700 platforms to generate
complete and accurate accounting, billing, and SLA management.
soll.
soll.


STMS integrates smoothly with ECI Telecom's LightSoft 360 Management
System. In networks where third-party NMS or OSS systems are deployed,
STMS can be easily integrated into the existing management environment. The
distributed processing architecture located on each system element is naturally
able to scale with a growing system. The modular architecture enhances
reliability.

Figure 11-2: Layered management system
soll.
soll.


STMS Features
STMS can configure up to 300 network services simultaneously and support up
to 1.6 M Layer 2 P2P services (16 K/2 Layer 2 services per NE, for up to 200
NEs). STMS is based on a combined hardware and software platform design
able to support multiple simultaneous accesses from multiple locations with no
deterioration in response time.

Figure 11-3: STMS GUI features
STMS can be tailored to meet network service requirements and preferences.
For example, network QoS policies can be configured and managed with the
configuration exportable to a backup file. STMS supports flow and service
provisioning in the EMS and integration in the OSS. Supported services
include residential (HSI, voice, and video) and corporate services (Layer 3
MPLS VPN, Layer 2 VPN, Internet leased lines, video conferencing, and
voice).
soll.
soll.


A comprehensive information and alarm service includes:
Events collected in real time.
Alarm details presented in real time, with a history database maintained for
future reference.
Clearly distinguishable alarm severity; user-friendly alarm presentation.
Alarm definitions and levels tailored to operator specifications, including
threshold definitions, alarms by services, and customized alarm views.

Figure 11-4: STMS typical use: viewing operational status per service
soll.
soll.


Per-Device Management
STMS maintains a model of the managed network within its database
consisting of a set of managed objects representing the various elements. These
include physical (chassis, line card, port), logical (logical interface, protocol
family), abstraction of the network (subdomain, group), entity interacting with
the network (customer, subscriber), or services provided by the network (E
Lines, E-LANs, Layer 3 VPNs).
STMS uses the model to track the current state of the network and perform
fault, configuration, performance, accounting, and security management tasks
on the managed objects.
The STMS client is a Java-based GUI from which operators can manage,
provision, and monitor NEs to ensure maximum network stability and
eliminate configuration errors. It augments the traditional CLI and features:
Network explorer and customer explorer views that show interfaces,
services, and associated customers
Commissioning Tool
QoS explorer
Service explorer
Configuration manager
NE Credential management for 9200-series devices
Map and layout views of NEs
Cabinet view of each NE with the current card configuration
Alarm panel showing alarms that have occurred and subsequent user
acknowledgments
The STMS client can run as a standalone application on Windows, Linux, or
Solaris operating systems.
ShadeTree software allows you to monitor operation of the switch router
through Simple Network Management Protocol (SNMP) (read access only).
The switch router supports a wide range of Management Information Bases
(MIBs), described in Simple Network Management Protocol.
soll.
soll.


EMS-BGF
The EMS-BGF provides full-feature support for BroadGate, BG-Wave, and
CESR BG9300 platforms. The EMS-BGF functions at the EML in the TMN
scheme directly under LightSoft. It is designed as an open system in
compliance with the MTNM standard provided by CORBA.
ECI Telecom has enhanced the functionality and scalability of element
management in EMS-BGF V10 and above to the level of a carrier grade
application, providing a state-of-the-art GUI and superior user experience.
EMS-BGF V10 and above is based on Java together with a relational database,
allowing it to run on multiple platforms (e.g., Microsoft Windows, SUN

Solaris) and support multiple operators concurrently.
Having a robust architecture enables the EMS to support hundreds of NEs at a
time, letting customers expand their network without the need to install more
EMSs.
The EMS-BGF supports the entire FCAPS requirement, providing a wide range
of management functions (alarms, configuration, inventory, provisioning, and
security).

Figure 11-5: Platform view as displayed in the EMS-BGF
soll.
soll.


The EMS-BGF supports two modes: integrated and standalone. Integrated is
available only with the appropriate license. The EMS-BGF provides full EML
functions and is integrated with LightSoft that provides NML functionality.
This mode is suitable for large networks and those containing ECI/vendor
products in addition to BG NEs. In standalone mode, the EMS-BGF provides
full EML functionality and several NML functions, including network topology
management and E2E SDH/SONET trail management. Standalone mode is a
very low-cost solution for small networks containing only BG NEs.
NE Simulator
EMS-BGF applications installed on Windows systems offer a useful
NE Simulator that simulates the behavior of a real NE under current network
conditions. NE behavior can also be simulated under different circumstances.

Figure 11-6: NE Simulator
soll.
soll.


FE Utilities
EMS-BGF applications installed on SPARC and x86 systems provide a
complete set of FE utilities (ping ne, logout user, change neid, etc.) to help field
engineers monitor and troubleshoot basic network operations. For more
information, see the EMS-BGF User Manual.

Figure 11-7: FE utilities on the EMS-BGF
soll.
soll.


EMS-ATS
The EMS-ATS is the network management application for ATM functions
supported by the ATS card. It includes several types of services. Some support
specific EMS-ATS functionality (fault management, provisioning) while others
are general core services within the EMS-ATS (logging services, Security
Manager). The following figure shows the main EMS-ATS window.

Figure 11-8: EMS-ATS main window
soll.
soll.


The EMS-ATS is part of LightSofts layered management architecture. Via
LightSoft's GCT, you can drill down directly from LightSoft through the
EMS-XDM to the EMS-ATS. All three applications can be displayed and
managed through a single LightSoft interface, shown in the following figure.

Figure 11-9: EMS-ATS via LightSoft: seamless integration
The EMS-ATS continuously monitors the network and provides information
for detecting, recording, analyzing, and reporting faults and events. Thanks to
the integrated MTNM interface, current alarms are always visible via the
LightSoft banner.
New nodes can be added to the EMS-ATS through autodiscovery or manual
addition of an ATS card using the client GUI. Use the Auto Discovery dialog
box to define and perform a discovery operation in order to automatically add a
new ATS card to the EMS-ATS database. A range of IP addresses is searched
for ATS types. When one is discovered, it is added to the EMS database and
synchronized. The EMS-ATS then queries the ATS for information regarding
its internal topology and statuses (initial synchronization). The ATS Card
properties window displays the main parameters, even the IP address of the
XDM where the card is plugged in.
soll.
soll.


The EMS-ATS enables you to create, delete, modify, or retrieve connections of
type PVC, PVP, or VPL, with IMA PG:
Connections are created with their endpoints (one for ATM VPL/VCL, two
for most connection types) and connection attributes.
Connection information is retrieved.
Connections are deleted from the network and reserved resources freed.

Figure 11-10: Creating an ATM VC connection
soll.
soll.


The EMS-ATS manages activity logs for data tracking and offline analysis.
Each log has information and administrative attributes. The logs are initially
stored in the EMS-ATS database and, as they accumulate, manually exported
to preformatted text files and purged from the database. Log file management
is user-configurable.

Figure 11-11: Event log window
The EMS-ATS supports a full range of OAM, statistics, and performance
capabilities, for example, to isolate the root cause of an alarm. EMS-ATSs
intelligent filtering mechanism is implemented on three levels. Auto filter and
special filter options are also available.
The following interfaces are supported at the EMS-ATS, EMS-XDM, and
LightSoft levels:
MTNM interface to third parties or other OSSs
FTP export of alarms and PM ASCII files
SQL queries to the database
NBI Python scripts for ATM provisioning and inventory (EMS-ATS only)
soll.
soll.


Generic EMS
ECI Telecom is aware of the need for customers to have complete management
of all NEs, regardless of each ones specific functionality.
Guided by our open standards approach, ECI Telecom is offering the Generic
EMS to facilitate this strategy, providing a valuable solution to the entire
customer base.
While serving as a translator, the Generic EMS receives SNMP traps or events
from the NE and converts them to the MTNM protocol. It receives commands
from the NMS and delivers them to the NE. It can also be customized to serve
as a platform for specific project requirements.
The Generic EMS offers a cost-effective management solution, enabling
customers to have an integral view of their network with minimal integration
efforts and affordable licensing cost.
Generic EMS capabilities can benefit:
Network operators that want to cut their OPEX and simplify network
management integration with newly introduced NEs.
Network operators that want quick and simple integration with existing
SNMP-based equipment while leveraging the advantages of LightSoft.
The following figure illustrates the main screen of the Generic EMS.

Figure 11-12: Generic EMS main screen
soll.
soll.


Generic EMS Operation
The Generic EMS is a Java-based application run on a Solaris platform that can
manage up to 500 NEs in parallel in a single instance. Supported functionality
includes:
NE Management and Inventory: NE inventory down to the port level is
presented in the NMS topology.
Fault Management: All reported events, faults, and alarms are included in
the current alarm window of the NMS.
GCT: When device-specific actions such as configuration are required, the
NMS user can drill down to the NE and act from within the NE Local Craft
Terminals (on page 12-1).
NMS Trail Creation: XCs can be uploaded from the EMS for HO trails.
The Generic EMS enables you to see and manage the NE via its element
manager. The following figure illustrates a typical view of an AccessWave
element.

Figure 11-13: AccessWave management system view
soll.
soll.


The Generic EMS utilizes the same GUI style as LightSoft, offering the same
'look and feel' and thereby simplifying the user experience. This smooth GUI
integration is highlighted in the following figure.

Figure 11-14: Generic EMS in the Current Alarms window


In this chapter:
Overview ....................................................................................................... 12-1
LCT-XDM ..................................................................................................... 12-2
LCT-BGF ...................................................................................................... 12-3
LCT-ATS ....................................................................................................... 12-4
Overview
ECI Telecom offers a powerful suite of Local Craft Terminals (LCTs),
PC-based installation, maintenance, commissioning, and configuration tools for
field technicians. LCTs provide rapid direct connection to deployed NEs using
a standard serial interface. Each type of NE managed by LightSoft utilizes a
specific application (LCT-XDM, LCT-BGF, or LCT-ATS).
For smaller networks with fewer platforms, LCTs can be used as an
economical standalone EMS that includes a current alarm window, NE
database backup and restore capabilities, and current PM and TCA
configuration.
LCTs support all site functionalities: installation, port and XC provisioning, NE
commissioning (including slot assignment, IP routing, and DCC ports
configuration), and definition of cross connections, flows, and troubleshooting.
LCTs support alarm and event management, inventory, PM, security
management, system administration, and log management.
The system provides you with a clear view and control of NE internals, cards
and objects, status, and configuration. Access from the LCT is
password-protected. The intuitive Java-based interface is simple to use and
runs on Windows platforms.
12
Local Craft Terminals
soll.
soll.


LCT-XDM
The LCT-XDM is the application for XDM NEs, featuring:
A GUI client application running on a PC or laptop
A main window equipped with small-network manager capabilities,
displaying a list of multiple NEs and current statuses
Fault, configuration, cross connection, and performance management
functionalities
To prevent conflicts between operators in the NOC and LCT users in the field,
the EMS-XDM utilizes a handshake protocol. Through this mechanism, the
EMS-XDM explicitly authorizes one specific LCT user to start activities.
The LCT-XDM main window displays a topology list of NEs available in the
network and their current statuses.

Figure 12-1: LCT-XDM main window
The following figure illustrates a typical shelf view through the LCT-XDM.

Figure 12-2: LCT-XDM shelf view
soll.
soll.


Module labels in the LCT-XDM GUI are automatically coordinated with the
EMS-XDM GUI to keep the display synchronized. Synchronization is
completed transparently whenever the LCT is connected or disconnected.
LCT-BGF
The LCT-BGF is the PC-based BG field tool. The easy-to-use GUI provides
direct connection to deployed NEs using an Ethernet interface.
The LCT-BGF and EMS-BGF utilize the same GUI, offering the same 'look
and feel'.

Figure 12-3: Platform view as displayed in the LCT-BGF
soll.
soll.


LCT-ATS
The LCT-ATS is a flexible solution allowing you to manage an ATS card in an
XDM system from any location using in-band or out-of-band connections.
Click in the window to select any feature. To manage multiple ATS cards, use
the EMS-ATS.
Use the LCT-ATS to:
Create new connections between ports
View existing connections and their statistics
Configure an ATS card
Configure each port, interface, and protocol
Perform ATM OAM tests
View alarms and events for the system, card, and port levels
Download new software versions
Back up and restore the configuration database (CDB)
Configure ATM signaling
The LCT-ATS main application window is the primary interface between the
user and the ATS card. Its structured approach provides easy access to all
layers and levels of operation.

Figure 12-4: LCT-ATS main window
soll.
soll.


432006-2006-023-A00 ECI Telecom Ltd. Proprietary A-1

The primary reference documents for this General Description are:
1. IEEE 802.1ag: Virtual Bridged Local Area Networks Amendment 5 -
Connectivity Fault Management.
2. IEEE 802.1D: Media access control (MAC) Bridges (Incorporates IEEE
802.1t and IEEE 802.1w).
3. IEEE 802.1p: Traffic Class Expediting and Dynamic Multicast Filtering.
4. IEEE 802.3ah: Ethernet in the First Mile (Link OAM).
5. IETF RFC 1823: LDAP Application Program Interface (API).
6. IETF RFC 1901: Introduction to Community-based SNMPv2.
7. IETF RFC 2251: Lightweight Directory Access Protocol (v3)
[specification of the LDAP on-the-wire protocol].
8. IETF RFC 2252: Lightweight Directory Access Protocol (v3) - Attribute
Syntax Definitions.
9. IETF RFC 2253: Lightweight Directory Access Protocol (v3) - UTF-8
String Representation of Distinguished Names.
10. IETF RFC 2254: The String Representation of LDAP Search Filters.
11. IETF RFC 2255: The LDAP URL Format.
12. IETF RFC 2256: A Summary of the X.500(96) User Schema for use
with LDAPv3.
13. RFC 2474: Definition of the Differentiated Services Field (DS Field) in
the IPv4 and IPv6 Headers.
14. RFC 2597: Assured Forwarding PHB Group.
15. IETF RFC 2829: Authentication Methods for LDAP.
16. IETF RFC 2830: Lightweight Directory Access Protocol (v3) -
Extension for Transport Layer Security.
17. IETF RFC 3014: Notification Log MIB.
A
Reference Documents
soll.
soll.

A-2 ECI Telecom Ltd. Proprietary 432006-2006-023-A00

18. RFC 3246: An Expedited Forwarding PHB (Per-Hop Behavior).
19. IETF RFC 3377: Lightweight Directory Access Protocol (v3) -
Technical Specification.
20. IETF RFC 3411: SNMP Framework MIB.
21. IETF RFC 3414: SNMP User-Based SM MIB.
22. IETF RFC 3415: SNMP Vies-Based ACM MIB.
23. ISO 9001: Quality Management System: Requirements.
24. ISO 14001: Environmental Management Systems - Requirements With
Guidance for Use.
25. ISO 17025: General requirements for competence of testing and
calibration laboratories.
26. ISO 27001: Information Security Management Systems: Requirements.
27. ISO/IEC-9595, Information Technology: Open Systems Interconnection,
Common Management Information Services.
28. ISO/IEC-9596, Information Technology: Open Systems Interconnection,
Common Management Information Protocol.
29. ITU-T G.774 and G774.n: SDH Information Model.
30. ITU-T G.784: Synchronous Digital Hierarchy (SDH) Management.
31. ITU-T G.803: Architectures of Transport Networks Based on the
Synchronous Digital Hierarchy.
32. ITU-T G.805: Generic Functional Architecture of Transport Networks.
33. ITU-T G.809: Functional Architecture of Connectionless Layer
Networks.
34. ITU-T G.831: Management Capabilities of Transport Networks Based
on the Synchronous Digital Hierarchy (SDH).
35. ITU-T G.872: Architecture of Optical Transport Networks.
36. ITU-T G.874: Management Aspects of the Optical Transport Network
Element.
37. ITU-T G.8010/Y.1306: Architecture of Ethernet Layer Networks.
38. ITU-T G.8011/Y.1307: Ethernet over Transport - Ethernet Services
Framework.
39. ITU-T M.2140: Transport Network Event Correlation.
40. ITU-T M.3010: Principles for a Telecommunications Management
Network.
soll.
soll.

432006-2006-023-A00 ECI Telecom Ltd. Proprietary A-3

41. ITU-T M.3013: Considerations for a Telecommunications Management
Network.
42. ITU-T M.3100: Generic Network Information Model.
43. ITU-T M.3180: Catalogue of TMN Management Information.
44. ITU-T M.3200: TMN Management Services and Telecommunications
Managed Areas - Overview.
45. ITU-T M.3300: TMN Interface Requirements.
46. ITU-T M.3400: TMN Management Functions.
47. ITU-T X.217: Open Systems Interconnection, Service Definition for the
Association Control Service Element.
48. ITU-T X.219: Remote Operations - Model, Notation and Service
Definition.
49. ITU-T X.227: Open Systems Interconnection, Connection-Oriented
Protocol for the Association Control Service Element: Protocol
Specification.
50. ITU-T X.229: Remote Operations - Protocol Specification.
51. ITU-T X.710: Open Systems Interconnection, Common Management
Information Service.
52. ITU-T X.720: Open Systems Interconnection, Structure of Management
Information - Management Information Model.
Information - Definition of Management Information.
Information - Guidelines for the Definition of Managed Objects.
55. ITU-T X.731: Open Systems Interconnection, Systems Management -
State Management Function.
Alarm Reporting Function.
Time Management Function.
Software Management Function.
59. ITU-T Y.1311: Network-based VPNs - Generic architecture and service
requirements.
60. MEF Technical Specification 10.1: Ethernet Services Attributes Phase 2.
61. MPLS-TP Network Management requirements
(draft-ietf-mpls-tp-nm-req)
soll.
soll.

A-4 ECI Telecom Ltd. Proprietary 432006-2006-023-A00

62. MPLS-TP NM Framework (draft-ietf-mpls-tp-nm-framework)
63. OHSAS 18001: Occupational Health and Safety Management Systems -
Specification.
64. OMG: Notification Service Specification V 1.0.
65. OMG: The Common Object Request Broker - Architecture and
Specification V 2.6.
66. SOAP 1.1: Simple Object Access Protocol.
67. TM Forum 513: MTNM Business Agreement Release 3.5.
68. TM Forum 518: Framework Document Delivery Package (DDP)
Business Agreement (BA) V1.1.
69. TM Forum 518: Resource Provisioning DDP BA V1.0.
70. TM Forum 608: Multi Technology Network Management Information
Agreement V 2.1 and V 3.5.
71. TM Forum 814: Multi Technology Network Management Solution Set
V 2.1 and V 3.5.
72. TM Forum 854: The MTOSI XML Solution Set Package Release 1.1.
73. WS-I Basic Profile 1.1: Web Services Interoperability.
74. WSDL 1.1: Web Services Description Language.

432006-2006-023-A00 ECI Telecom Ltd. Proprietary B-1

This glossary contains definitions of certain abbreviations and acronyms used
in this document.

ADM Add/Drop Multiplexer
AIS Alarm Indication Signal
AoC ADM on Cards
APC Automatic Power Control
API Application Program Interface
APS Automatic Protection Switching
ASCII American Standard Code for Information Interchange
ASP Application Service Provider
ATM Asynchronous Transfer Mode
ATS ATM Switch
BLSR Bidirectional Line Switched Ring
BPSR Bidirectional Path Switched Ring
BSC Base Station Controller
BTS Base Transceiver System
CAC Connection Admission Control
CDB Configuration Database
CESR Carrier Ethernet Switch/Router
CFM Connectivity Fault Management
ChaCha Channel Changes
CLU Clock Unit
CNM Customer Network Management
CORBA Common Object Request Broker Architecture
CoS Class(es) of Service
CUOD Consolidation Unit for Optical Distribution
CVFE Code Violation Far End
B
Glossary
soll.
soll.

B-2 ECI Telecom Ltd. Proprietary 432006-2006-023-A00

CVNE Code Violation Near End
CWDM Coarse Wave Division Multiplexing
DCC Data Communications Channel
DCF Dispersion Compensatory Fiber
DCN Data Communication Network
DIO Data I/O card
DNI Dual Node Interface
DRI Dual Ring Interface
DRP Disaster Recovery Plan
DWDM Dense Wave Division Multiplexing
E2E End-To-End
EAH-VPLS Ethernet Access Hierarchical VPLS
EIS Ethernet Interface Switch
EML Element Management Level
EMS Element Management System
EMS-ATS ATS Element Management System
EMS-BG BroadGate's Element Management System
EMS-SYNCOM SYNCOM's Element Management System
EMS-XDM XDM's Element Management System
EVC Ethernet Virtual Circuit
LE Logical Element
LightSoft ECI Telecom's Network Manager
FCAPS Fault, Configuration, Accounting, Performance, Security
FEC Forward Error Correction
FRR Fast ReRoute
FTM FuN Topology Map
FTP File Transfer Protocol
FuN Functional Node
GCT GUI Cut-Through
GNE Gateway Network Element
GUI Graphical User Interface
HO High Order
HTML Hyper Text Markup Language
I/O Input/Output
IP Internet Protocol
ISDN Integrated Services Digital Network
ITU-T International Telecommunication Union-Telecommunication
soll.
soll.


LAN Local Area Network
LDAP Lightweight Directory Access Protocol
LDL Logical Data Link
LE Logical Elements
LO Low Order
LOD Loss of Data
LOS Loss of Signal
LP LightPath
LSP Label Switched Path
MCP Multiplexer Control Processor card
ME Managed Element
MoT MPLS over Transport
MPPM MultiPeriod Performance Monitoring
MS Multiplexer Section
MSC Mobile Switching Center
MSP Multiplex Section Protection/Linear
MSPP MultiService Provisioning Platform
MS-SPRing Multiplex Section Shared Protection Ring
MTNM Multi-Technology Network Management
MTTR Mean Time To Repair
NAS New American Standard (version)
NE Network Element
NEL Network Element Layer
NG Next Generation
NGN Next Generation Network
NGOSS Next Generation Operations Support System
NML Network Management Layer
NMS Network Management System
NOA Number of Amplifiers
NOC Number of Channels
NT Network Terminal
NUT Non-preemptable Unprotected Traffic
NVM Non-Volatile Memory
OADM Optical Add/Drop Multiplexers
OAM Operations, Administration, Management
OC Optical Carrier, the transmission speeds defined in the
SONET specification
OC-12 Optical Carrier level 12, 622.08 Mbps
soll.
soll.


OC-192 Optical Carrier level 192, 9.953 Gbps
OC-3 Optical Carrier level 3, 155.52 Mbps
OC-48 Optical Carrier level 48, 2.488 Gbps
OCH Optical Channel
ODU Optical Data Unit
OMS Optical Multiplex Section
OMSP Optical Multiplex Section Protection
OPEX Operating Expenses
OPI Optical Physical Interface
OPS Optical Physical Section
OSNR Optical Signal Noise Ratio
OSPF Open Shortest Path First
OSS Operations Support Systems
OTN Optical Trail Network
PB Provider Bridge
PC Personal Computer
PDH Plesiochronous Digital Hierarchy
PE Provider Edge
PELES Power Equalization for Lightwave Enabled Servers
PM Performance Monitoring
PN Physical Node
POP Point of Presence
POS Packet Over SDH/SONET
PPC Power Per Channel
PRC Primary Reference Clock
QoS Quality of Service
RADIUS Remote Authentification Dial-in User Service
RDI Remote Defect Indication
RDP Resource Domain Partitioning
RDR Remote Database Replication
ROADM Resource Domain Partitioning
RS Regenerator Section
RSTP Rapid Spanning Tree Protocol
SAN Storage Area Networks
SDH Synchronous Digital Hierarchy (ITU standard for
synchronous fiber media transmission)
SEC SDH Equipment Clock
SIO SDH/SONET Input/Output
soll.
soll.


SLC Span Loss Changes
SLRG Shared Link Risk Group
SNC Sub Network Connection
SNCP Sub Network Connection Protection
SNMP Simple Network Management Protocol
SOA Service Oriented Architecture
SoC Start of Chain
SONET Synchronous Optical Network (American standard for
synchronous fiber media transmission)
SP Service Provider
SPI SDH Physical Interface
SPO Specific Payload Objects
SQL Structured Query Language
SSUL Synchronization Source Unit - Local
SSUT Synchronization Source Unit - Transit
STM Synchronous Transfer Mode
STM-1 Synchronous Transport Module 1, 155.52 Mbps
STM-16 SYNCOM 2488.32 Mbps Synchronous Digital Multiplexer
STMS ShadeTree Management System
SW Software
TC Tandem Connection
TCA Threshold Crossing Alarms
TCI Trail Consistency Indicator
TCM Tandem Connection Monitoring
TCMP Tandem Connection Performance Monitoring
TCO Total Cost of Ownership
TCP Transmission Control Protocol
TDM Time Division Multiplexing
TE Traffic Engineering
TG Timing Generator
TM Terminal Multiplexer
TMF TeleManagement Forum
TMN Telecommunications Management Network
TMU Timing Unit
TNM Telecommunications Network Management
TP Termination Point
soll.
soll.


TRS Tributary SDH (SYNCOM card)
TSC Tunnel Segment Consistency
TST Terminated Server Trails
TU Termination Unit
UPSR Unidirectional Path Switched Ring (SONET)
VC Virtual Container/Virtual Connection
VPLS Virtual Private LAN Service
VPN Virtual Private Network
VSI Virtual Service Instances
WAN Wide Area Network
XC Cross Connect
XML eXtensible Markup Language

432006-2006-023-A00 ECI Telecom Ltd. Proprietary I-1

A
Acquisition 5-30
Activity log 9-10
Administration 3-17, 9-3
download/upload NE software 3-17
profiles 9-3
Alarm and event 4-7, 4-13
filters 4-7
logs 4-13
Alarm export interfaces 10-6
Alarms 4-2, 4-3, 4-4, 4-7, 4-13
current alarms 4-2
filters 4-7
indicators 4-4
logs 4-13
severity levels 4-3
user notes 4-7
C
Card assignment and configuration 3-11
CNM 1-7
Configuration functions 3-8
CORBA 10-2
CSV format 6-6
Customer Network ManagementSee
CNM 1-7
D
Data Communications ChannelSee DCC
3-10
Database access using SQL 10-5
DCC 3-10
Discovery functions 3-16
DomainsSee Resource domains 9-4
E
Events 4-7, 4-13
filters 4-7
logs 4-13
Exporting 6-6, 10-6
to CSV 6-6
to XML 10-6
F
Features and benefits 1-7
Forcing specific timing source 3-15
G
Gateway protection 3-16
Glossary of Terms B-1
I
Importing 5-51, 10-6
from XML 10-6
traffic configuration files 5-51
Inserting NEs into links 3-3
IP routing for NEs 3-5
L
LayersSee Topology layers 2-6
M
Main window 2-3
Maintenance 3-15, 8-2, 8-5
forcing specific timing source 3-15
switching protection 8-5
viewing NE Timing Sources 3-15
MSPP 1-18
Multilayer topology views 1-7, 2-6
MultiService Provisioning PlatformSee
MSPP 1-18
Index
Index 1Net End to End Management Suite
soll.

I-2 ECI Telecom Ltd. Proprietary 432006-2006-023-A00

N
NEs 3-2, 3-5, 3-10, 3-11, 3-12, 3-13, 3-
17, 9-9
attributes 3-10
card assignment 3-11
creating and configuring 3-2
downloading/uploading software 3-
17
setting IP Routing 3-5
setting passwords 9-9
timing and synchronization 3-13
viewing internal attributes 3-12
Northbound interface 1-7, 10-2
O
Open interface architecture 10-1
P
Pathfinder 5-3
PM 7-2, 7-7, 7-8, 7-10
current monitoring 7-2
Ethernet parameters 7-10
historical 7-7
logs 7-8
optical parameters 7-10
setting thresholds 7-8
Printing and exporting 6-6
Profiles 9-3
Protection switching 8-5
R
Resource domains 9-4
S
SDH/SONET trail bitrates 5-2
Secure Unix environment 9-15
Security 3-17, 9-2, 9-3, 9-4, 9-5, 9-8, 9-
9
concurrent users 9-5
profiles 9-3
resource domains 9-4
setting password 9-9
system security 9-8
user security 9-2
Security log 9-10
SQL database access 10-5
Synchronization 5-30
T
Timing and synchronization 3-13
Timing sources of NEs 3-15
TMF-MTNM standard 10-2
Topology layers 2-6
Topology links 3-3
automatic insertion of NEs into 3-3
Trail types 5-2
SDH/SONET 5-2
Trails 5-1, 5-8, 5-9, 5-30
acquisition and synchronization 5-
30
filtering 5-9
information 5-8
managing 5-1
resources 5-9
U
UMEs 3-18
Unix security 9-15
Unmanaged ElementsSee UMEs 3-18
User notes on notifications 4-7
User security 9-2
Users, concurrent 9-5
X
XML 10-6

LightSoft NMS General Description PDF

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

LightSoft NMS General Description PDF

Încărcat de

Drepturi de autor:

Formate disponibile

1Net

MultiService Provisioning Platforms (MSPP) platforms. LightSoft

family of All-Native and All Packet Multiservice

family of multiplexers at the STM-1, STM-4, and

or a relational database application.

10 system, taking advantage of advanced

S-ar putea să vă placă și