LightSoft V10.1 User Guide PDF

LightSoft®
Version 10.1
User Guide
LightSoft User Guide
V10.1
Catalog No: X91390
Drawing No: 432006-2451-7H3-A00
July 2014
1st Edition
ECI's NPT-1200, NPT-1020, NPT-1021, and NPT-1010 comply with the CE2.0 standard.
ECI's NPT-1600 complies with the MEF9 and MEF14 standards.
ECI's qualification lab is accredited by A2LA for competence in electrical testing according to
the International Standard ISO IEC 17025-2005 General Requirements for the Competence of
Testing and Calibration Laboratories.
ECI's management applications run on VMWare virtualization hypervisors.
© Copyright by ECI, 2002-2014. All rights reserved worldwide.

This is a legal agreement between you, the end user, and ECI Ltd. (“ECI”). BY OPENING THE DOCUMENTATION AND/OR DISK PACKAGE, YOU ARE
AGREEING TO BE BOUND BY THE TERMS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT, PROMPTLY RETURN
THE UNOPENED DOCUMENTATION AND/OR DISK PACKAGE AND THE ACCOMPANYING ITEMS (INCLUDING WRITTEN MATERIALS AND BINDERS OR
OTHER CONTAINERS), TO THE PLACE FROM WHICH YOU OBTAINED THEM.
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'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. 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 reserves the right, without prior notice or liability, to make changes in equipment design or specifications. Information supplied by ECI is
believed to be accurate and reliable. However, no responsibility whatsoever is assumed by ECI 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 product(s) are for informational purposes only and are not warranties of product performance or otherwise, either express or
implied. ECI's standard limited warranty, stated in its sales contract or order confirmation form, is the only warranty offered by ECI.
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'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. All specifications are subject to change without prior notice. All graphics included in this document are for illustrative purposes
only and might not correspond with your specific product version.
The documentation and/or disk and all information contained therein is owned by ECI and is protected by all relevant copyright, patent, and other
applicable laws and international treaty provisions. Therefore, you must treat the information contained in the documentation and disk as any
other copyrighted material (for example, a book or musical recording).
Other Restrictions. You may not rent, lease, sell, or otherwise dispose of 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.
All trademarks mentioned herein are the property of their respective holders.
ECI shall not be liable to you or to any other party for any loss or damage whatsoever or howsoever caused, arising directly or indirectly in
connection with 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 (when provided by ECI) and
that such instructions were understood by them. It is hereby clarified that ECI shall not be liable to you or to any other party for any loss or damage
whatsoever or howsoever caused, arising directly or indirectly in connection with you fulfilling and/or failing to fulfill in whole or in part the "Before
You Start/Safety Guidelines" instructions.
Contents
1 About This Guide ......................................................................................... 1-1
1.1 Intended Audience................................................................................................................. 1-1
1.2 Document Organization ......................................................................................................... 1-1
1.3 Notes and Warnings............................................................................................................... 1-2
1.4 Related Publications .............................................................................................................. 1-3
1.5 How to Obtain ECI Technical Documentation ....................................................................... 1-3
1.6 Technical Assistance .............................................................................................................. 1-4
2 Managing Elements and Groups .................................................................. 2-1

2.1 Working with MEs .................................................................................................................. 2-1
2.1.1 Creating MEs ........................................................................................................................... 2-2
2.1.2 Forcing an ME Upload ............................................................................................................. 2-2
2.1.3 Viewing/Editing ME Properties ............................................................................................... 2-3
2.1.4 Moving MEs between EMSs .................................................................................................... 2-5
2.1.5 Managing Unified Platform and Card Migration ................................................................... 2-13
2.2 Working with VNEs .............................................................................................................. 2-20
2.2.1 Creating a VNE....................................................................................................................... 2-21
2.2.2 Managing Optical VNE Platforms and Cards ......................................................................... 2-22
2.2.3 Configuring Virtual RSVP Tunnels.......................................................................................... 2-25
2.3 Working with LEs ................................................................................................................. 2-28
2.3.1 LE Icons.................................................................................................................................. 2-29
2.3.2 Setting LE Location ................................................................................................................ 2-30
2.3.3 Creating Secondary LEs ......................................................................................................... 2-30
2.3.4 Creating Secondary LEs in the Optical Layer ......................................................................... 2-37
2.3.5 Modifying LE Ports ................................................................................................................ 2-38
2.3.6 Viewing ETH/MPLS LEs with the Same Network ID ............................................................... 2-40
2.3.7 Viewing/Editing LE Properties ............................................................................................... 2-41
2.4 Working with Groups ........................................................................................................... 2-50
2.4.1 Creating Groups .................................................................................................................... 2-52
2.4.2 Adding MEs, LEs, and Groups to a Group .............................................................................. 2-53
2.4.3 Removing MEs, LEs, and Groups from a Group..................................................................... 2-53
2.4.4 Viewing Group Members ...................................................................................................... 2-54
2.4.5 Expanding/Collapsing Group Objects .................................................................................... 2-54
2.4.6 Deleting Groups .................................................................................................................... 2-54
2.4.7 Group Properties ................................................................................................................... 2-55
ECI Telecom Ltd. Proprietary iii

LightSoft® User Guide Contents
2.5 Working with UMEs ............................................................................................................. 2-56

2.5.1 Creating UMEs ....................................................................................................................... 2-57
2.5.2 Modifying UME Ports ............................................................................................................ 2-81
2.5.3 Accessing a UME via Telnet ................................................................................................... 2-82
2.5.4 UME Properties ..................................................................................................................... 2-83
2.6 Working with EMSs .............................................................................................................. 2-84
2.6.1 Viewing the EMS List ............................................................................................................. 2-84
2.6.2 Creating EMSs ....................................................................................................................... 2-86
2.6.3 Managing and Unmanaging EMSs ......................................................................................... 2-87
2.6.4 Forcing EMS Uploads............................................................................................................. 2-87
2.6.5 Discovering MEs .................................................................................................................... 2-88
2.6.6 Viewing/Editing EMS Properties ........................................................................................... 2-88
2.6.7 Accessing EMSs ..................................................................................................................... 2-90
2.7 Common LightSoft Operations on Objects .......................................................................... 2-94
2.7.1 Viewing and Editing Object Properties.................................................................................. 2-94
2.7.2 Viewing Object-related Current Alarms ................................................................................ 2-95
2.7.3 Viewing Trails ........................................................................................................................ 2-95
2.7.4 Deleting Objects .................................................................................................................... 2-95
2.7.5 Creating an EMS or NE Inventory .......................................................................................... 2-96
3 ETH/MPLS Networking ................................................................................ 3-1

3.1 Global MPLS Layer ................................................................................................................. 3-1
3.1.1 VPLS and MPLS Networking .................................................................................................... 3-2
3.2 Provider Bridge Networks ...................................................................................................... 3-3
3.3 Hybrid Network Configurations ............................................................................................. 3-4
3.4 Administrative Groups ........................................................................................................... 3-4
3.5 Root and Leaf Configurations ................................................................................................ 3-6
3.6 MPLS PE and PB Identification ............................................................................................... 3-7
3.6.1 Upgrading PEs and PBs to Global MPLS Layer Functionality ................................................... 3-8
3.7 Supported ETH/MPLS Port Types .......................................................................................... 3-9
3.8 Connectivity Guidelines ....................................................................................................... 3-11
3.8.1 MPLS Layer Connections ....................................................................................................... 3-12
3.8.2 PB and MPLS PE Connections ................................................................................................ 3-16
3.8.3 PB and MPLS-PE Gateway Connections ................................................................................ 3-18
3.8.4 External Connections - Connecting an MPLS PE or PB to a UME or L1 ................................. 3-21
3.8.5 Invalid PB Network Topology Indications.............................................................................. 3-22
3.9 Changing an MPLS PE to a PB .............................................................................................. 3-22
ECI Telecom Ltd. Proprietary iv

3.10 PB Network Properties ........................................................................................................ 3-23

3.10.1 General Tab ........................................................................................................................... 3-24
3.10.2 CoS Tab .................................................................................................................................. 3-25
4 Topology Links and Ports ............................................................................. 4-1

4.1 Topology Link Concepts ......................................................................................................... 4-1
4.1.1 Links and Multilinks ................................................................................................................. 4-1
4.1.2 Link Direction .......................................................................................................................... 4-2
4.1.3 Link Types ................................................................................................................................ 4-2
4.1.4 Shared Risk Link Groups (SRLGs) ............................................................................................. 4-3
4.1.5 MoE and ETY Topology Links ................................................................................................... 4-4
4.1.6 Radio Links............................................................................................................................... 4-6
4.1.7 Radio Ports .............................................................................................................................. 4-7
4.1.8 Endpoint Selection for Links .................................................................................................... 4-8
4.1.9 Fiber Connectivity ................................................................................................................... 4-8
4.1.10 Minimal Match of Supported Tunnels .................................................................................. 4-10
4.2 Topology Link Management ................................................................................................ 4-11
4.2.1 Creating Topology Links ........................................................................................................ 4-11
4.2.2 Deleting Topology Links ........................................................................................................ 4-15
4.2.3 Viewing Topology Link Information ...................................................................................... 4-15
4.2.4 Configuring Link TE Parameters ............................................................................................ 4-20
4.2.5 Configuring LE CoS Parameters ............................................................................................. 4-21
4.2.6 Updating Link Metric Values ................................................................................................. 4-22
4.2.7 Viewing SRLG and Other Diversity Information .................................................................... 4-23
4.2.8 Optimizing Low Order Resources .......................................................................................... 4-23
4.2.9 Creating an MoE Link using CESR9700/9600 NEs.................................................................. 4-27
4.2.10 ASON TE Link Information ..................................................................................................... 4-32
4.2.11 Working with Multiple Links and LEs .................................................................................... 4-34
4.3 Inserting and Removing NEs in Links ................................................................................... 4-36
4.3.1 Inserting Elements in SDH Links ............................................................................................ 4-36
4.3.2 Removing an Element from a SDH Link ................................................................................. 4-40
4.3.3 Inserting or Removing Elements to/from Optical Links ........................................................ 4-47
4.3.4 Inserting or Removing Elements to/from ASON Links .......................................................... 4-48
4.4 Viewing Resource Availability on Links ................................................................................ 4-50
4.4.1 Availability Map ..................................................................................................................... 4-51
4.4.2 Availability for Link ................................................................................................................ 4-62
4.4.3 Logical Data Links (LDL) ......................................................................................................... 4-66
4.4.4 Link Availability Constraints .................................................................................................. 4-82
ECI Telecom Ltd. Proprietary v

4.5 Performing Trail Failure Analysis ......................................................................................... 4-84

4.6 Topology Link Troubleshooting............................................................................................ 4-86
4.6.1 MAC Address Problems in Link or Port ................................................................................. 4-86
4.6.2 TE Mismatch Problem ........................................................................................................... 4-87
4.7 Maintenance Operations on Links ....................................................................................... 4-92
4.8 Automatic Link Adaptation .................................................................................................. 4-93
4.9 Changing Ports and Links between Non-Colored and Colored............................................ 4-93
4.10 Managing MS-SPRing Rings ................................................................................................. 4-94
4.10.1 Understanding MS-SPRing Rings ........................................................................................... 4-94
4.10.2 Creating an MS-SPRing Ring .................................................................................................. 4-95
4.10.3 Editing MS-SPRing Ring Attributes ........................................................................................ 4-99
4.10.4 Editing the MS-SPRing Ring Topology ................................................................................. 4-100
4.10.5 Deactivating or Deleting an MS-SPRing Ring ....................................................................... 4-101
4.10.6 MS-SPRing Management Window Fields ............................................................................ 4-102
4.10.7 MS-SPRing Properties and Operations ................................................................................ 4-106
4.11 Creating Link Windows ...................................................................................................... 4-109
4.11.1 Create Topology Link Dialog Box ......................................................................................... 4-109
4.11.2 Create Topology Link Advanced Attributes ......................................................................... 4-111
4.11.3 Path Trace Configuration Dialog Box................................................................................... 4-114
4.12 Port Properties ................................................................................................................... 4-115
4.12.1 Supported ETH/MPLS Port Types ........................................................................................ 4-116
4.12.2 Properties for Port Toolbar ................................................................................................. 4-118
4.12.3 General Tab ......................................................................................................................... 4-119
4.12.4 Optics Tab............................................................................................................................ 4-121
4.12.5 Radio Tab............................................................................................................................. 4-126
4.12.6 Radio Tab for EoR Ports ....................................................................................................... 4-128
4.12.7 L1 Connectivity Tab ............................................................................................................. 4-129
4.12.8 ETH/MPLS Tab ..................................................................................................................... 4-131
4.12.9 IP Tab (port properties) ....................................................................................................... 4-134
4.13 Link Properties ................................................................................................................... 4-135
4.13.1 Properties for Link Toolbar.................................................................................................. 4-135
4.13.2 General Tab ......................................................................................................................... 4-137
4.13.3 Advanced Tab ...................................................................................................................... 4-140
4.13.4 Optics Tab............................................................................................................................ 4-143
4.13.5 ETH/MPLS Tab ..................................................................................................................... 4-144
4.13.6 Endpoints Tab...................................................................................................................... 4-145
4.13.7 SRLGs Tab ............................................................................................................................ 4-147
ECI Telecom Ltd. Proprietary vi

4.13.8 Radio Tab............................................................................................................................. 4-148

4.13.9 CAC Tab ............................................................................................................................... 4-150
4.13.10 TE Other Tab........................................................................................................................ 4-151
4.13.11 EXP Tab ................................................................................................................................ 4-153
5 Provisioning SDH and EoS/MoT Trails .......................................................... 5-1

5.1 Trail Concepts ........................................................................................................................ 5-2
5.1.1 Trails and Virtual Links ............................................................................................................ 5-2
5.1.2 SRLG and Other Shared Resource Minimization in Path Selection ......................................... 5-3
5.1.3 Connection Admission Control (CAC) ...................................................................................... 5-5
5.1.4 LAG Support ............................................................................................................................ 5-5
5.1.5 CNM and Trail Provisioning ..................................................................................................... 5-6
5.1.6 Subnet Uploading from the EMS level .................................................................................... 5-7
5.1.7 LightSoft ASON Support .......................................................................................................... 5-7
5.2 Trail Creation Options ............................................................................................................ 5-9
5.3 Creating SDH and EoS/MoT Trails ........................................................................................ 5-10
5.3.1 Before Starting EoS/MoT Trail Creation ................................................................................ 5-11
5.3.2 Creating a Trail ...................................................................................................................... 5-12
5.3.3 Implementing Diverse Routes ............................................................................................... 5-14
5.3.4 Diagnosing a Create Trail Failure ........................................................................................... 5-16
5.4 Create Trail Window ............................................................................................................ 5-17
5.4.1 Create Trail Toolbar ............................................................................................................... 5-18
5.4.2 Map View .............................................................................................................................. 5-20
5.4.3 Trail Parameters Tab ............................................................................................................. 5-20
5.4.4 Basic Trail Parameters Pane .................................................................................................. 5-21
5.4.5 Advanced Trail Parameters Pane .......................................................................................... 5-24
5.4.6 EoS/MoT Configuration Pane ................................................................................................ 5-25
5.4.7 Trail Properties Pane ............................................................................................................. 5-28
5.4.8 Endpoints & Path Tab ............................................................................................................ 5-28
5.4.9 Path Completion Method ...................................................................................................... 5-29
5.4.10 Endpoints List Pane ............................................................................................................... 5-29
5.4.11 Select Segment Pane ............................................................................................................. 5-34
5.4.12 Select Server Trail and Services Panes .................................................................................. 5-36
5.4.13 Select Resource Pane ............................................................................................................ 5-38
5.4.14 Resource Tree Pane ............................................................................................................... 5-40
5.4.15 Resource List Pane ................................................................................................................ 5-41
5.4.16 Information About a Specific Server Trail ............................................................................. 5-42
5.5 ASON Trail Provisioning ....................................................................................................... 5-42
ECI Telecom Ltd. Proprietary vii

5.5.1 Before Starting ASON Trail Creation ..................................................................................... 5-43

5.5.2 After the ASON Trail is Activated .......................................................................................... 5-44
5.5.3 Converting Preexisting Trails to ASON .................................................................................. 5-44
5.5.4 ASON Provisioning Conditions .............................................................................................. 5-45
5.5.5 ASON Protection and Priority Schemes................................................................................. 5-52
5.5.6 Creating an ASON Trail .......................................................................................................... 5-55
5.5.7 Redefining an ASON Provisioned Path (Admit) ..................................................................... 5-61
5.5.8 Reconnecting ASON Cross Connects ..................................................................................... 5-64
5.5.9 Associating ASON Trails ..................................................................................................... 5.5.9-1
5.5.10 Defining Regions for Protection ...................................................................................... 5.5.10-1
5.5.11 Migrating to a Different Protection Scheme ................................................................... 5.5.11-3
5.6 DNI/DRI Protection ........................................................................................................ 5.5.11-6
5.6.1 Dual Node Interworking .................................................................................................... 5.6.1-6
5.6.2 Dual Ring Interworking ...................................................................................................... 5.6.2-7
5.6.3 Creating SDH DRI Trails ..................................................................................................... 5.6.3-8
5.6.4 Creating a Data DRI Trail ................................................................................................. 5.6.4-11
5.6.5 Removing a Bridge Segment ........................................................................................... 5.6.5-15
5.7 Planned Trails................................................................................................................. 5.6.5-16
5.7.1 Creating and Exporting a Planned Trail ........................................................................... 5.7.1-16
5.7.2 Importing Planned Trails ................................................................................................. 5.7.2-18
6 Performing Actions on Trails and Links ........................................................ 6-1

6.1 Accessing the Trail List Window............................................................................................. 6-1
6.2 Trail List Window ................................................................................................................... 6-3
6.2.1 Trail List Toolbar ...................................................................................................................... 6-4
6.2.2 Map View ................................................................................................................................ 6-6
6.2.3 Trails Pane ............................................................................................................................... 6-6
6.2.4 Trail Properties Pane ............................................................................................................. 6-17
6.2.5 Endpoints & Path Tab ............................................................................................................ 6-24
6.2.6 Endpoints List Pane ............................................................................................................... 6-24
6.2.7 Resource Tree Pane ............................................................................................................... 6-24
6.2.8 Resource List Pane ................................................................................................................ 6-25
6.3 Viewing Trail Information .................................................................................................... 6-26
6.3.1 Viewing Information Detail ................................................................................................... 6-26
6.3.2 Viewing Associated Client or Server Trails ............................................................................ 6-27
6.3.3 Viewing Alarms for Selected Trails ........................................................................................ 6-28
6.3.4 Monitoring the ASON Domain .............................................................................................. 6-28
6.4 Viewing Availability Map Information ................................................................................. 6-30
ECI Telecom Ltd. Proprietary viii

6.5 Performing Trail Operations ................................................................................................ 6-31

6.6 Filtering the Trails Pane ....................................................................................................... 6-32
6.6.1 Creating a Quick Trail Filter ................................................................................................... 6-33
6.6.2 Working with Advanced Trail Filters ..................................................................................... 6-35
6.7 Reconnecting Trails .............................................................................................................. 6-41
6.8 Editing and Deleting SDH, Optical, and EoS/MoT Trails ...................................................... 6-43
6.8.1 Editing Trails .......................................................................................................................... 6-44
6.8.2 Deleting Trails........................................................................................................................ 6-47
6.9 Splitting a Long Trail............................................................................................................. 6-49
6.10 Relocating SDH Client Trails ................................................................................................. 6-50
6.11 Managing Data Trail Bandwidth .......................................................................................... 6-52
6.11.1 Increasing Trail Bandwidth .................................................................................................... 6-52
6.11.2 Decreasing Trail Bandwidth .................................................................................................. 6-53
6.11.3 Activating Trail Bandwidth .................................................................................................... 6-55
6.12 S-VLAN Registration from a Link or Trail.............................................................................. 6-55
6.12.1 Adding and Removing S-VLAN Registration for ETY Links ..................................................... 6-56
6.12.2 Adding and Removing S-VLAN Registration for EoS Trails .................................................... 6-56
6.13 Inserting MPLS PEs into MoT/MoE Links ............................................................................. 6-57
6.13.1 What Insert PE Does .............................................................................................................. 6-58
6.13.2 Insert PE Prerequisites .......................................................................................................... 6-59
6.13.3 Insert PE into MoT/MoE Procedure ...................................................................................... 6-60
6.13.4 Insert PE Window .................................................................................................................. 6-63
6.13.5 Insert PE Results Summary .................................................................................................... 6-65
6.14 Removing MPLS PEs from MoT/MoE Links .......................................................................... 6-67
6.14.1 Remove PE Prerequisites ...................................................................................................... 6-68
6.14.2 Remove PE Procedure ........................................................................................................... 6-68
6.14.3 Remove PE Window .............................................................................................................. 6-72
6.14.4 Remove PE Results Window .................................................................................................. 6-73
6.14.5 Process Finished Successfully but With Some Errors ............................................................ 6-75
6.14.6 Manual Roll Back or Continue Upon Failure ......................................................................... 6-77
6.14.7 Reconstructing the Topology ................................................................................................ 6-77
6.14.8 Manual Roll Back or Continue Requirements ....................................................................... 6-77
6.15 Batch Trail Operations ......................................................................................................... 6-79
6.15.1 Exporting Trails ...................................................................................................................... 6-80
6.15.2 Importing Trails ..................................................................................................................... 6-83
6.15.3 Exporting/Importing Traffic Entities via UNIX ....................................................................... 6-85
ECI Telecom Ltd. Proprietary ix

7 Synchronizing Trails ..................................................................................... 7-1

7.1 Trail Synchronization Concepts.............................................................................................. 7-1
7.1.1 Trail Synchronization Exceptions............................................................................................. 7-2
7.1.2 OCH and LP Trail Creation and TCI Counts .............................................................................. 7-3
7.1.3 Flex Trails ................................................................................................................................. 7-4
7.2 Accessing Trail Inconsistency Information............................................................................. 7-7
7.3 Performing Trail Synchronization .......................................................................................... 7-7
7.3.1 Trail Synchronization Procedure ........................................................................................... 7-11
7.4 Trail Consistency Indicator Window .................................................................................... 7-14
7.4.1 TCI Details Pane ..................................................................................................................... 7-15
7.4.2 Parameters Pane ................................................................................................................... 7-16
7.4.3 Selected Objects Pane ........................................................................................................... 7-17
7.5 Trail Synchronization Window ............................................................................................. 7-19
7.5.1 Floating Windows .................................................................................................................. 7-21
7.6 Trail Consistency Indicator Use Cases.................................................................................. 7-24
8 Provisioning MPLS Tunnels .......................................................................... 8-1

8.1 MPLS Tunnel Concepts .......................................................................................................... 8-2
8.1.1 Label Switching ........................................................................................................................ 8-2
8.1.2 P2P and P2MP Tunnel Types ................................................................................................... 8-3
8.1.3 Underlying Link Types ............................................................................................................. 8-4
8.1.4 Tunnel Mode ........................................................................................................................... 8-4
8.1.5 Virtual RSVP Tunnels ............................................................................................................... 8-6
8.1.6 FRR Tunnel Protection ............................................................................................................. 8-8
8.1.7 CAC for MPLS Tunnels ........................................................................................................... 8-14
8.1.8 MPLS-TP Tunnel OAM ........................................................................................................... 8-16
8.1.9 Tunnel Pathfinding ................................................................................................................ 8-16
8.1.10 SRLG Avoidance in Bypass Path Selection ............................................................................. 8-17
8.1.11 Tunnel Traffic Engineering and QoS ...................................................................................... 8-18
8.2 Options for Creating Tunnels ............................................................................................... 8-21
8.3 Creating Tunnels .................................................................................................................. 8-21
8.3.1 Defining the Tunnel Parameters ........................................................................................... 8-23
8.3.2 Selecting Endpoints for a Tunnel........................................................................................... 8-25
8.3.3 Configuring Protected Ports for Bypass Tunnels ................................................................... 8-26
8.3.4 Assigning Tunnel Path Inclusions and Exclusions .................................................................. 8-28
8.3.5 Activating the Tunnel ............................................................................................................ 8-29
8.3.6 Selecting Bypass Tunnels Manually ....................................................................................... 8-30
ECI Telecom Ltd. Proprietary x

8.3.7 Setting the FRR Protection Mode .......................................................................................... 8-31

8.3.8 Diagnosing a Create Tunnel Failure ....................................................................................... 8-32
8.4 Create Tunnel Window ........................................................................................................ 8-34
8.4.1 Create Tunnel Menu and Toolbar ......................................................................................... 8-35
8.4.2 Map View .............................................................................................................................. 8-37
8.4.3 Tunnel Parameters ................................................................................................................ 8-37
8.4.4 Endpoints and Path ............................................................................................................... 8-50
8.4.5 Configuring OAM for Bidirectional Tunnels .......................................................................... 8-54
8.5 Hierarchical CoS (HR-CoS) Tunnels ...................................................................................... 8-61
8.6 Virtual RSVP Tunnel Type..................................................................................................... 8-62
8.7 Automatic Multi-Tunnel Creation ........................................................................................ 8-63
8.7.1 Automation Windows ........................................................................................................... 8-68
9 Performing Actions on Tunnels.................................................................... 9-1

9.1 Accessing the Tunnel List Window ........................................................................................ 9-1
9.2 Tunnel List Utilities................................................................................................................. 9-2
9.3 Tunnel List Window ............................................................................................................... 9-3
9.3.1 Tunnel List Menu and Toolbar ................................................................................................ 9-4
9.3.2 Map View ................................................................................................................................ 9-7
9.3.3 Tunnels Pane ........................................................................................................................... 9-8
9.3.4 Tunnel Parameters Tab ......................................................................................................... 9-12
9.3.5 Endpoints and Path Tab ........................................................................................................ 9-16
9.4 Viewing Tunnel Information ................................................................................................ 9-17
9.4.1 Viewing Tunnel Information.................................................................................................. 9-18
9.4.2 Showing Tunnels Associated with a Link ............................................................................... 9-19
9.4.3 Viewing Associated Traffic Entities ....................................................................................... 9-19
9.4.4 Viewing Alarms for Selected Tunnels .................................................................................... 9-21
9.5 Performing Tunnel Operations ............................................................................................ 9-22
9.6 Actions on Bypass Tunnels ................................................................................................... 9-23
9.7 Filtering the Tunnels Pane ................................................................................................... 9-24
9.7.1 Creating a Quick Tunnel Filter ............................................................................................... 9-26
9.7.2 Working with Advanced Tunnel Filters ................................................................................. 9-27
9.8 Reconnecting Tunnels .......................................................................................................... 9-33
9.9 Updating FRR/EFRR Protection ............................................................................................ 9-34
9.10 Editing Tunnel Protection .................................................................................................... 9-35
9.11 Editing Tunnels..................................................................................................................... 9-37
9.11.1 Adding or Removing P2MP Tunnel Tail Endpoints ................................................................ 9-37
ECI Telecom Ltd. Proprietary xi

9.11.2 Editing Tunnel Bandwidth ..................................................................................................... 9-41

9.11.3 Adding, Editing, or Removing Tunnel CoSs ........................................................................... 9-42
9.11.4 Converting Tunnels into HR-CoS Tunnels .............................................................................. 9-44
9.11.5 Deleting Tunnels.................................................................................................................... 9-45
9.12 Batch Tunnel Operations ..................................................................................................... 9-47
9.12.1 Exporting Tunnels .................................................................................................................. 9-48
9.12.2 Importing Tunnels ................................................................................................................. 9-51
10 Synchronizing Tunnels ............................................................................... 10-1

10.1 Viewing Tunnel Segment Consistency Status ...................................................................... 10-1
10.2 Performing Tunnel Synchronization .................................................................................... 10-2
10.3 Tunnel Segment Consistency (TSC) Window ....................................................................... 10-5
10.3.1 Severity Breakdown Pane ..................................................................................................... 10-6
10.3.2 Selected Objects Pane ........................................................................................................... 10-6
10.4 Tunnel Synchronization Window ......................................................................................... 10-8
10.4.1 Tunnel Synchronization Window Toolbar ............................................................................. 10-9
10.4.2 Tunnel Synchronization Floating Window Columns ............................................................ 10-10
10.5 Tunnel Consistency Use Cases ........................................................................................... 10-11
11 Provisioning Ethernet Services .................................................................. 11-1

11.1 Understanding Data Network Services ................................................................................ 11-2
11.1.1 Ethernet Service Types .......................................................................................................... 11-3
11.1.2 Understanding Ethernet Service Endpoints and Their Interfaces ......................................... 11-5
11.1.3 Distinguishing between Services ........................................................................................... 11-7
11.1.4 Understanding H-VPLS Service .............................................................................................. 11-7
11.1.5 Understanding PW Redundancy ......................................................................................... 11-22
11.1.6 Understanding VLAN Tree Service ...................................................................................... 11-23
11.1.7 Understanding CES .............................................................................................................. 11-26
11.1.8 Understanding PB Protection Choices ................................................................................ 11-27
11.1.9 Understanding BPDU Tunneling Dual Homing .................................................................... 11-28
11.1.10 Understanding RSTP Multiple Homing ................................................................................ 11-29
11.1.11 Understanding Ethernet Ring Protection ............................................................................ 11-30
11.1.12 Understanding BSC Policer Profiles ..................................................................................... 11-32
11.1.13 Understanding CFM ............................................................................................................ 11-33
11.1.14 Understanding CFM-PM (Y.1731) ....................................................................................... 11-41
11.2 Creating a Service .............................................................................................................. 11-41
11.2.1 Service Creation Guidelines and Recommendations .......................................................... 11-49
11.3 Creating Multidomain Services .......................................................................................... 11-51
ECI Telecom Ltd. Proprietary xii

11.4 Creating Freeform Services ................................................................................................ 11-60

11.5 Configuring BPDU Tunneling Dual Homing Services .......................................................... 11-62
11.5.1 Creating Access Link Dual Homing ...................................................................................... 11-63
11.5.2 Creating Internetwork Dual Homing ................................................................................... 11-65
11.6 Creating RSTP Multiple Homing Services........................................................................... 11-68
11.7 Configuring ERP Protection................................................................................................ 11-71
11.7.1 Creating ERP PB Ring Services ............................................................................................. 11-71
11.7.2 Creating ERP DH H-VPLS Services ........................................................................................ 11-75
11.7.3 Enabling ERP Service Editing ............................................................................................... 11-79
11.8 Creating CES Services ......................................................................................................... 11-79
11.8.1 Editing CES Services ............................................................................................................. 11-86
11.9 Creating Services for CESR 9600/9700 NEs ....................................................................... 11-86
11.9.1 Creating a Service in NMS with Service Definitions ............................................................ 11-87
11.9.2 Modifying Default QoS Values for Services ......................................................................... 11-88
11.10 Creating and Working with Global Service Templates ...................................................... 11-89
11.11 Working with Advanced EMS-based Endpoint Configurations ......................................... 11-90
11.12 C-VLAN Port Settings.......................................................................................................... 11-92
11.12.1 Configuring C-VLAN Values for a Port ................................................................................. 11-92
11.12.2 Applying C-VLAN Translation to a Selected Endpoint ......................................................... 11-94
11.13 S-VLAN Registration ........................................................................................................... 11-95
11.13.1 Automatic S-VLAN Registration ........................................................................................... 11-96
11.13.2 Manual S-VLAN Registration for a PB MP2MP Service ....................................................... 11-96
11.14 CoS Mapping for Ethernet Services ................................................................................... 11-97
11.14.1 Configuring Priority-CoS Mapping ....................................................................................... 11-98
11.14.2 Configuring DSCP-CoS Mapping .......................................................................................... 11-98
11.15 Selecting Tunnels Manually for a Service ........................................................................ 11-100
11.16 Managing Policer Profiles ................................................................................................ 11-101
11.16.1 Viewing the Policer Profiles List ........................................................................................ 11-102
11.16.2 Creating a Policer Profile ................................................................................................... 11-103
11.16.3 Editing a Policer Profile ..................................................................................................... 11-105
11.16.4 Deleting a Policer Profile ................................................................................................... 11-105
11.16.5 Acquisition of Policer Profiles............................................................................................ 11-106
11.16.6 Assigning Policer Profiles to CoS Values of an Endpoint ................................................... 11-106
11.17 Configuring Service Overbooking .................................................................................... 11-108
11.17.1 Understanding MPLS CAC and Service Overbooking ........................................................ 11-109
11.18 Configuring PB P2P Services between MCS Cards ........................................................... 11-109
11.18.1 Use Case 1: Direct P2P Service between MCS Cards ......................................................... 11-111
ECI Telecom Ltd. Proprietary xiii

11.18.2 Use Case 2: PB P2P Service with RSTP Enabled ................................................................. 11-111
11.19 Managing CFM MAs ......................................................................................................... 11-112
11.19.1 Adding MAs to a Service.................................................................................................... 11-113
11.19.2 Editing Service MAs ........................................................................................................... 11-116
11.19.3 Removing MAs .................................................................................................................. 11-118
11.19.4 Validating MAs .................................................................................................................. 11-119
11.19.5 Resynching MAs ................................................................................................................ 11-121
11.19.6 Implementing LLCF ............................................................................................................ 11-122
11.19.7 Handling Transient Alarms ................................................................................................ 11-124
11.20 Configuring CFM-PM (Y.1731) ......................................................................................... 11-124
11.20.1 Creating New DM Sessions................................................................................................ 11-125
11.20.2 Editing and Deleting DM Sessions ..................................................................................... 11-129
11.20.3 Creating New SLM Sessions............................................................................................... 11-131
11.20.4 Editing and Deleting SLM Sessions .................................................................................... 11-134
11.20.5 Displaying a List of Current CFM-PM Counters ................................................................. 11-136
11.20.6 Service Performance Management Window (Y.1731) ...................................................... 11-137
11.21 Troubleshooting Service Provisioning.............................................................................. 11-141
11.21.1 Actions Performed by Complete and Activate .................................................................. 11-141
11.21.2 Connectivity Validation Messages and Actions ................................................................. 11-142
11.21.3 Diagnosing a Create Service Failure .................................................................................. 11-144
12 Performing Actions on Ethernet Services ................................................... 12-1

12.1 Accessing the Ethernet Service List Window ....................................................................... 12-1
12.2 Viewing Service Information ................................................................................................ 12-2
12.2.1 Viewing Information Detail ................................................................................................... 12-2
12.2.2 Viewing Associated Traffic Entities ....................................................................................... 12-3
12.2.3 Viewing Alarms for Selected Services ................................................................................... 12-3
12.2.4 Viewing Services Associated with a Policer Profile ............................................................... 12-3
12.3 Viewing RSTP/ERP Information............................................................................................ 12-4
12.3.1 RSTP Map Window ................................................................................................................ 12-6
12.3.2 ERP Map Window .................................................................................................................. 12-7
12.4 Performing Service Operations ............................................................................................ 12-8
12.5 Implementing MAC Address Learning Query .................................................................... 12-10
12.6 Implementing vFIB Utilization Query ................................................................................. 12-11
12.7 Toggling Between Network and DB Service Views ............................................................ 12-12
12.8 Filtering Ethernet Services ................................................................................................. 12-12
12.8.1 Creating a Quick Service Filter ............................................................................................ 12-14
ECI Telecom Ltd. Proprietary xiv

12.8.2 Working with Advanced Service Filters ............................................................................... 12-16

12.9 Reconnecting Services ....................................................................................................... 12-23
12.10 Editing and Deleting Services ............................................................................................. 12-25
12.10.1 Editing Services ................................................................................................................... 12-26
12.10.2 Deleting Services ................................................................................................................. 12-28
12.11 Acknowledging Service Modifications ............................................................................... 12-30
12.12 CFM Maintenance Operations ........................................................................................... 12-30
12.12.1 Maintenance Operation Window for a Service ................................................................... 12-31
12.12.2 Selecting Source/Target for Loopback or Link Trace ........................................................... 12-34
12.12.3 Loopback ............................................................................................................................. 12-37
12.12.4 Link Trace ............................................................................................................................ 12-39
12.12.5 Continuity Check ................................................................................................................. 12-41
12.13 Data PM Management ....................................................................................................... 12-43
12.14 Service Migration ............................................................................................................... 12-45
12.15 Service Acquisition and ESI ................................................................................................ 12-47
12.15.1 Synchronizing Ethernet Services ......................................................................................... 12-48
12.15.2 Checking Network Conformance ........................................................................................ 12-48
12.15.3 Admitting Services to DB ..................................................................................................... 12-49
12.15.4 Deleting Services from DB ................................................................................................... 12-50
12.15.5 Imposing Services on the Network...................................................................................... 12-51
12.15.6 Deleting a Service ................................................................................................................ 12-52
12.16 Batch Service Operations ................................................................................................... 12-53
12.16.1 Exporting Services ............................................................................................................... 12-53
12.16.2 Importing Services ............................................................................................................... 12-56
13 Provisioning Optical Trails ......................................................................... 13-1

13.1 Optical Concepts and Background Information................................................................... 13-1
13.1.1 Optical Devices, Links, and Ports ........................................................................................... 13-2
13.1.2 Types of Ports and Interfaces ................................................................................................ 13-4
13.1.3 Optical Trails.......................................................................................................................... 13-7
13.1.4 Channels .............................................................................................................................. 13-13
13.1.5 Alarms Master Mask (AMM) ............................................................................................... 13-13
13.1.6 Optical Trail Protection ....................................................................................................... 13-14
13.2 Initial System Setup ........................................................................................................... 13-31
13.2.1 Laser Configuration ............................................................................................................. 13-32
13.2.2 Power Control Channels and Trail Creation/Deletion ......................................................... 13-33
13.3 Acquiring/Importing Optical Trails Automatically ............................................................. 13-33
ECI Telecom Ltd. Proprietary xv

13.3.1 Optical Trail Creation Options ............................................................................................. 13-33

13.3.2 Creating Optical Trails Through Discovery .......................................................................... 13-34
13.3.3 Optical Trail Acquisition by Synchronization ....................................................................... 13-37
13.4 Provisioning Optical Trails Manually.................................................................................. 13-41
13.4.1 Introduction to Optical Trail Provisioning ........................................................................... 13-41
13.4.2 Provisioning OMS Trails....................................................................................................... 13-43
13.4.3 Provisioning OCH Trails ....................................................................................................... 13-48
13.4.4 Displaying the Active Route/Path ....................................................................................... 13-79
13.4.5 Provisioning ODU Trails ....................................................................................................... 13-80
13.4.6 Provisioning LP Trails ........................................................................................................... 13-85
13.4.7 Migrating non-ASON Optical Trails to ASON Protected Optical Trails .............................. 13-101
13.4.8 Defining Trail Protection ................................................................................................... 13-102
13.4.9 Selecting a Path Completion Method ............................................................................... 13-106
13.4.10 AoC Configuration Troubleshooting .................................................................................. 13-111
13.5 Viewing and Editing Optical Trail Attributes .................................................................... 13-112
13.6 Viewing Trail Optical Parameters .................................................................................... 13-112
13.7 Deleting Optical Trails ...................................................................................................... 13-116
13.8 Inserting and Removing Optical Components ................................................................. 13-117
13.9 Optical Trails Supporting Information and Schematics ................................................... 13-117
13.9.1 Viewing Optical Channel Availability ................................................................................. 13-117
13.9.2 Channel Frequencies and Wavelengths ............................................................................ 13-125
13.9.3 Schematics: Multiroute OCH Trails, Optical DRI................................................................ 13-129
14 Migrating Optical Trails ............................................................................. 14-1

14.1 Workflow ............................................................................................................................. 14-1
14.2 Limitations ........................................................................................................................... 14-2
14.3 Preparing the Network Topology......................................................................................... 14-2
14.3.1 Placing Links in Maintenance Mode ...................................................................................... 14-3
14.3.2 Creating New Topology Links ................................................................................................ 14-3
14.4 Migrating Trails .................................................................................................................... 14-4
14.4.1 Manually................................................................................................................................ 14-6
ECI Telecom Ltd. Proprietary xvi

List of Figures
Figure 2-1: Server failure during Move ME process ..................................................................................... 2-12
Figure 2-2: Client failure during Move ME process ...................................................................................... 2-12
Figure 2-3: Unified migration scenario ......................................................................................................... 2-13
Figure 2-4: Unified Migration window ......................................................................................................... 2-14
Figure 2-5: Tunnel List indicating new Virtual RSVP tunnel ......................................................................... 2-27
Figure 2-6: LEs are split according to separate functions they perform ...................................................... 2-28
Figure 2-7: Primary LE split into secondary LEs ............................................................................................ 2-30
Figure 2-8: Ports and links automatically assumed by secondary LEs.......................................................... 2-31
Figure 2-9: Secondary LE icon ....................................................................................................................... 2-31
Figure 2-10: Devices represented by icons generated by Create LE process ............................................... 2-37
Figure 2-11: Groups created according to function ..................................................................................... 2-38
Figure 2-12: ETH/MPLS LEs with the same network ID ................................................................................ 2-40
Figure 2-13: Properties for LE - SDH ............................................................................................................. 2-43
Figure 2-14: Properties for LE - Optical ........................................................................................................ 2-44
Figure 2-15: Properties for LE - PB................................................................................................................ 2-45
Figure 2-16: Properties for LE - MPLS ........................................................................................................... 2-47
Figure 2-17: Properties for LE - MPLS - CoS tab ........................................................................................... 2-49
Figure 2-18: Shelf Group............................................................................................................................... 2-51
Figure 2-19: Create UME - Terminal OTN template - Regular ports ............................................................ 2-57
Figure 2-20: Create UME - SDH templates common content ...................................................................... 2-59
Figure 2-21: Create UME - Standard SDH UME template ............................................................................ 2-61
Figure 2-22: Create UME - SDH Inline UME template .................................................................................. 2-62
Figure 2-23: Create UME - SDH Splitter UME template ............................................................................... 2-63
Figure 2-24: Create UME - SDH Coupler UME template .............................................................................. 2-64
Figure 2-25: Create UME - SDH Splitter/Coupler UME template ................................................................. 2-65
Figure 2-26: Create UME - Terminal OTN template - Regular ports ............................................................ 2-66
Figure 2-27: Terminal OTN UME template - Colored ports .......................................................................... 2-67
Figure 2-28: Create UME - OTN Inline UME template .................................................................................. 2-69
Figure 2-29: Create UME - OTN DeMux UME template ............................................................................... 2-70
Figure 2-30: Create UME - OTN DeMux UME template ............................................................................... 2-72
Figure 2-31: Create UME - OTN OADM UME template ................................................................................ 2-74
Figure 2-32: Create UME - OTN Splitter UME template ............................................................................... 2-75
Figure 2-33: Create UME - OTN Coupler UME template .............................................................................. 2-76
Figure 2-34: Create UME - OTN DGE Coupler UME template ...................................................................... 2-77
Figure 2-35: Create UME - OTN Splitter/Coupler UME template................................................................. 2-78
Figure 2-36: Create UME - OTN Regenerator UME template....................................................................... 2-79
Figure 2-37: Create UME - OTN ETH-MPLS Data UME template.................................................................. 2-80
Figure 2-38: Modify UME dialog box ............................................................................................................ 2-81
Figure 2-39: Properties for UME dialog box ................................................................................................. 2-83
Figure 2-40: Create EMS dialog box ............................................................................................................. 2-86
ECI Telecom Ltd. Proprietary xvii

LightSoft® User Guide List of Figures
Figure 2-41: Properties for EMS window ..................................................................................................... 2-89

Figure 3-1: MPLS network .............................................................................................................................. 3-2
Figure 3-2: Provider Bridge network .............................................................................................................. 3-3
Figure 3-3: EA-HVPLS group............................................................................................................................ 3-4
Figure 3-4: Internal Admin groups within a PB network ................................................................................ 3-5
Figure 3-5: External Admin groups including several networks ..................................................................... 3-5
Figure 3-6: L1 P2P services ............................................................................................................................. 3-6
Figure 3-7: L1 root and leaf network .............................................................................................................. 3-6
Figure 3-8: MPLS network upgraded to support MoE topology link .............................................................. 3-8
Figure 3-9: Separate MPLS network management to global MPLS layer management ................................ 3-9
Figure 3-10: Tunnel in MPLS network to tunnel in MPLS Layer ..................................................................... 3-9
Figure 3-11: MoE connection – general description .................................................................................... 3-12
Figure 3-12: Ethernet overlay using intercard MoE on MCS30-X10G cards................................................. 3-13
Figure 3-13: MoE and MoT connections within an MPLS network .............................................................. 3-14
Figure 3-14: EoS trails connecting nodes within a PB network .................................................................... 3-15
Figure 3-15: Connecting PBs in different networks ...................................................................................... 3-16
Figure 3-16: Connecting PB network regions ............................................................................................... 3-16
Figure 3-17: Single connection between PB network and PE (MPLS layer) ................................................. 3-17
Figure 3-18: EoS trails grouped in a LAG ...................................................................................................... 3-18
Figure 3-19: RSTP or ERP required for MPLS PE link to two PB nodes ......................................................... 3-19
Figure 3-20: RSTP required for MPLS PE link to multiple PB nodes ............................................................. 3-19
Figure 3-21: Dual homing, ERP, or RSTP required for two MPLS PEs linked to two PB nodes ..................... 3-20
Figure 3-22: RSTP multiple homing required for multiple connections between MPLS PEs and
PB network ................................................................................................................................. 3-20
Figure 3-23: Connecting MPLS to multiple PB network regions .................................................................. 3-21
Figure 3-24: Connection between PB LE and UME....................................................................................... 3-21
Figure 3-25: Properties for PB network - General tab.................................................................................. 3-24
Figure 3-26: Properties for PB network - CoS tab ........................................................................................ 3-25
Figure 4-1: Links and multilinks ...................................................................................................................... 4-1
Figure 4-2: MoE connection – general description ........................................................................................ 4-4
Figure 4-3: Ethernet overlay using intercard MoE on MCS30-X10G cards..................................................... 4-5
Figure 4-4: Microwave radio transmissions in line of sight ............................................................................ 4-7
Figure 4-5: GbE Ethernet radio service with native TDM capabilities ............................................................ 4-7
Figure 4-6: Fiber connectivity (two modes) ................................................................................................... 4-9
Figure 4-7: Create Topology Link dialog box ................................................................................................ 4-13
Figure 4-8: Actual Links between Two Elements.......................................................................................... 4-16
Figure 4-9: Internal Links View window ....................................................................................................... 4-16
Figure 4-10: Trails showing TSI conflicts in Trail 1 and 2 .............................................................................. 4-44
Figure 4-11: TSI conflicts in Trail 1 and 2 resolved by Align Trails ................................................................ 4-44
Figure 4-12: Align Trails Scenario ................................................................................................................. 4-45
Figure 4-13: Availability Map color legend ................................................................................................... 4-51
Figure 4-14: Availability map ........................................................................................................................ 4-51
ECI Telecom Ltd. Proprietary xviii

Figure 4-15: Availability Chart: PSI tab ......................................................................................................... 4-52

Figure 4-16: Availability Chart: Port tab ....................................................................................................... 4-53
Figure 4-17: Actual Links between Two Elements dialog box ...................................................................... 4-56
Figure 4-18: Optical Availability Table .......................................................................................................... 4-57
Figure 4-19: Availability data CSV example .................................................................................................. 4-58
Figure 4-20: Optical Availability Preferences ............................................................................................... 4-61
Figure 4-21: Availability for Link for SDH dialog box .................................................................................... 4-63
Figure 4-22: Availability for Link window based on CAC .............................................................................. 4-64
Figure 4-23: End-to-end DLT trail ................................................................................................................. 4-67
Figure 4-24: LDL connecting third party network via MSP 1+1 .................................................................... 4-76
Figure 4-25: Show DLTs ................................................................................................................................ 4-78
Figure 4-26: Show LDLs................................................................................................................................. 4-79
Figure 4-27: Show LDL Properties ................................................................................................................ 4-79
Figure 4-28: Show Trail Failure Analysis ....................................................................................................... 4-85
Figure 4-29: Two trails potentially at risk if the selected object fails ........................................................... 4-86
Figure 4-30: Example of three MS-SPRing rings in a network ...................................................................... 4-95
Figure 4-31: MS-SPRing List window .......................................................................................................... 4-102
Figure 4-32: MS-SPRing ring list pane......................................................................................................... 4-103
Figure 4-33: MS-SPRing Parameters pane .................................................................................................. 4-104
Figure 4-34: MS-SPRing node list pane (2) ................................................................................................. 4-104
Figure 4-35: Create Topology Link dialog box ............................................................................................ 4-109
Figure 4-36: Path Trace Configuration dialog box ...................................................................................... 4-114
Figure 4-37: Properties for Port dialog box ................................................................................................ 4-115
Figure 4-38: Properties for Port - ETH/MPLS dialog box - General tab ...................................................... 4-119
Figure 4-39: Properties for Port - OTN - Optics .......................................................................................... 4-121
Figure 4-40: Properties for Port - ETH/MPLS dialog box - L1 Connectivity tab - MoE................................ 4-129
Figure 4-41: Properties for Port - ETH/MPLS - ETH/MPLS tab.................................................................... 4-131
Figure 4-42: Properties for Port - IP tab ..................................................................................................... 4-134
Figure 4-43: Properties for Link - MoT - General tab ................................................................................. 4-135
Figure 4-44: Properties for Link - MoT - General tab ................................................................................. 4-137
Figure 4-45: Properties for Link - SDH - Advanced Tab .............................................................................. 4-140
Figure 4-46: Link properties - optics tab..................................................................................................... 4-143
Figure 4-47: Link Properties: ETH/MPLS tab .............................................................................................. 4-144
Figure 4-48: Properties for Link - MoT - SRLGs tab .................................................................................... 4-147
Figure 4-49: Properties for Link - MoT - CAC tab........................................................................................ 4-150
Figure 4-50: Properties for Link - MoT - TE Other tab ................................................................................ 4-151
Figure 4-51: Properties for Link - MoT - EXP tab ........................................................................................ 4-153
Figure 5-1: ASON sample implementation scenario (Source ITU-T) .............................................................. 5-8
Figure 5-2: ASON sample implementation scenario (Source ITU-T) .............................................................. 5-8
Figure 5-3: Create Trail window ................................................................................................................... 5-17
Figure 5-4: Trail Parameters tab ................................................................................................................... 5-17
ECI Telecom Ltd. Proprietary xix

Figure 5-5: Endpoints & Path tab ................................................................................................................. 5-18

Figure 5-6: Advanced Trail Parameters pane ............................................................................................... 5-24
Figure 5-7: EoS/MoT Configuration pane ..................................................................................................... 5-25
Figure 5-8: Trail Properties pane .................................................................................................................. 5-28
Figure 5-9: Path Completion Method pane .................................................................................................. 5-29
Figure 5-10: Endpoints List pane .................................................................................................................. 5-29
Figure 5-11: Select Endpoint dialog box ....................................................................................................... 5-32
Figure 5-12: Select Segment pane ................................................................................................................ 5-34
Figure 5-13: Resource Tree pane.................................................................................................................. 5-40
Figure 5-14: Resource Tree pane showing diverse routes ........................................................................... 5-40
Figure 5-15: Resource List pane ................................................................................................................... 5-41
Figure 5-16: Mixed network including ASON and non-ASON NEs................................................................ 5-46
Figure 5-17: Trail traversing mixed network with non-ASON DWDM NEs................................................... 5-47
Figure 5-18: Network with MS-SPRing and ASON protection ...................................................................... 5-48
Figure 5-19: MSP1+1 - logical view as single ASON data link ....................................................................... 5-50
Figure 5-20: MSP 1+1 and ASON path placement ........................................................................................ 5-51
Figure 5-21: Segment adjacent the VC-4 (Term.) endpoint that includes shared resources is not
1++ protected............................................................................................................................. 5-51
Figure 5-22: Create Trail window displaying Trail Parameters tab .............................................................. 5-56
Figure 5-23: Configure TE Parameters window ...................................................................................... 5.5.10-2
Figure 5-24: DNI bridging using a single NE.............................................................................................. 5.6.1-7
Figure 5-25: DNI bridging using two NEs .................................................................................................. 5.6.1-7
Figure 5-26: DRI Bridging - bidirectional trail using two NEs.................................................................... 5.6.2-8
Figure 5-27: DRI Bridging - unidirectional trail using four NEs ................................................................. 5.6.2-8
Figure 5-28: Plan Trail window ............................................................................................................... 5.6.5-16
Figure 6-1: Trail List window........................................................................................................................... 6-3
Figure 6-2: Trails pane .................................................................................................................................... 6-6
Figure 6-3: Trail Properties pane .................................................................................................................. 6-17
Figure 6-4: Trail Properties pane Standard view .......................................................................................... 6-18
Figure 6-5: Trail Properties pane Standard view - Basic tab ........................................................................ 6-19
Figure 6-6: Trail Properties pane Standard view - Advanced tab ................................................................. 6-20
Figure 6-7: Trail Properties pane Standard view - Protection tab ................................................................ 6-21
Figure 6-8: Trail Properties pane Standard view - Statistics tab .................................................................. 6-22
Figure 6-9: Resource Tree pane.................................................................................................................... 6-24
Figure 6-10: Resource Tree pane showing diverse routes ........................................................................... 6-25
Figure 6-11: Resource List pane ................................................................................................................... 6-25
Figure 6-12: Provisioned trail paths ............................................................................................................. 6-28
Figure 6-13: Restoration trail paths.............................................................................................................. 6-29
Figure 6-14: Show ASON Domain from Trail List window ............................................................................ 6-29
Figure 6-15: Trails pane ................................................................................................................................ 6-32
Figure 6-16: Quick Filter field bar on Trails pane ......................................................................................... 6-33
Figure 6-17: Edit Trail window ...................................................................................................................... 6-44
ECI Telecom Ltd. Proprietary xx

Figure 6-18: Insert PE process ...................................................................................................................... 6-57

Figure 6-19: Insert PE window ...................................................................................................................... 6-63
Figure 6-20: Insert PE results summary ........................................................................................................ 6-65
Figure 6-21: Remove PE window .................................................................................................................. 6-72
Figure 6-22: Remove PE Results window ..................................................................................................... 6-74
Figure 7-1: Trail Consistency Indicator window ........................................................................................... 7-14
Figure 7-2: Trail Consistency Indicator window - Selected Objects pane .................................................... 7-17
Figure 7-3: Selected Objects pane ................................................................................................................ 7-18
Figure 7-4: Trail Synchronization window .................................................................................................... 7-19
Figure 7-5: DataBase Trails Sequence window............................................................................................. 7-22
Figure 7-6: Network Trails Sequence window .............................................................................................. 7-22
Figure 7-7: Admitted Trails List window ....................................................................................................... 7-23
Figure 8-1: MPLS overview ............................................................................................................................. 8-2
Figure 8-2: Illustration of label switching ....................................................................................................... 8-3
Figure 8-3: P2P tunnel .................................................................................................................................... 8-3
Figure 8-4: P2MP tunnel ................................................................................................................................. 8-3
Figure 8-5: E-LSP tunnel example ................................................................................................................... 8-5
Figure 8-6: Hybrid network including both MPLS-TP and IP-MPLS regions ................................................... 8-6
Figure 8-7: Service case examples in hybrid network .................................................................................... 8-7
Figure 8-8: FRR tunnel protection .................................................................................................................. 8-8
Figure 8-9: FRR link protection ....................................................................................................................... 8-9
Figure 8-10: FRR link protection for P2MP ..................................................................................................... 8-9
Figure 8-11: FRR node protection ................................................................................................................ 8-10
Figure 8-12: FRR node protection for P2MP ................................................................................................ 8-10
Figure 8-13: Link and node protection at same hop not allowed ................................................................ 8-10
Figure 8-14: Dual FRR for link protection ..................................................................................................... 8-11
Figure 8-15: P2MP tunnel drop-and-continue nodes................................................................................... 8-11
Figure 8-16: Dual FRR example 1 .................................................................................................................. 8-11
Figure 8-17: Dual FRR example 2 .................................................................................................................. 8-12
Figure 8-18: eFRR bypass configuration ....................................................................................................... 8-12
Figure 8-19: eFRR protects without wasting BW.......................................................................................... 8-13
Figure 8-20: eFRR protects against multiple simultaneous node failures .................................................... 8-13
Figure 8-21: eFRR protects against two simultaneous failures in two tunnel segments ............................. 8-14
Figure 8-22: FRR node protection for P2MP ................................................................................................ 8-17
Figure 8-23: Load sharing across unequal paths .......................................................................................... 8-19
Figure 8-24: Tunnel Parameters tab ............................................................................................................. 8-37
Figure 8-25: Tunnel - Basic Parameters pane ............................................................................................... 8-38
Figure 8-26: Create Tunnel - Advanced Parameters pane ........................................................................... 8-45
Figure 8-27: Create Tunnel - Protection Parameters pane .......................................................................... 8-47
Figure 8-28: Create Tunnel - Status Parameters pane ................................................................................. 8-48
Figure 8-29: Create Tunnel - General Parameters pane............................................................................... 8-49
ECI Telecom Ltd. Proprietary xxi

Figure 8-30: Endpoints pane......................................................................................................................... 8-51

Figure 8-31: Path pane ................................................................................................................................. 8-51
Figure 8-32: Inclusions pane ......................................................................................................................... 8-53
Figure 8-33: Exclusions pane ........................................................................................................................ 8-53
Figure 8-34: Virtual RSVP tunnels included in Tunnels List .......................................................................... 8-62
Figure 8-35: Create Tunnel Mesh window ................................................................................................... 8-68
Figure 8-36: Create Root and Leaf Tunnels window .................................................................................... 8-69
Figure 8-37: Tunnel Mesh and Multi Bypass Tunnels Selected Elements pane ........................................... 8-70
Figure 8-38: Root and Leaf Tunnels window Endpoints & Path tab ............................................................. 8-71
Figure 8-39: Automation Results pane ......................................................................................................... 8-74
Figure 9-1: Tunnel List window ...................................................................................................................... 9-3
Figure 9-2: Tunnel List - Tunnel Parameters tab .......................................................................................... 9-12
Figure 9-3: Tunnel creation - basic parameters............................................................................................ 9-13
Figure 9-4: Tunnel Parameters tab - Advanced Parameters pane ............................................................... 9-14
Figure 9-5: Tunnel Parameters tab - Protection Parameters pane .............................................................. 9-14
Figure 9-6: Tunnel Parameters tab - Status Parameters pane ..................................................................... 9-15
Figure 9-7: Tunnel Parameters tab - General Parameters pane .................................................................. 9-15
Figure 9-8: Endpoints pane........................................................................................................................... 9-16
Figure 9-9: Path pane ................................................................................................................................... 9-16
Figure 9-10: Inclusions pane ......................................................................................................................... 9-17
Figure 9-11: Exclusions pane ........................................................................................................................ 9-17
Figure 9-12: Show Tunnel window ............................................................................................................... 9-20
Figure 9-13: Update FRR protection window ............................................................................................... 9-35
Figure 10-1: Tunnel Segment Consistency (TSC) window ............................................................................ 10-5
Figure 10-2: Selected Objects pane .............................................................................................................. 10-6
Figure 10-3: Tunnel Synchronization window .............................................................................................. 10-8
Figure 11-1: MEF port types ......................................................................................................................... 11-6
Figure 11-2: Pseudowire representation...................................................................................................... 11-6
Figure 11-3: VPLS network configuration ..................................................................................................... 11-7
Figure 11-4: Typical H-VPLS topology ........................................................................................................... 11-8
Figure 11-5: Multiple H-VPLS domains ......................................................................................................... 11-9
Figure 11-6: SHG configuration in VSI ........................................................................................................ 11-10
Figure 11-7: Disconnected domains ........................................................................................................... 11-11
Figure 11-8: H-VPLS domains ..................................................................................................................... 11-11
Figure 11-9: P2MP service on single homing topology .............................................................................. 11-12
Figure 11-10: P2MP service on dual homing topology............................................................................... 11-14
Figure 11-11: MP2MP service on single homing topology ......................................................................... 11-16
Figure 11-12: SHG 0 (Null) domains ........................................................................................................... 11-17
Figure 11-13: MP2MP service on dual homing topology ........................................................................... 11-18
Figure 11-14: H-VPLS top-down provisioning example .............................................................................. 11-20
Figure 11-15: H-VPLS domains ................................................................................................................... 11-21
ECI Telecom Ltd. Proprietary xxii

Figure 11-16: Generalized PE Dual-Homing Topology ............................................................................... 11-22

Figure 11-17: Sharing Gateways between Domains................................................................................... 11-23
Figure 11-18: VLAN tree topology example ............................................................................................... 11-24
Figure 11-19: VLAN tree domain example ................................................................................................. 11-25
Figure 11-20: VLAN Tree - Network tab - Domains defined ....................................................................... 11-25
Figure 11-21: VLAN tree service map with domains indicated .................................................................. 11-26
Figure 11-22: CESoPSN service in mobile backhaul application ................................................................. 11-27
Figure 11-23: DH for access network or internetwork connections .......................................................... 11-29
Figure 11-24: Two methods for closing an RSTP ring ................................................................................. 11-30
Figure 11-25: RPL basic example ................................................................................................................ 11-31
Figure 11-26: RPL implementation example .............................................................................................. 11-31
Figure 11-27: LLCF in hub and spoke configuration ................................................................................... 11-40
Figure 11-28: ERP PB ring example with one PE node ............................................................................... 11-74
Figure 11-29: ERP PB ring example with two PE nodes.............................................................................. 11-74
Figure 11-30: PB rings configured with mixture of RSTP and ERP PB ring services.................................... 11-75
Figure 11-31: ERP DH H VPLS with V shape topology................................................................................. 11-77
Figure 11-32: ERP DH H VPLS with parallel lines topology ......................................................................... 11-78
Figure 11-33: C-VLANs selection area in VLANs pane ................................................................................ 11-92
Figure 11-34: Service Summary pane ....................................................................................................... 11-137
Figure 11-35: DM Sessions pane .............................................................................................................. 11-137
Figure 11-36: Set DM Session pane .......................................................................................................... 11-138
Figure 11-37: SLM Sessions pane ............................................................................................................. 11-138
Figure 11-38: Select SLM Session parameters.......................................................................................... 11-139
Figure 12-1: RSTP map view ......................................................................................................................... 12-6
Figure 12-2: RSTP/ERP Map window - ERP ................................................................................................... 12-7
Figure 12-3: Ethernet Service MAC Address Learning Query dialog box ................................................... 12-10
Figure 12-4: Ethernet Service vFIB Utilization Query dialog box................................................................ 12-11
Figure 12-5: Services pane.......................................................................................................................... 12-12
Figure 12-6: Edit Ethernet Service window ................................................................................................ 12-27
Figure 12-7: CFM Maintenance Operation window ................................................................................... 12-30
Figure 12-8: Service Summary pane ........................................................................................................... 12-32
Figure 12-9: Select Source pane ................................................................................................................. 12-32
Figure 12-10: Select Target pane ................................................................................................................ 12-33
Figure 12-11: Results pane ......................................................................................................................... 12-33
Figure 12-12: Select Source window .......................................................................................................... 12-36
Figure 12-13: Select Target window ........................................................................................................... 12-37
Figure 12-14: Loopback Protocol................................................................................................................ 12-37
Figure 12-15: Results Loopback pane ......................................................................................................... 12-38
Figure 12-16: Link Trace protocol ............................................................................................................... 12-39
Figure 12-17: CCM protocol ....................................................................................................................... 12-41
Figure 12-18: Export Services window ....................................................................................................... 12-54
ECI Telecom Ltd. Proprietary xxiii

Figure 13-1: Optical network example: typical elements and trails............................................................. 13-2
Figure 13-2: Regenerators in optical networks ............................................................................................ 13-3
Figure 13-3: Hierarchy of optical trails ......................................................................................................... 13-7
Figure 13-4: Optical network example: four distinct trail layers................................................................ 13-12
Figure 13-5: Optical network example: LP trail incorporating ODU trail ................................................... 13-13
Figure 13-6: PGO-related line ports (XDM/NPT equipment) ..................................................................... 13-21
Figure 13-7: PGO LP-protection (Apollo equipment) ................................................................................. 13-22
Figure 13-8: Simple unidirectional OMS trail ............................................................................................. 13-22
Figure 13-9: Partially protected OMS by presence of OMSP ..................................................................... 13-23
Figure 13-10: Partially protected OMS by underlying links ........................................................................ 13-23
Figure 13-11: OMSP protection for Apollo equipment .............................................................................. 13-24
Figure 13-12: OMSP multispan protection for Apollo equipment ............................................................. 13-24
Figure 13-13: OLP_S2 protection for Apollo equipment ............................................................................ 13-25
Figure 13-14: OLP_S2 multispan protection for Apollo equipment ........................................................... 13-25
Figure 13-15: Service card line protection ................................................................................................. 13-26
Figure 13-16: COSCs in optical networks .................................................................................................... 13-27
Figure 13-17: COSCs in optical networks .................................................................................................... 13-28
Figure 13-18: OSC topology - 2M and 100M options ................................................................................. 13-30
Figure 13-19: Typical Apollo combiner topology........................................................................................ 13-31
Figure 13-20: Create Trail window for optics ............................................................................................. 13-41
Figure 13-21: Two-card configuration ........................................................................................................ 13-47
Figure 13-22: Three-card configuration ..................................................................................................... 13-47
Figure 13-23: Four-card configuration ....................................................................................................... 13-48
Figure 13-24: OCH trail activation window ................................................................................................ 13-52
Figure 13-25: Resource Tree displaying multiroute trail with DRI bridge .................................................. 13-62
Figure 13-26: Resource tree representation of multiroute trail with DRI bridge ...................................... 13-70
Figure 13-27: A1: 1 trail, 1 path, 2 routes................................................................................................... 13-72
Figure 13-28: B2: Optical DRI bridge type B with two sub-bridges ............................................................ 13-73
Figure 13-29: B1: Optical DRI bridge type A ............................................................................................... 13-73
Figure 13-30: DRI bridge bypassing failures on main and protection paths .............................................. 13-75
Figure 13-31: OCH Trail Use Case 2 ............................................................................................................ 13-78
Figure 13-32: OCH Trail Use Case 2 ............................................................................................................ 13-79
Figure 13-33: Unprotected P2MP LP trail topology ................................................................................... 13-86
Figure 13-34: Creating LP trails: basic trail parameters ............................................................................. 13-87
Figure 13-35: Unprotected LP without UME .............................................................................................. 13-98
Figure 13-36: Protected LP with endpoints in UMEs.................................................................................. 13-98
Figure 13-37: Protected LP without splitter-coupler or UME .................................................................... 13-99
Figure 13-38: Bidirectional DRI Bridge of an LP or ODU2 Trail ................................................................... 13-99
Figure 13-39: LP or ODUk DRI bridge using Apollo AoC Cards ................................................................. 13-100
Figure 13-40: OMCM25_4 combiner card topology example .................................................................. 13-101
Figure 13-41: DNI Protection .................................................................................................................... 13-104
ECI Telecom Ltd. Proprietary xxiv

Figure 13-42: DNI Provides an Alternative Path ....................................................................................... 13-104

Figure 13-43: Optical DNI representation ................................................................................................ 13-105
Figure 13-44: Path field ............................................................................................................................ 13-109
Figure 13-45: Optical Trail Parameters table tooltip ................................................................................ 13-112
Figure 13-46: Optical trail parameters table ............................................................................................ 13-113
Figure 13-47: Optical Availability Table, single trail selection .................................................................. 13-118
Figure 13-48: Optical Availability Table after Split icon is selected.......................................................... 13-119
Figure 13-49: Optical Availability Table OCH Sub Lambda View .............................................................. 13-122
Figure 13-50: A1: 1 trail, 1 path, 2 routes................................................................................................. 13-129
Figure 13-52: A3: 1 trail, 2 paths, 4 routes (2 routes per path)................................................................ 13-130
Figure 13-53: A4: 2 trails, 2 paths, 4 routes (2 routes per path, XCs in Y TRP are at the LP trail) ............ 13-130
Figure 13-55: A6: 1 trail, 2 paths, 2 routes (XCs in the Y TRP are at the LP trail) ..................................... 13-130
Figure 13-59: A10: 1 trail, 2 paths, 2 routes (XCs in the Y TRP are at the LP trail) ................................... 13-131
Figure 13-61: A12: 1 trail, 2 paths, 2 routes (endpoints are on the AoC client ports) ............................. 13-132
Figure 13-62: A13: 1 trail, 2 paths, 4 routes (2 routes per path, XCs in the Y TRP are at the LP
trail) ........................................................................................................................................ 13-132
Figure 13-63: A14: 1 trail, 2 paths, 2 routes (user-defined protection) ................................................... 13-132
Figure 13-65: A16: 1 trail, 2 paths, 2 routes (non-multiroute X-protected trail) ..................................... 13-133
Figure 13-66: B1: Optical DRI bridge type A ............................................................................................. 13-133
Figure 13-67: B2: Optical DRI bridge type B with two sub-bridges .......................................................... 13-134
Figure 13-68: B3: Optical DRI bridge type B with one sub-bridge ............................................................ 13-134
Figure 13-69: B4: Enhanced protection by overlapping main and protection routes.............................. 13-134
Figure 13-70: B5: Protected trail with multiple routes and two DRI bridges of type B............................ 13-135
Figure 13-71: B6: Protected trail with multiple routes and DRI bridges of type B with multiple
segments ................................................................................................................................ 13-135
Figure 13-72: B7: Protected DRI bridges of type A using Y regenerators................................................. 13-135
Figure 13-73: C1: Local drop site with equipment protection and fixed channels using
Mux/DeMux ........................................................................................................................... 13-136
Figure 13-74: C2: Local drop site with channel selection flexibility (colorless) using
ROADM8E-ROADM8I with no protection .............................................................................. 13-136
Figure 13-75: C3: Local drop site that mixes ROADM8A and ROADM2A ................................................. 13-137
Figure 13-76: D1: Customer network with a possible superimposed multiroute OCH trail .................... 13-138
Figure 13-77: D2: Multiroute OCH trail with amplifier and regenerator in paths, common
segments and XCs used by main and protection routes........................................................ 13-138
Figure 13-78: D3: Multiroute OCH trail cannot traverse ODU XCs in CMBR40 cloud .............................. 13-139
ECI Telecom Ltd. Proprietary xxv

Figure 13-79: D4: Trivial case of multiroute OCH trail with ambiguous marking of path type ................ 13-139
Figure 13-80: D5: Multiroute OCH trail with overlapping main and protection routes ........................... 13-139
Figure 13-81: E1: Two multiroute OCH trails with ODU2 client trail ........................................................ 13-140
Figure 13-82: E2: ODU2 trail with multiroute OCH server trail ................................................................ 13-140
Figure 13-83: F1: Protected ODU2 and edge OCH trails .......................................................................... 13-140
Figure 13-84: F2: Protected ODU2 and left side edge OCH trails ............................................................. 13-141
Figure 13-85: F3: Externally protected ODU2 trail ................................................................................... 13-141
Figure 13-86: F4: Protected ODU2 and edge OCH trails .......................................................................... 13-141
Figure 13-87: F5: Protected ODU2 with protected OCH server trails ...................................................... 13-142
Figure 13-88: G1: LP trail as client of ODU2 and OCH trails ..................................................................... 13-142
ECI Telecom Ltd. Proprietary xxvi

List of Tables
Table 2-1: ME properties ................................................................................................................................ 2-4
Table 2-2: Unified Migration List Fields ........................................................................................................ 2-15
Table 2-3: Examples of automatic secondary LEs created per optical card ................................................. 2-32
Table 2-4: Properties for LE dialog box icons ............................................................................................... 2-42
Table 2-5: Properties for LE dialog box fields - SDH ..................................................................................... 2-43
Table 2-6: Properties for LE dialog box fields - Optical ................................................................................ 2-45
Table 2-7: Properties for LE dialog box fields - Ethernet PB......................................................................... 2-46
Table 2-8: Properties for LE dialog box fields - MPLS PE .............................................................................. 2-47
Table 2-9: Properties for Group dialog box fields ........................................................................................ 2-55
Table 2-10: UME templates - common information .................................................................................... 2-59
Table 2-11: UME templates - common buttons ........................................................................................... 2-59
Table 2-12: SDH Standard UME template information ................................................................................ 2-61
Table 2-13: SDH Inline UME template information ...................................................................................... 2-62
Table 2-14: SDH Splitter UME template information ................................................................................... 2-63
Table 2-15: SDH Coupler UME template information .................................................................................. 2-64
Table 2-16: SDH Splitter/Coupler UME template information ..................................................................... 2-65
Table 2-17: OTN Terminal UME template information ................................................................................ 2-67
Table 2-18: OTN Inline UME template information ..................................................................................... 2-69
Table 2-19: OTN Mux UME template information ....................................................................................... 2-71
Table 2-20: OTN DeMux UME template information ................................................................................... 2-73
Table 2-21: OTN OADM UME template information.................................................................................... 2-74
Table 2-22: OTN Splitter UME template information................................................................................... 2-75
Table 2-23: OTN Coupler UME template information.................................................................................. 2-76
Table 2-24: DGE Coupler UME template information .................................................................................. 2-77
Table 2-25: OTN Splitter/Coupler UME template information .................................................................... 2-78
Table 2-26: OTN Regenerator UME template information .......................................................................... 2-79
Table 2-27: OTN ETH/MPLS Data UME template information ..................................................................... 2-80
Table 2-28: Properties for UME dialog box fields......................................................................................... 2-83
Table 2-29: EMS List window menu and toolbar.......................................................................................... 2-85
Table 2-30: EMS List window columns ......................................................................................................... 2-85
Table 2-31: Create EMS dialog box fields ..................................................................................................... 2-86
Table 2-32: Properties for EMS dialog box fields ......................................................................................... 2-90
Table 2-33: GCT operations menu ................................................................................................................ 2-91
Table 3-1: Properties for Network PB - General dialog box fields................................................................ 3-24
Table 4-1: Information supplied for each link or internal link in the multilink ............................................ 4-16
Table 4-2: Topology link shortcut menu options.......................................................................................... 4-17
Table 4-3: Default QoS values ...................................................................................................................... 4-30
Table 4-4: Predefined filter options ............................................................................................................. 4-34
Table 4-5: List window function icons .......................................................................................................... 4-35
Table 4-6: SDH and Optical Availability Map CSV data fields ....................................................................... 4-58
ECI Telecom Ltd. Proprietary xxvii

LightSoft® User Guide List of Tables
Table 4-7: Optical Channel Availability table CSV data fields ....................................................................... 4-59
Table 4-8: Link Availability menu options..................................................................................................... 4-63
Table 4-9: Link CAC Availability diagram features ........................................................................................ 4-65
Table 4-10: LDL and DLT Show shortcut options .......................................................................................... 4-78
Table 4-11: MS-SPRing management window toolbars ............................................................................. 4-105
Table 4-12: MS-SPRing ring parameter fields ............................................................................................. 4-107
Table 4-13: Create Topology Link dialog box fields .................................................................................... 4-110
Table 4-14: Hide/Show toggle settings in Create Topology Link dialog box .............................................. 4-110
Table 4-15: Create Topology Link dialog box.............................................................................................. 4-112
Table 4-16: Path Trace Configuration dialog box fields.............................................................................. 4-114
Table 4-17: Properties for Port dialog box icons ........................................................................................ 4-118
Table 4-18: Properties for Port dialog box fields - General tab.................................................................. 4-119
Table 4-19: Properties for Port dialog box fields - Optics tab .................................................................... 4-121
Table 4-20: Properties for Port dialog box fields - Radio tab ..................................................................... 4-126
Table 4-21: Properties for Port dialog box fields - Radio tab ..................................................................... 4-128
Table 4-22: Properties for Port dialog box fields - L1 Connectivity tab...................................................... 4-129
Table 4-23: Properties for Port dialog box fields - ETH/MPLS tab.............................................................. 4-131
Table 4-24: Properties for Port dialog box fields - IP tab ........................................................................... 4-134
Table 4-25: Properties for Link dialog box.................................................................................................. 4-135
Table 4-26: Properties for Link dialog box fields - General Tab ................................................................. 4-137
Table 4-27: Properties for Link dialog box fields - Advanced Tab .............................................................. 4-141
Table 4-28: Link Properties dialog box - Optics tab .................................................................................... 4-143
Table 4-29: Properties for Link dialog box fields - ETH/MPLS tab .............................................................. 4-144
Table 4-30: Properties for Link dialog box fields - SRLGs tab ..................................................................... 4-148
Table 4-31: Properties for Link dialog box fields - Radio Tab ..................................................................... 4-149
Table 4-32: Properties for Link dialog box fields - TE Other tab................................................................. 4-152
Table 4-33: Properties for Link dialog box fields - EXP tab ......................................................................... 4-153
Table 5-1: Create Trail window toolbar icons............................................................................................... 5-19
Table 5-2: Basic Trail Parameters pane fields............................................................................................... 5-21
Table 5-3: Advanced Trail Parameters pane fields ....................................................................................... 5-24
Table 5-4: EoS/MoT Configuration pane fields............................................................................................. 5-25
Table 5-5: Endpoints List pane fields ............................................................................................................ 5-30
Table 5-6: Endpoints List pane shortcut options .......................................................................................... 5-30
Table 5-7: EoS endpoint selection rules for NNI types ................................................................................. 5-34
Table 5-8: Trail Paths pane - Resource View fields....................................................................................... 5-41
Table 5-9: Server trails shortcut menu options ............................................................................................ 5-42
Table 5-10: ASON CoS Priorities ................................................................................................................... 5-54
Table 5-11: Provisioned path redefinition troubleshooting ......................................................................... 5-64
Table 5-12: Protection Migration Options.............................................................................................. 5.5.11-4
Table 6-1: Trail List window toolbar ............................................................................................................... 6-4
Table 6-2: Trails pane toolbar ......................................................................................................................... 6-7
ECI Telecom Ltd. Proprietary xxviii

Table 6-3: Trails pane shortcut menu options................................................................................................ 6-8

Table 6-4: Trails pane columns ..................................................................................................................... 6-10
Table 6-5: Trail Properties pane fields – Advanced tab................................................................................ 6-20
Table 6-6: Trail Properties pane fields – Protection tab............................................................................... 6-21
Table 6-7: Trail Properties pane fields – Statistics tab ................................................................................. 6-23
Table 6-8: Insert PE window toolbar icons ................................................................................................... 6-63
Table 6-9: Insert PE window fields ............................................................................................................... 6-64
Table 6-10: Results Summary toolbar icons ................................................................................................. 6-65
Table 6-11: Remove PE window information fields ..................................................................................... 6-73
Table 6-12: Remove PE window information fields ..................................................................................... 6-73
Table 6-13: Remove PE Results toolbar........................................................................................................ 6-74
Table 6-14: Remove PE Results window information fields ......................................................................... 6-75
Table 6-15: Process steps and manual roll back requirements .................................................................... 6-78
Table 7-1: Typical Flex Reasons ...................................................................................................................... 7-4
Table 7-2: Trail Consistency Indicator toolbar.............................................................................................. 7-15
Table 7-3: Indications of warning flags ......................................................................................................... 7-16
Table 7-4: Selected Objects pane of Trail Consistency Indicator window.................................................... 7-18
Table 7-5: Trail Synchronization window toolbar......................................................................................... 7-19
Table 7-6: Trail Synchronization floating window columns.......................................................................... 7-21
Table 7-7: Events List window fields............................................................................................................. 7-24
Table 7-8: Trail consistency use cases - optical trail layer ............................................................................ 7-24
Table 7-9: Trail consistency use cases - SDH trail layer ................................................................................ 7-25
Table 7-10: Trail consistency use cases - unidentified trail layer ................................................................. 7-25
Table 8-1: Create Tunnel menu and toolbar icons ....................................................................................... 8-35
Table 8-2: Basic Parameters pane fields....................................................................................................... 8-38
Table 8-3: Advanced Parameters pane fields ............................................................................................... 8-45
Table 8-4: Protection Parameters pane fields .............................................................................................. 8-47
Table 8-5: Status Parameters pane fields ..................................................................................................... 8-48
Table 8-6: General Parameters pane fields .................................................................................................. 8-49
Table 8-7: Endpoints pane fields .................................................................................................................. 8-51
Table 8-8: Path pane shortcut options ......................................................................................................... 8-51
Table 8-9: Path pane fields ........................................................................................................................... 8-52
Table 8-10: Inclusions pane fields ................................................................................................................ 8-53
Table 8-11: Exclusion pane fields ................................................................................................................. 8-53
Table 8-12: OAM tab .................................................................................................................................... 8-55
Table 8-13: Edit OAM fields .......................................................................................................................... 8-57
Table 8-14: OAM Status and Maintenance Operations Fields ..................................................................... 8-59
Table 8-15: Create Tunnel Mesh and Multiple Bypass window toolbar icons ............................................. 8-70
Table 8-16: Automation window Selected Elements pane fields................................................................. 8-71
Table 8-17: Automation window Selected Elements pane fields................................................................. 8-72
Table 8-18: Full Tunnel Mesh or Multiple Bypass Results toolbar icons ...................................................... 8-74
ECI Telecom Ltd. Proprietary xxix

Table 8-19: Full Tunnel Mesh or Multiple Bypass Results window contents ............................................... 8-75
Table 9-1: Tunnel List menu and toolbar icons .............................................................................................. 9-4
Table 9-2: Tunnels pane toolbar..................................................................................................................... 9-9
Table 9-3: Tunnels pane columns ................................................................................................................. 9-10
Table 10-1: TSC window toolbar................................................................................................................... 10-5
Table 10-2: Indications of warning flags ....................................................................................................... 10-6
Table 10-3: Selected Objects pane of TSC window ...................................................................................... 10-7
Table 10-4: Tunnel Synchronization window toolbar................................................................................... 10-9
Table 10-5: Tunnel Synchronization floating window columns ................................................................. 10-10
Table 10-6: Tunnel Inconsistency types and possible remedial actions .................................................... 10-11
Table 11-1: Default QoS values .................................................................................................................. 11-88
Table 11-2: C-VLAN ID translation options ................................................................................................. 11-95
Table 11-3: Policer Profiles List window columns .................................................................................... 11-103
Table 11-4: Add MA dialog box parameters ............................................................................................. 11-113
Table 11-5: MA states ............................................................................................................................... 11-120
Table 11-6: Performance Management window...................................................................................... 11-137
Table 11-7: Set DM/SLM Session pane fields ........................................................................................... 11-139
Table 11-8: Troubleshooting messages .................................................................................................... 11-142
Table 12-1: RSTP/ERP Map window options ................................................................................................ 12-5
Table 12-2: Predefined service filters ......................................................................................................... 12-13
Table 12-3: Service filtering by service state .............................................................................................. 12-13
Table 12-4: Configurable selection criteria for overall service attributes .................................................. 12-22
Table 12-5: Maintenance Operation window ............................................................................................ 12-31
Table 12-6: Select Source pane fields ......................................................................................................... 12-32
Table 12-7: Select Target pane fields ......................................................................................................... 12-33
Table 12-8: Results pane Loopback tab functions ...................................................................................... 12-38
Table 12-9: Results pane Loopback tab information.................................................................................. 12-38
Table 12-10: Results pane Link Trace tab functions ................................................................................... 12-40
Table 12-11: Results pane Link Trace tab information ............................................................................... 12-41
Table 12-12: Results pane Connectivity Check tab functions .................................................................... 12-42
Table 12-13: Results pane Connectivity Check tab information ................................................................ 12-43
Table 12-14: Service ESI operations ........................................................................................................... 12-48
Table 13-1: Port and interface terminology ................................................................................................. 13-5
Table 13-2: Trails and their resources .......................................................................................................... 13-8
Table 13-3: Server trails required per card type ........................................................................................ 13-10
Table 13-4: Trail protection quality ............................................................................................................ 13-14
Table 13-5: Estimated OSNR displayed in LightSoft, based on pre-FEC BER .............................................. 13-53
Table 13-6: Trail type and endpoints .......................................................................................................... 13-63
Table 13-7: Trail Optical Parameters window toolbar ............................................................................. 13-114
Table 13-8: Trail Optical Parameter fields ................................................................................................ 13-114
Table 13-9: Utilization Table menu and toolbar options.......................................................................... 13-119
ECI Telecom Ltd. Proprietary xxx

Table 13-10: DWDM Frequencies and Wavelengths................................................................................ 13-126

Table 13-11: CWDM Wavelengths ........................................................................................................... 13-129
ECI Telecom Ltd. Proprietary xxxi

1 About This Guide
The LightSoft User Guide includes information about how to use the LightSoft network management
system (NMS), including managing elements, groups, topology links, ports, and managing traffic. It provides
detailed information about how to provision, manage, and synchronize SDH and Optical trails, Ethernet
services, and MPLS tunnels. It also includes information about the addition of protection that is appropriate
for the technology type.
1.1 Intended Audience

This guide is part of the LightSoft Documentation Suite, and is intended for network operations center
(NOC) personnel who manage relevant network equipment.
Parent Topic
1 About This Guide
1.2 Document Organization

The LightSoft Documentation Suite provides all the information that you require to perform actions in
LightSoft. It includes the following manuals:
 What's New in this Version: Outline of the new features added in the latest version, and links to the
relevant topics.
 Getting Started & Administration Guide: Introduction to LightSoft GUI, all information about how to
log on, and perform basic functions in LightSoft. It also includes how to perform security and account
administration.
 User Guide: Creating, managing and performing actions on SDH and Data trails, MPLS tunnels,
Ethernet services, and optical trails. Includes creating and managing network topology, as well as
adding protection appropriate for the technology type.
 Performance Management Guide: How to view performance and alarm information and perform
troubleshooting and fault management.
 Supporting Information: Supplementary information related to this User Guide.
Parent Topic
1 About This Guide
ECI Telecom Ltd. Proprietary 1-1

LightSoft® User Guide About This Guide
1.3 Notes and Warnings

When applicable, this guide uses the following notes and warnings:
NOTE: clarifying information, specific instructions, commentary, sidelights, or interesting

points of information.
CAUTION: failure to follow directions could result in damage to equipment or loss of

information.
WARNING: failure to follow directions could result in bodily harm or loss of life.
LASER WARNING: how to avoid personal injury. All personnel involved in equipment
installation, operation, and maintenance must be aware that laser radiation is invisible.
Therefore, although protective devices generally prevent direct exposure to the beam,
personnel must strictly observe the applicable safety precautions and, in particular, must
avoid staring into optical connectors, either directly or using optical instruments.
ESD: information on how to avoid discharge of static electricity and subsequent damage to
the unit.
TIP: helpful information and handy hints that can make your task easier.
IMPORTANT: essential information to which you must pay attention.
Parent Topic
1 About This Guide

1.4 Related Publications

The following additional publications may be of assistance to you:
 LightSoft What’s New in this Version: Outline of the new features added in the latest version of
LightSoft, and includes links to the relevant topics.
 LightSoft Getting Started and Administration Guide: An introduction to LightSoft GUI, all information
about how to log on, and perform basic functions in LightSoft. It also includes how to perform security
and account administration.
 LightSoft User Guide: Documents all major actions that can be performed in LightSoft, including
creating, managing and performing actions on SDH and Data trails, MPLS tunnels, Ethernet services,
and optical trails. It also documents creating and managing network topology, as well as adding
protection appropriate for the technology type.
 LightSoft Fault Management and Performance Monitoring Guide: Documents how to view
performance and alarm information and perform troubleshooting and fault management.
 LightSoft Supporting Information: Includes supplementary information related to the LightSoft
Documentation Suite.
 Relevant EMS User Guides
 Relevant LCT User Guides
 Remote Database Replicator (RDR) User Manual
 Master Glossary and Acronyms
Parent Topic
1 About This Guide
1.5 How to Obtain ECI Technical Documentation

To obtain technical documentation related to any ECI product, contact:
ECI Telecom Ltd.
Network Solutions Division
Documentation Department
30 Hasivim St.
Petach Tikva 4959388
Israel
Fax: +972-3-9268022
Email: ECI Telecom Ltd.
Parent Topic
1 About This Guide

1.6 Technical Assistance

For all product-related questions and issues, including installation, configuration, operation, and
maintenance, contact your local ECI Customer Support representative.
You can also contact the global ECI Customer Support Center at:
Telephone +972-3-9266000
Telefax +972-3-9266370
Email on.support@ecitele.com
Parent Topic
1 About This Guide

2 Managing Elements and Groups
NOTE: In some procedures, the term platform is referred to in the GUI as shelf.
LightSoft supports the following object types:

 Managed Element (ME): Piece of equipment (typically a platform) in the network managed by
LightSoft and an EMS. Represented as an icon in the LightSoft physical view.
 Logical Element (LE): Object or logical element in the equipment (e.g., port) representing the
capabilities of an ME in a specific technology layer.
 Group: A logical collection of objects (MEs, LEs, or groups) that can be managed as a single entity.
 Unmanaged Element (UME): Network element (NE) managed by LightSoft but not associated with an
EMS, usually used in an SDH/DWDM context.
 Virtual NE (VNE): MPLS equipment in dynamic IP/MPLS regions, working with RSVP-TE tunnels.
Limited EMS functionality is provided for VNEs using a specialized StubEMS.
 Element Manager System (EMS): Software application managing elements that can also be managed
by LightSoft.
LightSoft distinguishes between MEs that make up the network and LEs corresponding to MEs. This ability
enables true multidimensional network management perspective. For example, you can focus on MEs to
create or delete an ME, and you can focus on LE ports at each technology layer when managing trails.
2.1 Working with MEs

An ME represents a piece of network equipment managed by LightSoft and an EMS. A representative icon
and status information are shown in the LightSoft physical view.
When an ME is added to the network in the physical layer, an LE is automatically created in the relevant
technology layer. If the ME contains ports that belong to multiple technologies (as may be the case with
XDM/NPT platforms), an LE is created for each technology in its corresponding layer.
This section describes operations that can be performed on MEs.
NOTE: Operations relevant for VNEs are so indicated. See Working with VNEs.
Parent Topic

LightSoft® User Guide Managing Elements and Groups
2.1.1 Creating MEs

Creating an ME requires actions in both LightSoft and the relevant EMS. You can create an ME directly from
the LightSoft main window physical (EMS) layer.
To create an ME:
1. In the Topology layer dropdown list, select the Physical (EMS) layer.
2. In the network map, select the EMS for which you want to create an ME, and in the main window
Topology tab, in the Create group, click ME. The Create ME dialog box for the selected EMS opens.
3. Complete the steps required to create an ME in the selected EMS (see the relevant EMS User Guide).
Parent Topic
2.1.2 Forcing an ME Upload

You can force upload an ME, with or without its internal subnetwork connections (cross connects). Choose
either:
 Fast Upload: Upload only the changes since the last upload.
 Full Upload: Upload all object data.
NOTES:
 Requires EMS Administration capability.
 To avoid other users defining trails in the same area, coordinate with your workgroup
before performing a force upload.
 You can also force upload VNEs.

To force upload an ME:

1. In the Physical (Site) topology view, select the NE you want to upload, and in the main window
System tab, in the Force Upload group, select one of the following:
 ME: Upload ME data only.
 ME and Connections: Upload ME and subnetwork connections data.
A message is displayed asking if you want to perform a full upload.
2. Select:
 Yes: Full upload.
 No: Fast upload.
The upload is performed. The ME icon appears blue during upload. Once complete the color reflects
its updated state.
Parent Topic
2.1.3 Viewing/Editing ME Properties
To view/edit ME properties:
1. In the map view, right-click an ME and click Properties. The Properties for ME window opens.
Editable fields have a white background.

 To open the relevant EMS for the ME, click .
 To open alarms related to the ME, click .
2. Edit the relevant fields, and click . The changes are saved.
Table 2-1: ME properties
Field Description
ME Name ME name. A primary LE name in a technology layer can be the same or different
from that of its related ME/UME in the physical layer.
ME Type ME type.
Status ME usability, connection, or alarm state. Indicates the most severely alarmed
port.
System Location ME location.
Main IP Address Main ME IP address.
Gateway The ME is a gateway (Yes/No).
Version Software version running on the ME.
Managed By Type of management system running the ME.
Logical Elements (LEs) Names of the LEs to which the current ME is mapped in different technology
layers.
Maintenance
Maintenance function status (On/Off).
Consistency State Consistency between LightSoft and the respective EMS depending on the actual
status (Consistent/Inconsistent).
Inconsistent indicates that an ME was deleted from the EMS but cannot be
deleted from LightSoft (e.g., when a trail passes through an ME in LightSoft that
was deleted in the EMS.
Low Priority Delay Number of seconds delay before restoration is attempted after a fault on an
ASON trail with this ME as headend node. Value downloaded from system
preferences, or can be adjusted manually here if needed.
Comments Free-text.
Parent Topic

2.1.4 Moving MEs between EMSs
NOTE: This topic is not relevant for VNEs.
You can move one or more MEs from one EMS to another. When working with EMSs V8.2 and higher, you
can move MEs automatically in LightSoft. When working with earlier EMS versions, during the LightSoft
process you are prompted to perform actions manually in the relevant EMS (see the relevant EMS User
Guide).
The process has minimal impact on performance. You can work concurrently with other LightSoft
applications and only the affected MEs are locked during the process.
This process improves efficiency by:
 Balancing and merging EMSs: balance the number of MEs among the existing EMSs, or reduce the
total number of EMSs by combining ME management from several EMSs into one.
 Organizing MEs by location: arrange MEs under an EMS located in the same geographic region.
 Organizing MEs by logical or functional group: organize MEs under EMSs according to logical function
(e.g., MEs serving specific traffic).
 Upgrading MEs to a new EMS version: field engineers can upgrade selected MEs at a customer site.
During the upgrade, other EMSs continue to manage and the MEs that they manage remain
serviceable.
NOTE: LightSoft notifies Northbound applications of Move ME changes using a delete

notification (for old Distinguished Name (DN)) followed by a create notification (for new DN).
The notification applies to MEs, subnets, and physical topology links. To prevent an excessive
number of notifications, you can restart the NMSNBA to perform full upload.
Parent Topic
2.1.4.1 Prerequisites and Limitations

Note the following:
 Two MEs with the same ME ID cannot reside under the same EMS. Before moving MEs to a new EMS,
ensure that all MEs have a unique ID. In the rare event that an ME ID needs to be modified:
 If the EMS provides NBI Move ME support, change the ME ID to a unique value and proceed.
 If the EMS does not provide NBI Move ME support, you cannot change the ME ID during the
process and should not move the ME. Move the ME to a different EMS that does not have the
same ID or upgrade the EMS to support NBI Move ME.
 All the NEs participating in a particular cross-NE feature (MS-SPRing protection scheme, FTM links,
PELES chains, or topology links) must be moved concurrently.

 In Automatic Move ME mode, any omitted MEs are identified during validation. Select the remaining
MEs you want to move, disconnect the selected ME from the other NEs, or reconsider moving that
ME.
 In Manual Move ME mode, only topology link cross-NE relations are validated. All other cross-NE
relation types (MS-SPRing, FTM links, and PELES chains), are not automatically validated. To prevent
future problems, before starting the operation, ensure that the selected MEs include all the
participants of any relevant cross-NE relation.
Validation is an optional tool that can be used to diagnose and troubleshoot issues with cross-NE
relations. Use Validate to check the feasibility of a Move ME action before activating the process
(which may be time consuming) and/or to confirm no cross-NE relation issues remain.
NOTE: To perform Move ME you must have Change Topology Capabilities for the relevant
source and target EMSs. The Move ME operation is recorded in the Activity Log. See Getting
Started and Administration Guide.
Parent Topic
2.1.4.2 Moving MEs
To move MEs from one EMS to another:

1. In the main window Topology tab, in the Modify group, click Move ME. The Move ME window opens,
displaying a list of available EMSs.
2. In the Move ME window:
 In the Source EMS dropdown list, select the EMS from which to move MEs.
 In the Target EMS dropdown list, select an EMS to which to move MEs (only EMSs compatible
with the Source EMS are listed).
TIP: To search an EMS in the Source EMS or Target EMS pane, select the EMS and type a
search string.

If one or both versions of the source/target EMSs do not support automatic Move ME function via
LightSoft, a message is advises that the remaining steps must be performed manually. Click OK and
see the EMS-MPT User Guide for details of manually moving MEs.
Make sure to deal correctly with MS-SPRing, FTM link and PELES chain cross-NE relations that are not
detected by LightSoft Validation.
3. In the Source pane, select the MEs to be moved and click , or click to move all MEs. The MEs
are moved to the Target EMS pane.
4. (Optional) Click Validate to confirm that no cross-ME conditions are present that would impede
moving the selected elements.
5. To implement the Move ME changes, click Apply. A progress bar shows LightSoft Validating again and
then updating the LightSoft database and processes.
6. If Manual mode applies, a dialog box prompts you to perform actions manually at the EMS level (see
Moving MEs between EMSs in the relevant EMS User Guide. When manual actions in the EMS are
complete, in LightSoft click Continue.
LightSoft verifies all manual changes. If any steps were missed, a message lists the actions that must
be completed.

LightSoft completes the Move ME process. A Process Summary window is displayed. It displays an
operation summary, including the source and target EMSs, the names of MEs moved, and the total
duration of the operation.
The Process Summary window displays the following information:

 Number of successfully moved ME: includes the name of the MEs successfully moved to the
new EMS.
 Number of failed MEs: includes the name of each ME that was not moved successfully.
 Number MEs not deleted from source EMS: includes MEs successfully moved to the target
EMS, but not deleted from the source EMS.
 Number of MEs not created in target EMS: number of MEs for which the target EMS did not
receive the relevant files from source EMS.
 Number of MEs for which migration file is not received from source EMS: Includes MEs that
were moved to new the new EMS and removed from source EMS, but some ME database
information was not received by the new EMS database.
 Number of MEs for which migration file is not loaded to target EMS: Includes MEs that were
moved to new the new EMS and removed from source EMS, but some ME database information
was not written to the new EMS database successfully.
 Number of MEs remain not synchronized in EMS: number of MEs that remain unsynchronized
in the EMS.
 Total number of MEs: Total number of MEs involved in the Move ME process.
7. If the source EMS is now empty (contains no NEs), the following message opens:
'If you want to delete the empty source EMS, change it to Unmanaged and then delete it from the
menu.'
Parent Topic

2.1.4.3 Reassigning a Card
To reassign a card:
Extract the card and insert a different one in the slot.
 Reassign the relevant ports via the EMS.
 From LightSoft, run a script to convert reassigned ports to reflect new Distinguished Names (DNs). The
script can be run with minimal operational disruption for most cards. Processes that are
time-consuming to restart (e.g., Topology Manager and Alarms in large databases) can remain running
on the client during the process.
NOTE: For more information about the DN conversion process, contact your local Customer
Support representative.
Parent Topic
2.1.4.4 Troubleshooting Move ME Failures

Errors may cause the Move ME process to fail. This section describes troubleshooting procedures.
For certain typical errors, the failure reason window opens, identifying the affected ME(s).
To view suggested solution for a failure:

1. In the Failure Reason window, Failed MEs table, click a row. The suggested solution for the selected
failure is displayed below the table.
2. To implement the suggested solution, click Apply. Repeat for each failure listed.
3. After implementing all suggested solutions:
 Click Retry to continue the Move ME process from the point at which it failed.
OR
 Click Cancel to revert to the pre-Move ME configuration.

Communication Error Failure

If there is a communication failure, Retry may not produce an immediate response. A communication error
message opens. Wait until communication is reestablished and then click Retry again.
Fatal Error when Reverting to Pre-Move ME Configuration

In rare cases, when reverting to the Pre-Move ME configuration, a fatal error occurs and manual
corrections are required. For more information, contact your local Customer Support representative.
Parent Topic
2.1.4.4.1 Troubleshooting Duplicate ME IDs

If a duplicate ME ID is detected, an error appears in the Failure Reason window. All failed MEs are
displayed in the table. If the EMS supports changing the ME ID, you can change it from this window.
To change a duplicate ME ID:

1. In the Failure Reason dialog window Failed MEs table, select the relevant entry.
2. In the Enter a new ME ID field, enter a unique ID for the ME, and click Apply. If the EMS does not
support changing the ME name, a message lists all the MEs with duplicate ME IDs.
Parent Topic

2.1.4.4.2 Cross-NE Connections Failure

All the NEs participating in a particular cross-NE feature (MS-SPRing protection scheme, FTM links, PELES
chains, or topology links created in an EMS) must be moved at the same time. If this does not happen,
LightSoft displays a Cross NE Connection error during validation.
The Failed MEs table in the Failure Reason window lists the MEs selected for moving that belong to
cross-NE features for which not all the member MEs were selected. Select the relevant row to display a list
of missing MEs.
NOTE:
 In Automatic mode, Validate identifies missing MEs. Missing MEs can be added to the
Move ME process or the ME can be disconnected from other MEs.
 If Manual mode applies, only topology link cross-NE relations are automatically validated.
Other types of relationships (MS-SPRing, FTM links and PELES chains) must be validated
manually by other means. Before you start the operation, to prevent errors occurring,
ensure that ME selections include all the participants of a cross-NE relation.
To add MEs to solve cross-NE relation issues:

1. In the Failure Reason window Failed MEs table, double-click a line. The missing MEs associated with
the cross-NE feature are listed.
2. Select the checkbox of each ME that you want to add to the process, and click Apply.
3. Click Retry. Move ME reevaluates the cross-NE relations. If MEs are still missing, click Cancel to close
the Failure Reason window, and in the Move ME window, deselect the problematic ME.
4. In the Move ME window, click Validate to check that all cross-NE relation issues are resolved.
Parent Topic

2.1.4.4.3 Recovering from a Server or Client Failure

If a client or server failure occurred during a Move ME process upon restarting LightSoft, a failure recovery
process starts automatically. The sequence differs according to the source of the failure.
Recovering from Server Failure

 When the server failure error message opens, either:
 Click Restart. The Move ME window closes. LightSoft reverts to the original configuration and
the Move ME window reopens.
Or
 Click Close. The Move ME window closes; configuration reverts to the original configuration.
Figure 2-1: Server failure during Move ME process
Recovering from Client Failure

When the client failure message opens, it shows details of the pending Move ME process and the name of
the user who initiated the previous Move ME action.
Figure 2-2: Client failure during Move ME process
To recover from a client failure:

 When the client failure message opens, do one of the following:
 To continue the Move ME process from where it was before the failure, click Continue.
 To end the Move ME process, click Close. The database and all processes revert to the previous
configuration.
 To end the Move ME process and close the Move ME window, click Cancel. The database and all
processes revert to the previous configuration.
Parent Topic

2.1.5 Managing Unified Platform and Card Migration

Unified Migration enables management of the migration process of one or more NEs to a different NE type,
while retaining the functionality of the original NEs. The migration process is managed by LightSoft, and
avoids the need to delete and then recreate existing objects, including elements, links, trails, tunnels, cross
connects, or services. This reduces the required manpower and processing time dramatically. Unified
migration is non-traffic affecting at the NMS level, so the user can continue working on other tasks in
LightSoft during the migration process.
The user can also use this tool to coordinate selected card migrations, including slot reassignment, and card
replacement or upgrade. Card migration and reassignment is specified and performed at the EMS level, and
progress can be viewed from LightSoft in the same way as in NE migration.
Figure 2-3: Unified migration scenario
Unified migration offers a range of product replacement options, such as migration from XDM-100 to
XDM-300 or XDM-900 platforms, migration from BG-30 to BG-64 platforms, or migration from BG-64 to
NPT-1200 platforms.
The LightSoft Unified Migration window provides a management console from which to manage the
migration process, and ensure the NMS database is updated accordingly. The user can also access
additional details about each NE (such as NE Properties) directly from the Unified Migration window.
Migration can be performed for several NEs simultaneously, and involves the following steps:
 From the LightSoft Unified Migration window, select the NE(s) that you want to migrate.
 Validate the selections, to verify that the NE is not disconnected, unmanaged, or already part of a
migration process.
 Access the EMS via GCT and perform the migration at EMS-level. EMS-level migration includes
indicating the equipment you want to move, and physically moving the cards and fibers (see the
relevant EMS User Guide). During migration, the relevant NE is locked in the NMS, and appears
light-blue (unmanaged).
 Update the LightSoft database with the DN changes. This action is automatically performed by
LightSoft, once the migration process is complete in the EMS.
In LightSoft V8 and higher, unified migration from XDM-100 to XDM-300; XDM-100 to XDM-900 BG-40 to
BG-20, and BG-30 to BG-64 is supported.
In LightSoft V9 and higher, unified migration from BG-20 to BG-30 is also supported.

NOTE: The migration feature is traffic affecting during the period that the cards are physically
removed from the old ME and until they are placed in the new ME platform and physically
reconnected to the network.
To perform an NE migration:
1. In the relevant EMS, physically connect the target (new) NE to the network and configure a temporary
IP address for it.
2. In the LightSoft Physical layer, from the Main window Topology tab Modify ME/LE area, click Unified
Migration. The Unified Migration window opens.
Figure 2-4: Unified Migration window
3. In the Unified Migration map, right-click the NE that you want to migrate (original NE) and click Add
to List. A new entry is added to the Unified Migration list window, displaying details of the NE.
Repeat this step for each NE that you want to migrate.
4. Click Validate. LightSoft validates the migration process for each of the NEs in the Unified Migration
list.
5. Once all NEs are validated, for each NE, click Open EMS Migration and perform the necessary
migration steps in the relevant EMS. The NE appears unmanaged in LightSoft throughout the
migration process. Once migration is complete in the EMS, the relevant migration information is sent
to LightSoft.
LightSoft performs a full NE upload, updating the LightSoft database, deleting the old NE, and marking
the new NE as managed. A summary message is displayed, and detailed information is recorded in the
Activity log.
6. To rollback to previous configuration, return the equipment to its original state, and click Abort.

Table 2-2: Unified Migration List Fields
Field Description
Name ME name
Type ME type (e.g., XDM-100).
Status ME status (Disconnected, Connected, Uploading, OK, Warning, Minor,
Major, Critical).
Migration Status Stage of the migration process at which the NE is currently located.
Parent Topic
2.1.5.1 Requirements and Limitations

Requirements:
 LightSoft V8 and higher.
 EMS versions: EMS-MPT V1.2, or EMS-XDM V8.4 and higher.
 Change Topology capability.
Card Reassignment during Unified Migration

Card reassignment is performed via the Unified Migration window. The procedure is automated for all
except the following card types:
 SIO16_2 to SIO164
 SIO1n4_16 to SIO1n4B_32
 SIO64 to SIO164
 SIO16_2 to SIO16_2B
 SIO16_2 to SIO16_4B
For information about migration of these exceptions, contact your local Customer Support representative.
Updating XML Scripts after Migration

XML files that contain NEs and/or cards that were part of the unified migration process may not run after
migration. It is recommended that you recreate XML files that use NEs and/or cards that are used in the
migration process, after migration is successfully completed.
Performing Both NE Migration and Card Migration

 If you perform NE Migration, and the EMS becomes disconnected, do not perform a card migration
until the EMS is reconnected.
 If you perform Card Migration, and the EMS becomes disconnected, do not perform NE Migration until
the EMS is reconnected.
Parent Topic

2.1.5.2 Unified Migration of XIO16_4 to XIO64

In LightSoft V9 and higher, you can migrate from an XIO16_4 card to an XIO64 card. This action is initiated
and coordinated in LightSoft. You can monitor progress of the migration steps in LightSoft. You can upgrade
all cards in a ring at the same time, and upgrade all links in a single action.
Requirements and Limitations

For each card that you want to migrate:
 If the NE Management Mode is either DCC Only or Gateway, there must be a DCC connection on
port1 of each XIO16_4 card.
 All port connections must be on the same card. If this is not the case, migration is not allowed and an
error message is displayed.
 Port connections must have the same port number on the corresponding port. If this is not the case,
migration is not allowed.
 All ports on the XIO16_4 card must be configured as STM-16 rate.
 MSP and MS-SPRing protection should be removed from all ports.
 If the XIO16_4 card is connected to an XDM or UME, migration is not allowed and an error message is
displayed.
To upgrade XIO16_4 card(s) to XIO64:

1. For each NE that you want to upgrade, remove the XIO16_4 cards, and insert the XIO64 card.
2. In LightSoft, right-click the NE that you want to upgrade and click Open. The EMS-APT NE Shelf View
opens.
3. Right-click the XIO16_4 card, and click Slot Assignment. The Slot Assignment window opens.
4. Select Reassign.

5. Right-click the card you want to migrate, click Reassign > XIO64 and then click Apply.
A confirmation message is displayed, showing the card will automatically be reassigned to XIO64.
6. Click Yes. Migration begins. The NE status appears as unmanaged in LightSoft. No actions can be
performed on the NE, and no trails can be created during the migration process. The migration status
can be monitored in LightSoft.
7. Repeat the previous steps for each card that you want to migrate.

To view migration status in LightSoft:

1. In LightSoft select the NEs with cards that you want to migrate, and in the Topology tab, Modify
NE/LE area, select Unified Migration. The Unified Migration window opens, displaying the selected
NEs and the migration status, including:
 Type: Element type.
 Status: NE status (inconsistent, unmanaged, or connected).
 Migration Status: status of the migration (e.g., fetching files).
2. In the Unified Migration window, click to update the migration status.

When migration of a card is complete, the links attached to the associated NE become inconsistent.
The status of trails associated with the migrated links becomes Incomplete Edit. No operations can be
performed on trails in this state, and all actions performed on trails with Incomplete Edit fail.
When all NEs are migrated, the status of all links is inconsistent.

To migrate links and trails:

1. Delete all Tunnels and Ethernet Services that pass through the card that you want to migrate from
LightSoft (see Deleting Tunnels , and Deleting Services from DB). (These cannot be migrated, but they
can be added back to LightSoft later via Admit).
2. In LightSoft Topology tab, in the Modify Links area, click Migrate Links & Trails. The Migrate Links and
Trails window opens, showing a list of the links that can be migrated.
3. Select the link(s) you want to migrate, or click to select all, and then click . Links are
migrated to STM-64 links, and associated trails are migrated concurrently. At the end of the
migration, a message is displayed, showing the number of links that have succeeded/failed.
Successfully migrated links are automatically removed from the Migrate Links & Trails list, and the
associated trails return to trail state OK. Links that fail are listed, showing a reason for the failure.
4. If Tunnels or Ethernet services were deleted, perform Admit to readmit them to LightSoft (see
Performing Tunnel Synchronization and Admitting Services to DB).
NOTE: In the event that a trail remains in Incomplete Edit state, delete the trail and then
recreate it.
Parent Topic

2.2 Working with VNEs

VNEs are used to represent MPLS and optical equipment under certain conditions.
 MPLS:
 In dynamic IP/MPLS network regions, VNEs represent third-party MPLS devices supporting
signaled MPLS (RSVP-TE) tunnels, usually connected to a CESR network.
 In static MPLS-TP networks, VNEs represent devices that are not managed by LightSoft. These
PEs may be transit elements or endpoints.
Ethernet ports in MPLS VNEs can represent endpoints of services that terminate in external devices or
even beyond in third party networks. You can use LightSoft to configure VNEs to serve as endpoints
for Virtual RSVP tunnels and for a VLAN Tree service.
 Optical: In optical networks, VNEs have CWDM/DWDM passive photonic modules in platforms that
can be used as companion platforms to the other NEs. These passive optical modules free slots in
existing platforms for more active modules which are required to expand the network. You can use
LightSoft to configure these platforms and modules.
In most respects, VNEs are equivalent to a minimalist version of regular MEs, with most of the VNE
properties predefined. VNEs are created, edited, and deleted through the LightSoft GCT using a StubEMS.
After configuring the new VNE and its cards, an NE is added to the network in the physical layer and a
corresponding LE is automatically created in the MPLS or Optical technology layer.
Functionality common to all MEs is documented in the relevant topics under Working with MEs. VNE object
properties are essentially the same as the ME properties and are viewed through the LE Properties window.
Parent Topic

2.2.1 Creating a VNE

Creating a VNE requires actions in both LightSoft and StubEMS. The StubEMS is configured for managing
either MPLS or optical VNEs. To set the type of VNEs in a StubEMS, run one of the following scripts:
 Optical: ./StubEMS.sh -d
 MPLS: ./StubEMS.sh -c
To create a VNE:
2. In the network map, right-click a StubEMS icon, and select ME.
For an optical VNE, the Create Virtual NE window opens.
For an MPLS VNE, the StubEMS window opens.
a. For optical: Fill in the fields and click Apply. The Virtual Photonic NE Information dialog box
opens. Insert platforms and assign cards as explained in Managing Optical VNE Platforms and
Cards.
b. For MPLS: Click the Create New ME icon, complete the fields, and click Create. For details on
configuring the VNE as virtual RSVP tunnel endpoints, see Configuring Virtual RSVP Tunnels.
When you close the dialog box, an icon for the new Artemis NE appears in the map view.

Parent Topic
2.2.2 Managing Optical VNE Platforms and Cards
NOTE: In some procedures, the term platform is referred to in the GUI as shelf.
Using LightSoft, configure the number of platforms available for each optical VNE, and assign cards to the
slots in each platform.
The Artemis is an example of an optical VNE. It can be assigned between one and five platforms.
NOTE: For more information about Artemis shelves, cards and modules see the Artemis
General Description, Specifications, and Installation Manual.
To configure optical VNE platforms and cards:

1. Right-click the Artemis NE icon and click Open. The Virtual Photonic NE Information dialog box
opens.

2. Click Insert Shelf. The Insert Shelf dialog box opens.
3. Insert a shelf ID number (1-5), and click OK. A Shelf tab is added to the Virtual Photonic NE
Information window.

4. Double-click a slot. The Assign Equipment window opens, displaying the cards that can be selected.
5. Select a card and click Assign. The Card information dialog box opens.
6. Enter the necessary information, and click Apply. The card appears in the slot.
7. To delete a platform, in the Virtual Photonic NE Information dialog box, click Delete Shelf.
8. To unassign a card, in the Shelf tab, click the card and click Unassign.
Parent Topic

2.2.3 Configuring Virtual RSVP Tunnels

Virtual RSVP tunnels usually run between STMS MEs and VNEs. Create them, using the LightSoft GUI cut
through (GCT) to the StubEMS.
To create a virtual RSVP tunnel:

1. If you are currently working in LightSoft, first open StubEMS through the GCT. If you are already in
StubEMS, skip to step two.
a. In the Topology layer dropdown list, select the Physical (EMS) layer. )
b. In the network map, right-click StubEMS, (the EMS for which you want to create a VNE) and select
Open. The StubEMS window opens.
c. Select the ME/PE List tab.
2. In the list of VNEs, select the NE for which you want to create tunnels.
3. Select the Tunnel XC List tab. If any tunnels beginning in the selected NE have already been defined,
these tunnels are listed in the upper half of the window. The name of the VNE appears in the NE
Name field.
4. To open a new XC Info pane, in the lower half of the window, click Create New XC.
5. In the XC Info pane, enter the information in the relevant fields (Tunnel Name, Customer, DestNetPE
ID, DestPE). Note that most of the fields in this pane are completed automatically by the EMS. (For
example, the name of the selected NE appears in the NE Name field. The Tunnel Type is always
P2PVirtualRSVP.)

TIPS:
 Choose a meaningful Tunnel Name, ideally one that identifies the tunnel source and
destination (e.g., VNE1_to_VNE7).
 The DestPE and DestNetPE ID for the new tunnel destination PE can be found in the LE
Properties window of the PE. To open the LE Properties window, right-click the
destination LE icon in the LightSoft topology map and select Properties.
6. Click Create. The new tunnel is added to the Tunnel XC list in the upper half of the window.
7. Repeat steps 4-6 for each tunnel you want to create for the selected VNE, specifying the destination
endpoint for each tunnel.
8. Close the StubEMS window and return to LightSoft.
9. Synchronize and admit the new tunnels to LightSoft:
a. In the network map, select the StubEMS icon.
b. In the main window Tunnels tab, in the General group, click Tunnel Consistency.
c. Synchronize and admit the new tunnels through the TSC window (see Synchronizing Tunnels).

The network map in the following figure includes icons representing VNEs created in StubEMS. The Tunnel
List window in the following figure lists the Virtual RSVP tunnels configured for these VNEs. One tunnel in
the list under the network map has been selected and is therefore highlighted. The two VNEs that are the
endpoints for this tunnel are also highlighted in the network map. Since these are Virtual NEs with a Virtual
RSVP tunnel running between them, there is no physical connection drawn in the map between the two
VNEs. Configuration details for this tunnel appear in the Tunnel Parameters pane. Note that this tunnel is
type Virtual RSVP, indicated by a read-only field in the Advanced Parameters pane.
Figure 2-5: Tunnel List indicating new Virtual RSVP tunnel
Parent Topic

2.3 Working with LEs

Elements in a technology layer are referred to as Logical Elements (LEs). An LE represents a set of ports
acting as a functional unit. When an ME is added to the network in the physical layer, LightSoft
automatically creates an LE in the corresponding technology layer. The LE represents the capabilities of the
ME and the type of traffic it can carry. An LE may contain multiple ports supporting multiple technologies
represented on different layers. A port may be contained by only a single LE of a specific layer.
LEs can also be created manually to represent more specific functions. This is done by moving ports from a
primary LE containing all the ports in the layer into secondary LEs. For example, an LE representing a WDM
multiplexer can be split into LEs that represent the multiplexer card and the separate transponder
channels, so that each channel is visible and accessible.
Figure 2-6: LEs are split according to separate functions they perform
Groups and group hierarchies can be defined independently in each layer. You can group selected elements
on any layer (physical or logical) under a single group icon. Groups can be nested (groups of groups) to any
level. You can also access the associated EMS and display the corresponding EMS object in the LE.
This section describes how to:
 Set the LE location: place LEs on technology layer maps in the same location as the corresponding ME
in the physical layer map.
 Create secondary LEs: split an LE into secondary LEs distinguished by function. Create Ethernet switch
LEs for RSTP maps.
 Modify LE Ports.
 Show Network by ID: Display all Ethernet LEs that have the same Network ID as a specific Ethernet LE.
 View LE properties.
Parent Topic

2.3.1 LE Icons
The LE icon indicates the type of LE and LE direction, as shown in the following tables.
SDH LE types
Icon Description Icon and directions Description
Cross Connect Regenerator

Splitter-Coupler Combiner
SDH Terminal
ETH/MPLS LE types
Icon Description Icon and directions Description
Client Ports Service Ports

Ethernet Ports Provider Edge
Ethernet Switch Provider Bridge

Encryptor (such as offered
Ethernet Terminal in the Aurora family of
encryption solutions)
Line Ports
Optical LE types
Icon and
Description Icon and directions Description
directions
Mux/DeMux Optical Amplifier
Splitter-Coupler OADM
Optical Monitor Transponder
Optical Switch Mux
Optical Terminal DeMux
Generic Combiner
Parent Topic

2.3.2 Setting LE Location

After MEs are created and uploaded to LightSoft, they are automatically placed in the physical layer view.
Related LEs are created and placed in each supported technology layer. LEs are also automatically placed
for UMEs created in LightSoft.
You can reposition ME objects in the physical layer map view or LEs in any technology layer (e.g., to
correspond to relative map positions).
You can reposition objects manually, or you can set selected LEs in the same location as the equivalent
physical layer object in all technology layers. In this way, you can automatically place primary LEs of all or
selected MEs/UMEs in all relevant technology layers.
To set LEs in the same location as corresponding physical layer objects:

2. In the map, select the relevant MEs or UMEs.
3. In the main window Tools tab, in the Positioning group, click Set LE Location. All corresponding LEs
are placed in the same positions in their respective technology maps.
Parent Topic
2.3.3 Creating Secondary LEs

When cards are first assigned in the EMS, LEs are created in the relevant technology view(s) corresponding
directly to the equivalent NEs in the physical view.
To observe specific traffic flows and provide a finer degree of granularity, you can split primary LEs into
secondary LEs of different functions. The LE that corresponds to an element in the physical layer is referred
to as a primary LE. The components that are split from it are called secondary LEs.
Secondary LEs can be created to varying levels of granularity, down to single port level. For example, a
primary optical LE may consist of a transponder and a multiplexer. The link between the optical elements is
more visible in the map when they are represented by separate secondary LE icons.
Figure 2-7: Primary LE split into secondary LEs
Secondary LEs can be created either manually, specifying the internal objects from a source LE, or
automatically, with all relevant internal objects split out into multiple secondary LEs at once. Automatic
secondary LE creation (recommended when available) moves ports from the master LE to single or multiple
secondary LEs based on EMS-defined port groupings.

When a secondary LE is created, the corresponding ports are removed from the source LE and any links to
those ports are automatically assumed by the secondary LE. In the following example, the three links
between LE1 and LE2 are assumed by the corresponding secondary LEs. The physical layer remains
unchanged.
Figure 2-8: Ports and links automatically assumed by secondary LEs
The default name for a secondary LE is the primary LE name with an underscore and a suffix with a
sequential number (for example, if the primary LE is X62-49, secondary LEs will be X62-49_1, X62-49_2,
etc.).
Figure 2-9: Secondary LE icon
This section describes how to:

 Modify LE names and LE properties.
 Modify port distribution between primary and secondary LEs.
 View/Hide selected primary LEs.
In the ETH/MPLS layer, "empty" primary LEs (where all associated components were split out to secondary
LEs) can be hidden in the map view and tree.
To show/hide an empty primary LE:

 In the main window View tab, in the Show/Hide group, click Empty Primary LE.
Parent Topic

2.3.3.1 Creating Secondary LEs Automatically

Use the automatic LE creation option to create secondary LEs for all relevant devices without having to
make specific selections. Secondary LEs can be created automatically in the ETH/MPLS and/or optical layers
by an Ethernet switch or an optical component, respectively.
Parent Topic
2.3.3.1.1 By Ethernet Switch

Ethernet objects uploaded from the EMS are discovered automatically and a representative LE is created.
PB and MPLS PE LEs are created automatically according to the assigned card. Special attributes are
assigned to the LEs automatically (e.g., RSTP-essential L2 attributes that enable the LEs to be visible in the
RSTP map).
The automatic LE creation process is applied to PB and MPLS PE objects only. Other secondary LEs can are
created manually.
Parent Topic
2.3.3.1.2 By Optical Card

If you want to create secondary LEs automatically, you must specify this option during the Create LE
process. The number of secondary optical LEs that are created varies according to the card and its
components.
When automatic LE creation is performed, ports are automatically split out into single or multiple LEs based
on the functionality of the card. In most cases the ports are distributed to a single LE per card. Where a
single card has more than one independent function, the ports are split out to multiple LEs (e.g.,
TRP25_4AB or MO_OFA_PHBC). For the AoC ADM card, two cards form a single secondary LE since the two
cards function as a single functional unit.
Table 2-3: Examples of automatic secondary LEs created per optical card
Card name Number of LEs per card Type

AoC Terminal 1 1 AoC Terminal
AoC ADM 1 LE per pair of cards 1 AoC ADM
CMBR25_2 2 2 Combiners
MO_ACC6_SP50 6 3 Splitters, 3 Couplers
MO_DW40VMD 1 1 Mux/DeMux
MO_DW16MDR 1 1 Mux/DeMux
TRP10_2 1 1 Transponder

Automatic LE creation translates AoC ADM card pairs into single LEs. The LE name is taken from the master
card slot. While the automatic split is performed only on the top (primary LE) level, the Tree view shows
two slots.
Limitations
 After automatically creating secondary optical LEs, it is not recommended to create additional LEs
manually. Adding ports manually can result in unexpected port distributions (e.g., new ports may be
added to the primary LE rather than the secondary LE).
 It is not recommended to split an AoC ADM card into multiple LEs.
 If cards are reassigned in an EMS, the secondary LEs and associated links must be rebuilt manually. The
process is automatic in the case of AoC Terminal to AoC ADM card reassignments.
Parent Topic

Use the automatic LE creation option to create secondary LEs for all relevant devices without having to
make specific selections.
NOTE: The nature of the secondary LEs created at the optical layer varies according to the
type of optical card.
To create secondary LEs automatically:

1. In the Topology Layer dropdown list, select the technology layer in which you want to create the LEs.
2. In the map, select the LE which contains the internal objects or functions (ports or switches) that you
want to split out into secondary LEs and in the main window Topology tab, in the Create group, click
LE. The Create Logical Element window opens.
3. In the LE Name field, enter a name for the LE.

4. Select the Auto Create Optical LE checkbox, and click Apply. LightSoft calculates the secondary LEs
that can be created and lists them in the Available Automatic Split Selection Table window.
5. To remove an entry, deselect the checkbox for the relevant row in the table.
6. To edit the name of an LE, click Edit and enter a new name for the LE.
7. Click OK. The selected LEs are created and the cursor displays a representative icon ( ).
8. Move the cursor to the required location in the map and click once to drop the LEs in place. The new
LEs are distributed between the cursor position and the master LE and a message opens.
9. Click OK.
10. To edit the properties of an LE, right-click the LE and select LE Properties.
Parent Topic
2.3.3.3 Creating Secondary LEs Manually

You can create an LE manually, using either a primary or secondary LE as the source LE. (When creating LEs
automatically, a primary LE must be selected as the source LE.) Ports that have already been removed from
the primary LE to a secondary LE are not included in the automatic split.
To create secondary LEs manually:

1. In the Topology Layer dropdown list, select the technology layer in which you want to create the
LE(s).
2. In the map, select the LE which contains the internal objects or functions (ports or switches) that you
want to split out into secondary LEs and in the main window Topology tab, in the Create group, click
LE. The Create Logical Element window opens.

3. In the LE Name field, enter a name for the LE.

4. Clear the Auto Create LE checkbox, if applicable. The port selection area of the window becomes
active.
5. In the LE Type dropdown list, select the type of LE you want to create (options vary according to the
LE's technology). The icon for that LE type is displayed next to the dropdown list.
6. Click the arrow adjacent to the LE icon and select the directionality you require ( ).
7. (Optional) If the primary LE is part of a group, to add the secondary LE to the same group, check the
Add to LE group checkbox.
8. In the Primary LE area, select the cards, slots, or ports that the secondary LE represents, and click Add
. The selected elements are moved to the Secondary LE area.
9. Click Apply. The LE is created and the cursor displays a representative LE icon ( ).
10. Move the cursor to the required location on the map, and click once to drop the LE in place.
11. To edit the properties of an LE, right-click the LE, and select LE Properties.
Parent Topic

2.3.3.4 Reassigning LEs and Cards

As described earlier, when cards are first assigned in the EMS, the LE in the LightSoft technology view
initially reflects the same physical element as in the physical view. To be able to observe specific traffic
flows, LEs must be split out from the master into single or multiple secondary LEs distinguished by function.
When this is done through automatic LE creation, ports are automatically distributed based on
EMS-defined port groupings. In the case of paired AoC ADM cards, ports are moved to a single secondary LE
(two AoC ADM cards interact as one logical element).
In general, if cards are reassigned in the EMS, the process automatically deletes the old secondary LEs and
associated ports and creates new ports in the Master LE. Any links still connected to the old ports become
inconsistent. To avoid difficulties when reassigning cards:
1. First delete all existing links to old ports in the associated secondary LEs.
2. Perform card reassignment in the EMS. (Successful execution of step 1 ensures that existing
secondary LEs are automatically removed.)
3. Perform a new Create LE process to split out the ports to new secondary LEs according to function.
AoC Terminal to AoC ADM Card Reassignments

Exceptionally for AoC Terminal to AoC ADM card reassignments in the EMS, if automatic LE creation was
employed to create the original AoC Terminal card's LE, LightSoft automatically adapts the LE configuration
as needed for AoC ADM based on EMS-defined optical object groupings. This enables specific traffic flows
to be observed correctly.
The AoC Terminal-type LE (with 4-8 ports) becomes an AoC ADM-type LE, adding up to eight more ports to
the same LE. (The number of ports varies according to AoC type.) Although an AoC ADM occupies two slots
in the EMS (also reflected in the Tree view), it remains a single LE in LightSoft. Any links related to the old
ports remain consistent. No additional Create LE or Modify LE procedure is required.
NOTE: If a manual Create LE operation previously moved ports of the same group to different
LEs and the AoC Terminal is subsequently reassigned to AoC ADM, any new ports are added to
the master LE instead of to the appropriate secondary LE. In this case, manually move the
ports to the appropriate secondary LE through the Modify LE option. See Modifying LE Ports.
Parent Topic

2.3.4 Creating Secondary LEs in the Optical Layer
NOTE: The nature of the secondary LEs created in the optical layer varies according to the
type of optical card.
Specific use of the Create LE functionality is recommended for the optical layer. The recommended
workflow includes creating secondary LEs and then grouping sets of these LEs for maximum operational
flexibility and clarity.
1. Create LEs for each element in the optical site, such as LEs for each transponder channel, multiplexer
device (Mux, DeMux, booster, and/or preamp), and splitter-coupler ports.
 For each multichannel transponder card, create an LE to represent the add, drop, and line ports
of each channel.
 For the AUX card, create an LE for each triplet of splitter-coupler ports.
 Create LEs to represent each Mux.
The following picture shows a configuration with TRP cards, AUX cards, and Mux devices, represented
by icons generated by the Create LE process.
Figure 2-10: Devices represented by icons generated by Create LE process
2. Create groups according to function (see Working with Groups).

 Client groups hierarchy, comprising:
 Individual TRP LEs
 TRP LEs grouped with their corresponding splitter-coupler LEs
 Single Client group (UME or other endpoint of the client service)
 All Client group comprising the client groups for all channels
 All Mux Devices (MD) group, comprising Mux, DeMux, booster/preamp LEs
 Site group, comprising the All Client group and the All MD group

The circled numbers refer to the groups displayed in the following figure.
Figure 2-11: Groups created according to function
Parent Topic
2.3.5 Modifying LE Ports

Modify the ports distribution between a primary and secondary LE in the Edit Logical Element window.
Change the LE name and other LE attributes in the Properties for LE dialog box. When deleting the
secondary LE, all the ports are reverted back to the primary LE (see Deleting Objects).
To redistribute ports between a primary and secondary LE:

1. In the Topology layer dropdown list, select the appropriate technology layer.
2. In the topology map, select both the primary LE and the secondary LE between which you want to
redistribute ports.

3. In the main window Topology tab, in the Modify group, click LEs. The Edit Logical Element window
opens.
4. Redistribute the cards, slots, or ports as needed, by moving them between the Primary LE and
Secondary LE panes. Select the object in the relevant pane and click or to move it to
the other pane. (To select/deselect all cards/slots/ports, click or .)
5. Click Apply, and then Close.
Parent Topic

2.3.6 Viewing ETH/MPLS LEs with the Same Network ID

The Network ID of a data card is set in the EMS to partition the Ethernet topology into different networks.
You can view all Ethernet LEs (data cards) that have the same Network ID This function is enabled only for
automatically split LEs created by selecting the Split by Ethernet Switch checkbox in the Create Logical
Element dialog box.
Figure 2-12: ETH/MPLS LEs with the same network ID
To view a list of data cards with the same Network ID:

1. In the Topology layer dropdown list, select the ETH/MPLS layer.
2. Right-click an Ethernet LE that has been automatically split, and select Show Network By ID. A new
map view opens, showing only the LEs of data cards having the same Network IDs. The network ID
and the number of nodes are shown in the view header.
Parent Topic

2.3.7 Viewing/Editing LE Properties

You can view and edit the properties of selected LEs.
By default, the primary LE name is the same as that of its related ME/UME in a physical layer (Physical or
EMS) by default. Changes to the corresponding ME/UME name are automatically reflected in the primary
LE. You can change this by changing the name of the LE. The corresponding ME/UME name is not affected,
and from then on, the related objects have different names. Any further changes to the ME name are not
reflected in the LE.
NOTES:
 The Properties for LE window fields vary according to LE type.
 This section is also applicable to VNEs, which are categorized as a type of MPLS PE.
To view/edit LE properties:
1. In the map view, right-click the LE and click Properties. The Properties for LE dialog box opens.
2. To modify the LE direction, select the required direction in the dropdown box to the right of the LE
Type field (relevant LEs only).

For a secondary LE, the type of port can be changed (selected in the dropdown list). The symbol displayed
in the technology map view also appears. Where applicable, an additional selector allows you to choose the
directionality of the symbol.
Table 2-4: Properties for LE dialog box icons
Icon Name Description

Open Opens a GCT session for this LE; see Accessing EMSs.
Alarms Shows the alarms applying to this LE; see Viewing EMS Current
Alarms for an Object.
Open Parent ME Opens the Properties for ME dialog box for the ME
corresponding to this LE; see Viewing/Editing ME Properties.
Download TE Downloads TE parameters to the ports in EMS.
Parameters to EMS The icon changes to enabled when TE parameters are edited and
the TE Mismatch value is User defined mismatch AND one of the
following also apply:
 A problem is encountered sending it to EMS (an error
message opens).
 A system preference is edited. See also Download TE
Parameters to EMS Icon.
Parent Topic

2.3.7.1 SDH LE Properties

The following is the Properties for LE dialog box for a selected SDH LE.
Figure 2-13: Properties for LE - SDH
Table 2-5: Properties for LE dialog box fields - SDH
Field Description
LE Name LE name. LightSoft allows you to keep a primary LE name in a technology layer
either aligned with or different from that of its related ME/UME in a physical
layer; see Viewing and Editing Object Properties.
LE Type Type of equipment represented by a primary LE, for example, XDM-1000, or the
type of port represented by a secondary LE. For Ethernet LEs, shows Provider
Bridge (PB), Provider Edge (MPLS), or L1 ETY.
Primary LE: LE type is read only.
Secondary LE: The type of port can be changed (selected in the dropdown list).
The symbol displayed in the technology map view also appears. Where
applicable, an additional selector allows you to choose the directionality of the
symbol.
Status Usability state of the LE (for example, OK), connection state (from an ME), or
alarm state (e.g., Major, Minor) reflecting the most severely alarmed port; see
Object Status Color Indications in the Performance Monitoring Guide.

Field Description
Associated Layer Topology layer represented by the LE.
Active Timing Source Timing source currently in use.
Active Timing Source Whether the active timing source is internal or external.
Type
Configured Timing Timing source as configured in the EMS.
Source
Configured Timing Type of timing source; see Viewing NE Timing Sources in the Performance
Source Type Monitoring Guide.
Configured Timing Quality of timing source; see Viewing NE Timing Sources in the Performance
Source Quality Monitoring Guide.
Associated ME ME to which the LE is related.
Primary LE
Primary LE: LE Name is repeated.
Secondary LE: Primary LE from which this secondary LE was split.
Consistency State Consistency state of the associated ME. See parameter definition in
Viewing/Editing ME Properties.
Comment Free text. Saved in LightSoft only.
Parent Topic
2.3.7.2 Optical LE Properties

The following is the Properties for LE dialog box for a selected optical LE.
Figure 2-14: Properties for LE - Optical

Table 2-6: Properties for LE dialog box fields - Optical
Field Description
LE Name See SDH LE Properties.
LE Type
Status
Associated Layer
Associated ME
Primary LE
Consistency State
Comment
Parent Topic
2.3.7.3 Ethernet PB LE Properties

The following is the Properties for LE dialog box for a selected Ethernet PB LE.
Figure 2-15: Properties for LE - PB

Table 2-7: Properties for LE dialog box fields - Ethernet PB
Field Description
LE Type
Status
Associated Layer
Network ID Network ID of the LE. Set in the EMS to partition the Ethernet topology
into different networks.
When the Show Network ID option is selected for an Ethernet LE, a
window opens listing all data cards with the same Network ID; see
Viewing ETH/MPLS LEs with the Same Network ID.
Bridge MAC Address MAC address of the data card.
CFM MEP ID MEP identification; see MEP and MIP Panes in the Supporting
Information Supplement.
STP Type Spanning Tree Type of the data card (None, RSTP, MSTP).
STP Bridge Priority Value 4K to 60K, in steps of 4K.
Associated ME See SDH LE Properties.
Primary LE
Consistency State
Comment
Parent Topic

2.3.7.4 MPLS PE LE Properties

The following is the Properties for LE dialog box (General tab) for a selected MPLS PE LE.
Figure 2-16: Properties for LE - MPLS
Table 2-8: Properties for LE dialog box fields - MPLS PE
Field Description
LE Type
Status
Associated Layer
Network ID See Ethernet PB LE Properties.
PE ID PE ID of the MPLS PE.
Capability LSP Whether L-LSP and/or E-LSP and/or signaled tunnels are supported.
 NA: not an MPLS port (default)
 L-LSP tunnels only
 E-LSP tunnels only
 Signaled (LDP/RSVP) tunnels only
 L-LSP and E-LSP tunnels
 L-LSP and Signaled tunnels
 E-LSP and Signaled tunnels
 E-LSP, L-LSP, and Signaled tunnels
See Tunnel Mode.

Field Description
TE Mismatch Whether TE parameter values for this PE differ from values specified in
system preferences:
 Match: Parameters are identical.
 User defined mismatch: TE configuration was changed by the user and
does not match system preferences.
 Capability constraints: System preferences TE configuration cannot be
downloaded to the equipment due to capability constraints of the
equipment. For example, if the System Preferences Overbooking is 20,
downloading it to specific equipment that supports max overbooking
value of 10 fails.
 Update failure in EMS: LightSoft values are not equal to the EMS
values.
For details of the system preference values, see MPLS TE Configuration
Preferences in the Getting Started & Administration Guide.
For details about TE Mismatch and how to solve the problem, see TE
Mismatch Problem.
Bridge MAC Address See Ethernet PB LE Properties.
CFM MEP ID
STP Type
STP Bridge Priority
Associated ME See SDH LE Properties.
Primary LE
Consistency State
Comment
Parent Topic

2.3.7.4.1 CoS Tab

The following is the Properties for LE dialog box (CoS tab) for a selected MPLS PE LE.
When a new PE is created in the MPLS layer, its CoS values are derived from default values set in the
Preferences window CAC workspace; see CAC Preferences in the Getting Started & Administration Guide.
The PE CAC configuration can be changed in the Properties for Link window CAC tab (see CAC Preferences
in the Getting Started & Administration Guide).
Figure 2-17: Properties for LE - MPLS - CoS tab
Parent Topic
2.3.7.4 MPLS PE LE Properties

2.4 Working with Groups

You can create groups of any combination of network objects. This enables you to manage and monitor
objects hierarchically in way that reflects your network, both geographically, and functionally. You can
group objects as follows:
 Site groups: Create groups in the physical layer, which allow users to classify MEs by their physical
location (node, region, room, building, city, country, etc.).
 Functional groups: Create groups in the relevant technology layer, to classify LEs by a range of
technology entities, including:
 Node, region
 Chain, ring, mesh
 Subnet, group of subnets, backbone group, access group
 OADM, Mux/DeMux, optical amplifier, optical terminal, transponder
 SDH core, SDH access
 PB, MPLS, EA-HVPLS group
The PB, MPLS, and EA-HVPLS groups are not the same as automatically created network groups, which
comprise LEs that have the same network ID.
Admin groups are created automatically from former network groups when upgraded LEs are loaded to
LightSoft, and have the same properties and behavior as user-defined groups (see Administrative Groups).
When you create a group, you can view alarms for all objects in the group, view all trails served by the MEs
or LEs in the group, and manage all group members simultaneously. A group can contain elements on the
same topology layer and can be nested by creating groups to any level. You can also add and remove
elements to/from any type of group except shelf groups.
Shelf groups are created automatically from all LEs that support MoF ports (i.e., hybrid cards of the MCS
card family) located within a single NE. The MoF and PSI ports within an NE by default are automatically
configured as a full mesh of backplane connections between the MoF and PSI ports within that NE.
Depending on the number of ports, the full mesh may reach up to exponential numbers of connections.
Collapsing all these connections into a single logical shelf group simplifies management of the resources
within the NE. LightSoft creates and deletes shelf groups automatically; users are not able to add or remove
elements from a shelf group. To simplify usage, shelf groups remain in a collapsed state, represented by a
single shelf group icon ( ) on the topology map, unless the user explicitly chooses to expand that
group. Shelf groups are not included in the standard Expand All or Collapse All command.

Shelf groups have the same properties and behavior as user-defined groups. Users can expand the shelf
group to see the internal cards and the connections between the cards (MoF), as illustrated in the following
figure.
Figure 2-18: Shelf Group
Note that shelf groups include only the hybrid cards of the MCS card family that support MoF ports. Other
cards installed in the platform are displayed on the LightSoft map as in usual, following the same behavior
guidelines as in previous LightSoft versions. For more information about PSI and MoF ports and links, see
Supported ETH/MPLS Port Types.
Parent Topic

2.4.1 Creating Groups

You can create a user-defined group comprising any number of MEs, LEs, and/or groups (including
automatically defined network groups). User-defined groups may not include partial contents of multiple
automatic groups.
To create a group:
1. In the appropriate topology view, select the elements you want to include in the group by holding the
SHIFT key and clicking each element, or by dragging the mouse over the region where the elements
are located. Each selected element is highlighted.
2. In the main window Topology tab, in the Create group, click Group. The Create Group dialog box
opens.
3. Enter a name for the group.

4. Select a Group Type. Available options depend on whether the group is in the physical or technology
layer.
5. In the Comment field, enter additional details about the group.
6. Click Apply. The group is added to the Inventory tree. To cancel the operation without creating a
group, click Cancel.
A group icon with a group name appears in the map. Click once to lock it in place.
Parent Topic

2.4.2 Adding MEs, LEs, and Groups to a Group

You can add MEs, LEs, and other groups to a group. Partial contents of multiple automatic groups cannot be
included in a user-defined group.
OPTIONAL FEATURE: Adding an NE group to another NE group is a fully integrated add-on

capability, available on a cost basis. If not purchased, this feature and related menu
commands are unavailable.
To add objects to a group:

1. In the appropriate topology view, click the object you want to add to a group and in the main window
Topology tab, in the Modify group, click Add to Group. The Add to Group dialog box opens.
2. If necessary, click the nodes to expand the tree and show specific groups.
3. Select the group to which you want to add the selected object, and click Add.
Parent Topic
2.4.3 Removing MEs, LEs, and Groups from a Group

You can remove MEs, LEs, and/or groups from an existing group.
To remove an object from a group:

 In the appropriate topology view, click the object you want to remove from a group and in the main
window Topology tab, in the Modify group, click Remove From Group. The object is removed.
Parent Topic

2.4.4 Viewing Group Members

In the Map view, you can select an object and view all the objects belonging to the same group.
To show members of the same group:

 Right-click an object and select Show Group Members. All members of the same group are highlighted
in the Map view.
Parent Topic
2.4.5 Expanding/Collapsing Group Objects

You can group similar objects under a single group icon. You can expand/collapse grouped objects to
view/hide the contents.
To expand a group:
 Right-click the group icon and select:
 Expand: display group objects in the same window
 Expand in New View: display group objects in a new window.
To collapse a group:
Right-click an object belonging to the group you want to collapse and click Collapse. All group objects are
grouped under the group icon.
Parent Topic
2.4.6 Deleting Groups

Ungroup members of a group to delete the group but not the individual objects. Automatically created
network groups cannot be deleted manually.
To delete (ungroup) a group:

 In the appropriate topology view, click the group you want to delete, and in the main window Element
tab, in the Element group, click Delete. The group is deleted, but the individual objects remain in the
view.
Parent Topic

2.4.7 Group Properties

You can view or edit the properties of a selected user-defined group, and view related alarms.
To view or edit group properties:

1. In the map view, right-click a group and select Properties. The Properties for Group window opens.
2. Edit the relevant field(s) and click .
3. Click , to view alarms related to group objects.

Table 2-9: Properties for Group dialog box fields
Field Description
Group Name Group name.
Status Status of group (the most severe alarm status of any contained
element), for example, OK or Alarm, including severity (Major, Minor,
etc.).
Group Type Type when group was created.
Parent Group Group to which the group belongs (not relevant if the root is
selected).
Number of Elements Number of elements in the group.
Contained Elements Names of elements in the group.
Comments Free text.
Parent Topic

2.5 Working with UMEs

UMEs represent external equipment that is part of the network but not managed by a LightSoft-managed
EMS, including:
 Client equipment acting as a connection to the LightSoft-managed network. An endpoint must be
created to represent external equipment, before links can be created to the external equipment. A
UME provides the endpoint.
 An element or subnetwork that is not integrated with LightSoft and is therefore not known to it.
 Passive network equipment more commonly part of optical networks, like multiplexers or splitters,
that are generally not managed. To see the true topology of the network, represent them with UMEs.
LightSoft provides templates for UME attributes, such as name, icon, ports of different rates, and traffic
flow pattern (connection between one port and another).
When a UME represents an element or subnetwork connected between two LightSoft-managed
subnetworks, you must create two trails: one from the first subnetwork to the UME, and one from the UME
to the second subnetwork. The UME acts as a terminal to which two separate trails connect.
UMEs are particularly useful when the network has optical sections and optical trails acquired from the
network. If LightSoft is not aware of an ME that acts as an endpoint to an optical trail, the trail is only
partially created. A UME can be created to represent this endpoint.
You can perform a variety of operations on UMEs, as described in this section.
Parent Topic

2.5.1 Creating UMEs

Create UMEs in the relevant topology layer, defining the UME type, and the template you require. You can
also configure the template to match your requirements in the Create UME dialog box in which you select
the type of UME and template to be used.
Figure 2-19: Create UME - Terminal OTN template - Regular ports
LightSoft-provided templates simplify the creation of UMEs in any topology layer. Each template opens in
its own dialog box with appropriate technology labeling.
The number of UMEs that can be created concurrently is limited to 20 by default. Duplicate UMEs use the
same label as the original, with additional extensions (e.g., _1, _2). You can later rename duplicate UMEs
and alter their configuration.
NOTE: The maximum number of UMEs that can be created concurrently is 20. It is not
possible to enter a value larger than 20 in the Number of UMEs field.
When the current focus is a group expanded in a separate view in the physical layer, you can optionally
automatically add the new UMEs to the same group.
New UMEs are automatically added to the user's applicable resource domain, and only users with
permissions for that domain can access that UME. A user with permissions for more than one resource
domain chooses which to apply to the new UME; see UME Basic Fields and Buttons.

To create a UME:
1. In the appropriate technology layer, in the main window Topology tab, in the Create group, click
UME. The Create UME dialog box opens.
 If a physical layer is active, the SDH UME template opens at the Standard SDH type, and the
Technology Layer fields are enabled. Select the required layer.
 If a technology layer is active, the principle UME template of that technology opens; the
associated field is selected by default and the remaining fields are disabled.
2. In the UME Type field, select the required UME template type. Only those of the selected technology
layer are shown.
3. Enter the number of similar UMEs to be created based on the same configuration.
4. Enter the necessary values for the required UME. For information about specific template variations:
 SDH UME Templates
 OTN UME Templates
 ETH/MPLS Data UME Template
TIP:When you place the mouse over an item/field, a context-sensitive popup description
opens, for example, the maximum number of ports allowed.
5. When you have configured the UME, click Apply. A Create UME position holder icon appears at
the cursor position. (You can also click Clear to start over, or Close to close the dialog box without
saving the configuration.)
6. Move the cursor to the required location in the map, and click to place it. One or more UME
icons are placed at the cursor position (according to the parameter Number of UMEs).
7. When the current focus is a group expanded in a separate view in the physical layer, a message
provides the option to automatically add the new UMEs to the same group. To associate the new
UMEs to the group, click Yes. If multiple UMEs are requested, a confirmation message shows the
number of UMEs created.
8. Click OK. The Create UME dialog box reopens.
9. Click Clear to clear the current entries and start again from Step 2, or click Close to close the dialog
box.
If you created multiple UMEs, move each one to space them out in the window map as needed. When you
create a UME, the corresponding LEs are created in the technology layers based on the UME ports.
Parent Topic

2.5.1.1 UME Basic Fields and Buttons

The following information is common to all UME templates.
Figure 2-20: Create UME - SDH templates common content
Table 2-10: UME templates - common information
Selection/Field Description
Technology Layer When opened from a technology layer, that layer's field is selected and all
others are disabled. When opened from the physical layer, all fields are
enabled and any layer can be specified for the UME.
UME Type UME types available for the currently selected technology layer. See:
 SDH UME Templates
 OTN UME Templates
 ETH/MPLS Data UME Template
Click to open the UME Image window, which describes the signal flow of the
currently selected UME type.
Number of UMEs Number of UMEs to be created with the current characteristics.
Resource Domain Appears only if the user has permissions to more than one resource domain.
Select the domain to which to add the UME.
UME Name Identifying name for the UME (mandatory).
UME Location Free text (UME's location).
Comment Free text.
Table 2-11: UME templates - common buttons
Button Description
Apply Creates UMEs based on the specified parameters. The dialog box remains
open ready to create more UMEs if needed.
Clear Clears the current selections so you can start a new UME definition.
Close Closes the dialog box. Any settings that were not applied are discarded.
Parent Topic
2.5.1 Creating UMEs

2.5.1.2 SDH UME Templates

The following specific SDH UME configuration templates are available:
 SDH Standard UME Template
 SDH Inline UME Template
 SDH Splitter UME Template
 SDH Coupler UME Template
 SDH Splitter/Coupler UME Template
Parent Topic
2.5.1 Creating UMEs

2.5.1.2.1 SDH Standard UME Template

The SDH Standard template represents unmanaged ports. SDH trails may terminate in these ports or may
go through the UME. You define the rates and number of UME ports. Port configuration of an existing UME
can be changed as needed; see Modifying UME Ports.
Figure 2-21: Create UME - Standard SDH UME template
Table 2-12: SDH Standard UME template information
Parameters common to all See UME Basic Fields and Buttons.
UMEs
Description of how the element is connected in the network.
Ports per Rate For each port rate, select the number of ports you want to configure. The
available rates are organized within SDH and EoS & Data rate category tabs.
Parent Topic

2.5.1.2.2 SDH Inline UME Template

The SDH Inline template represents unmanaged ports of inline equipment, for example, an amplifier.
Topology links can be created to these ports to depict the network topology, but no trails may use this
UME. Only two ports exist for this type of UME.
Figure 2-22: Create UME - SDH Inline UME template
Table 2-13: SDH Inline UME template information
UMEs
STM Ports Number of UME ports (always two).
Parent Topic

2.5.1.2.3 SDH Splitter UME Template

The SDH Splitter template represents unmanaged ports of splitters. Topology links can be created to these
ports to depict the network topology.
Figure 2-23: Create UME - SDH Splitter UME template
Table 2-14: SDH Splitter UME template information
UMEs
STM Ports Number of UME ports (always three).
Parent Topic

2.5.1.2.4 SDH Coupler UME Template

The SDH Coupler template represents unmanaged ports couplers. Topology links can be created to these
ports to depict the network topology.
Figure 2-24: Create UME - SDH Coupler UME template
Table 2-15: SDH Coupler UME template information
UMEs
Parent Topic

2.5.1.2.5 SDH Splitter/Coupler UME Template

The SDH Splitter/Coupler template represents unmanaged ports of splitter/coupler objects. Topology links
can be created to these ports to depict the network topology.
Figure 2-25: Create UME - SDH Splitter/Coupler UME template
Table 2-16: SDH Splitter/Coupler UME template information
UMEs
Parent Topic

2.5.1.3 OTN UME Templates

The following OTN UME templates are available:
 OTN Terminal UME Template
 OTN Inline UME Template
 OTN Mux UME Template
 OTN DeMux UME Template
 OTN OADM UME Template
 OTN Splitter UME Template
 OTN Coupler UME Template
 OTN DGE Coupler UME Template
 OTN Splitter-Coupler UME Template
 OTN Regenerator UME Template
Parent Topic
2.5.1 Creating UMEs
2.5.1.3.1 OTN Terminal UME Template
The Terminal OTN template represents unmanaged ports of terminal equipment in the OTN layer, typically
client equipment connected to the managed network. Topology links and optical trails can be created to
these ports. The port configuration of an existing UME can be changed as needed; see Modifying UME
Ports.
The window includes a Colored tab for the configuration of colored ports.
Figure 2-26: Create UME - Terminal OTN template - Regular ports

Figure 2-27: Terminal OTN UME template - Colored ports
Table 2-17: OTN Terminal UME template information
UMEs

Non-colored ports: For each port rate, select the number of ports you want to configure.
STM-1-STM-256
FE
GbE, 10 GbE
DSR
FC-1G, FC-2G, FC-10G
Colored OCH ports: Select the number of ports required at the specified rate:
STM-16-C, STM-64-C  0 (default): None.
GbE-C, 10GbE-C  1: One.
OPS-1  40/80/8: An entire band of ports.
OTU1, OTU2, OTU3, OTU4 Tip: If you need more than one port in a band, define the entire band of
ports and then remove those that are not needed using the Modify UME
Ports function; see Modifying UME Ports. (You can remove ports only if no
ports in the band are connected. If any are connected, first remove the
links.)
If you selected 1 or 40/80/8, the OCH Band selector becomes enabled.
Select the band that applies:
 C Band-100GHz: 40 DWDM ports spaced 100 GHz apart.
 C Band-50GHz: 80 DWDM ports spaced 50 GHz apart.
 CWDM: 8 CWDM ports spaced 20 THz apart.
If you selected 1, the OCH Channel selector is also enabled, showing
band-specific channels. Select the required channel for the port.
If the OTU1, OTU2, or OTU3, OTU4 dropdown list is set to:
 1: the OCH Band dropdown list has a Non-Colored option. If selected,
the OCH Channel dropdown list becomes unavailable (gray), and Tuned
Frequency in the OCH layer rate is 1300.
 40/80/8: Applicable number of ports (40 or 80 or 8) created at the
indicated spacing. Channel selection is not relevant in this case.
Note: When an entire band of ports is created, the ports can be modified
(certain ones removed) provided no ports have been connected.
Parent Topic

2.5.1.3.2 OTN Inline UME Template

The OTN Inline template represents unmanaged ports of terminal equipment in the OTN layer, typically
client equipment connected to the managed network. Topology links and optical trails can be created to
these ports.
Figure 2-28: Create UME - OTN Inline UME template
Table 2-18: OTN Inline UME template information
UMEs
Fiber Ports Number of UME ports (always two).
Parent Topic

2.5.1.3.3 OTN Mux UME Template

The OTN Mux template represents unmanaged ports of a C band Mux. The channels differ depending on
the OCH Band configured.
OCH Band Channels

C Band-100 Ghz 40
C Band-50 Ghz 80
C Band Ext-100 Ghz 44
Figure 2-29: Create UME - OTN DeMux UME template

Table 2-19: OTN Mux UME template information
UMEs
Select UME Type

Whether the UME is a Mux or DeMux.
OTM Ports Number of OTM ports (always one).
OCH Band Selection The C Band. (100 Ghz, 50 Ghz, Ext-100 Ghz, Ext-50 Ghz.)
OPS_1 Ports Number of OPS_1 ports. This changes depending on what is selected for
OCH Band Selection. (40/80/44/88).
STM Ports Number of UME ports (always two).Number of UME ports (always two).
Parent Topic

2.5.1.3.4 OTN DeMux UME Template

The OTN DeMux template represents unmanaged ports of a 40-channel C band DeMux The channels differ
depending on the OCH Band configured.
OCH Band Channels

C Band-100 Ghz 40
C Band-50 Ghz 80
Figure 2-30: Create UME - OTN DeMux UME template

Table 2-20: OTN DeMux UME template information
UMEs
Select UME Type

Whether the UME is a Mux or DeMux.
OTM Ports Number of OTM ports (always one).
OCH Band Selection The C Band. (100 Ghz, 50 Ghz, Ext-100 Ghz, Ext-50 Ghz.)
OPS_1 Ports Number of OPS_1 ports. This changes depending on what is selected for
OCH Band Selection. (40/80/44/88).
STM Ports Number of UME ports (always two).
Parent Topic

2.5.1.3.5 OTN OADM UME Template

The OTN OADM template represents unmanaged ports of an OTN OADM. You can specify to add and drop
four channels that can be configured as either East/West or A-B.
Figure 2-31: Create UME - OTN OADM UME template
Table 2-21: OTN OADM UME template information
UMEs
OADM Type
Whether the OADM is East/West (EW) or AB.
OTM Ports Number of OTM ports - 4 for East/West, 2 for A-B.
OCH Band Selection C Band. 100 GHz automatically applies.
OPS_1 Ports Number of OPS_1 ports used for the OCH trail add/drop (always eight).
Select OCH Frequencies Select the required channels.
Parent Topic

2.5.1.3.6 OTN Splitter UME Template

The OTN Splitter template represents unmanaged ports of a splitter. Optical LightPath trails may traverse
this UME.
Figure 2-32: Create UME - OTN Splitter UME template
Table 2-22: OTN Splitter UME template information
UMEs
Fiber Ports Number of UME ports (always three).
Parent Topic

2.5.1.3.7 OTN Coupler UME Template

The OTN Coupler template represents unmanaged ports of a coupler. Optical LightPath trails may traverse
this UME.
Figure 2-33: Create UME - OTN Coupler UME template
Table 2-23: OTN Coupler UME template information
UMEs
Fiber Ports Number of UME ports (always three).
Parent Topic

2.5.1.3.8 OTN DGE Coupler UME Template

The OTN Dynamic Gain Equalizer (DGE) Coupler template represents unmanaged ports of a coupler used
for 80-channel DGE sites. Optical LightPath trails may traverse this UME.
Figure 2-34: Create UME - OTN DGE Coupler UME template
Table 2-24: DGE Coupler UME template information
UMEs
Source Ports Number of source ports (always one).

(80 Channels)
Sink Ports Number of sink ports (always two).
(40 Channel)
Parent Topic

2.5.1.3.9 OTN Splitter-Coupler UME Template

The OTN Splitter/Coupler template represents unmanaged ports of a splitter/coupler. Optical LightPath
trails may traverse this UME.
Figure 2-35: Create UME - OTN Splitter/Coupler UME template
Table 2-25: OTN Splitter/Coupler UME template information
UMEs
Fiber Ports Number of UME ports (always six).
Parent Topic

2.5.1.3.10 OTN Regenerator UME Template

The OTN Regenerator UME represents unmanaged ports of an OTN regenerator. You can specify the port
type and channels.
Figure 2-36: Create UME - OTN Regenerator UME template
Table 2-26: OTN Regenerator UME template information
UMEs
Line Port OPS-1, OTU1, OTU2, OTU3, OTU4.

Channel 1 Default 0. If left as 0, the port can be used for any OCH channel. If you select
a specific channel, only that channel can be used for a new trail. You can
select any of the 40 DWDM or 8 CWDM channels (192.1 to 196.0 or 1471 to
1611).
Channel 2 As Channel 1.
Parent Topic

2.5.1.4 ETH/MPLS Data UME Template

The ETH/MPLS Data UME template represents ETH/MPLS layer ports of UMEs, typically client equipment
connected to the managed network. The port configuration of an existing UME can be changed as needed;
see Modifying UME Ports.
Figure 2-37: Create UME - OTN ETH-MPLS Data UME template
Table 2-27: OTN ETH/MPLS Data UME template information
UMEs
Opens a description of how the element is connected in the network.
Ports per Rate Number of ports per required rate.
Parent Topic
2.5.1 Creating UMEs

2.5.2 Modifying UME Ports

You can modify the port configuration of existing Standard SDH, OTN Terminal, or ETH/MPLS Data UMEs,
using the Modify UME dialog box. (The ports on other UME types are not configurable.)
Figure 2-38: Modify UME dialog box
See also UME Properties.
NOTE: If you need more than one OCH port in a band, define the entire band of ports (see
OTN Terminal UME Template) and then remove the ports that are not needed using the
Modify UME Ports function. You can only remove ports that are not connected. If they are
connected, first remove the links.
To modify a UME:
1. With the Physical (Site) layer selected, in the LightSoft main window map view, right-click the UME
you want to modify and select Modify UME Ports. The Modify UME dialog box opens, showing the
current UME type and values. The fields vary according to the UME type. If the number of ports for
the UME type is fixed, the message "Cannot add ports to this type of UME" appears.
2. Edit the values, as required (editable fields have a white background).
3. Click Apply to save the changes. An Action Completed window opens. Click OK. The Modify UME
Ports dialog box closes.
Parent Topic

2.5.3 Accessing a UME via Telnet

Telnet is a user-host protocol that allows you to connect to a UME from your UNIX station. A telnet window
opens to the equipment, enabling you to run CLI commands. Available functions vary according to the
equipment characteristics.
For Telnet to be accessible, the UME must have a valid IP address, and port, if needed. You code this
information in the Properties for UME dialog box IP Address field. The format is 1.1.1.1 8888 (IP 1.1.1.1 and
port 8888). See UME Properties.
NOTE: As an external application, Telnet is not affected by LightSoft's inactivity timeout

mechanism. If LightSoft senses inactivity and automatic locks or logs out, the Telnet session
remains active.
To start a Telnet session with a UME:

1. In the Physical (Site) or EMS layer, right-click a UME in the map view and select Telnet UME. A Telnet
window opens.
(If the IP address is missing or invalid, a message appears. Click OK. Add or correct the IP details in the
Properties for UME dialog box IP Address field, and retry.)
2. Run CLI commands, as needed, in accordance with the equipment characteristics.
3. When you have finished, close the Telnet window to return to the LightSoft environment.
Parent Topic

2.5.4 UME Properties

You can view and edit the properties of selected UMEs.
To view or edit the UME Properties

1. Right-click a UME in the map view, and select Properties. The Properties for UME dialog box opens.
Figure 2-39: Properties for UME dialog box
2. Edit the relevant fields, and click .
Table 2-28: Properties for UME dialog box fields

Field Description
UME Name UME name. LightSoft allows you to keep a primary LE name in a
technology layer either aligned with or different from that of its related
ME/UME in a physical layer. See Viewing and Editing Object Properties.
UME Type UME type, defined in the UME creation process.
Location Free text (UMEs location).

Logical Elements (LEs) Names of the LEs in different technology layers to which the current
UME is mapped.
IP Address
For Telnet accessibility, field contains a valid IP address, and port, if
needed, Format is 1.1.1.1 8888 (representing equipment with IP 1.1.1.1
and port 8888).
Comment Free text.
Parent Topic

2.6 Working with EMSs

As a network management system for large networks, LightSoft acts as an umbrella system for multiple
EMSs.
You can perform a variety of operations on EMSs. This section describes EMS-specific operations:
 Viewing EMS list: See Viewing the EMS List.
 Create EMS: See Creating EMSs.
 Manage/Unmanage EMS: See Managing and Unmanaging EMSs.
 Force Upload: See Forcing EMS Uploads.
 Accessing an EMS: See Accessing EMSs.
 Discover ME: See Discovering MEs.
For information about the properties of EMS, see Viewing/Editing EMS Properties. For specific EMS
information, see the corresponding EMS User Guide.
Other EMS operations, common to more than one object type, are described in Accessing EMSs.
OPTIONAL FEATURE: The number of EMSs that LightSoft manage is a fully integrated add-on
capability, available on a cost basis. It is not possible to create and manage more EMSs than
stipulated in your license.
Parent Topic
2.6.1 Viewing the EMS List

The EMS List window displays information about the EMSs managed by LightSoft.
To open the EMS List:

2. In the main window Topology tab, in the Lists group, click EMS List. The EMS List window opens.

Table 2-29: EMS List window menu and toolbar
Toolbar
Menu option Description
icon
List
Export Exports list data to a delimited format file, such as
comma-separated values (CSV), for import to Microsoft Excel or
a relational database application.
EMS
Properties Displays information about the selected EMS.
Open Opens a GCT to the selected EMS.

Current Alarms Opens a GCT to the Current Alarms window, filtered to show
only alarms in the selected EMS.
Create ME Opens the Create ME window.
Force Upload Force uploads the selected EMS.
Create EMS Opens the Create EMS window.
Table 2-30: EMS List window columns
Column Description
Managed Status Status of the EMS: Managed or Unmanaged.
EMS Name Name of the EMS.
Registry Name Name of the EMS in the CORBA naming service registry.
EMS Type EMS type, for example, EMS-MPT.
EMS Host Address IP address of the EMS server.
EMS Version Version number of the EMS.
No. of MEs Number of elements managed by the EMS.
WS_ID EMS workstation ID.
Parent Topic

2.6.2 Creating EMSs

You can create an EMS in LightSoft.
WARNING: Contact your local Customer Support representative before performing any of the
operations described in this section.
To create an EMS:
2. In the main window Topology tab, in the Create group, click EMS. The Create EMS window opens.
Figure 2-40: Create EMS dialog box
3. Select an EMS in the Registry Name tree.

4. Enter the details of the EMS in the fields, and click Apply. The new EMS is created and added to the
EMS list.
Table 2-31: Create EMS dialog box fields

Field Description
Registry Name EMS registry names in a tree structure.

EMS Name Name identifying the EMS in LightSoft.
Session Login Login name for accessing the EMS. This value is transferred to the EMS.
Note: When creating a generic EMS, specify LSNuser as the session login.
Session Password Password for accessing the EMS with the session login; generally "1". This
value is transferred to the EMS.
Note: When creating a generic EMS for GenEMS V1.15, specify genems as
the session password. For later versions, use "1".

Field Description
Registry Name EMS registry names in a tree structure.

Managed Status Whether the EMS is managed or unmanaged.
LightSoft Workstation Name of LightSoft workstation providing access to the EMS.
Parent Topic
2.6.3 Managing and Unmanaging EMSs

EMSs controlled or not controlled by LightSoft are considered managed or unmanaged, respectively. Their
status is indicated in the EMS List window Managed Status column. Set an EMS to Unmanaged during
maintenance or repair to prevent LightSoft from receiving notifications from the EMS during this time.
To set the EMS status:

2. Select an EMS, and click Properties . The Properties for EMS dialog box opens.
3. Change the Managed Status field from Unmanaged to Managed or vice versa.
4. Click Apply.
Parent Topic
2.6.4 Forcing EMS Uploads

You can force upload an EMS or its alarms. The color of the EMS icon is blue during upload and then
changes to its updated state.
To force upload an EMS:

1. In the Physical (EMS) topology view, select an EMS.
2. In the menu bar, select System, Force Upload, and then EMS. The EMS data is uploaded.
To force upload alarms for an EMS:

1. In the Physical (EMS) topology view, select an EMS.
2. In the menu bar, select System, Force Upload, and then Alarms. The alarms for the EMS are
uploaded.
Parent Topic

2.6.5 Discovering MEs

Discovering MEs is a way to expedite ME creation by creating multiple MEs concurrently. Specify the range
of IP addresses you want to search during the discovery process. When IP address ranges are not
continuous, you can exclude certain addresses.
NOTE: The discovery process requires support from the EMS managing the MEs. Not all EMSs
support the discovery mechanism.
To discover MEs:
 In the Physical (EMS) layer, right-click an EMS in the map view or its node in the Inventory tree, and
select Discover ME. The NE discovery window of the EMS opens.
Parent Topic
2.6.6 Viewing/Editing EMS Properties

You can view or edit the properties of an EMS in the Properties for EMS window. Note that only properties
relevant for the selected EMS are displayed.
WARNING: Consult your local Customer Support representative before editing EMS
properties.
To view/edit EMS properties:


3. Select the EMS you want to view/edit, and click Properties . The Properties for EMS dialog box
opens.
Figure 2-41: Properties for EMS window
4. Edit the relevant fields (fields with a white background are editable), and click Apply ( ).
5. To view alarms for the selected EMS, click Alarms . The EMS Current Alarms window opens
filtered for the selected EMS.
6. To open a GCT to the EMS, click Open object .

Table 2-32: Properties for EMS dialog box fields
Field Description
EMS Name Name of EMS.
Status Current alarms status of EMS (highest severity status).
Managed Status Indicates whether EMS is managed or unmanaged.
Disconnected MEs Number of disconnected elements managed by the EMS.
Registry Name Registry name of EMS.
EMS Host Name Name of EMS host.
EMS Host Address IP address of EMS host.
EMS Type Type of EMS, for example, EMS-MPT or StubEMS.
EMS Version Version number of EMS.
MTNM Version Version number of MTNM.
EMS Location Location of EMS in the network.
Number of MEs Number of elements managed by EMS.
Session Login Login for initiating EMS session.
Session Password Session password.
Managing Workstation LightSoft workstation managing the EMS (relevant for cluster
configuration only).
Active NMS Host
Connect Failure Reason Displays reason for connection failure when EMS alarm color code is gray.
Comments Free text.
Parent Topic
2.6.7 Accessing EMSs

You can access an EMS directly from LightSoft without having to start a new session via the EMS List
window, or you can access an EMS via a GCT session. LightSoft features single sign-on between supported
layers. Once you are logged in to LightSoft, you do not require an additional login to access managed EMSs
through GCT.
The EMS window and available options vary according to the object from which you access the EMS. For
example:
 Starting from an EMS opens the EMS main window.
 Starting from an ME or primary LE generally opens a shelf view. In some cases, such as the SR9700
family product line of Carrier Ethernet Switch/Routers (CESR), the EMS (STMS is the SR9700 EMS) main
window opens.
 Starting from a secondary LE (if all ports of the LE relate to the same card) opens the card internals
view. Otherwise, the shelf view opens.

When you perform GCT to EMSs such as the STMS, security levels and capabilities applying at the EMS level
may differ from LightSoft-assigned levels.
NOTE: The EMS window and available options vary depending on the EMS selected.
To access an EMS from the EMS List:

2. Select the EMS you want to access.
3. In the EMS List window toolbar, click . The main window of the EMS opens.
To access the EMS via GCT:

In the Main window map or the tree view, right-click the relevant object and select Open. The EMS main
window opens. Additional GCT options are listed in the following table.
Table 2-33: GCT operations menu
Operation Description
Open Display object windows from an EMS without having to start an
individual EMS session.
Current Alarms (EMS) Display current EMS alarms for an object without having to start an
individual EMS session.
Software Management Update selected NEs' resident software in the EMS.
Cross Connection Create or modify cross connects for a selected ME or LE.
Ping Ping an object to determine whether it is connected to the network and
is active; see Pinging an Object.
Set Route Set the EMS IP routing data that supervises communications between
the EMS and its managed NEs; see Setting EMS IP Routing Data.
Set Printers Access to the EMS printer configuration window.
Parent Topic

2.6.7.1 Viewing EMS Current Alarms for an Object

You can view the EMS Current Alarms window for an object without having to start an individual EMS
session.
To view EMS current alarms:

1. In the Physical (EMS) layer, right-click an EMS in the map view or its node in the Inventory tree.
OR
In the relevant topology layer, right-click an ME or LE in the map view or its node in the Inventory
tree.
2. Select Current Alarms (EMS). The Current Alarms window of the corresponding EMS opens. View the
alarms as described in the corresponding EMS User Guide.
Parent Topic
2.6.7.2 Updating NE Software

You can update selected NE software from the EMS by drilling down to the EMS SW Download window via
GCT.
To update NE resident software:

1. In the Physical (EMS) layer, right-click an EMS in the map view or its node in the Inventory tree.
OR
In the relevant topology layer, right-click an ME or LE in the map view or its node in the Inventory
tree.
2. Select Software Management. The EMS SW Management window opens. Complete the action as
described in the corresponding EMS User Guide.
Parent Topic
2.6.7.3 Creating and Modifying Cross Connects

You can create or modify cross connects for a selected ME or LE by accessing the EMS XC Browser window
via GCT.
To create or modify cross connects:

 In the relevant topology layer, right-click an ME or LE in the map view or its node in the Inventory tree,
and select Cross Connection. The EMS XC Browser window opens. Complete the action as described in
the corresponding EMS User Guide.
Parent Topic

2.6.7.4 Pinging an Object

You can ping an object to determine whether it is connected to the network and is active. As the ping
executes, ping data appears in the dialog box.
To ping an object:
1. Select a topology layer.
2. Select an object in the Map view, and on the menu bar select System and then Ping. A Ping dialog box
opens; the ping executes and data is posted to the dialog box.
3. To stop the operation, click Stop. To restart the operation, click Start.
Parent Topic
2.6.7.5 Setting EMS IP Routing Data

This function opens a UNIX window and activates the Set Route script for setting EMS IP routing data
regulating communications between the EMS and its managed NEs.
Contact your local Customer Support representative for further information about this utility.
To set EMS IP routing data:

1. Select the Physical (EMS) topology layer.
2. Select an EMS in the Map view.
3. In the main window System menu, in the Tools group, click Set Route.
Parent Topic
2.6.7.6 Setting Printers

You can set printers in the EMS Printer Configuration window, directly from LightSoft.
To set printers:
1. Select the Physical (EMS) topology layer.
2. Select an EMS in the Map view and in the main window System menu, in the Tools group, click Set
Printers.
Parent Topic

2.7 Common LightSoft Operations on Objects

You can perform a wide range of LightSoft and GCT operations on objects selected in either the LightSoft
main window map or in the tree view. Most operations can be performed in the menu bar, toolbar, or
shortcut menus. Some operations are available only from shortcut menus.
You can perform operations on secondary objects like individual ports by drilling down in the tree. These
operations include, for example, opening a GCT session to the EMS shelf view for a port.
Parent Topic
2.7.1 Viewing and Editing Object Properties

You can view and edit detailed information about an object (ME, LE, group, UME, EMS, or network).See the
following sections:
 Viewing/Editing ME Properties
 Viewing/Editing LE Properties
 Group Properties
 UME Properties
 Viewing/Editing EMS Properties
 PB Network Properties
To view object properties:

1. In the relevant topology layer, select the object whose information you want to view, and in the main
window Element tab, in the Element group, click Properties. A Properties window opens displaying
information about the selected object. Fields with a white background are editable.
2. Edit fields that you want to change and click Apply ( ). A confirmation window opens.
3. Click Yes. The changes are saved.
Parent Topic

2.7.2 Viewing Object-related Current Alarms

You can view a filtered list of current alarms associated with a selected object.
To show the current alarms associated with an object:

 Right-click the object and select Current Alarms. The Current Alarms window opens, showing the
alarms on the selected object.
NOTE: For information about fault management, see the Performance Management Guide.
Parent Topic
2.7.3 Viewing Trails

You can view trails traversing a specific element or link. You can choose to view only trails of a specific
technology type when selecting a single SDH or optical link. (This option is not available from Ethernet links,
multilinks, or NEs.)
To view the trails traversing a specific object:

 Right-click the element or link, select Show Trails, and then:
 If the object is an individual link with SDH rates, select either High Order or Low Order.
 If the object is an individual link with optical rates, select the relevant rate from the list of
optical trail types.
A Trail List window opens, displaying only trails traversing the selected object.
Parent Topic
2.7.4 Deleting Objects

You can delete objects in the LightSoft database.
MEs/UMEs:
 Before deleting an ME or UME, delete associated topology links and trails (see Removing an Element
from a Link).
 The ability to delete an ME from LightSoft depends on the object being connected to LightSoft and the
compatibility of the corresponding EMS:
 If the EMS supports deleting an object from LightSoft, the object is deleted from LightSoft and
the EMS at the same time.
 If the EMS does not support deleting an object from LightSoft or the ME is disconnected, first
delete it manually from the EMS. Then it is automatically deleted from LightSoft.

LEs:
 Primary LEs cannot be deleted.
 Deleting a secondary LE removes the secondary LE icon and returns all associated resources (ports and
links) to the primary LE.
Groups:
 Deleting a group removes the group icon and removes the association between the grouped objects. It
does not delete the group members (see Deleting Groups).
To delete an object:
 Select an object, and in the main window Element tab, in the Element group, click Delete. The object
is deleted.
Parent Topic
2.7.5 Creating an EMS or NE Inventory

You can produce an equipment inventory for a specific EMS, NE, or for all NEs on the network.
An NE inventory includes the NE ID, name, and all associated equipment for each NE. You can include only
the actual type of NE cards or both the actual and expected types.
The script output provides the following equipment information, where applicable:
Column Description
Expected Assigned card per slot assignment.
Actual Equipment physically in the slot.
Version Hardware and software versions.
Serial # Equipment serial number.
Application code Type of optical module.
Format the report output using your choice of delimiter.
To retrieve inventory information:

 In the UNIX command line, run the following minimum parameters:
EqpInvnt.pl -h
EqpInvnt.pl -d X -e ems_name -n ne_name -a
EqpInvnt.pl (This expression prints CSV file to UNIX terminal.)
The following script options apply:

usage: EqpInvnt.pl [-d X] [-e ems_name] [-n ne_name] [-a]
Where:

Command Description
-a Includes only cards with actual type (type not equal to NONE). If command is
omitted, expected type is also printed.
-d X
Output report should use X delimiter, not spaces. If command is omitted, a CSV
format is implied.
-e ems_name Includes information related to the specified EMS (e.g., EMS_MPT_xx).
-n ne_name Includes information related to the specified NE (e.g., ManagedElement~~xxx). If
omitted, information for all the NEs associated with the EMS is printed.
Example Output
EMS EMS_MPT_12 XDM.z2-csl-6.715"
=============================================================
NE ManagedElement~~4556 "XDM4556"
-------------------------------------------------------------
"I3 OM16_1 1 " "HW Undefined, SW Undefined" "123456" "PS3"
"I6 OM16_1 2 " "HW Undefined, SW Undefined" "123456" "PB5"
NE ManagedElement~~2892 "1234567_1234567_1234567_1234567"
-------------------------------------------------------------
"IC5 PIO2_84 " "HW Undefined, SW Undefined" "123456" "N/A"
"IC2 OM16_1xx 1 " "HW Undefined, SW Undefined" "123456" "AV5"
"IC2 OM16_1xx 2 " "HW Undefined, SW Undefined" "123456" "AV5"
Parent Topic

3 ETH/MPLS Networking
The LightSoft 1Net end-to-end traffic management solution features a global Multiprotocol Label Switching
(MPLS) layer that includes an unlimited number of MPLS Provider Edge (PE) elements in the MPLS layer.
These PEs may be interconnected in a variety of ways, including E-LSP tunnel mode in forward and
backward directions and label switching over the tunnel paths using MPLS over Transport (MoT) trails and
MPLS over Ethernet (MoE), or MPLS over Generic Routing Encapsulation (MoG) links. The free PEs can
optionally be organized within Admin groups if desired.
The MPLS layer can include Provider Bridge (PB) elements organized in PB networks. These can flexibly be
interconnected with MPLS PEs. LightSoft also supports L1 and L2 root and leaf service configurations.
In the LightSoft GUI:
 represents MPLS PE elements.
 represents PB elements.
 represents PB networks.
 represents hybrid EA-HVPLS groups combining PB and MPLS elements.
 represents MPLS networks in LightSoft installations that have not yet upgraded to the current
global MPLS structure.
3.1 Global MPLS Layer

An MPLS network is designed to carry a wide variety of data traffic, including IP packets, native ATM, SDH,
and Ethernet frames. MPLS brings new concepts to data communication networks, such as virtual circuit
(VPN) network capabilities, traffic engineering techniques for better QoS, Fast Reroute (FRR) protection,
and reduced performance requirements from switching equipment.
The LightSoft 1Net solution offers the following global MPLS layer features:
 One global parent MPLS network. All MPLS PEs are placed directly under the MPLS layer root in the
network inventory tree. Each PE is identified by a unique global MPLS network ID (Global PEID).
To simplify network management, the many objects in the MPLS layer can be organized into logical
Admin groups; see Administrative Groups.
 MPLS tunnel paths can traverse MoT trails and MoE, and MoG topology links. MoE links can be routed
to/from any PE in the entire MPLS layer, including not-yet-upgraded PEs in individual MPLS networks,
while MoT trails typically connect MPLS PEs only within the individual MPLS networks. See MPLS Layer
Connections.
 Tunnels configured in E-LSP mode can be configured with up to eight CoS-color combinations; see
Tunnel Mode.
 Label switching over the tunnel path enables different equipment with varying label ranges to coexist
in a single network; see Label Switching.

LightSoft® User Guide ETH/MPLS Networking
 LightSoft manages MPLS networks with mixtures of upgraded PEs under the global MPLS layer root
and not-yet-upgraded PE members of individual MPLS networks. However, PEs should be upgraded to
global MPLS layer functionality as soon as possible; see Upgrading PEs and PBs to Global MPLS Layer
Functionality.
Not-yet-upgraded MPLS cards continue to be associated with their former individual MPLS networks,
as explained in earlier versions of the LightSoft User Guide. They are identified by a local PE ID within
a specific MPLS network; see MPLS PE and PB Identification.
Parent Topic
3.1.1 VPLS and MPLS Networking

MPLS PE LEs (such as MCS) use Virtual Private LAN Service (VPLS) to implement MP2MP Ethernet services
over MPLS networks.
The service entity in a single MPLS PE is referred to as a Virtual Switch Instance (VSI), also known in generic
MTNM terminology as a Flow Domain Fragment (FDFr).
A VSI is implemented for each service endpoint LE. On an MPLS network, these endpoint LEs are
interconnected by MPLS tunnels and the Ethernet frames are encapsulated into MPLS frames using two
MPLS labels: the outer tunnel label and the inner Ethernet service. The VSI indicates over which tunnel(s) to
transmit a frame using the Ethernet Address Learning mechanism. At the end of the tunnel, the inner label
determines which VSI handles the frames. In order to prevent looping, a VSI forwards such an incoming
frame over an Access Link and never over another tunnel. (This is called the Split Horizon mechanism.)
For MP2MP services, a full mesh of tunnels is generally required between the LEs that are service
endpoints. (The number of connections can be optimized though an H-VPLS configuration; see
Understanding H-VPLS Service.)
A similar mechanism, Virtual Private Wire Service (VPWS), is used to implement a P2P Ethernet service over
an MPLS network. In this case, Ethernet address learning is not required.
The following diagram shows a MP2MP service implemented by VPLS. This configuration involves a full
tunnel mesh connecting the LEs of each service endpoint.
Figure 3-1: MPLS network
Parent Topic
3.1 Global MPLS Layer

3.2 Provider Bridge Networks

A Provider Bridge (PB) networks is a type of bridged network used by communications providers. A bridge
network relays Ethernet frames between the bridges over Ethernet links using learning. To prevent looping,
RSTP is implemented on the bridges. A PB network relays a customer's Ethernet frames (with optional
C-VLAN tagging) between customer sites using provider bridging.
An S-VLAN tag may be added to the customer frames to identify the services to which they belong. The
service entity in a single PB is referred to as a Virtual Switch Instance (VSI), also known in generic MTNM
terminology as a Flow Domain Fragment (FDFr).
In LightSoft networks, the PBs are typically connected with EoS trails. L2 cards/logical elements (such as EIS
and MCS) implement PBs. They are interconnected by EoS trails and the Ethernet frames are encapsulated
in GFP for transmission over them A PB L2 service typically interconnects multiple Ethernet (ETY) ports. (For
a description of all data port types supported by LightSoft at the logical level, see Supported ETH/MPLS Port
Types.)
The following diagram illustrates a simple PB network.
Figure 3-2: Provider Bridge network
A PB can also include root and leaf configurations, with an EoS trail connecting an L2 bridge card and an L1
data card (such as DIO); see Root and Leaf Configurations.
Parent Topic

3.3 Hybrid Network Configurations

MPLS and PB NEs can be combined into hybrid administrative groups. MPLS elements can be connected to
PB networks to form an Ethernet Access Hierarchical VPLS (EA-HVPLS) network group. EA-HVPLS groups
overcome limitations on the number of services configured on a single PB network. The PB LEs are divided
into smaller subnetworks by placing an MPLS element between them. More importantly, such a
configuration allows the MPLS element to interconnect with multiple PB networks.
The following figure shows an EA-HVPLS group consisting of an MPLS component connected to two PB
networks via EoS trails.
Figure 3-3: EA-HVPLS group
A service begins and leaves at service endpoints on PB cards (such as EIS), traversing EoS trails between the
PBs. The frames enter and leave the MPLS part of the network through gateway PEs, traversing MPLS
tunnels over MoT trails between MPLS PEs.
Typically, two links are configured between the PB networks and MPLS components for redundancy
protection. Dual homing is used to prevent loop formation. The BPDU frames (used by RSTP) are carried
through the MPLS component between the ports by defining a dual homed service. This mechanism
ensures that one of the links is active and the other is standby.
Parent Topic
3.4 Administrative Groups

In the MPLS layer schema, all PEs are 'free PEs' in a single global MPLS layer. To facilitate their
management, PEs can be grouped into Admin Groups.
These groups are especially useful for a large network that contains isolated islands or logical parts, each
providing a different service. Groups avoid the strict MPLS network rules that generally apply to MPLS layer
objects.
Admin groups and data networks reflect the alarms of their contained LEs, and networks and links reflect
any inconsistent topologies.
PB networks remain as networks within the global MPLS layer and retain their network properties. PB
groups are also available for special purpose grouping needs.

External and Internal Groups

The following figure shows internal Admin groups within a PB network.
Figure 3-4: Internal Admin groups within a PB network
An Admin group can contain an entire PB network and one or more PEs located directly under the MPLS
layer’s root. The following figure shows external administrative groups that include several networks.
Figure 3-5: External Admin groups including several networks
Admin Group Operations

You can change the group composition, assign meaningful names, and collapse groups for convenience. The
following groupings can be created:
 PB network with another PB network.
 PB LEs within the same PB network.
 Free PEs in a new group, with additional free PEs.
 Free PEs with a PB group to form an Admin group, with additional free PEs added/removed to/from
the group as needed.
You can assign any group type (PB, MPLS, EA-HVPLS, etc.) that logically describes the entity you are
creating.
Restrictions
 A group cannot cross a network. For example, a free PE from the MPLS layer cannot be grouped with
some PBs of a PB network. The free PE must be grouped with the network as a whole.
 Adding a free PE to a PB network is not allowed.
 Selected LEs can be grouped within a PB or MPLS network (for example, 4 of 8 elements can be
selected for a group). Additional LEs cannot subsequently be added (for example, a 5th LE). You must
first delete the group and then redefine it with five LEs.
Parent Topic

3.5 Root and Leaf Configurations

Root and leaf configurations are typically used for customers or branch offices that only communicate
directly with the headquarters and not with one another.
L1 P2P Services
L1 devices (such as DIO) can be connected by EoS trails. This creates an L1 P2P service between the ETY
endpoints. No network is implied.
Figure 3-6: L1 P2P services
L1 Root and Leaf Network

L1 root and leaf is an Ethernet L1 network, comprising P2P connections between an L2 device at the
headquarters node (for example, an MCS card configured as either MPLS or PB) and L1 cards (such as DIO)
at branch office nodes, connected by EoS trails. According to the L2 card configuration, either an MPLS or a
PB network is formed.
Figure 3-7: L1 root and leaf network
L2 P2MP Service Implemented on MPLS Network

A VPLS root and leaf configuration (also known as VPLS Star) involves L2 MPLS cards (such as MCS) at all
nodes, using MoT trails and tunnels to connect the headquarters and branch office nodes. The connections
comprise an MPLS network. The associated LightSoft service is referred to as P2MP (root and leaf).
NOTE: A leaf in one PE cannot send traffic to a leaf in another PE within an MPLS network.
However, traffic is not blocked between leaves in the same MPLS PE or within a PB network.
Parent Topic

3.6 MPLS PE and PB Identification

In the global MPLS layer topology, each PE is identified by a global MPLS network ID (Global PEID) that is
unique throughout the MPLS layer, enabling the PE to be provisioned in the MPLS layer root. PEs that have
been upgraded from earlier versions are assigned a Global PEID which is a combination of the former
network ID and the PE ID. Not-yet-upgraded PEs are also identified through a unique global MPLS network
ID.
Changing the Global PEID

PEs with PEIDs that are not unique (such as a newly inserted PE with the same PEID as an existing PE) are
considered inconsistent in LightSoft; their corresponding LE state becomes inconsistent and the LE is
colored white in the topology map and tree. Until the inconsistencies are cleared, these PEs cannot be
connected or used in any provisioning action.
To clear the inconsistency from each PE:

 Modify each PE's network ID or PEID in the EMS so that the Global PEIDs in LightSoft are unique.
Changing the PE ID
Not-yet-upgraded MPLS PEs with the same PB network ID are grouped in one MPLS network. Changing the
MPLS network ID of a PE LE associates the LE under the corresponding new MPLS network.
You can change the PE ID in the EMS only if the MPLS card has no MoT/MoE/MoG ports. Ensure that the PE
ID is unique within the intended network. Note that:
 If the PE is not connected, and an individual MPLS network exists with the same value, the PE becomes
a member of that network.
 If the PE is connected in LightSoft by an MoT, MoG, or MoE connection, the EMS change is rejected
and the PE remains where it is with its former global PE ID. When the PE resides in an individual MPLS
network, the PE becomes inconsistent (reason "Inconsistent - MPLS network ID - NMS-EMS conflict").
Changing the PB LE Network ID

All PB LEs with the same PB network ID are grouped in one PB network (PB network ID and Ethernet
network ID are the same attribute). Changing the Ethernet network ID of a PB LE associates the LE under
the corresponding new PB network.
You can change the PB network ID in the EMS only if the LEs are free from all connections (links, trails,
services). Recreate those connections after the PB is moved.
NOTE: If you do not wish to remove the connections, perform a Split PB Network procedure.
For details, contact your local Customer Support representative.
Parent Topic

3.6.1 Upgrading PEs and PBs to Global MPLS Layer

Functionality
LightSoft accommodates network configurations that include MPLS PEs not yet upgraded to global MPLS
layer functionality. These PEs are located within individual MPLS networks of up to 256 PEs. These legacy
MPLS networks can connect to PB networks (L2 access network), with the combined MPLS-PB network
constituting a single Ethernet Access (EA) network. The EA networks are not connected by tunnels.
Legacy not-yet-upgraded PEs remain in their former MPLS networks until all PEs in that network are
upgraded. LightSoft then converts the MPLS network (and any associated EA-HVPLS networks) into Admin
groups according to their former individual network associations:
 Former MPLS networks become MPLS groups.
 Former EA-HVPLS networks become EA-HVPLS groups, including MPLS groups and any associated PB
networks.
Automatically created Admin groups behave in exactly the same way as user-defined groups. The same
network icons are used to identify the new MPLS and EA-HVPLS groups in map views.
When PEs are subsequently added to LightSoft:
 Upgraded PEs are automatically placed under the root of the MPLS layer, and organized within new or
existing groups in the same way as other user-defined groups. Parameters of upgraded PEs are
configured through System Preferences.
 Not-yet-upgraded PEs are automatically placed in individual MPLS networks according to their
assigned network ID. As with legacy PEs, after all PEs of a network are upgraded, the associated
networks are automatically converted to groups. Parameters of not-yet-upgraded PEs are configured
through individual PE properties windows.
NOTE: When an added upgraded PE has the network ID of an existing individual MPLS
network, it becomes a member of that MPLS network. In this way, upgraded PEs are utilized to
expand existing MPLS networks of not-yet-upgraded PEs. Expanding the network does not
necessitate first upgrading all the existing PEs.
The following figure describes an MPLS network of PEs upgraded to support MoT trails and MoE links. It
shows that the tunnel path can traverse multiple MPLS networks, and be routed to/from any PE in the
entire MPLS layer. This example also applies to MoG links.
Figure 3-8: MPLS network upgraded to support MoE topology link

The following figure shows the evolution from separate MPLS network management to global MPLS layer
management.
Figure 3-9: Separate MPLS network management to global MPLS layer management
The following figure shows:

 MPLS network tunnels internal to local MPLS networks (solid lines).
 MPLS layer topology tunnels traversing the entire MPLS Layer (dashed lines).
Figure 3-10: Tunnel in MPLS network to tunnel in MPLS Layer
For more information, see earlier versions of the LightSoft User Guide.
Parent Topic
3.6 MPLS PE and PB Identification
3.7 Supported ETH/MPLS Port Types

ETH/MPLS ports are represented by two LightSoft layer characteristics:
 Physical layer, configured at the EMS level, including:
 EoS ports (Ethernet over SDH trails).
 ETY ports (Ethernet at the physical layer).
 MoT ports (MPLS ports over SDH trails), identified as being MPLS I-NNI interfaces.
 MoE ports (MPLS ports over Ethernet). Interface type not relevant.
MoE ports apply to P2P, P2MP, or MP2MP services. Also supports MoE LAG functionality.
(Rooted MP on MoE virtual link is restricted for services.)
 MoG ports (MPLS over Generic Routing Encapsulation). This port is used to transport data
over an IP network.
 PSI ports (Packet Switch Interface). Physical ports connecting two MPLS cards over the NE
fabric. The PSI port is displayed in the tree view of the LightSoft interface at the same level as
the other MPLS port types. Users can right-click the PSI port icon in the tree to open Current
Alarms or PM windows for that port.

Physical PSI ports on an NE card represent the aggregate capacity of all the logical MoF ports
configured on that NE card. For example, an MCS50_10P card includes a single physical PSI
destination port with a capacity of up to 10G. This PSI port represents the logical MoF ports
grouped on that card. LightSoft automatically connects each PSI port in an NE through logical
MoF port links to every other PSI port in that NE, with the exception of a second PSI port located
on the same card. This enables automatic creation of a full mesh of connectivity within that NE.
Note that the cumulative capacity of all the logical MoF ports grouped under a PSI port cannot
exceed the physical capacity of that PSI port.
 Ethernet logical layer, including:
 ETY and EoS ports, identified by type as one of the following logical interfaces:
 UNI (User Network Interface) ports connect a user to the network. The frames on a
UNI port are either untagged or C-VLAN tagged, and are associated with a service on the
basis of C-VLAN with multiple C-VLANs defining a single service. CoS is assigned. Policing is
performed by service.
 E-NNI (External Network-to-Network Interface) ports connect ports of different

networks. The frames on an E-NNI port are S-VLAN tagged; each S-VLAN denotes a service.
CoS Mapping is supported. Policing is performed per service.
 I-NNI (Internal Network-to-Network Interface) ports connect ports of the same

network. The frames on an I-NNI port are S-VLAN tagged. The S-VLAN ID determines the
Ethernet service. Policing is not performed.
 Intercard MoE ports . Backplane connectivity via vertically adjacent slots. Intercard MoE
ports function like physical MoE ports.
 MoF (MPLS over Fabric) ports . Connectivity between MPLS cards via the internal NE fabric.
Since all cards in the NE can communicate directly, NE resources can be grouped together into a
single high-capacity matrix flow domain.
MoF ports and links are similar to IC-MoE ports, in that IC-MoE ports are used to connect two
adjacent MCS cards via the backplane and MoF ports are used to connect multiple hybrid cards
within the same NE via the internal fabric.
LightSoft manages MoF links and ports automatically, enabling simplified provisioning and
management of complex full mesh topologies. MoF ports are functionally equivalent to IC-MoE
ports, nested within a shelf group. See Working with Groups.
In the LightSoft tree, a port is sometimes referred to by its joint type:
 ETY called ETY UNI port
 ETY called ETY E-NNI or ETY I-NNI port
 EoS called EoS UNI port
 EoS called EoS E-NNI or EoS I-NNI port

For information about the logical interfaces used for service creation, see Understanding Ethernet Service
Endpoints and their Interfaces.

MPLS Network Port Types

LightSoft-supported MPLS ports are MoT, MoE, MoG, and MoF ports. 1Net-capable PEs and their ports are
listed directly under the MPLS layer root in the inventory tree.
In the case of old-capability PEs, an "old-style" MPLS network is automatically created when MoT ports are
connected. (The network does not need to be declared as an MPLS network.) These networks are
automatically phased out when all its associated PEs and EMSs are upgraded.
Ethernet Network Port Types

A PB network uses EoS trails or ETY links with endpoints in a PB LE (such as EIS card).
L1 SDH ports (such as DIO card) can be connected to the PB network, but are not considered part of the
network (in a PB network only L2 ports are allowed). The Admin group in the MPLS layer permits collecting
these ports into one group.
An L2 card (such as EIS and MCS) comprises SDH ports, a bridge, and Ethernet (ETY physical) ports.
EoS trails, ETY links, and Ethernet services are created independently.
L1 Ports
The ports on L1 cards (such as DIO) connect an SDH trail termination with Ethernet interfaces. The EoS trail
is created directly to the port, entering as SDH and leaving as Ethernet. When an EoS trail is created from
an SDH network, the L1 service already exists, encapsulated in the same port.
EoS ports enable the use of SDH cards in PB networks. The root and leaf remote endpoints can also be
connected for GbE or FE.
Parent Topic
3.8 Connectivity Guidelines

The following sections describe conditions and use cases for PB and MPLS PE connectivity. Note the
following general restrictions:
 PB networks cannot connect using I-NNI ports.
 Dual Homing requires two links between MPLS and PB networks (or UMEs).
 LAG inconsistencies are not allowed.
Parent Topic

3.8.1 MPLS Layer Connections

MPLS tunnel paths traverse MoT trails, MoG, and MoE topology links. MoE links can traverse multiple
individual MPLS networks and be routed to/from any PE in the MPLS layer. MoT trails typically connect
MPLS PEs within the separate MPLS networks. An MoE link is either an Ethernet single link at 1 or 10 GB
rates, or a LAG of n x 1 GB links or n x 10 GB links.
Parent Topic
3.8.1.1 MoE and ETY Topology Links

Service implementation solutions can either be SDH or Ethernet-based. MoT and MoT trails require an SDH
platform. ETY and MoE link equivalents operate similarly, but are not SDH-based.
 MoE links vs. MoT trails: MoE physical links connect Ethernet (MoE) ports. Services are created over
MPLS tunnels, which traverse either MoE physical links directly, or MoT trails over SDH links. MoE
physical links behave like MoT virtual links.
 ETY links vs. EoS trails: ETY physical links between ETY ports connect services directly to the physical
layer, with no SDH cards in between. ETY links function the same way as EoS trails under the same
rules. EoS is still in use, and has its own advantages, for example, SDH protection.
MoE links are created between MPLS PEs. ETY links can be created between MPLS PEs or PBs. The
applicable ports must be configured as MoE or ETY at the EMS, and uploaded to LightSoft. In this process,
validations are performed on the port for example, MAC Address mismatch; see MAC Address Problems in
Link or Port. The standard ETY port type is used, assigned as MoE with rates GbE/GbE-C or 10 GbE/10
GbE-C. (Colored ports supported for GbE Ethernet port for optical ODU layer can also be used for Ethernet
connections.)
MoE Links
MoE links connect PEs in an MPLS network over a packet interface. They carry MPLS packets over Ethernet
transport in MPLS-based metro networks.
The MoE link can be a server for E-LSP tunnels and serve a variety of service types, including P2P and P2MP.
(Some capabilities depend on specific equipment support.)
MoE links enable, for example, interoperable VPWS/VPLS services between and within H-VPLS domains.
See Ethernet Service Types.
Figure 3-11: MoE connection – general description

The MoE link appears in the ETH/MPLS layer as a direct physical connection, represented as a standard ETY
port rate of: GbE, 10GbE, GbE-C, or 10GbE-C. An MoE icon in the inventory tree shows MoE usage on
an ETY port.
Intercard MoE is a type of MoE link used to connect ports on two different data cards. It is currently
available for ports on two different MCS cards located within the same platform. The connection is typically
used for Ethernet overlay networks to close 10 GbE rings. The following figure illustrates an Ethernet
overlay service using intercard MoE ports on MCS30-X10G cards.
Figure 3-12: Ethernet overlay using intercard MoE on MCS30-X10G cards
If the MoE creation procedure fails, all actions are rolled back except the Source and NH MAC address
provisioning. (These are updated in the next link creation.)
MoG Links
MoG (MPLS over GRE - Generic Routing Encapsulation) ports and links enable a L3VPN service to be
sent over an IP/MPLS network. An MoG link can be created in LightSoft between two MoG ports. The IP
mask must be the same for both ports. IP attributes are defined at the EMS level, however LightSoft
overrides the EMS values, calculating the destination IP addresses from the ports selected.
MoG creates a MPLS link that runs over L3 VPN service in the IP/MPLS network, in contrast to MoE which is
an MPLS link that runs over Ethernet (which is Layer 2). MoE exchange MAC address and MoG exchanges IP
addresses. In general, the MoG port supports all features of the MoE port, and it also includes GRE
encapsulation.
MoG links can be connected between MoG ports only.
NOTE: MoG operations are generally the same as those of MoE, except in places where MoE’s
special features are described.
MoF Links
MoF (MPLS over Fabric) ports and links provide connectivity between MPLS cards via the internal NE
fabric. Since all cards in the NE can communicate directly, NE resources can be grouped together into a
single high-capacity matrix flow domain. LightSoft manages MoF links automatically. This enables, for
example, simplified provisioning and management of complex mesh topologies. Users access MoF links
through Shelf Groups; see Working with Groups.

ETY Links
An ETY link is characterized by two ETY endpoint ports (Ethernet port type Layer 1 ETY or Layer 2 ETY), with
interface type I-NNI, E-NNI, or UNI.
ETY links function like EoS trails for global MPLS layer topology purposes. The following rules apply to ETY
link creation (not applicable to MoE links):
 Same LAG value at the endpoints (i.e., port type and Master/Slave/None settings). If not, the link is
inconsistent.
 Same interface type value. Different ETY ports with interface type values E-NNI and I-NNI are allowed,
but a warning is issued.
 Same RSTP value at the endpoints (Enabled/Disabled). Different RSTP value is allowed, but a warning is
issued.
For an ETY link between a PE and PB, RSTP can be Disabled for the PE and Enabled for the PB.
NOTE: Even if a warning is indicated, you can continue the operation if applicable.
Parent Topic
3.8.1.2 Connecting MPLS PEs in the MPLS Layer

Connect MPLS PEs in the MPLS layer with MoT trails or MoE links to enable top-down service provisioning
over tunnels using LightSoft.
Figure 3-13: MoE and MoT connections within an MPLS network
You can also connect MPLS PEs with EoS trails or ETY links, but in this case service provisioning is bottom-up
using the EMS.

MPLS PEs can be connected via I-NNI/E-NNI/UNI ports, but the resulting links or trails cannot be used for
provisioning services. A warning is displayed when attempting to create a link/trail. Connection in these
circumstances emulates actual connectivity and traffic flow in the field. Although provisioning services over
these ports is not supported in LightSoft, the ports appear occupied to indicate that traffic may be
traversing them. This provides a minimal match between the field state and LightSoft management state.
Parent Topic
3.8.1.3 Connecting PBs in a PB Network

Connect nodes within a PB network with EoS trails and/or ETY links using I-NNI ports.
Figure 3-14: EoS trails connecting nodes within a PB network
Using E-NNI or UNI ports is allowed, but the resulting link or trail cannot be used for provisioning services
via LightSoft. Services can be provisioned bottom-up via the EMS.
All endpoints must be I-NNI with the same network ID (cannot be in different PB networks); otherwise
service creation is disallowed. (A PB network is defined by a network ID established in the EMS.)
The PB network may also become inconsistent due to network changes after a trail is created. In this case,
the virtual link remains valid and a service can be created.
Parent Topic

3.8.1.4 Connecting Two PB Networks

You can connect two PB networks directly with EoS trails or ETY links using E-NNI or UNI ports. In this case,
RSTP must be disabled in the participating ports and services must be provisioned bottom-up using the
EMS.
Figure 3-15: Connecting PBs in different networks
Alternatively, you can connect the PB networks through an MPLS network, using EoS trails or ETY links with
I-NNI ports. This enables top-down service provisioning using LightSoft.
Figure 3-16: Connecting PB network regions
Parent Topic
3.8.2 PB and MPLS PE Connections

Parent Topic
3.8.2.1 PB and MPLS PE Connectivity Rules

In the global MPLS layer topology, information regarding connections between upgraded PEs (not
associated to previous MPLS networks) is shifted from the network level to the service provisioning stage.
For example, inconsistency is no longer reflected in a network becoming ‘white’ - a message regarding the
problem is received in the course of creating or editing a service.
NOTE: Specific connectivity rules can optionally be disabled. Contact your local Customer
Support representative for details.
The use cases that follow describe trail connections that are either disallowed or yield problematic network
topologies. In the latter case, a warning is generated during service creation.

NOTE: In order to support unanticipated topologies, several validation rules may be disabled
with the assistance of your local Customer Support representative. A rule suspension applies
to the entire LightSoft system and not just a specific network. If the rules are suspended,
networks do not become inconsistent.
Parent Topic
3.8.2.2 Connecting PB and MPLS Networks

To enable top-down service provisioning using LightSoft, connect an MPLS PE and a PB network with EoS
trails or ETY links using I-NNI ports.
Figure 3-17: Single connection between PB network and PE (MPLS layer)
NOTE: If E-NNI or UNI ports are used, the PB network remains consistent and the link remains
valid, but the link cannot be used for top-down service creation.
Parent Topic

3.8.2.3 Connecting MPLS PE to PB with Multiple Links

When a single MPLS PE node and PB node are connected through multiple EoS trails or ETY links, either LAG
or RSTP (but not both) must be enabled to prevent loops. Both ends of the connection must be configured
with the same protocol.
If LAG is defined, only the LAG Master connection is considered (it can be unprotected or protected as are
all other single connections).
Figure 3-18: EoS trails grouped in a LAG
Connection rules for EoS trails also apply to ETY links; see LAG Support.
Parent Topic
3.8.3 PB and MPLS-PE Gateway Connections

Parent Topic
3.8.3.1 Validating PB and MPLS-PE Gateway Protection

Inconsistencies or conflicts in gateway protection states may lead to a risk of traffic loops or cuts. For
example, Ethernet services flood packets to the destination links. Therefore, Ethernet protection
mechanisms try to prevent loops – the risk that the endpoint receives the same packets from two different
gateways. Conflicts in the participating protection mechanisms may undermine their ability to provide
effective protection.
To avoid potential traffic loops or traffic cuts, the following gateway protection rules apply:
 For Automatic S-VLAN registration: All participating gateway connections must be protected.
Otherwise, you are warned that some gateways are not protected and there is a risk of traffic loops.
 For Manual S-VLAN registration: The selected gateway connections must be either ALL protected or
ALL unprotected. You cannot work with a mixture of protected and unprotected gateways.
Otherwise, you are warned that only some gateways are protected and that you are at risk of traffic
cuts.

LightSoft does not block unauthorized gateway selections. You are presented with a warning window and
asked to confirm the choice of gateways. The warning does not necessarily imply an error. If you are
satisfied with the selection, you can continue at your own risk. With each warning, the following options
are provided:
 Continue: Proceed with the current selection and complete/activate the service, in spite of the
potential for traffic loop or traffic cut.
 Cancel: Return to previous state (do not delete the current selection).
Parent Topic
3.8.3.2 Connecting an MPLS PE to Two PBs

When a single MPLS1 PE node is connected to two PB nodes through two EoS trails or ETY links, the ports
must either be configured with RSTP or configured with ERP and have RSTP disabled. You cannot work with
both ERP and RSTP enabled for the same set of links.
Figure 3-19: RSTP or ERP required for MPLS PE link to two PB nodes
Parent Topic
3.8.3.3 Connecting an MPLS PE to Many PBs

When a single MPLS PE node is connected to multiple (up to 40) PB nodes through multiple EoS trails or ETY
links, RSTP must be enabled.
Figure 3-20: RSTP required for MPLS PE link to multiple PB nodes
Parent Topic

3.8.3.4 Connecting Two MPLS PEs to the Same PB Network

When two MPLS PE nodes are connected to the same PB network, the connection must be via two different
PB nodes. One of the following protection mechanisms must be enabled between the participating nodes:
BPDU tunneling dual homing, ERP, or RSTP service. When working with one of these protection
mechanisms, only one of these two connections is operative at any time. The other connection is used as
backup.
Figure 3-21: Dual homing, ERP, or RSTP required for two MPLS PEs linked to two PB nodes
Parent Topic
3.8.3.5 Connecting Many MPLS PEs to the Same PB Network

When multiple (up to 32) MPLS PE nodes are connected to the same PB network, RSTP multiple homing
service must be enabled between the participating nodes.
Figure 3-22: RSTP multiple homing required for multiple connections between MPLS PEs and PB network
Parent Topic

3.8.3.6 Connecting an MPLS PE Gateway to Many PB Networks

A single MPLS PE gateway node can be connected to multiple PB networks. The network configuration must
work within the following guidelines:
 No P2P service can be defined between the two participating PB networks.
 The MPLS gateway node cannot be configured as the root of a rooted MP service.
All S-VLAN IDs configured for any of the PB networks participating in this topology must be unique within
the group of PB networks. This is not checked by LightSoft during internal verifications. You must manage
the pool of available S-VLAN IDs and verify that each value is unique.
Figure 3-23: Connecting MPLS to multiple PB network regions
Parent Topic
3.8.4 External Connections - Connecting an MPLS PE or PB

to a UME or L1
An MPLS PE or PB can connect to a UME or L1 without restriction, using E-NNI or I-NNI ports. RSTP can be
enabled or disabled.
Figure 3-24: Connection between PB LE and UME
L1 Ethernet services are typically configured over two L1 ports connected with an EoS trails. Root and leaf
applications are typically configured over L1 ports connected to PB or MPLS ports connected with an EoS
trail. The root and leaf service endpoint is in the L1 port, and policing is done in the PB/MPLS EoS port.
Parent Topic

3.8.5 Invalid PB Network Topology Indications

An invalid PB network topology is reflected in the Network Validation Status parameter, showing various
fail reasons and corresponding fail sources; see PB Network Properties - General Tab.
Parent Topic
3.9 Changing an MPLS PE to a PB

The Change PE to PB operation, performed in the EMS, changes the MatrixFD switching mode attribute in
the EMS from MPLS back to PB on equipment with this attribute (such as the MCS card). This is useful if a
PB is accidentally changed to PE and system topology requires it to be changed back. (In general,
maintaining enhanced MPLS capabilities is desirable even if MoT ports are not available. This operation has
the effect of removing MPLS options, leaving only simple Layer 2 capability.)
In some equipment, the procedure is not required as the switching mode is changed automatically from PE
to PB once all the MPLS ports (MoE or MoT) have been unassigned. Similarly, once the first MPLS port is
assigned, the equipment acquires PE capabilities (applicable for equipment such as CESR 9300 series).
LightSoft supports the EMS operation to change equipment back to PB capability only when no trails
remain on this LE (no MoT or MoE ports are configured).
The operation, performed at the EMS, then changes the PE to PB and inserts it into the relevant PB network
(according to PB network ID). If this PB network does not exist, a new PB network is created.
NOTE: If it is not practical to remove existing trails, an alternative procedure is available. For
more information, contact your local Customer Support representative.
Parent Topic

3.10 PB Network Properties

The Properties for Network window is used to view and configure PB network settings.
Note that:
 Authorized users can configure LightSoft system settings for network-wide features such as general TE,
CoS, CAC, and EXP mapping preferences. System preferences can only be set by a system administrator
and are applied to all server clients. See MPLS TE Configuration Preferences in the Getting Started &
Administration Guide.
 MPLS and EA-HVPLS network types apply only when not all network objects have been upgraded to
global MPLS layer technology. PEs that do not yet support global MPLS layer capabilities continue to be
grouped within their pre-upgrade MPLS networks. Whenever such a PE is connected to a PB network
object, the resulting EA-HVPLS network also remains. These MPLS and EA-HVPLS networks coexist in
the MPLS layer until the last PE has been upgraded. They are listed in the root of the inventory tree.
Network properties of MPLS equipment not yet upgraded to global MPLS layer capabilities are edited
through the MPLS Network Properties window. For more information, see previous versions of the
LightSoft User Guide.
To view and edit PB network properties:

1. In the LightSoft main window Topology Layer dropdown list, select the ETH/MPLS view.
2. Right-click the network group icon representing the desired network, and select Properties. The
Properties for Network window opens.
3. Choose the appropriate tab, and edit the parameters, as required (editable parameters have white
backgrounds).
When a parameter is edited, an asterisk appears in the tab selector. The asterisk disappears when
Apply is clicked to save the changes.
To view alarms associated with the network, click .
4. Click Apply to save the changes in all tabs.
Parent Topic

3.10.1 General Tab

The General tab shows default general parameters of a PB network.
Figure 3-25: Properties for PB network - General tab
Table 3-1: Properties for Network PB - General dialog box fields
Field Description
Network Name User-assigned label for use in addition to the network ID. By default, the
network name is the network ID. (Editable)
Network Status Usability state of the network (for example, OK) or alarm state (e.g.,
Major, Minor) reflecting the most severely alarmed network
component; see Object Status Color Indications.
Network Type PB.
Network ID Each PB and MPLS NE is assigned a network ID in the EMS/LCT. LightSoft
does not modify it. Networks may span EMS domains with the same
network ID used by multiple EMSs.
Parent Network Name Global network to which the current network belongs (if any).
Connected MPLS Networks Legacy MPLS networks (if any) connected to the PB network.
Validation Status Valid (connected) or Fail Reason: Disjointed, Invalid interconnection, or
Dual Homing violation.
Fail Source: For a non-valid network, ID of the object associated with the
failure.

Field Description
Network Name User-assigned label for use in addition to the network ID. By default, the
network name is the network ID. (Editable)
Number of Elements Number of elements in this specific network.
Contained Elements List of LEs and groups (same as for user-defined groups).
Comments Free text.
Parent Topic
3.10.2 CoS Tab

The CoS tab shows default CoS parameters of a PB network. Values are set to specific CoS values (from
CoS0 to CoS7) according to the card type, as indicated by the EMS.
Figure 3-26: Properties for PB network - CoS tab
Parent Topic

4 Topology Links and Ports
Topology links (called topology or internal links) represent the available transport capacity between
network nodes over which trails carrying traffic are defined. A topology link joins two ports of different
objects (MEs, LEs, and UMEs). An internal link joins two ports within the same object.
4.1 Topology Link Concepts

The following sections provide some key topology link concepts, focusing on SDH and Ethernet/MPLS links.
Note that optical links are described in Provisioning Optical Trails. Other concepts are explained in context.
Parent Topic
4.1.1 Links and Multilinks

In all LightSoft map views, lines between MEs, LEs, UMEs and/or groups denote the presence of one or
more topology links. In this guide, these lines are referred to as links and multilinks.
Figure 4-1: Links and multilinks
SDH multilink line widths vary according to the number of links and link rates they represent. The actual
number of links in a multilink (when higher than one) is indicated by a number inside a square
.
Selected multilinks appear highlighted. When MEs are moved on a map, the multilinks follow them to their
new location.
The multilinks can be expanded to show the actual links between or within the elements. You can access
information and functions for each link within the multilink; see Viewing Topology Link Information.
The color of a multilink denotes its alarm state, indicating the most severely alarmed port of all associated
links. When a multilink is expanded, a specific link's color refers to the most severely alarmed port at either
end of that link. For a description of the alarm state colors and their meaning, see Object Status Color
Indications.

LightSoft® User Guide Topology Links and Ports
An internal multilink symbol adjacent an object icon indicates the presence of internal links within
the object.
Radio links are represented in the map windows by dashed lines ; see Radio
Links.
ASON links are identified in map windows with an icon on the line ; see
LightSoft ASON Support.
Parent Topic
4.1.2 Link Direction

Topology links can be unidirectional (transporting traffic in one direction) or bidirectional (transporting
traffic in two directions). Typically, SDH and radio links are bidirectional and optical links are unidirectional,
although there are exceptions. Directionality is determined as follows:
 If both selected endpoints are bidirectional, the link is bidirectional.
 If both selected endpoints are unidirectional (one transmit and one receive), the link is unidirectional.
 If one endpoint is unidirectional and the other bidirectional, the link is unidirectional.
Parent Topic
4.1.3 Link Types

LightSoft, as a multi-technology layer manager, automatically recognizes the relationships between
technology layers representing multi-technology ports on every layer on which they appear. It is useful that
the current layer view shows the links between ports from underlying layers on which trails are
provisioned. For this reason, LightSoft supports the following types of links:
 Physical links: Physical views show all LightSoft- or EMS-defined elements and their related physical
links, which were created in LightSoft (described in this section) or discovered automatically from an
EMS. Technology views show the objects and physical links pertaining to the displayed view.
 Backplane intercard links: Backplane links physical links connecting ports on two different data cards
through the backplane. The intercard MoE connection is typically used for Ethernet overlay networks
to close 10 GbE rings. Intercard MoE links are created automatically by LightSoft when the two partner
ports are identified. MoF links provide connectivity between hybrid cards via the internal NE fabric.
These ports are represented by the standard MoE icons in the topology map views.
 Virtual links: Virtual links are a special type of topology link that is logical, not a physical connection on
the native layer. Technology views show objects and links in their own technology layer, as well as
objects and logical connections provisioned in underlying technological layers. These logical
connections are represented as "virtual links" in the current technology layer. LightSoft automatically
creates virtual links in one technology layer as a result of trail creation actions in the underlying
technology layer.

For example, MoT trails (that are SDH, providing connectivity between two MPLS ports) are the virtual
links in the ETH/MPLS layer used for tunnel creation. Similarly, LightPath (LP) trails between SDH ports
may be displayed in the SDH layer as virtual links if all criteria are met. For more information about
virtual links in the context of trails, see Trails and Virtual Links.
For information about trails and trail creation, see the sections starting from Managing Traffic.
You can work with virtual links in the technology layers in the same way as you work with physical
links.
Parent Topic
4.1.4 Shared Risk Link Groups (SRLGs)

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. If an event involving the common entity
occurs, all the links of an SRLG could be disrupted.
The presence of SRLGs and other types of resource sharing have implications for LightSoft PathFinder trail
and tunnel route selection processes. For details, see SRLG and Other Shared Resource Minimization in
Path Selection , and SRLG Avoidance in Bypass Path Selection.
When SRLGs are used to define ducts, LightSoft generates a duct failure alarm if all links associated with the
same duct fail. The Alarm Correlation feature must be installed and enabled; see Alarm Correlation.
How SRLGs are Specified in LightSoft

The shared resources used by a link can manually be coded into the SRLG parameter in the Create
Topology Link dialog box or subsequently added/removed using the SRLG parameter; see Link Properties.
When the same SRLG code is identified in multiple links, these links are considered to share the associated
resource.
SRLGs are also coded automatically to a link for use by MPLS tunnels whenever an MoT trail is created that
traverses the link.
This is represented by an "automatic SRLG" in the link properties SRLG parameter. The SRLG ID is unique
over the MPLS layer. This type of SRLG is automatically removed from the link if the MoT trail is
subsequently deleted. Automatic SRLGs on a link cannot be manually added or removed.
For virtual links, the SRLG parameter is read-only and displays the accumulated SRLGs of the underlying
technology links.
Parent Topic

4.1.5 MoE and ETY Topology Links

Service implementation solutions can either be SDH or Ethernet-based. MoT and MoT trails require an SDH
platform. ETY and MoE link equivalents operate similarly, but are not SDH-based.
 MoE links vs. MoT trails: MoE physical links connect Ethernet (MoE) ports. Services are created over
MPLS tunnels, which traverse either MoE physical links directly, or MoT trails over SDH links. MoE
physical links behave like MoT virtual links.
 ETY links vs. EoS trails: ETY physical links between ETY ports connect services directly to the physical
layer, with no SDH cards in between. ETY links function the same way as EoS trails under the same
rules. EoS is still in use, and has its own advantages, for example, SDH protection.
MoE links are created between MPLS PEs. ETY links can be created between MPLS PEs or PBs. The
applicable ports must be configured as MoE or ETY at the EMS, and uploaded to LightSoft. In this process,
validations are performed on the port for example, MAC Address mismatch; see MAC Address Problems in
Link or Port. The standard ETY port type is used, assigned as MoE with rates GbE/GbE-C or 10 GbE/10
GbE-C. (Colored ports supported for GbE Ethernet port for optical ODU layer can also be used for Ethernet
connections.)
MoE Links
MoE links connect PEs in an MPLS network over a packet interface. They carry MPLS packets over Ethernet
transport in MPLS-based metro networks.
The MoE link can be a server for E-LSP tunnels and serve a variety of service types, including P2P and P2MP.
(Some capabilities depend on specific equipment support.)
MoE links enable, for example, interoperable VPWS/VPLS services between and within H-VPLS domains.
See Ethernet Service Types.
Figure 4-2: MoE connection – general description
The MoE link appears in the ETH/MPLS layer as a direct physical connection, represented as a standard ETY
port rate of: GbE, 10GbE, GbE-C, or 10GbE-C. An MoE icon in the inventory tree shows MoE usage on
an ETY port.

Intercard MoE is a type of MoE link used to connect ports on two different data cards. It is currently
available for ports on two different MCS cards located within the same platform. The connection is typically
used for Ethernet overlay networks to close 10 GbE rings. The following figure illustrates an Ethernet
overlay service using intercard MoE ports on MCS30-X10G cards.
Figure 4-3: Ethernet overlay using intercard MoE on MCS30-X10G cards
If the MoE creation procedure fails, all actions are rolled back except the Source and NH MAC address
provisioning. (These are updated in the next link creation.)
MoG Links
MoG (MPLS over GRE - Generic Routing Encapsulation) ports and links enable a L3VPN service to be
sent over an IP/MPLS network. An MoG link can be created in LightSoft between two MoG ports. The IP
mask must be the same for both ports. IP attributes are defined at the EMS level, however LightSoft
overrides the EMS values, calculating the destination IP addresses from the ports selected.
MoG creates a MPLS link that runs over L3 VPN service in the IP/MPLS network, in contrast to MoE which is
an MPLS link that runs over Ethernet (which is Layer 2). MoE exchange MAC address and MoG exchanges IP
addresses. In general, the MoG port supports all features of the MoE port, and it also includes GRE
encapsulation.
MoG links can be connected between MoG ports only.
NOTE: MoG operations are generally the same as those of MoE, except in places where MoE’s
special features are described.
MoF Links
MoF (MPLS over Fabric) ports and links provide connectivity between MPLS cards via the internal NE
fabric. Since all cards in the NE can communicate directly, NE resources can be grouped together into a
single high-capacity matrix flow domain. LightSoft manages MoF links automatically. This enables, for
example, simplified provisioning and management of complex mesh topologies. Users access MoF links
through Shelf Groups; see Working with Groups.

ETY Links
An ETY link is characterized by two ETY endpoint ports (Ethernet port type Layer 1 ETY or Layer 2 ETY), with
interface type I-NNI, E-NNI, or UNI.
ETY links function like EoS trails for global MPLS layer topology purposes. The following rules apply to ETY
link creation (not applicable to MoE links):
 Same LAG value at the endpoints (i.e., port type and Master/Slave/None settings). If not, the link is
inconsistent.
 Same interface type value. Different ETY ports with interface type values E-NNI and I-NNI are allowed,
but a warning is issued.
 Same RSTP value at the endpoints (Enabled/Disabled). Different RSTP value is allowed, but a warning is
issued.
For an ETY link between a PE and PB, RSTP can be Disabled for the PE and Enabled for the PB.
NOTE: Even if a warning is indicated, you can continue the operation if applicable.
Parent Topic
4.1.6 Radio Links

The radio ports and links are configured in the EMS-BGF and then uploaded to LightSoft. See the EMS-BGF
User Manual.
LightSoft supports radio links in two types of platforms:
 NE dedicated for microwave technology:
 BGW-10
 BGW30E
 BGW64
 BGW9310
 Expansion platform used with an existing NE, for example, BG20 becomes BGW20.
In the map view, you can set the topology to display only the radio links.
To view only radio links:

1. Select either the Physical (Site), SDH, or ETH/MPLS topology layer.
2. In main window View tab, in the Show/Hide group, click Show Only Radio Links.
Parent Topic

4.1.7 Radio Ports

Radio microwave (MW) technology is a media-less technology that relies on electromagnetic waves. These
radio waves are strictly regulated by governmental bodies. Implementations use either licensed frequency
bands between 6 GHz and 40 GHz or unlicensed sub-6 GHz frequency bands. MW radio links require an
unobstructed line of sight, as illustrated in the following figure.
Figure 4-4: Microwave radio transmissions in line of sight
The radio technology supports several payload types over the same radio media. This means that both TDM
(SPDH) and Ethernet (FE/GbE) traffic can be transmitted over a single radio port.
The available payloads are:
 SPDH (up to 84 x E1)
 Ethernet (up to 2 x FE/2 x GbE)
 Hybrid of SPDH and ETH
Figure 4-5: GbE Ethernet radio service with native TDM capabilities
LightSoft displays the hybrid ports slightly differently than does the EMS. The EMS displays a hybrid radio
port with three objects (TDM, Ethernet over Radio (EoR) and outdoor unit (ODU)). LightSoft displays two
different ports.
 Radio port: Represents the radio transmission link and serves the TDM traffic (SPDH). This port
connects to another radio port with a TDM link (displayed as STM-4 rate).
 EoR port: One of the Layer 2 card (e.g., DMGE card) ports or one of the BGW-10 ports (has no Layer 2
card but has a switch). Since it has no physical layer, it is a logical port (similar to EoS and MoT ports),
but is displayed as an ETY port (pure Ethernet with no VCGs).
In LightSoft, a radio port links to an EoR port. LightSoft uses the EoR ports as Ethernet link endpoints (the
service's server). The EoR port carries the Ethernet traffic from the radio port (from the EMS), the Ethernet
alarms, and the Ethernet counters (for PM).
In the EMS-BGF, the EoR port is connected to a MIF radio port. For radio port configuration instructions, see
the EMS-BGF User Manual.
Parent Topic

4.1.8 Endpoint Selection for Links

Endpoints can be disabled (grayed) for various reasons. If you click a disabled port, the Status field shows
why the ports cannot be connected. The most frequent reasons are:
 Port type or rate is not compatible with a port already selected.
 A LAG port must be connected only to a matching LAG port. A Master port must be connected
to a Master port, and a Slave port must be connected to a Slave port.
 Port is not consistent, as indicated in the Consistency State field of the port properties window; see
the parameter description in Port Properties General Tab.
 Port is logical. Logical (nonphysical) data ports cannot be connected; see the description of logical
ports in Supported ETH/MPLS Port Types.
 Port direction (Src or Snk ) is not compatible with the direction of the port already selected
(paired ports must be selected in Src/Snk pairs).
In some cases, endpoints can be selected even though the result may be a problematic link:
 Dissimilar media types, such as electrical and optical ports. The action is allowed with a warning.
 Minimal match of supported tunnels. Endpoint ports selected for the link have at least one tunnel
mode capability in common, for example, they must both support L-LSP or both support E-LSP.
Otherwise the link cannot be created, See Minimal Match of Supported Tunnels.
Parent Topic
4.1.9 Fiber Connectivity

Fiber connectivity defines the characteristics of the connectivity between ports connected via physical
fibers. Fiber connectivity can be defined for links that connect to Apollo (OPT9624/OPT9608/OPT9603) NEs
only. Defining fiber connectivity provides the following benefits:
 Power equalization: Fiber connectivity is essential for OTS ports participating in power equalization to
pass power control parameters to one another (e.g., ports residing in passive optics cards, optics cards
and WDM ports on L1 service cards). With the exception of passive optics cards, these ports cannot
transmit traffic if fiber connectivity configuration is missing. For all other cards, fiber connectivity is
optional.
 Diagnostic information: Provided via Optics Network Control Parameters (ONCP).
 Trail application: Links and trails can be created in the NMS and their configuration sent to STMS, and
vice versa.
Fibers can be connected in one of the following ways:
 Intra-fiber connectivity (internal): Fibers are connected with an NE. For example connectivity
between cards residing in the same chassis, or between an Apollo card and an Artemis (passive)
optical card. Fiber connectivity parameters defined on one port are automatically copied to the peer
port.
 Inter-fiber connectivity (external): Fiber connectivity between two different NEs. Fiber connectivity
parameters must be defined on the NEs at both endpoints of the fiber.

The following figure illustrates the two types of fiber connectivity.

Figure 4-6: Fiber connectivity (two modes)
In LightSoft, fiber connectivity must be defined on the following ports to enable traffic to run:
 OTUk
 OTS
 OCHP
Fiber connectivity can be defined either bottom up (defined in STMS, and automatically uploaded to
LightSoft, or top-down (defined in LightSoft during topology link creation, and automatically downloaded to
STMS). When creating links in the STMS, fiber connectivity information is uploaded to LightSoft by default
(Report to LightSoft checkbox selected in STMS). LightSoft creates the relevant topology links and updates
the link parameters accordingly.
Incomplete links
When creating a link between an Apollo NE and an XDM/NPT or UME in LightSoft, the link is defined as
incomplete unspecified in STMS, because the other endpoint cannot be viewed in the STMS.
When creating a link in the STMS, incomplete links indicate the STMS cannot see the other side of the link.
If an incomplete link is created in STMS, the link is not uploaded to LightSoft. Incomplete links are classified
in STMS as follows:
 Incomplete unspecified: The other endpoint is unknown (e.g., a UME or XDM/NPT).
 Incomplete unmanaged: The other endpoint is defined, but unmanaged.
 Incomplete unconfigured: The other endpoint is not specified (applies to link creation in ShadeTree
only).
Define fiber connectivity as part of the create topology link process (see Creating Topology Links). For an
explanation of fiber connectivity parameters, see Create Topology Link Advanced Attributes.
Parent Topic

4.1.9.1 Prerequisites and Guidelines

The following prerequisites and guidelines should be adhered to when configuring fiber connectivity:
 LightSoft supports the definition of fiber connectivity for NEs managed by the same STMS, by a
combination of STMS and a UME, or STMS and XDM/NPT.
 Before configuring fiber connectivity, configure the relevant ports.
 For a bidirectional port, up to two unidirectional fibers can be defined per port. For a unidirectional
port, only a single fiber of the applicable direction can be applied.
 When configuring intra-fiber connectivity, it is not necessary to explicitly configure both peer ports.
Configure fiber connectivity parameters on one peer port and the NE automatically configures fiber
connectivity parameters on the other port.
 It is possible to define fiber connectivity without specifying a wavelength value. For intra-connectivity,
if the wavelength value is defined at one end, the NE automatically configures the wavelength value in
the corresponding peer port during configuration.
 If a link is created in STMS, and the link already exists in the NMS (i.e., the same endpoints are
connected directly with an existing link), LightSoft keeps the existing link, and updates the link
attributes as per the information received from STMS.
 If a link is created in STMS, and only one endpoint is occupied in the NMS, the link is created, and both
links are marked inconsistent.
 If link creation fails in the STMS, the corresponding link is not created in the NMS either.
When creating a new link in the STMS, the report to NMS checkbox must be selected to ensure the
topology link configuration is uploaded to the NMS.
Parent Topic
4.1.9 Fiber Connectivity
4.1.10 Minimal Match of Supported Tunnels

A port selected as a MoE link endpoint can support any combination of tunnel modes:
 E-LSP (E) and/or
 L-LSP (L) and/or
 Signaling (S)
Link creation is allowed when both the endpoint ports selected for the link have at least one tunnel mode
capability in common, for example:
 If the two endpoints support L and LE, respectively (they have L-LSP in common), link creation is
allowed.
 If the endpoints support only L and E, respectively (they have no tunnel mode in common), link
creation is not allowed.
This is because a tunnel cannot be created in the EMS between ports that do not share the same
tunnel mode.

The tunnel modes supported by a port are indicated by letter combinations in the port label:
 One tunnel mode by itself (E, or L, or S)
 Any two (LS, or LE, or ES) concurrently
 All three (LEs) concurrently
For a description of the tunnel modes, see Tunnel Mode.
Parent Topic
4.2 Topology Link Management

This section describes the multiple tasks you can perform on topology links.
When creating links, you can automatically provision the link with VC-4 server trails. For example, an
STM-16 link can be created with 16 VC-4 server trails.
In addition to creating topology links manually, topology links between NEs of the same EMS can be
created automatically by acquisition in the EMS during upload, or by notification when the EMS supports
links (upload and notification) in its MTNM interface. (Links between NEs of different EMSs must be created
manually in LightSoft.)
NOTES:
 ASON-protected trails require topology links with STM-16 or STM-64 rates between
ASON-enabled NEs. See LightSoft ASON Support.
 LightSoft automatically performs the link and trail infrastructure changes consistent with
port reassignments from STM-1 to STM-4; see Automatic Link Adaptation.
Parent Topic
4.2.1 Creating Topology Links

A link represents a fiber connection between two ports. Physical topology links can be created in any
topology layer (Physical, OTN, SDH, or Ethernet).
Topology link creation includes the following stages:
1. Selecting the link objects.
2. Defining the link ports and other parameters.
3. Defining advance parameters (optional).
NOTE: STMS can create links up to a maximum length of 500 km only.

Prerequisites
 Before linking NEs, verify that the required cards and ports have been assigned in the NEs at the EMS
level. Different typology link types require different cards. Note that the ports must be compatible.
Depending on the type of port, this might include selecting ports with compatible rates, or optical
channels, or coherency, or LAG configuration. See the relevant EMS User Guide.
 Before a LAG 1:1 link can be created, the link endpoints must already be configured at the EMS level to
support LAG 1:1. Endpoints for a LAG 1:1 link can be located on either two LAG 1:1 ports or one
LAG 1:1 port and one UME port.
 To create a topology link using a CESR9700/9600 NE, first complete the steps described in Creating an
MoE Link using CESR9700/9600 NEs and then continue with the steps in this procedure.
 When creating a topology link using an OMLT NE (e.g., OPT9608/OPT9624/OPT9603), configure the
fiber connectivity parameters. (See also Create Topology Link Advanced Attributes). When creating a
link between an OMLT NE and an XDM/NPT or UME in LightSoft, the link is not downloaded to the
STMS. The link should be created in the corresponding STMS via GTC.
 Radio links for BroadGate equipment can must first be created in the EMS-BGF and then uploaded to
LightSoft; see the EMS-BGF User Manual. For equipment supported under the generic EMS, radio links
are created through LightSoft using the standard Create Topology Link Dialog Box.
 If a link intended for ASON is created in LightSoft, it must be configured for ASON in the EMS before it
is used in LightSoft.

To create a topology link:

1. Select the object(s) that the links span. In the topology view, do one of the following:
 Link between two objects (MEs/LEs, UMEs, or groups): To make the selection, hold the
SHIFT key (if selecting in the map) or the CTRL key (if selecting in the tree).
 Internal link: Select a single ME/LE.
2. In the main window Topology tab, in the Create group, click Topology Link. The Create Topology Link
window opens. The two panes display hierarchical tree structures showing the objects, slots, and
ports. For an internal link, the two panes show details of the same object.
Figure 4-7: Create Topology Link dialog box
3. Define the link ports and parameters:

a. In the Select Type field, select a port type from the dropdown list. The ports that are not of the
selected type are disabled.
b. Select a port from each pane to be defined as the link endpoints, see Endpoint Selection for Links.
NOTE: To help you identify which ports have similar protection types, frequencies, and other
attributes, display/hide different port details using the View menu; see Create Topology Link
Dialog Box.
c. (Optional) In the Label field, change the default label (a concatenation of the port names).
d. To build the server trail automatically (only used in very specific cases), select the Build VC-4
Server Trail checkbox.
4. (Optional) To view and configure advance parameters, click More. The Link Attributes pane opens in
the lower part of the window. And additional tab is displayed for optical attributes, if applicable. If
you do not define these values, LightSoft automatically uses the default values, see Create Topology
Link Advanced Attributes.

5. Click Apply.
6. (Optional) If you are creating a LAG 1:1 protected link, the following popup message opens.
 To automatically configure a second (protective) LAG link, click Yes.

If the second link already exists, the link creation request fails.)
 To create only a single link, select No.
LAG 1:1 links can only be created between compatible ports that share the same parameter settings.
If both ports are LAG 1:1 ports, LightSoft configures a second link between their associated ports.
7. The link creation process begins, and the Progress bar is shown at the bottom of the dialog box. The
Status field shows ongoing changes on selected ports.
For each link created, a Create Link conclusion message appears, describing the new link's endpoints
and layer. The new link icon is displayed in all the relevant topology views.
Some circumstances cause a warning or failure, for example:
 Protection group incompatibility; see Protection Group Object (PGO).
 Forward Error incompatibility; see Forward Error Correction (FEC) in OCH Trail Endpoint
Validations.
 Frequency (Channel) incompatibility; see Channels.
8. To create another link with the same elements, repeat steps 2-5. You do not have to wait until link
creation is complete.
While link creation is in process, you can minimize the dialog box and perform other unrelated
actions.
Parent Topic

4.2.2 Deleting Topology Links

Before deleting a link, all trails must be removed from it. An MoE link must not have traffic or tunnels.
Links created in LightSoft or an EMS can be deleted from LightSoft. Links created in an EMS should be
inconsistent and show the inconsistency reason "Deleted from EMS". This usually happens if a link with a
trail in LightSoft is deleted from an EMS.
To delete a topology link:

1. In a topology view, select the multilink from which you want to delete a link.
2. Right-click and select Expand. The Actual Links between Two Elements dialog box opens.
NOTE: If the selected link has an ME/LE group on one side, right-clicking the group and select
Expand to display group components, then right-click and expand the multilink, to display the
links you want to delete.
3. Select the links you want to delete, right-click and select Delete.
Parent Topic
4.2.3 Viewing Topology Link Information

Multilinks can be expanded to show the actual topology and internal links between/within elements and
their port endpoints. The specific NEs at the link endpoints care displayed even if within nested groups
(regardless of depth of nesting). You can access information and functions for each link. Actions can be
performed on multiple selected links at a time; see Working with Multiple Links and LEs.
To view information about individual links in a multilink:

 In any topology or technology layer, in any map view, do one of the following:
 To view a topology link between two elements: Right-click a multilink between two objects, and
select Expand. The Actual Links between Two Elements window opens.
 To view an internal link within one element: Right-click an object icon showing an internal
multilink icon , and select Internal Links. The Internal Links View window opens.

The diagram at the top of the Actual Links between Two Elements window shows the endpoints of the
multilink, either an element or a group of elements. When an endpoint is a group, the name of the overall
parent group is shown in the diagram and an additional column is added to the list to identify the element
name of each specific link's endpoint.
Figure 4-8: Actual Links between Two Elements
The diagram at the top of the Internal Links View window shows a single element.
Figure 4-9: Internal Links View window
Table 4-1: Information supplied for each link or internal link in the multilink
Column Description
Element1 Only appears if endpoint at one end of the multilink is a group. Shows the element
name of the specific link's endpoint.
Port1 Name of specific link's endpoint.
Link Name Name of link, either default name (name of first and second endpoints in
alphabetical order), or user-assigned.
Element2 Only appears if endpoint at the other end of the multilink is a group. Shows the
element name of the specific link's endpoint.
Port2 Name of specific link's endpoint.
Rate Rate of link (may differ from port rate).
Media Port media type: Electrical, Optical, Virtual, or N/A.
Protection Type of link protection (for example, MS-SPRing). On physical topology links, the
protection scheme is from the link itself. On virtual links, it is derived from the
underlying trail.
You can access shortcut menus with useful tools for link management, by right-clicking a link name in the
Link List table or a link in the topology map view. Menu options depend on the context and type of link. For
example, ASON menu options are only displayed for ASON links. The following table lists most of the menu
options of these two shortcut menus.

Table 4-2: Topology link shortcut menu options

Properties Properties of the selected topology link; see Link Properties.
Current Alarms Opens the Current Alarms window for alarms affecting the link state
(endpoints in the case of a physical link); see Fault Management in the
Performance Monitoring Guide. When this option is selected from the
multilink shortcut menu, LightSoft displays alarms for all links associated
with the multilink.
Delete Deletes selected topology link. Only available for LightSoft-created links
and in accordance with validation rules (for example, there must be no
trails in the link to be deleted). See Topology Link Management.
Availability Opens availability information for the selected link; see Viewing Resource
Availability on Links.
Expand Opens the Actual Links between Two Elements window.
Collapse Collapses and closes the currently expanded group or object.
Link List Open the Link List window focusing on the selected links.
Show Trails Opens the filter options that open the Trail List window with the
appropriate subset of trail displayed:
 All Trails: All trails associated with the selected object (single link,
multilink, or element).
 High Order Trails: All high order (HO) trails associated with the
selected object.
 Low Order Trails: All low order (LO) trails associated with the selected
object.
 Optical Trails: Select the type of optical trails to display (OMS, OCH,
ODU, or LP).
Show Tunnels (ETH/MPLS view only) Opens the following options for the selected link in
the Tunnel List window:
 All Tunnels: All tunnels associated with the selected link.
 Protected Tunnels: All protected tunnels associated with the selected
link.
 Bypass Tunnels: All bypass tunnels protecting the selected link.
Show Services Shows all services that traverse the selected link in the Service List
window.
Trail Consistency Opens the Trail Consistency Indicator window for trails filtered for the
selected link. (A virtual link is filtered by the associated trail.) See
Synchronizing Trails.
Tunnel Consistency Opens the Tunnel Segment Consistency window for tunnels filtered for
the selected link. (A virtual link is filtered by the associated tunnel.) See
Synchronizing Tunnels.
ETH Service Consistency Opens the Ethernet Synchronizing Indicator (ESI) window for services,
filtered for the selected link. See Service Acquisition and ESI.


Show Ring In the map view, highlights all links sharing the same ring name as the
selected link, whether set manually, or system-defined (designating the
links as participating in a specific MS-SPRing scheme; see Managing
MS-SPRing Rings). If no ring name is defined in the selected link’s link
properties, a "No ring was found" message appears. See Ring Name in Link
Properties - General Tab.
Note: This function is case sensitive. Only exactly matching ring names are
considered as shared.
Show Trails of Ring Opens the Trails List window filtered with all trails associated with the
selected link that run on this and other links sharing the same ring name. If
no ring name is defined in the selected link’s link properties, a "No ring
was found" message appears. See Ring Name in Link Properties - General
Tab.
Show Ring Affecting Alarms Displays all alarms relevant for the selected ring.
Expand Ring in New View In a new view, shows all links sharing the same ring name as the current
link, whether present in the current view or not. (The current view may be
composed of selected objects opened in a new view with the Open in New
View function.) The elements that are endpoints to those links are also
shown, along with any other links extending from those elements (which
might not share the same ring name). See Ring Name in Link Properties -
General Tab.
Show SRLG In the map, highlights all links having same SRLGs as the selected link; see
Viewing SRLG and Other Diversity Information. See Shared Risk Link
Groups (SRLGs).
Show ASON Domain Marks all ASON-based entities (elements and links) in the current map
view; see Monitoring the ASON Domain (page 6-28).
Expand ASON Domain in New Same as Show ASON Domain, but opens the objects in a new window; see
View Monitoring the ASON Domain (page 6-28).
Show LDL Properties Shows properties of a selected Logical Data Link (LDL) trail; see LDL
Properties (page 4-79).
Show DLTs Shows the Data Link Trails (DLTs) associated with a selected LDL trail; see
Showing Related DLT Trails (page 4-78).
MS-SPRing Configuration Opens a GCT to the MS-SPRing configuration properties in the EMS for a
selected individual link (when supported by the EMS).


Link Operations Opens link operations options (options differ according to link context),
including:
 S-VLAN Registration: Adds S-VLAN registration to an ETY link,
enabling all services of the PB network to utilize that link. For more
details, see S-VLAN Registration from a Link or Trail.
 S-VLAN Deregistration: Removes the S-VLAN registration from the
selected ETY link. The associated services can no longer use that link.
 Configure TE Parameters: Opens window for user to configure TE
parameters such as CAC and EXP in/out for all selected links.
 ASON Link Metric Configuration: Downloads ASON metric values to
the link's endpoints.
 ASON Configuration: Opens ASON parameter configuration window.
Maintenance Operations Opens the Maintenance Operations window, which enables you to
perform maintenance operations on links (such as Loopback, AIS, and RDI)
to diagnose network problems, see Maintenance Operations in the
Performance Monitoring Guide.
Performance Monitoring Current PM: Enables you to view current trail performance for 15-minute
or 24-hour intervals.
Set Trail PMH Enabled: Enable PMH data collection for selected trail.
Set Trail PMH Disabled: Disable PMH data collection for selected trail.
See Monitoring Trail Performance in the Performance Monitoring Guide.
Availability Opens availability information for the selected link; see Viewing Resource
Parent Topic

4.2.4 Configuring Link TE Parameters

You can change link TE parameters for multiple links simultaneously. For information about the link
properties that can be modified, see Link Properties - CAC Tab , TE Other Tab , EXP Tab.
NOTE: For CESR 9700/9600 ports, the total bandwidth values (in the Total (%) column) are
defined in STMS only. When modifying CAC for CESR 9700/9600 ports, only the CAC ratio
between reserved BW and reserved shared BW can be modified in LightSoft. To change the
Total % values, change the CIR values in the appropriate Queue blocks in STMS.
To modify TE parameters for selected links:
1. In the Link List window, select the required links and click Configure TE Parameters . The
Configure TE Parameters window opens.
2. Modify the values as needed and click Apply. The changes are applied to all selected links.
Parent Topic

4.2.5 Configuring LE CoS Parameters

You can simultaneously change CoS parameters for multiple selected PEs.
To modify CoS parameters for selected PEs:
1. In the LE List window, select the required PEs, and click Configure CoS Parameters . The
Configure CoS Parameters window opens.
2. Modify the values as needed, and click Apply. The changes are applied to the selected PEs.
Parent Topic

4.2.6 Updating Link Metric Values

If the CSFP default metric is modified in the System Preferences window, the changes must be propagated
to the embedded links to take effect in the NMS.
To update the embedded links with the new metric value:

1. In LightSoft, select the Topology tab, and click Link List. The Link List window opens.
2. In the filter (top right of the window), select LDL & ASON Links. The list is filtered to display LDL and
ASON-related links only. The EP1ASON Metric and EP2 ASON Metric columns display current the
metric value for each link. If the metric value is not updated, the value Mismatch is displayed.
3. Select the checkbox in the row of each link you want to update, and click Reconfigure Link Metric
. The Result Dialog window shows the updated status.

4. To update the information displayed, click Refresh.
Parent Topic

4.2.7 Viewing SRLG and Other Diversity Information

You can view diversity in the network in a number of ways.
To view/add SRLG associations for an SDH/optical link/MoT virtual link:

 In the Link Properties window, click the Advanced tab. A list of SRLGs associated with the link is
displayed.
 To add or modify user-defined SRLGs, see the SRLG (Ducts) parameter in Link Properties -
Advanced Tab.
For MoT virtual links, manual SRLGs are added at the physical or SDH level and viewed in Link
Properties - SRLGs Tab.
To view links with identical user-assigned SRLGs:
NOTE: This action cannot be performed in the Ethernet layer.
 In the relevant layer (except Ethernet), right-click a link and select Show SRLG. The links that share the
same user-assigned SRLGs and their associated endpoint MEs are highlighted in the map.
To view resource-sharing information for a trail:

 In the Trail Properties pane, click the Protection tab. Resource-sharing information (including number
of shared MEs, links, SRLGs, and cards) is displayed for each trail, regardless how the trail was created
(see the Protection tab parameters in Trail Properties Pane).
Parent Topic
4.2.8 Optimizing Low Order Resources

LightSoft can reorder Low Order resources to free up VC-3 and VC-4 resources that would otherwise be
taken up by VC-12 and/or VC-3 resources (defragmentation). Optimization can be performed on:
 Physical and virtual SDH links only.
 Short (single segment/single link) high order server trails only.
 For MS-Spring protected trails, short segment LO trails only.
 Links on which one or more element is a UME. However, the XCs on the UMEs must be modified
manually after optimization is completed.
 LO MoT Trails that do not have bypass tunnels.

From the Optimize LO Resources window, you can view the current availability chart, and in the Expected
Availability area, LightSoft provides an estimate of how many resources of each type can be made available
through the optimization process.
Requirements and Limitations

 Before starting optimization, ensure that the MEs on both of the link endpoints are uploaded.
 LO resource optimization cannot be performed on long high order trails (trails that traverse more than
one link).
 LO Trails can only be optimized to a VC-4 trail that has the same protection type as the original VC-4 trail.
 LO trails traversing Long HO trails, are not supported by the optimization process.
 LO trails traversing HO Trails with current protection level are not supported by the optimization process.
 If you abort the operation once it has started, only trails on which optimization was attempted before
the operation was aborted are displayed in the summary window.
To perform low order resource optimization:

1. From the Physical or SDH Layer map, right-click a link and select Optimize LO Resources. Or, from the
Link List window, right-click a link and select Link Utilities > Optimize LO Resources. The Optimize LO
Resources window opens, displaying current resource availability, and the expected availability after
optimization for each rate type.
The number of trails for each rate type is displayed in the table below the Expected Availability chart.

2. To view details of the resources for each rate, click Show Resources Map. Select the relevant tab to
view differing granularity (VC-3, VC-2, or VC-12).
3. Optionally click Create short HO server trails to fill gaps in HO resources.

4. Click Apply. The optimization process begins, and each LO resource is reordered into the lowest free
resource, until no further reordering is possible. This process can take a significant amount of time
(e.g., > 2 hours for 1000 LO trails). When the process is complete, a window is displayed, showing a
summary of the trails that were successfully optimized, and any trails that failed.
Note that if no reordering is required during optimization, the results windows appear empty.

The summary window shows the Original Availability, the Expected Availability, and the Current
Availability. Current Availability shows the actual number of resources available after low order
resource optimization.
5. If the results show that the resources have not been fully optimized, run the process again
Parent Topic

4.2.9 Creating an MoE Link using CESR9700/9600 NEs

When using CESR9700/9600 NEs, perform the following steps in the STMS before creating a MoE topology
link:
1. In the STMS:
a. Create service profiles. )
b. Correlate system preferences.

c. Modify default QoS values.
2. In LightSoft, create the topology link (see Creating Topology Links).
Parent Topic
4.2.9.1 Creating a Service Profile in STMS

Before creating an MoE topology link, create eight service profiles in STMS, to ensure integration of the
creation of MoE links in the STMS with the NMS link creation.
NOTE: For information about service profiles, see the STMS User Manual.
To configure a service profile in STMS:

1. In LightSoft, right-click the CESR9700/9600 NE, and select Open. The STMS window opens.
2. Select the QoS Explorer tab.

3. In the STMS Network Explorer tree, under the Templates icon, right-click the Service Profiles folder
and select Create. The Create Service Profile window opens.
4. Enter the relevant information (editable fields have a white background).

5. Select the Apply template to NEs checkbox, and click Finish. The Apply Templates window opens.
6. Select all NEs, and click Finish.
Parent Topic

4.2.9.2 Correlating System Preferences

The EMS LightSoft CoS translates the CoS and color definitions from the NMS to the service profiles in the
EMS. The EMS and NMS preferences must match. Correlate the system preferences from STMS, either per
EMS or per NE.
To correlate system preferences between EMS and NMS:

1. In the STMS menu, click Edit and then Server Preferences.
2. In the STMS Network Explorer tree, select the relevant EMS or NE and then select the LightSoft COS
tab. The Service Profiles are displayed.
3. (When updating a single NE only) Clear the Use System Defaults checkbox.
4. Ensure that all the CoS and color definitions match those in the system preferences of the NMS.
Modify fields as required.
5. Click Apply. The changes are saved.
Parent Topic

4.2.9.3 Modifying Default QoS Values

When an MoE link is created, drop profiles and queue blocks are created automatically. The default values
are applied to the link. Default values can be modified, if required.
NOTE: When using eight queues, BE class must be configured in the LightSoft default
templates.
10 GbE ports must be configured as Trunk Mode in STMS. See the STMS User Manual for
details.
The following values are applied to the link by default.
Table 4-3: Default QoS values
Profile/Block Parameter Default Value Applies to

Drop Profile Green Min. Threshold (%) 40 All CoS
Max.Threshold (%) 90 All CoS
Drop Probability (%) 50 All CoS
Drop Profile Yellow Min. Threshold (%) 10 All CoS
Queue Blocks Scheduling Class ef+ CoS 7
Scheduling Class ef CoS 6
Scheduling Class af CoS 0-5
PIR Maximum port CoS 0-5
rate.
CIR 12.5% of port rate. All CoS
(e.g., 1 Gb = 125 Mbps;
10 Gb = 1250 Mbps)
NOTE: The CIR value directly affects the CAC values in the NMS.

To modify the default QoS values:

1. In the STMS QoS Explorer tab, right-click Templates and select Create LightSoft Default Templates.
Drop and queue profiles are created and appear under the relevant folders in the STMS Network
Explorer tree.
2. Select the relevant drop profile or queue block that you want to modify, and in the Properties tab,
change the field values as required.
NOTE: The LightSoftDfaultUniQueueBlock template is relevant for services only.
Parent Topic

4.2.10 ASON TE Link Information

The creation of an ASON topology link (data link) between two NEs during link discovery triggers the
creation of a TE Link and Control Channel. A TE link is a logical connection between two NEs. It presents a
way to group or map information about certain physical resources (and their properties) that interconnect
LSR (NEs) into information used by CSPF for path computation and by GMPLS signaling. A TE link can be
represented as a tube between two NEs that contains the physical data links.
From this version, each DL and LDL is configured as a separate TE Link. Each TE link contains either a single
Data Link or a single LDL.
Up to 16 LDLs are supported between two NEs, with each SDH port supporting up to five LDLs. The number
of DLTs that you can define within each LDL, is defined as follows:
 STM-4: 1-4 DLTs
 STM-16 1-16 DLTs
 STM-64 1-63 DLTs.
(A DLT is a building block for an LDL, creating connectivity via Non-ASON NEs.)
TE links are listed in the TE links list. You can view a list of ASON TE links at the EMS system level or the NE
levels in the EMS. You can view TE link configuration parameters and status information for selected TE
links from the EMS. From EMS-MPT V1.2 and higher, multiple unbundled TE link mode is supported. The TE
link mode field is read-only in EMS-MPT.
From LightSoft V8.1 and higher, it is possible to set the TE link mode for the entire ASON network NE.
OPTIONAL FEATURE: ASON functionality is a fully integrated add-on capability, available on a

cost basis. If not purchased, this feature and related menu commands are unavailable.
Parent Topic
4.2.10.1 Configuring the TE Link Mode

ASON TE link mode can be defined as bundled or unbundled. To enable the embedded software to
associate SRLGs with a specific link (rather than placing all the SRLGs of all the DLs in the TE-link together),
TE-link mode must be configured as unbundled. Define TE link mode status in the LightSoft system
preferences. Changes are applied to all ASON MEs in the network.
NOTE: ASON ME TE link mode cannot be changed if you have one or more DL/LDL in the
network.

To define the default TE Link mode status:

1. In the System tab of the LightSoft ribbon, click Preferences. The Preferences window opens.
2. Click the System tab and then ASON Configuration. The ASON Configuration Preferences are
displayed.
3. In the ASON Parameters area, TE Link Mode dropdown box select Auto Unbundled or Auto Single
Bundle and then click Apply.
4. In the System tab of the LightSoft ribbon, click ASON ME Parameters Download. TE link mode
settings are downloaded to all ASON MEs. A message is displayed when the download is completed.
Parent Topic
4.2.10.2 Viewing TE Link Mode Status in the NMS
To view ASON TE link mode status in LightSoft

 Right-click an ME and select Properties. The ME Properties window opens displaying the following
fields:
 TE Link Mode: displays the TE link mode configured on the selected ME.
 TE Link Consistency: indicates whether the ME TE link mode is aligned with the TE link mode
configured in the Preferences window.
Parent Topic

4.2.11 Working with Multiple Links and LEs

You can view detailed information about multiple links and LEs. You can carry out administrative tasks such
as viewing attribute exceptions, modifying parameters, and running iterative tasks on selected objects.
Multiple List windows can be opened at the same time. Each window is represented by a tab at the bottom
of the window.
To view NE/link information for several objects:

1. In the Main window, select the relevant objects, and in the Topology tab, in the Lists group, click Link
List or LE List.
The Link List or LE List window opens; displaying entries for the selected object.
2. Actions can be performed on multiple selected objects at a time as explained in Operations on Link or
LE List Objects. You can filter the object list, if required.
Parent Topic
4.2.11.1 List Windows Filters

The Link List and LE List window contents can be filtered according to a selection of predefined filters.
To change the default filter:
 Select the filter that you want to make the default, and click Default Filter .
Table 4-4: Predefined filter options
Filter Description
Link filters
No Filter (Default)Do not filter the list. Enables the List window to open quickly,
without overhead.
All Links Show all physical and virtual links existing in the current layer. Note: The
physical layers (site and EMS) have no virtual links.
Ethernet Links All Ethernet layer links.

LDL & ASON Links LDL and ASON links.

MoE & MoT Links Physical (MoE) and virtual (MoT trail, intercard MoE) links.
Optical Links OTN links.
Physical Links Physical links.
Radio Links Radio links.
SDH Links SDH links.
Virtual Links Virtual links, including MoT, EoS, and LP.
LE filters
No Filter (Default) Do not filter the list. Enables the List window to open quickly,
without overhead. You can choose another filter as needed.
All Logical Elements All LEs.
All Split Nodes All secondary LEs (no primary LEs).
PB Nodes PB LEs.
PE Nodes PE LEs.
Parent Topic
4.2.11.2 Operations on Link or LE List Objects

To perform operations on multiple objects simultaneously:
In the Link List or LE List window, select the checkboxes of each object on which you want to perform the
action, and then click the relevant icon. The action is applied to all selected objects.
Table 4-5: List window function icons

Refresh Loads the current layer objects. If the window was opened with
preselected objects, loads only the same objects.
Print Prints the window list; see Printing.
Export Exports the list information in CSV format; see Exporting to CSV.
Preferences Opens the Preferences window; see Setting LightSoft Preferences
in the Getting Started & Administration Guide.
Open Properties Opens the object's properties window.
Current Alarms Opens the Current Alarms window showing alarms in the
selected objects.
Delete Deletes the selected object.
Configure TE (Link List only) Enables configuring TE parameters for multiple
Parameters selected links; see Configuring Link TE Parameters.


Configure CoS (LE List only) Enables configuring CoS parameters for multiple
Parameters selected PEs; see Configuring LE CoS Parameters.
Reconfigure Link Metric (Link List only) Enables reconfiguring the Link Metric for multiple
selected ASON links; see Reconfiguring the Metric for ASON Links.
Select All Selects all listed objects.
Clear All Clears all listed objects.
Default Filter Sets the currently selected filter as the default filter.
Parent Topic
4.3 Inserting and Removing NEs in Links

You can insert an ME or UME in an existing topology link, or disconnect it from a link, either in preparation
for its insertion into another link or removal from the network. An inserted UME can be useful for
maintaining accurate network topology.
Note that:
 The insert and remove processes may be traffic-affecting.
 When performing the actions described in this section, be sure to coordinate with your co-workers to
avoid other users defining trails in the same area.
 Inserting or removing NEs in links that are members of an MS-SPRing ring requires actions at both the
NMS and EMS level. See Editing the MS-SPRing Ring Topology.
 After an NE is inserted into or removed from the topology, LightSoft-old links that are no longer
needed are automatically removed.
 For cases not covered by the Insert and Remove ME/UME features, contact your local Customer
Parent Topic
4.3.1 Inserting Elements in SDH Links

You can insert an ME or UME in an existing SDH link. New links are created, trails on the new link are
properly configured, and the old link is deleted. There is no need to manually delete or edit trails. XC
changes corresponding to all trails going through the link are automatically downloaded to an ME via its
EMS.
Short VC-4 server trails are automatically split (terminated) in the inserted object. Long VC-4 server trails
and other HO trails are defined as through trails in the new object. LightSoft also enables you to split long
trails. (Short trails are trails with termination points at objects adjacent to the one being inserted. Long
trails are trails originating in more distant elements.)

When an object is inserted in a link, LightSoft performs the following sequence of actions:
1. Creates two new topology links to the ports of the inserted object.
2. Creates new VC-4 server trails on the new links, and downloads the XCs on the MEs being inserted, to
its EMS.
New VC-4 server trails are only created if the old link has short VC-4 server trails with endpoints on
the objects immediately adjacent to the one being inserted. Long VC-4 server trails are left as transit
XCs in the inserted element.
3. Moves existing HO (e.g., VC-4, VC-4-4c) and LO (VC-12, VC-3) traffic from the old to the new topology
links.0)
4. Removes the old topology link.
Prerequisites and Important Information

This procedure can be traffic affecting for trails that are not protected elsewhere in the network. To
prevent a possible impact on traffic, it is recommended to manually switch traffic to the alternate path:
 For SNCP-protected trails, switch all trails from the link using the Path Protection Switch window; see
Path Protection Switching.
 For MS-SPRing traffic, apply EMS Force actions on the nodes adjacent to the target link to switch
traffic off the link before inserting the ME.
This procedure is not suitable for inserting NEs into non-MS optical links, for example, between a
transponder and a port of type SDH.
The following conditions apply when inserting an object in a link:
 The selected ports for the insert must be the same rate as the intended link. Otherwise the ports will
not be enabled for selection.
 The object may be part of the LightSoft topology as long as the two ports used as endpoints for the
new links are available.
 Already-defined XCs can use these ports as long as there are no conflicts with the new XCs to be
created.
Parent Topic

4.3.1.1 Inserting an ME/UME in a Link
To insert an ME/UME in a link:

1. Select the Physical (Site) topology layer.
2. In the topology map, press SHIFT and select the link or multilink in which you want to insert the
element, and select the element you want to insert.
3. In the main window Topology tab, in the Modify group, click Insert ME/UME.
An error message appears if existing circumstances prevent the operation.
If a multilink is selected, the Insert Into Link window opens.
4. Highlight a link and click Select. The Insert ME/UME window opens.
Ports of the neighboring connected objects are automatically selected, so the available ports on the
"to be inserted" object are filtered by rate.

5. Define the following insert properties:

a. In the left and right panes, expand the trees and select a port in each tree.
b. (Optional) Modify the default link labels, as required.
c. (Optional) Modify the attributes of the two links, as required.
Click More to expand the Insert ME/UME dialog box to show two tabs with link attributes: Link1
for the link connecting the left port, and Link2 for the link connecting the right port.
The fields are the same as those of the More pane in the Create Topology Link dialog box (see
Create Topology Link Dialog Box.
Each tab initially shows the attribute values of the link to be replaced. You can change the
values for the new links.
NOTE: For MoT links, SRLG names can be removed or left as is. New SRLGs cannot be added.
6. (Optional) In the Insert ME/UME dialog box, click Validate to verify that the XCs can be created in the
inserted element. A warning appears if a precondition was absent (e.g., time slot interchange in the
NE to be inserted or trails existing in the element).
7. Click Apply. Validation check that the link selections are appropriate. A warning message indicates
this operation may be traffic affecting.
8. Click OK. The Progress bar show progress. When complete, a message is displayed.
9. Click OK. The ME or UME is now inserted in the selected link.
10. If the original link involved SYNCOM equipment at both ends (SYNCOM - SYNCOM link), delete the
original link in order to avoid notification to LightSoft for this link. Other original link configurations do
not require intervention at the EMS level.
Parent Topic

4.3.1.2 Troubleshooting
If a failure is encountered, perform the following steps:
First: Reconnect all VC-4 trails. Do not start the insert if there are failures.
Then:
1. Verify that the NE to be inserted is synchronized. (If it is not synchronized, the insert process will not
start.)
2. The insert can be started even if flex, incomplete, or inconsistent trails are present (the operation
skips these trails). However, we recommend fixing the condition before the insert as part of normal
network maintenance.
3. If a problem occurs during the insert, a failure message opens showing the failed trail's ID. Open the
trail list for that link and:
 Admit any inconsistent trails.
 Reconnect all incomplete and failed trails. If reconnection fails, admit the trails.
Parent Topic
4.3.2 Removing an Element from a SDH Link
NOTE: To insert/remove an element from an optical link, see Migrating Optical Trails.
In a dynamic network, MEs and UMEs must sometimes be placed differently in the topology or removed
from service and deleted from the network. You can disconnect an ME and UME from a link by
automatically replacing the two links on either side of an NE with a single direct link that connects the NE's
adjacent neighbors and bypasses the ME, while retaining all associated trails and services. Remove ME can
be performed on a disconnected ME, as long as the ME is connected to at least one connected ME.
If the ME is connected by additional pairs of links, these can also be removed by repeating the operation.
After all links are removed, the ME becomes a standalone element. It can then be reconnected to the
topology in a different way or deleted from the network.
You can either automatically delete the XCs (subnetwork connections (SNCs)) associated with the old
connection, or keep them intact:
 If you plan to link the element to the topology using the same ports, you can keep the old SNCs intact.
The ports then remain available in the EMS for connection to a new topology (not applicable to
Syncom 2.2). Keeping the SNCs also allows the process to run faster.
 If you plan to use different ports or remove the NE from the topology, it may be useful to
automatically delete SNCs at the same time that the links are removed from the NE. As well as freeing
resources, this avoids EMS-LightSoft conflicts and the generation of many TCIs (on SNCs that are in the
EMS and not yet admitted to LightSoft).

Before performing Remove ME, you should validate the trails. Validate checks that the trails that traverse
the selected ME will allow the remove ME procedure to be completed successfully (see also Remove
ME/UME Requirements and Limitations). If some trails fail validation, LightSoft provides a list of the trails
and the issues associated with them. Manually edit these trails before performing Remove ME.
Remove ME can solve basic TSI conflicts, however in some cases, it may also be necessary to perform Align
Trails. Validation checks whether Remove ME is able to solve all TSI conflicts, and recommends performing
Align trails before performing Remove ME, when necessary (see also Performing Align Trails).
NOTES:
 In some cases the Remove NE procedure cannot be performed successfully if Align Trails
has not been performed (such as when the target NE is disconnected).
 Align Trails is traffic affecting, because it involves editing the trail XCs. Force Switch to the
protection path is recommended before performing Align Trails.
 Defragmentation is not performed during the alignment process.
To remove an element from a link:

1. Select the Physical (Site) topology layer, and in the topology map, select the element you want to
remove from links.
2. In the main window Topology tab, in the Modify Links group, click Remove ME/UME. The Remove
ME/UME dialog box opens.

3. Specify how the operation is to be performed:

a. In the left and right panes, select the pair of links from which the element should be detached
(one on each side of the element). These links are replaced by a single link between the
neighboring elements.
In the map view, the selected links (or multilink containing the link) are automatically
highlighted.
NOTE: Only physical links of the same rate can be selected.
b. (Optional) The new link label (created by default) can be modified as required.
c. (Optional) To delete cross connects in the NE associated with the former links, select the Delete
SNC checkbox.
d. (Optional) Modify the attributes of the combined link. Click More to expand the Remove
ME/UME dialog box to show the link attributes.
The fields are the same as the More pane in the Create Topology Link dialog box. For a
description of the fields, see Create Topology Link Advanced Attributes.
Attribute values that are consistent with both the links that are to be replaced are initially
shown, such as the common technology layer, and a summed Length value, and can be changed
as required.
NOTE: For MoT links, SRLG names can be removed or left as is. New SRLGs cannot be added.
e. Click Path Trace Configuration to configure SDH path trace parameters; the Path Trace
Configuration dialog box opens. See Path Trace Configuration Dialog Box.
4. (Optional) Click Validate to verify that the operation can be performed as indicated, and to check
whether trails need to be aligned before performing Remove ME/UME. If a warning appears, this may
indicate a precondition that is not present, such as security authorization or a trail rule violation.
5. (Optional) Click Align Trails to remove TSI conflicts, if required (see also Performing Align Trails).

6. Click Apply. Validate is also automatically performed again, even if performed previously. A warning
appears that the operation may be traffic affecting.
7. Click OK. The operation may take a few minutes. The Progress bar at the bottom of the window
indicates that processing is in progress. After the processing is completed, a Succeeded message
appears.
8. Click OK, and then Close. The ME is removed from the selected links, and the adjacent links are
replaced by a single continuous link.
9. If the element involved more than one pair of links, you can repeat the procedure to remove it from
those links. 0)
10. If the original link involved SYNCOM equipment at both ends (SYNCOM - SYNCOM link), delete the
original link in order to avoid notification to LightSoft for this link.
Other original link configurations do not require intervention at the EMS level.
Parent Topic
4.3.2.1 Performing Align Trails

TSI conflicts must be removed, before performing Remove ME. LightSoft removes some basic conflicts
automatically during the Remove ME process. During Validation, LightSoft checks whether TSI conflicts
would remain after this process, and if so, recommends performing Align Trails as part of the validation
summary report. Align Trails must always be performed if one of the NEs involved in the Remove ME
process is disconnected. It can also be performed independently, without performing Remove NE.
The process of aligning trails, involves deleting XCs that are not aligned and creating new XCs that are
aligned. The Align Trails procedure is designed to resolve TSI conflicts on both HO trails and LO trails. LO
trails must not terminate on the target NE. Align Trails can be performed on SDH physical links and requires
at least one adjacent NE to be connected.
Align Trails does not need to align LO TSIs within the same VC4 resource. This is done automatically during
the Remove NE process.

An example of a TSI conflict in a Long HO trails is provided below. Trail 1 shows one TSI conflict, and trail 2
shows two TSI conflicts.
Figure 4-10: Trails showing TSI conflicts in Trail 1 and 2
When the Align Trails action is performed, the TSI in the existing trail on the target NE is removed, and new
pass-through XCs are created, to ensure trail alignment. In Trail 2, for example VC4-7 XCs are created to
ensure alignment in the HO Trail 2.
Figure 4-11: TSI conflicts in Trail 1 and 2 resolved by Align Trails
Before performing Align Trails you must perform Validation. Validation checks if there are reasons that
Align Trails cannot be performed on the selected topology. It checks the following:
 Verifies the links are SDH Physical Links, as required.
 Verifies both links are the same rate, as required.
 Checks Target NE Connection Status and warns if one or more NE is not fully uploaded. If both NEs are
not fully uploaded Align Trails cannot be performed.
 Checks if DRI, DNI, SNCP, or P2MP protection is present on the target NE. If yes, warns that DRI and
DNI protection should be removed before performing Align Trails.
 Checks if ASON trails present. If yes, ASON protection must be removed before proceeding to Align
Trails.
 Checks all trails are consistent. If inconsistent trails exist, validation fails and align trails cannot be
performed.

If validation fails, a message is displayed listing the trails and the reason for failure. If validation is
completed successfully, click Align Trails to start the process. The Align Trails action is recorded in the NMS
log and Activity log.
Once Align Trails is completed, a status message displays the number of HO and LO trails aligned
successfully, and also highlights any failures, providing a reason for the failures, where possible.
Although align trails is usually performed as part of the Remove NE process, it can also be run as a
stand-alone process.
To perform Align Trails standalone:

 Access the Remove ME window and click Align Trails.
Limitations:
 Align Trails does not solve TSI in unidirectional VC4 trails.
 The following use case is not supported:
Figure 4-12: Align Trails Scenario
Parent Topic
4.3.2.2 Remove ME/UME Requirements and Limitations

Before performing Remove NE:
 Ensure that at least one element is connected to the ME that you want to remove.
 Ensure the Trails state for all trails in the selected topology is OK. Trails of Trail Type flex (e.g., an HO
non-classified trail that terminates on the NE) are not supported.
 Ensure all LO trails on the selected topology traverse the selected links. LO trails that terminate on the
target ME are not supported.
 Ensure that all trails in EMS and LS trails are synchronized (i.e. use the same XCs).
 If a bypass tunnel exists on the selected topology, remove it (see Removing Bypass Tunnel Protection).
Bypass tunnels on the topology link are not supported during the Remove NE/UME process.

 Release maintenance operations on trails or other objects involved in the Remove process.
Maintenance operations are persistent until they are released. For details, see Maintenance
Operations.
 Remove services that terminate at the NE interfaces. In addition, timing, DCC trails, OSPF, DCC control,
and DCN supporting entities (such as clear channel) must be handled so as not to impact the network
when the NE is removed. However, trails that traverse an NE must not be deleted and the services
they supply must be preserved. These include service trails and server trails that terminate at its
interfaces.
 Remove ASON protection from the selected topology, if applicable. Remove ME/UME does not
support ASON Trails or ASON LDL links.
 If any links are MSP Linear protected, manually remove the protection. Removing an NE from MSP
Linear protected links is not supported directly during Remove ME/UME.
 DRI protection should be removed, if applicable. DRI XCs are not supported by the Remove ME/UME
process.
In addition, the following are not supported by Remove ME/UME:
 XCs that split on the target ME (e.g., DRI trail, trail with SNCP protection on the ME, or a P2MP trail).
Parent Topic
4.3.2.2.1 Guidelines for Specific Use Cases
Delete ME Use Cases
Protected MoT Trails Guidelines
If MoT has a protected tunnel, the following operations cannot be performed:
 Remove NE
 Edit, increase, or decrease MoT trail.
To solve this issue remove the protection, and then perform the action you require. Once the action is
completed, protection should be restored.
NOTE: Before removing protection, export protection details, including the Protection Actual
State and Bypass Tunnel details, to a CSV file. This information can be used to restore
protection once the action has been completed.
Parent Topic
4.3.2.2 Remove ME/UME Requirements and Limitations

4.3.2.3 Removing Bypass Tunnel Protection
To remove bypass tunnel protection:

1. In the Tunnel List window, identify the Protection Actual state of the tunnel.
2. To redefine the protected tunnel to unprotected, in the Tunnel List window, right-click the tunnel and
select Edit >Protection > Make Unprotected. The tunnel is disconnected from its bypass tunnel.
3. To remove the bypass tunnels that are protecting the MoT trail, in the Ethernet layer, right-click the
link and select Show Tunnels > Bypass Tunnels. The Tunnels List window opens, displaying the bypass
tunnels protecting the selected MoT.
4. For each bypass tunnel listed, right-click the tunnel and select Delete > Delete Tunnel(s) From DB
only. You can then edit, increase, or decrease the tunnel, or remove an NE without limitations.
Parent Topic
4.3.2.4 Restoring Bypass Tunnel Protection
To restore bypass tunnel protection:

1. Perform Admit for all bypass tunnels using TCI.
2. In the Tunnels List window, right-click the tunnel that you want to protect and select Edit >
Protection > Make Protected.
3. If the Protection Desired and Protection Actual states are not identical, right-click the tunnel, and
select Edit > Protection > Update FRR Protection. The Protection Actual field is updated and
protection is restored.
Parent Topic
4.3.3 Inserting or Removing Elements to/from Optical Links

Inserting or removing a card into/from optical links involves the following steps.
To insert an NE into an optical link:

1. Perform assignment of the new optical card in the EMS system. The card and its ports will then be
reflected in LightSoft.
2. Select the link to be replaced (old link) and open its Properties for Link window; see Link Properties.
3. Set the link's Maintenance State field to Manual Maintenance to enable creating new links on the
link's ports; see Maintenance Operations.
4. Create two new links from the original ports to the new module; see Topology Link Management.

5. Select the old link in the map and open the Trail List window; see Performing Actions on Trails and
Links. The trails traversing the old link appear in the Trails pane.
6. Select all the trails and perform the following Trail Consistency actions:
 Click Trail Consistency or right-click a trail and select Trail Consistency. The Trail
Consistency Indicator window opens; see Trail Consistency Indicator Window.
 Specify the optical trail type, according to the selected trails - OMS, OCH, or LP.
 Perform trail synchronization as described in Performing Trail Synchronization , using the Admit
selected trails to database option to readmit the trails. This causes the trails to traverse the
new link.
7. Delete the unnecessary old link; see Deleting Topology Links. (The old link is now free of trails.)
To remove an NE from an optical link:

1. Select each of the two old links to the element to be removed, and for each:
a. Open the link's Properties for Link window; see Link Properties. )
b. Set the links' Maintenance State field to Manual Maintenance to enable creating new links on
each link's ports; see Link Properties.
2. Create a new link between the ports of two neighboring elements; see Topology Link Management.
3. Select the two old links in the map and open the Trail List window. The trails traversing the old links
appear in the Trails pane; see Performing Actions on Trails and Links.
4. Select all the trails and perform the following Trail Consistency actions:
 Click Trail Consistency or right-click a trail and select Trail Consistency. The Trail
Consistency Indicator window opens; see Trail Consistency Indicator Window.
 Specify the optical trail type, according to the selected trails - OMS, OCH, or LP.
 Perform trail synchronization as described in Performing Trail Synchronization , using the Admit
selected trails to database option to readmit the trails. This causes the trails to traverse the
new link.
5. Delete the two unnecessary old links; see Deleting Topology Links. (The links are now free of trails.)
Parent Topic
4.3.4 Inserting or Removing Elements to/from ASON Links

Inserting or removing an NE to/from an ASON link involves actions in LightSoft and the EMS, as well as
physical fiber connections and disconnections. Physically disconnecting a fiber causes ASON restoration of
trails in the same way as when a fiber cut occurs. The operation affects traffic according to the relevant
protection type.
It is recommended to export the original ASON provisioned trails to XML as backup before you start to
insert or remove an NE. Make sure to coordinate operations between the field and the network operations
center (NOC).


To insert an NE into an ASON link:

1. Physically disconnect the fiber to be split. If alternative routes are found, the ASON trails on the link
are automatically rerouted by ASON restoration.
NOTE: If routes are not found, discontinue the procedure.
2. In LightSoft, acquire the rerouted ASON trails to make them provisioned (see Redefining an ASON
Provisioned Path (Admit) in the LightSoft User Guide. In the case of silver (1+1+R) trails, follow the
instructions Redefining ASON provisioned Path for 1+1+R Silver Trails in that section.)
3. In the EMS Topology Links window, exclude the topology links (see Excluding a Link from the ASON
Domain in the EMS User Guide).
4. In LightSoft, use Insert ME/UME to insert the NE into the ASON link (see Inserting Elements in SDH
Links in the LightSoft User Guide).
5. In the EMS Topology Links window, delete the original topology links (see Deleting a Topology Link in
the EMS User Guide).
6. In the EMS, assign the ACP to include the NE to be inserted if not already done. This may be done at
any stage before new topology link discovery.
7. Physically connect the two new links to the inserted NE.
8. In the EMS, discover the new topology links to include them in the ASON domain (see Topology Link
Discovery in the EMS User Guide).
9. In LightSoft, modify the ASON trails acquired in step 2 to traverse the two new topology links if
needed; see Editing Trails in the LightSoft User Guide.
To remove an NE from an ASON link:

1. Physically disconnect the fiber from the NE that you want to remove. If alternative routes are found,
the ASON trails on the link are automatically rerouted by ASON restoration.
NOTE: If routes are not found, discontinue the procedure.
2. In LightSoft, acquire the rerouted ASON trails to make them provisioned; see Redefining an ASON
Provisioned Path (Admit) in the LightSoft User Guide.

3. In the EMS Topology Links window, exclude the two topology links (see Excluding a Link from the
ASON Domain in the EMS User Guide).
4. In LightSoft, use Remove ME/UME to remove the NE from the ASON link; see Removing an Element
from a Link in the LightSoft User Guide.
5. In the EMS Topology Links window, delete the original topology links (see Deleting a Topology Link in
the EMS User Guide).
6. Physically connect the NE bypass fiber.
7. In the EMS Card Internals View, for the relevant NE card, right-click the RS Source or Sink Object and
click Set RS TTI to default (see Associating ASON Links to the ASON Domain in the EMS User Guide).
8. In LightSoft, if needed, modify the ASON trails acquired in Step 2 to traverse the old path again; see
Editing Trails in the LightSoft User Guide.
Parent Topic
4.4 Viewing Resource Availability on Links

The LightSoft Resource Availability on Links features are important tools for network traffic planning. At a
glance you can see the available capacity in the network as a whole and on specific links/multilinks.
Three views of current link availability are provided:
 Availability Map windows show the proportions of available resources across all or selected links
based on selected parameters (SDH or optical rate or source/CoS combination for ETH/MPLS); see
Availability Map. It also enables viewing availability for individual links in absolute terms.
 Create/Edit Trail: For optical trails only, toggle between the trails view, and availability map view (see
Viewing Availability Map Information).
 Availability for Link windows display charts that show the number and percentage of resources
available for building new trails on a selected link, based on all relevant parameters; see Availability for
Link.
Resource availability is shown as of the time that the feature was selected (and a rate was selected for the
Availability map) or since the last refresh, as indicated by the timestamp in the window footer.
Calculation requests are nonblocking for other LightSoft applications (client and server).
OPTIONAL FEATURE: The Availability Map and Availability for Link functionality is a fully
integrated add-on capability, available on a cost basis. If not purchased, the feature and
related menu options are unavailable.
Parent Topic

4.4.1 Availability Map

The Availability Map window displays a visual representation of links/multilinks in a particular layer, color
coding each link according to the available capacity for new trails on the link. A typical color legend is
illustrated in the following figure.
Figure 4-13: Availability Map color legend
Available capacity can be according to:

 Rate (SDH or optical) or
 Source and CoS combination (ETH/MPLS)
After parameters are selected or the window is refreshed, the percentage availability of each link/multilink
is calculated and color coded according to contiguous availability ranges shown in the legend in the status
bar. You can customize the ranges and color associations from the preferences window (see Modifying
Availability Preferences in the Getting Started & Administration Guide).
Multilinks and individual links are colored according to the component link or direction with the maximum
number of available resources. You can also view specific absolute availability information for individual
links.
Network operators can take advantage of the Availability Map's convenient sliding rule to simulate network
growth, simplifying network planning for future capacity needs.
A physical PSI port on an NE card represents the aggregate capacity of all the logical MoF ports grouped on
that card. In the Availability Map, NPT platforms are by default displayed as a single shelf group,
represented by a single icon. The availability displayed represents the total aggregate capacity of the PSI
port, in each direction, capacity which is available for use with external PEs. MoF links are not initially
visible on the Availability map since they are by default collapsed within their shelf group (Working with
Groups). If the NPT icon is expanded, all the internal MoF links are displayed and the availability of each
MoF link is listed.
Figure 4-14: Availability map
To view the available capacity of the MoF links within the shelf group, expand that shelf group. Once the
shelf group is expanded, MoF link capacity is displayed in the same manner as other link capacities.

Note that the total capacity of a PSI port represents the cumulative capacity of all the logical MoF ports
grouped under that PSI port. The cumulative capacity of all the logical MoF ports grouped under a PSI port
cannot exceed the physical capacity of that PSI port.
In addition to the Availability Map, users can also view capacity data through a corresponding set of
Availability Charts. 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 resources,
optical rates, or source/CoS combinations for Ethernet/MPLS services.
The Ethernet/MPLS tab shows bandwidth availability at the port and CoS level based on CAC assignments.
When working with hybrid data cards, the Availability Charts display both the aggregate PSI port capacity in
each direction (ingress and egress) as well as a breakdown of available capacity per MoF port, depending
on the tab selected. This is illustrated in the following figure.
Figure 4-15: Availability Chart: PSI tab

Figure 4-16: Availability Chart: Port tab
NOTES:
 In SDH networks, availability is depicted in terms of what can be provisioned for a selected
rate, which may be less than the overall capacity of the SDH link. For more information,
see Link Availability Constraints.
 In SONET networks, availability for concatenated trail rates (for example STS-12c) depends
on how preexisting trails are distributed within the link and the number of available
contiguous resources. For example, suppose four STS-3cs are configured on an OC-48 link
(leaving 12 unoccupied resources). If those STS-3cs are distributed on cells needed for the
STS-12c creation, availability at the STS-12c rate may be less than 3, and possibly nil.
Parent Topic
4.4.1.1 Viewing the Availability Map

From the relevant layer, select the Availability map, and choose the rate that you want to view. After the
relevant parameters are selected (a rate for SDH or optical, or Source and CoS selections for
MoT/MoE/MoG), the links in the map are color coded according to the available resources consistent with
those parameters. Multiple instances of the window may be opened at the same time, for example, based
in the same topology view but showing different rates.

To view the resource availability of links:

1. In the main window Layer dropdown list, select a topology view:
 For an SDH map, select the Physical (Site), or SDH layer.
 For an Optical map, select the Physical (Site), Optical, or OCH layer.
 For an Ethernet/MPLS map, select the ETH/MPLS layer.
2. Optionally preselect objects in the map view so that the Availability Map opens with only selected
objects and their links displayed, instead of all the objects.
3. In the main window Tools tab, in the Maps group, click Availability Map. The Availability Map
window opens.
4. Do either:
 SDH or Optical: In the Rate dropdown list, select a rate, and if required, in the Capacity
dropdown list, select the capacity.
 ETH/MPLS: In the Source dropdown list, select a source, and in the CoS dropdown list, select a
CoS.
The links/multilinks in the Availability Map window are color coded according to the resource
availability.
5. To view availability for a different rate/source, select the settings you require and click Refresh .
The Availability Map is updated.
Parent Topic

4.4.1.1.1 Availability Map for Different Technology Layers

You can view information from the follow technology layers:
 SDH layer: Shows availability of links for the selected SDH rate.
 ETH/MPLS layer: Shows availability of MoT, MoE, and MoG links over the entire global MPLS Layer
based on selected Source and CoS parameters. (EoS and ETY links, if any, appear in gray and are not
part of the analysis.). Select from the following source options:
 CAC Unshared Bandwidth: Displays availability based on bandwidth reserved for working
tunnels (default).
 CAC Shared Bandwidth: Displays availability based on bandwidth reserved for bypass tunnels.
 PM Current 15 Minutes and PM Current 24 Hours: Not currently supported.
For multilink, availability is the average value calculated on all the links in the multilink.
 CoS: Select the relevant CoS (0-7).
 Optical layer: shows availability of links based on the selected optical rate, and capacity (if applicable).
 OCH: The OCH links carrying OMS trails are color coded according to the percentage of available
channels / the total number of channels the links carry.
 LP: When LP rate is selected the links are color coded according to the percentage of resources
available for the selected LP type.
For example, if the selected LP is GbE8 (requiring 8 SPO resources), and the OCH has only 30 of
64 SPO resources still available, then up to three more GbE8 LPs could use the OCH. So the
percentage shown by the color code is 37.5%.
(This is represented by the equation [a/n]/[t/n], where a=Available Resources; t=Total
Resources n= No of resources needed for the specific LP rate. In this example, the calculation =
[30/8]/[64/8] = [3.75]/8 = 3/8 = 37.5%. [ ] represents the lower bound.)
For an LP rate, only links carrying OCH trails directly (with no OMS trail) and support the
selected LP type are colored.
 ODU: When ODU is selected, the map colors links carrying OCH trails directly (with no
underlying OMS trail) that support the selected ODU rate.
Availability of resources is shown only on segments where there is a single immediate
underlying trail or link.
Parent Topic

4.4.1.1.2 Viewing Availability of Individual Links

You can view availability for an individual link. You can also view information for individual links at the
specified rates in absolute terms, or for all applicable rates in or pie chart form.
To view availability information for individual links:

 In the Availability Map window, double-click a multilink. An Availability window opens for the
selected link, displaying details according to the selected topology layer.
Figure 4-17: Actual Links between Two Elements dialog box
The window is similar to the Actual Links between Two Elements dialog box (see Viewing
Topology Link Information). From the Availability Map view, each link is colored according to its
own availability, and the Availability column shows the availability of the link in absolute terms,
in the format No. available resources/Total resources Resource Type. If resources are not
symmetrical, the values shown are resources in direction with the least available resources (in
the same way as SDH Availability).

To view channel availability information for individual OCH links:

For OMS, individual link availability is presented in the form of Optical Availability Table, which shows
channel availability details.
 In the Availability dialog box, right-click an OCH link graphic and select Availability to open the Optical
Availability Table, which shows channel availability details for the link. For more details, see Viewing
Optical Channel Availability.
Figure 4-18: Optical Availability Table
Parent Topic

4.4.1.2 Exporting Availability Data in CSV Format

You can view SDH and optical Availability Map information in CSV format. The CSV file can be imported into
MS Excel or a relational database for further analysis.
To export availability data to a CSV file,
 From the Availability Map, click Export .

The basic availability data for all the objects currently in the map is stored by default at either
/tmp/NMSAvailMap.csv for SDH data, or /tmp/NMSUtilTable.csv for optical data. Each time the
Availability Map is updated, the file is overwritten with the current data.
Figure 4-19: Availability data CSV example
Table 4-6: SDH and Optical Availability Map CSV data fields
Field Description
Link Name User-assigned link name. By default it is the name of the first and second
endpoints in alphabetical order.
Virtual Link Whether the link is an actual one in the current technology layer (No) or a
virtual representation of a trail from an underlying technological layer
(Yes).
Link Rate Rate of the link (may be different from the rate of the port).
Available Resources Total number of trails that can still be provisioned at the selected rate on
the specified link.
Total Resources Total number of trails that can potentially be provisioned on the specified
link at the selected rate.
Used Resources (Optical map Indicates an OCH trail traversing OMS sections. The OCH trail originates
only) from at least one endpoint or passes through both.
Blocked Resources (Optical Indicates a channel is blocked at one/both endpoints by a group OADM, a
map only) red-blue filter, or a dropped channel without OCH.
% Available Proportion of trails that can still be provisioned vs. the total that can
potentially be provisioned on the specified link at the selected rate.

Table 4-7: Optical Channel Availability table CSV data fields
Field Description
Channel Optical channel wavelength value.
State Channel state - Free, In-use, Blocked, or Mixed; see Optical Availability
Tables.
Payload OCH payload type (DSR, ODU1, or N/A).
Resource Type For the LP rate, the LP Type, for example, SPO, ODU, Non-Structured, see
Availability Map for Optical).
Available Resources As described for the Availability dialog box Availability column; see
Viewing Availability of Individual Links.
Total Resources As described for the Availability dialog box Availability column; see
Viewing Availability of Individual Links.
Parent Topic
4.4.1.2.1 Exporting Availability Map Data to CSV with a Script

You can export SDH and optical availability map data to a CSV file by running a shell script on the NMS
server station. This runs at low priority with minimal strain on GUI operations. The exported availability
map is not based on any specific open and active map but on all the MEs and LEs in the server. A separate
file is created for each indicated rate.
Script syntax:
AvailMapExport -rate [-rate] [-rate] ... [-rate] [-f BaseFileName] [-p path]
Where:
–Rate For example, -LP, specifies a rate. At least one rate
must be supplied. A separate file is generated per
supplied rate. The file name becomes the basic file
name rate with an appended rate.
[-f BaseFileName] Basic file name (optional). If not provided the
default file name AvailMap is used. The csv file
name comprises the basic file name and an
appended rate with the .csv extension.
[-p path] Directory where the file will be saved (optional). If
not provided a default path /sdh_home/nms/ is
used.

For example:
AvailMapExport -user MyName -passwd MyPassword -VC-12 -VC-3 -LP -f Newname
The output is a csv file containing:
 Label name of the link that carries the trail
 Resource capacity
 Resource available and availability percentage for each rate selected
To run the script:

 Run the script in the command line or through the UNIX cron scheduler. The script location is
/opt/nms/server/sh/.
An additional script enables the LightSoft user to configure the crontab to run the map export script
at periodic intervals.
Scripts have a usage option that displays the allowed parameters and their possible values. The usage
is displayed if the script is run with no parameters or when a problem occurs with the parameters.
Script run errors are logged under “/var/NMS/logs/”. Example log errors: an unidentifiable rate,
directory could not be found.
Parent Topic
4.4.1.2 Exporting Availability Data in CSV Format

4.4.1.3 Modifying Availability Preferences

The Preferences window Availability workspace enables you to change the percentages and color coding of
resource availability information presented in various Availability windows and tables.
Figure 4-20: Optical Availability Preferences
In the Availability Ranges pane, you can modify the availability percentage ranges and color coding for the
Availability Map and the Sub Lambda View of Optical Availability Tables.
Change the percentages for each range in the From and To columns, as follows:
 Upper limit extends to just below the next whole number (e.g. 51-99% denotes 51% or more, and less
than 100%. Note: (100-100) and (0-0) ranges denote exactly 100% and exactly 0%.
 Any ranges can be defined, provided the upper and lower limits of adjacent ranges are continuous
(without gaps) and not overlapping.
In the Availability Status Pane, you can change the color coding of availability status in the Lambda View of
the Optical Channel tables. Five ranges can be defined, including Undeterminable (not associated with a
range). For the availability status definitions, see Optical Availability Tables in the LightSoft User Guide.

To modify availability ranges and colors:
1. In the Availability Map menu, click Preferences or select Map > Preferences. The Preferences
window opens.
2. In the User tab, select Availability.
3. Select the percentage range for each category, and the associated color from the relevant color
swatch . The changes are saved to your profile. The same color preferences apply in all
layers.
Parent Topic
4.4.2 Availability for Link

The Availability for Link window shows the number and percentage of resources available for building new
trails on a selected link based on all relevant parameters (SDH or optical rates or source/CoS combinations
for ETH/MPLS).
Parent Topic
4.4.2.1 Accessing Availability for a Link

The Availability for Link window is accessed as described in this section.
To view resource availability of a specific link:

1. In the LightSoft main window Topology Layer dropdown list, select a topology view: Physical (Site),
SDH, or Optical.
2. Right-click the required link/multilink and select Availability. The Availability for Link window opens.
If a multilink is selected, multiple windows open, one for each link in the multilink.
OR
3. If you want to view availability for a single link in a multilink:
a. Double-click the multilink to open the Actual Links between Two Elements dialog box; see
Viewing Topology Link Information.
b. Right-click the required link and select Availability for Link. The Availability for Link window for
that link opens.
You can also open the Availability for Link window in the Availability Map window (see Availability
Map) by right-clicking a link in that window and selecting Availability.

Table 4-8: Link Availability menu options
Toolbar
icon
View
Refresh Refreshes the window to show the current resource availability
percentages. The Last Update time stamp in the bottom right corner
of the status bar shows the date/time of the last refresh.
A view is automatically refreshed when a new preference is applied.
Preferences Enables you to change the colors associated with availability
categories; see Modifying Availability Preferences in the Getting
Started & Administration Guide.
Legend Shows or hides the status bar legend and Last Updated time stamp.
Close Closes the window.
Parent Topic
4.4.2.2 Link Availability for SDH/Optical

The window header shows the link name and its designated rate. When a multilink is selected, multiple
Availability for Link windows are opened, one for each link in the multilink.
Figure 4-21: Availability for Link for SDH dialog box
When a link is symmetric in both directions, the window shows the rate information on a single row. When
a link is bidirectional, availability information for each direction's rate is represented on a separate row.
For each possible rate of the link, a pie chart shows the percentages of available vs. unavailable resources.
The resources available vs. unavailable are listed under each pie.
NOTE: Availability is depicted in terms of what can be provisioned for a selected rate, which
may be less than the overall capacity of the SDH link. See Link Availability Constraints (page
4-82).

The legend at the bottom of the window explains the color coding. The available/unavailable colors are
user-configurable; see Modifying Availability Info Colors.
Blocked resources (resources already allocated at other rates or otherwise unusable) are included within
the Unavailable slices, and are not reflected separately in the statistics. If a link's ports cannot fill the link's
capacity (for example, an STM-64 link connected to a port that can handle only 32 VC-4s), the unusable
capacity is considered blocked ("unavailable" for purposes of the window information).
For the toolbar options, see Accessing Availability for a Link.
Parent Topic
4.4.2.3 MoT/MoE/MoF/MoG Link Availability based on CAC

Parameters
This window is used to view bandwidth availability at the port and CoS level based on CAC assignments; see
Link Properties - CAC Tab. The window is accessed in the Availability Map window whose Information
Source is set to CAC. Double-click a link to open, or right-clicking a link and selecting Availability > CAC.
Figure 4-22: Availability for Link window based on CAC
NOTE: When working with hybrid data cards, the Availability Charts display both the
aggregate PSI port capacity in each direction (ingress and egress) as well as a breakdown of
available capacity per MoF port, depending on the tab selected. PSI port capacity represents
the cumulative available capacity for all the logical MoF ports linked to that physical PSI port.

For the toolbar options, see Accessing Availability for a Link.
Table 4-9: Link CAC Availability diagram features
Option Description
BW Units Selector Enables choice of units expressed in terms of:
 Percentage of the port rate (% Port Rate), or
 Bandwidth (Mb/s)
Pie Charts and Bar Charts - Port and CoS levels
Allocated BW Portion of EMS-assigned port/CoS bandwidth reserved for working traffic
that is already allocated to tunnels.
Unreserved (unallocated) Portion of EMS-assigned bandwidth that is reservable for working traffic at
BW the port or CoS level that is not yet allocated to traffic.
Allocated Shared BW Portion of EMS-assigned port/CoS bandwidth reserved for bypass tunnels
that is already allocated to bypass tunnels.
Unreserved (unallocated) Portion of EMS-assigned port/CoS bandwidth reserved for bypass tunnels at
Shared BW the port or CoS level that is not yet allocated to traffic.
Non-Reservable BW Portion of EMS-assigned bandwidth not available for any purpose.
Parent Topic
4.4.2.4 Modifying Availability Info Colors

The Preferences dialog box enables you to change the colors of specified designations in the window pie
charts and number fields. The changes remain in effect for your user profile until modified.
To modify the availability info colors:
1. In the Availability for Link window toolbar, select Preferences , or select View > Preferences.
The Availability Info Preferences dialog box opens. The possibilities for change vary according to the
originating window.
Following are the Preference windows for SDH and ETH/MPLS CAC, respectively.

2. Change the color associated with a designation by customizing its color swatch . For
information about standard color customization, see Customizing LightSoft Object Status Colors in the
Getting Started & Administration Guide.
3. Click Apply to save the last changes and keep the dialog box open for additional changes, or OK to
save changes and close the dialog box. The Availability for Link window is automatically refreshed.
The status bar legend shows the new color codes. (You can click Reset to undo the changes since the
last apply, or Cancel to close the dialog box without saving the changes since the last apply. You can
click Defaults to reinstate the system default colors.)
Parent Topic
4.4.3 Logical Data Links (LDL)

Parent Topic
4.4.3.1 LDL Concept

A Logical Data Link (LDL) provides ASON protection to non-ASON-enabled elements in a trail path, such as
third party elements, or NEs or BGs without an ASON card. It enables a trail to be ASON protected even if
some elements it traverses are not ASON-enabled.
An LDL consists of the following components:
 An LDL link with a dual presentation:
 Virtual SDH topology link between ASON-enabled NEs.
 LDL trail in the SDH layer between those NEs, reflected in the Trail List window map only by its
endpoints. This type of trail serves an internal design purpose and has very limited user
relevance.
The link and trail are labeled on SDH map views with an orange icon to distinguish them from
regular ASON links . (The LDL does not appear in the Physical map view.) When a multilink
contains both ASON links and LDL links, the multilink is labeled with the ASON icon, while individual
links within the expanded multilink are labeled with their appropriate icon.
 A bundle of Data Link trails (DLTs), each terminated at an LDL port, which either realize or represent
the virtual link connectivity - DLT trails realize the virtual link connectivity when the LDL traverses
managed elements, or represent the connectivity when LDL traverses UMEs – third party NEs.
Each DLT trail represents a separate path in the non-ASON subnetwork, created per resource
according to PathFinder rules and consistent with regular trail creation preference constraints.

The following actions can be performed on an LDL and are described in this section:
 Individual DLT paths can be modified to traverse different combinations of non-ASON elements. (The
LDL trail itself does not have a path. It only has endpoints, which cannot be changed.)
 Regular VC-4 trails can be provisioned over an LDL trail, with specific DLT trails optionally selected as
resources.
 The entire LDL entity (all its components) can be deleted via the LDL trail. (Actions cannot be
performed from the topology link.)
 Reconnection in the same way as regular trails.
 View LDLs and their associated resources (DLTs).
This example Trail List window segment shows:
 An LDL trail, represented by its endpoints at the ASON-enabled elements XDM-130-6 and
XDM-130-43.
 DLT trails between those elements connecting XDM-130-7 end-to-end via non-ASON links.
Figure 4-23: End-to-end DLT trail
LDL and DLT trails are visible as virtual links in the SDH layer map and appear in the Trail List window when
all trails are displayed or when the specific objects are preselected. LDL trails can be viewed in isolation
using the Trail List window LDL filter. Then the DLT trails associated with that LDL trail can be viewed using
the Show DLTs option; see Showing Related DLT Trails.
The following infrastructure required to build an LDL link-and-trail and its associated DLT trails:
 Two ASON-enabled elements (with ACP or ACM card assigned - XDM-130-6 and XDM-130-43 in the
example) as endpoints.
 At least one non-ASON port in each element linked to a non-ASON subnetwork (UMEs in the example).
For information about the LDL link-and-trail creation process, see Creating an LDL Link.
The LDL link and trail, and associated DLT trails are defined with the following rates:
 An LDL link can be defined with an STM-1, STM-4, STM-16, or STM-64 rate.
 The associated LDL trail has an "LDL VC-4" trail rate.
 The associated DLT trails have a "DLT VC-4" rate. A maximum of one, 4, 16, or 64 DLTs can be defined
per LDL according to whether the selected link rate is STM-1, STM-16, or STM-64, respectively. The
actual number of DLT trails depends on the virtual resource capacity selected for the LDL link.

Up to 16 LDLs are supported between two NEs, with each SDH port supporting up to five LDLs. The number
of DLTs that you can define within each LDL, is defined as follows:
 STM-4: 1-4 DLTs
 STM-16 1-16 DLTs
 STM-64 1-63 DLTs.
(A DLT is a building block for an LDL, creating connectivity via Non-ASON NEs.)
Parent Topic
4.4.3.1.1 LDL Use Cases

The following are some examples of how LDL links may be used.
 Case 1: An operator who rents bandwidth from third party may still require ASON capabilities over the
rented bandwidth. This situation is characterized by two ASON-capable NEs linked by connections
through an unmanaged network, which may consist of equipment of another vendor and/or another
operator. The cross-connects implementing the connections at intermediate NEs are established
before configuration of the LDL by the appropriate management systems (not LightSoft).
 Case 2: An operator may mix into the network some equipment that does not support ASON. Then the
LightSoft managed network consists of a mixture of ASON-capable NEs (NEs with ACP) and
Non-ASON-capable NEs (non XDM/NPT equipment such as BG and XDM/NPTs without ACP). In this
case, LightSoft establishes the connections between the ASON capable NEs before configuring the LDL.
 Case 3: Multiple LDLs on one physical port are required, each connected to a different port at the
other LDL end. Each endpoint of the LDL will have an LDL port containing resources assigned to the
LDL.
Parent Topic
4.4.3.1 LDL Concept
4.4.3.1.2 LDL Restoration Path Selection Process

An LDL can be created between two ASON nodes which are connected via a third party SDH network. The
connection is via a maximum of 5 LDLs per physical link, each representing one LDL of rate STM-1, STM-4,
STM-16, or STM-64.
Up to 16 LDLs using up to four ports (each SDH port supporting up to five LDLs) are supported between two
NE. Each LDL is defined as a single TE link. The number of DLTs that you can define within each LDL, is
defined as follows:
 STM-4: 1-4 DLTs
 STM-16 1-16 DLTs
 STM-64 1-63 DLTs.
(A DLT represents the passthrough connection that is created in Non-ASON NEs for each LDL.

In the event of a fiber cut on an LDL between ASON NEs traversing a third party network, ASON first
searches for a path along disjointed ducts (involving regular ASON links and NEs, but not in other LDL
connections belonging to the physical link where the broken LDL is connected). If such a path is found,
recovery takes a few seconds.
If a path is not found via disjoint ducts, ASON tries to find a path via the same physical link over the
remaining four LDL connections through the third party. This reuse possibility saves on network resources
allocated for possible restoration purposes.
A single TE-link can contain up to five LDLs.
NOTE: In the latter case, the recovery is implemented one minute after the restoration
process starts.
Parent Topic
4.4.3.1 LDL Concept
4.4.3.2 Creating an LDL Link

You can create an LDL link and its component LDL trail and DLT trails.
To create an LDL link:

1. From the Physical layer map window, select two ASON-enabled NEs as endpoints, where at least one
non-ASON port in each element is connected to a non-ASON subnetwork (for example, UMEs or
non-ASON NEs). The two selected elements should have an ACP or ACM card assigned and
configured.
2. In the main window Topology tab, in the Create group, click Logical Data Link. The Create Logical
Data Link window opens, displaying the General tab.

3. In the Label field enter a label for the link, or LightSoft automatically adds a label based on the
selected LDL endpoints.
4. In the Rate dropdown list, select an LDL link rate. The selected rate determines:
 The compatible ports available for selection in Step 5.
 The maximum number of virtual resources (DLT trails) that can be defined for the LDL in Step 6
(one for STM-1, 4 for STM-4, 16 for STM-16, and 64 for STM-64).
5. To select the endpoint ports:
a. Click the End Port 1 dropdown list. A tree of the available ports on the left-side NE opens.
b. Click the required port and choose Select.
Ports are enabled for selection according to the selected LDL rate and other validations.
 STM-1 LDL rate enables selection of STM-1, STM-4, STM-16, or STM-64 ports.
 STM-4 LDL rate enables selection of STM-4, STM-16, or STM-64 ports.
 STM-16 rate enables selection of STM-16 or STM-64 ports.
 STM-64 rate enables selection of STM-64 ports only.

c. Click the End Port 2 dropdown list, click the required port from the right-side NE, and choose
Select. The End Port fields show the selected ports and the Resource Selection pane is enabled.
TIP: Different rate ports may be used on each side of the LDL. For example, you can define an
STM-1 LDL using an STM-1 port on one side and an STM-16 port on the other side. The
following step, describes how to select the STM-1 port's resource on one side and one of an
STM-16 port's resources on the other side, for example. The STM-16 port's remaining 15
resources remain available for other LDLs. Up to five LDLs can be created on different
resources of the same port.
6. In the Resource Selection pane, define the virtual resources that the LDL trail will use.
Two methods of resource selection are available - Auto-select or Manual. If you will use both
methods, perform Auto-select first, then select additional resources manually. Auto-select will clear
any previously selected resources.
a. Automatically select any number of resources for the LDL at once. In the next-available line in
the Resource Selection pane, right-click and select Auto-select.
The Auto-Select window opens.
 Select the number of resources required to be created (for example 4).

 Click OK.
The lines corresponding to the number of resources you requested are automatically filled. The
timeslots in each port are selected automatically. You can change any of these manually in the
Select dropdown list of each timeslot selector. In this case 4 resources were requested.
AND/OR
b. Select resources manually, one at a time, if needed:
In the Resource Selection pane, in the next available line:
 Select a timeslot in the Timeslot 1 dropdown list.

The timeslots available for a port are listed in the dropdown list at each virtual resource
line. Unavailable or inappropriate ports are not shown. (In this case the first available
timeslot is #5.)
 Select a timeslot in the Timeslot 2 dropdown list.

After a pair of timeslots is selected, a new empty line opens in the list. You can define additional
virtual resources in the same way.
Each virtual resource line in the list comprises a pair of real port resources on each element
side, as identified by the timeslot numbers that you select.
The number of virtual resource lines that you define determines the number of DLT trails that
will be created for the LDL. The maximum of virtual resources that you can define is limited by
the selected LDL rate.
You can perform the following additional actions on selected virtual resources:
 Change timeslots: Select different timeslots in the dropdown lists.
 Remove a virtual resource line: Right-click the line and select Remove or click Remove
.
 Remove all virtual resources: Right-click a line and select Remove All or click Remove All
.
The Capacity field shows the number of virtual resources currently defined for the LDL
according to the selections or removals you performed.
Resource Selection Troubleshooting
 Each port timeslot can be assigned to only one resource. If the same timeslot is selected in
two resource lines, both lines are colored in red, indicating that one of them should be
changed to another resource. If you click Apply, before the problem is resolved, a message
will prompts you to fix inconsistencies and then to click Apply again. (Check for red
marked lines by scrolling.)
 After resources are defined for an LDL, you can still change a port selection. The first port's
resource selections are automatically loaded to the new port.
However, if any resource specified for the old port happens to be already occupied in the
new port, a Select message appears on their resource line, prompting you to choose
another resource. If you click Apply before the problem is resolved, a message prompts
you to choose to either drop the conflicting resources, or cancel the Apply and make
further corrections.

NOTES:
 LDL link creation is a hybrid procedure that includes aspects of both link and trail creation.
Selecting timeslots is similar to the resource selection step in regular trail creation.
 Unlike regular trail creation, timeslot selection is mandatory since the number of DLTs
that should be created must be specified.
 PathFinder Preference Constraints for trail creation also apply to the LDL trail creation
part of the process; see Trail Creation Management Preferences in the Getting Started &
0)
7. (Optional) Click the Advanced Tab and in the SRLG (Ducts) field, enter a SRLG name (descriptive string
of up to 32 characters).
8. In the General tab, click Create. When complete, a message is displayed. If successful, it shows Logical
data link created successfully, showing the LDL Connection State is implicitly Full and the LDL
Configuration State is OK.
Specific details are displayed only when some aspect of the operation fails, including:
 LDL Connection State: State of contained DLT trails upon creation of LDL.
 Full: The requested number of DLT trails was created.
 Partial: Less than the requested number of DLT trails requested was created.

 LDL Configuration State: State of the LDL's endpoint ports in the EMS.
 OK: The LDL endpoint ports were created correctly in the EMS.
 Failed: The LDL endpoint ports were not configured in the EMS.
 Inconsistent: The LDL endpoint ports configuration involves some inconsistencies.
The difficulty in each problem case usually involves a connection failure during the download process.
It is recommended to check connections and try again.
9. Click OK. A new Create LDL dialog box opens, cleared of selections. You can start another LDL creation
session if required.
Parent Topic
4.4.3.2.1 Viewing and Managing SRLGs for LDLs

You can assign an SRLG to each TE link, via LightSoft. The SRLG is a user-defined string of up to 32
characters, and up to 20 SRLGs can be defined on a single link. To ensure that all TE links residing on the
same duct have same SRLG, the SRLG number is usually defined as the duct number. You can have more
than one TE link between the same NEs, so that more than one route is available in the event of a fiber cut.
You can assign a different SRLG number to main and protection links, to avoid having a single point of
failure (SPOF).
In the event of a fiber cut, ASON considers the SRLGs associated with a particular ASON trail when
calculating the optimum restoration path. When the trail is switched, the SRLG information associated with
the trail is also update, so that if a further fiber cut occurs, ASON can find an alternative route using the
most up-to-date SRLG information.
Define SRLG for an LDL during the LDL creation process (see Creating an LDL Link).
NOTE: SRLG definition is only supported when the TE Link mode is defined as unbundled. In
ASON version 8.4, SRLG can be defined for LDL's only.
Parent Topic

4.4.3.2.2 Defining LDL Link Metric Values

You can define LDL link metrics, including length, cost, and hop count.
To define LDL link metric values:

1. In the Link List window, right-click an LDL link and click Properties. The Link Properties window
opens.
2. Click Show LDL Properties. The Update logical Data Link Metrics window opens.
3. Enter values for Length, Cost, and Hop Count in the relevant fields. Only default defined in the
Preferences window is downloaded to embedded LDL links.
Parent Topic

4.4.3.2.3 LDLs Over Non-ASON Domains

LDL links enable an ASON operator to run ASON traffic over:
 Third party networks, or
 Supported equipment that does not have ASON protection.
This enables provisioning of services, as well as additional restoration possibilities, over leased third party
network bandwidth. (The typical connection between ASON NEs and a third party network is MSP 1+1
protection.)
Figure 4-24: LDL connecting third party network via MSP 1+1
ASON restoration on the LDL is limited to the resources currently allocated by the third party. As fiber cuts
occur and ASON resources are used for restoration, it is the ASON user's responsibility to monitor the
number of free resources still available on the LDL and to request the third party network administrator to
allocate more resources whenever a threshold is reached.
Free resources remaining on the LDL can be monitored using the Availability Map and Availability for Link
features; see Viewing Resource Availability on Links.
LDLs and MSP 1+1

An LDL trail can include an MSP 1+1 protected link segment.
Parent Topic
4.4.3.2.4 Non-LDL Traffic on an LDL

Where not all the link capacity is needed for LDL purposes, you define only part of the link's VC-4s as LDL.
For example, an STM-16 link can be defined with:
 8 regular VC-4s defined as ASON (with non-ASON trails possibly traversing them)
 8 VC-4s defined as LDL.

TIP: LDL resources are not restricted to ASON traffic. They can be used to run regular
non-ASON traffic provided the non-ASON trails are:
 Bidirectional (defined in both trail directions A-Z and Z-A)
 Symmetric (same number of VC-4s each direction).
The non-ASON trails are also subject to other applicable ASON server trail restrictions, for
example, that concatenated VC-4-4c and VC-4-16c trails cannot run over LDL. See ASON
Provisioning Conditions.
Parent Topic
4.4.3.2.5 Editing an LDL Link

You can modify the properties of an existing LDL.
To modify LDL link properties:

1. From the SDH Layer, right-click the LDL and click Properties. The LDL Properties window opens.
2. Modify the fields as required, and click Update Regions and Advanced Parameters. The LDL
parameters are updated.
Parent Topic

4.4.3.3 Viewing LDL and DLT Trail Information

You can view trails associated with an LDL or DLT trail, or view LDL trail properties.
To view LDL or DLT trail information:

 In the Trail List window Trails pane, right-click the relevant DLT or LDL trail, select Show, and then
choose one of the following options.
Table 4-10: LDL and DLT Show shortcut options
Option Description
Show LDLs Shows the LDL trail associated with a selected DLT trail.
Show DLTs Shows the DLT trails associated with a selected LDL trail.
Show LDL Properties Shows properties of a selected LDL trail.
Parent Topic
4.4.3.3.1 Showing Related DLT Trails

When an LDL trail is selected, Show DLTs shows all underlying DLTs of the selected LDL in a separate Trail
List window. These DLTs represent actual physical paths of the selected LDL.
Figure 4-25: Show DLTs
Parent Topic

4.4.3.3.2 Showing Related LDL Trails

When a DLT trail is selected, Show LDLs shows the associated LDL trail in a separate Trail List window. If
DLTs are selected from different LDLs, all the relevant LDLs are shown, one per selected DLT.
The LDL trail is represented in the map view only by its two endpoints.
Figure 4-26: Show LDLs
Parent Topic
4.4.3.3.3 LDL Properties
To view the properties of an LDL:

 In the Trail List window Trails pane, right-click the relevant and select Show LDL Properties. The Show
Logical Data Link properties window opens (see also Create LDL Link Dialog Box).
LightSoft Link Properties windows regard LDL links in the same way as regular topology links; see Link
Properties.
Figure 4-27: Show LDL Properties
Parent Topic

4.4.3.4 Provisioning Over LDLs

You can provision a regular VC-4 trail over a selected LDL link, using the LDL trail as part of its path. For
example, you can create a regular VC-4 trail with an LDL trail as one server trail, in conjunction with other
physical links.
Regular trails with the following rates may traverse an LDL trail:
 VC-4
 VC-4 VCAT services
 VC-4 server trails
In the provisioning process, the LDL server trail can be selected with or without attached resources (DLT
trails) in the same way as for regular trails. In the Create Trail window:
 Just select the LDL trail to be part of the trail path - resources will be selected automatically.
OR
 Right-click the LDL trail and choose Select Resources. You can then select specific DLT trails as
resources in the Select Resource pane.
For more information, see Creating a Trail.
NOTE: Terminated server trails (TSTs) may begin at an LDL link.
Parent Topic

4.4.3.5 Editing DLT Trails

You can edit the path of a selected DLT trail.
NOTE: The number of resources associated with an LDL cannot be increased or decreased.
However, non-ASON trails can be run on underutilized LDL resources; see Non-LDL Traffic on
an LDL.
To edit a DLT trail path:

1. Right-click a DLT trail in the Trail List window Trails pane and select Edit Highlighted. The Edit Trail
window opens, with only the Endpoints & Path tab enabled.
2. Edit the path in the same way as for regular trails; see Editing Trails.
Parent Topic
4.4.3.6 Deleting LDL Trails

Deleting an LDL link removes the LDL link and trail, and all associated DLT trails.
To delete a single LDL link:

 Right-click the topology link in the map view and select Delete.
To delete a single LDL link from a multilink:

1. Right-click the multilink and select Expand Link.
2. Right-click the required link line and select Delete.
Parent Topic

4.4.4 Link Availability Constraints

The Availability Map and Availability for Links windows, display availability in terms of what can be
provisioned for a selected rate, which may be less than the overall capacity of the SDH link.
Allocated and Available VC-4 Server Trails

The total counts of potentially available low order SDH resources (VC-12, VC-2 and VC-3) are not calculated
based on the overall capacity of the SDH link, but on the number of VC-4 server trails that are both
allocated and accessible:
 Allocated VC-4 trails: Although an STM-16 link can carry 48 VC-3s (3 VC-3s on each of 16 VC-4s), the
following STM-16 link Availability Chart extract shows only 6 VC-3s as possible. This is because only 2
VC-4s are allocated. The total resources are therefore 6 VC-3s (3 VC-3s x 2 VC-4s).
AND
 Accessible VC-4 trails: These are trails that terminate on the segment, making add-and-drop possible,
instead of just passing through. The following STM-16 link Availability Chart extract shows 7 allocated
VC-4s, implying potentially 21 VC-3s. But the VC-3 pie total is only 18. This is because one VC-4 just
passes through the segment and therefore is not counted.
NOTE: The availability statistics are calculated in terms of available capacity within VC-4
server trails. VC-4 service trails are ignored.

Concatenated Trail Availability

Availability for concatenated trail rates (for example VC-4-4c) depends on how preexisting trails are
distributed within the link and the number of available contiguous resources.
The following examples from the Select Resource pane illustrate:
 VC-4 selection (first picture) - four VC-4s are selected on an STM-16 link, leaving 12 unoccupied
resources.
 VC-4-4c selection (second picture) – shows all resources occupied. Since a VC-4-4c trail requires four
contiguous resource grid cells starting at specific offsets, VC-4s preexisting on any of those cells will
block the VC-4-4c trail creation.
Even though there are 12 unoccupied VC-4 resources on the link, if the preexisting VC-4s are distributed on
cells needed for the VC-4-4c creation, availability at the VC-4-4c rate may be less than 3, and possibly nil.
Parent Topic

4.5 Performing Trail Failure Analysis

OPTIONAL FEATURE: Trail Failure Analysis is a fully integrated add-on capability, available on
a cost basis. If not purchased, this feature and related menu commands are unavailable.
LightSoft provides a useful tool for network operators to identify vulnerabilities in network traffic patterns.
Operators can select one or more objects, (such as NEs, ports, cards, links, or SRLGs), and the Failure
Analysis will identify and lists the trails that would potentially be affected if the selected object(s) were to
fail.
The Show Failure Analysis tool is especially useful because:
 It offers a predictive analysis of what might potentially be at risk at some point in the future, based on
the current configuration.
 It includes in this analysis not only the traffic components physically routed through the selected
object, but also the traffic components that have a protective relationship linking them to the traffic
that is physically routed through the selected object.
Limitations:
 Failure Analysis does not support ASON trails.
 When selecting multiple objects, objects must be selected from a single location (either the LightSoft
tree, or the LightSoft map, or the Link List window). Performing Failure Analysis with objects selected
from a mixture of these locations is not supported.
 Trails that do not have a Trail State = OK (e.g., trails that are inconsistent or incomplete), are
automatically defined as potentially affected trails.
NOTE: The number of objects that can be included in a failure analysis is defined per object
type via the NmsClient.ini file preferences. If you select more objects than defined in the
preferences per object type, only a limited number of objects are included in the analysis. A
message is displayed, showing which objects LightSoft is including in the analysis. For more
information contact your local Customer Support representative.
NOTE: Failure Analysis can be accessed from the LightSoft tree, map, or Link List windows as
follows:
 LightSoft Tree: NEs, cards and/or ports.
 LightSoft Map: NEs, Links and SRLGs.
 Link List window: Links, and SRLGs.
From the LightSoft tree, or the Link List window. Right-click one or more object and select
Failure Analysis.

To view failure analysis for one or more objects from the LightSoft Map:
1. In the LightSoft map, press CTRL and select the object(s) that you want to include in the analysis, and
then in the LightSoft ribbon Tools tab, select Failure Analysis.
(If you want to select a single link within a multilink, expand the multilink, and then right-click the link
you want to include.)
Figure 4-28: Show Trail Failure Analysis
2. If you include link(s) that contain SRLGs, a message is displayed:
a. Select either Link or SRLG. If you select SRLG, a list of the ducts associated with the link are
displayed.
b. Select the checkbox for each SRLG you want to include in the analysis and click OK.
The failure analysis is performed. If no trails are affected in the event of a failure, a message is
displayed 'Trail failure analysis found no affected trails'. If there are trails that would be adversely
affected by a failure of the selected object, a Trail List window opens. The Trail List shows potentially
affected trails in the trail list table and in the corresponding trail map.

3. In the Trail List window, select a trail. The affected trail is highlighted on the Trail List map.
Figure 4-29: Two trails potentially at risk if the selected object fails
Parent Topic
4.6 Topology Link Troubleshooting

Parent Topic
4.6.1 MAC Address Problems in Link or Port

MAC Address Problem at a Link
When a link is connected, each endpoint port's MAC address is also recorded in the corresponding port
automatically. If the MAC address changes at one endpoint, the link is not synchronized automatically with
the EMS. The port at the corresponding endpoint can no longer recognize the MAC address. This typically
happens when a module is replaced at an endpoint, but can also indicate a MAC address configuration
failure during the link provisioning. A Next Hop MAC address inconsistency may arise following the
equipment change. In this case:
 The link is colored white in the map view.
 In the Properties for Link window:
 The Consistency State field in the link properties displays the message Inconsistent due to next
hop problem; see the parameter description in Link Properties - General Tab.
 The Reconnect MAC Address icon is enabled. Use this icon to correct the MAC addresses
at the ports and resynchronize the link; see Properties for Link Toolbar.

To resolve a Next Hop inconsistency after equipment is replaced:
 In the Properties for Link window, click Reconnect MAC Address . The Consistency State field will
show Consistent.
(This method avoids having to change the MAC address field manually in the EMS.)
MAC Address Problem at a Port

If you insert a module in a port, whose MAC address does not support the configuration, then in the EMS,
you are informed that the MAC address is not allowed. For example: Port MAC address cannot be
multicast or broadcast.
As a consequence, LightSoft then shows the port as inconsistent with relevant inconsistent reason.
To correct the problem, you must change the physical module
to one that has a valid MAC address. The port will then become consistent again in LightSoft.
Parent Topic
4.6.2 TE Mismatch Problem

TE Mismatch denotes a difference between TE Configuration, CoS, CAC, or EXP system preference
parameters and the corresponding PE or link property parameter values.
Upon creation of a link where both endpoints support EXP mapping (both support E-LSP tunnel mode),
global system parameters are automatically downloaded from the system preferences to the network
MoE/MoT ports at the link endpoints. The link and port properties are therefore aligned with the system
preferences. In particular, specific TE parameters are aligned and the properties TE Mismatch parameter
shows Match, meaning those parameters in the port properties are aligned with the global system
preferences.
NOTE: Authorized users can configure LightSoft system settings for network-wide features
such as general TE, CoS, CAC, and EXP mapping preferences. System preferences can only be
set by a system administrator and are applied to all server clients. See MPLS TE Configuration

Exception: EXP mapping values are not downloaded if a port's EXP mapping table already contains values.
The link creation will introduce values only if the table is completely empty. This is because tunnels may
already be configured on the port at the EMS level, and overwriting existing values would be traffic
affecting. In this case, other parameters are downloaded and accepted to the EMS as usual, and the TE
Mismatch parameter shows Match. However, the link will show an inconsistency (NMS-EMS Mismatch),
indicating that the values of NMS and EMS objects are not the same.
Once a link exists, a mismatch of parameter values between the preferences and the link properties can
occur for various reasons, both intended and unintended.
The TE Mismatch reasons are listed in the link and port properties; see parameter description in Link
Properties - Advanced Tab , or LE Properties - MPLS PE LE Properties.
The Download TE parameters to EMS icon downloads the TE configuration of the PE or the link
endpoint ports to the EMS. For details about how to use this icon, see Download TE Parameters to EMS
Icon.
The following TE mismatch situations may arise:
 User Defined Mismatch
 Resolving TE Mismatches
 Change in EMS Accepted by LightSoft
 Change in EMS Rejected by LightSoft
 TE Mismatch Reasons for PE or Link
Parent Topic

4.6.2.1 User Defined Mismatch

You may need to manually assign different TE Configuration, CoS, CAC, or EXP parameter value to a link to
accommodate specific equipment support limitations (PEs within a ring may be subject to EXP value
constraints - certain equipment may support 5 EXP Mapping entries while the system default is 8).
To change specific property values:

1. Edit the value in the relevant properties window tab as required.
2. Click Apply to apply it in the properties and download it to the EMS.

The Advanced tab TE Mismatch field shows User Defined Mismatch, which informs that the
properties differ from the system preferences. No further user action is needed.
NOTE: Both panes of the EXP table must have the same configuration. If the panes have
different values, an EXP Mapping Table Mismatch would result between the endpoints.
Parent Topic

4.6.2.2 Resolving TE Mismatches

You may need to change system preference default values (for example, an EXP Mapping value) for all new
links. In this case, existing link properties retain their old values and will no longer be aligned with the
system preference values.
To resolve TE mismatches:
1. Change the system preferences as needed. (See Configuring User and System Preferences in the
Getting Started & Administration Guide.)
A message appears in the system preferences alerting you that some ports may have incorrect values,
and directing you to make corrections within the relevant Properties windows if needed.
If CoS parameters are changed while PEs exist in LightSoft, you will be prompted that the TE
Mismatch attribute of PEs may not be updated. You should do this using the Properties for LE window
or LE List window.
2. Visit the affected properties window via the LE list, Link list, or TE properties or link properties, and
check the TE mismatch field values.
At this point, the TE Mismatch field still shows Match - it has not yet changed. (It may also show User
Defined Mismatch because of a previous manual change to the property.) However, the Download
TE parameters to EMS icon is enabled, thereby alerting you of a possible additional mismatch
problem in that window.
3. You can do one of the following two things:
 Accept the current property value: Click Download TE parameters to EMS in the
Properties tab to download the current link or PE parameters to the EMS, and make them
permanent. The TE Mismatch field will show User Defined Mismatch.
OR
 Accept the Preference values. To download the preference values to the properties and to the
EMS, in the Properties tab, click Default and then click Apply. The TE Mismatch field is updated
to Match.
Parent Topic

4.6.2.3 Change in EMS Accepted by LightSoft

A change in properties is sometimes initiated from the EMS (called Attribute Value Change, or AVC). If the
change is considered legal by LightSoft, it is automatically uploaded to the LightSoft properties. The
properties thereby differ from the system preferences. However, in general, no further user intervention is
needed, unless you wish to reinstate the value in LightSoft.
NOTE: The AVC may be rejected by LightSoft if the specific CoS in LightSoft has tunnels. In this
case, the link will be Inconsistent. For more details, see Change in EMS Rejected by LightSoft.
To cancel a legal change from the EMS:

1. Visit the affected properties window via the LE list, Link list, or TE properties or link properties, and
check the TE mismatch field values. No warning appears that you should do this (as in a preferences
change).
At this point, the TE Mismatch field still shows Match - it has not yet changed. (It may also show User
Defined Mismatch because of a previous manual change to the property.)
2. Reinstate the Preference values.
 Click Default in the Properties tab to download values from preferences. OR
 Click Apply to save the values and download them to the EMS.
The TE Mismatch field will show Match.
Parent Topic
4.6.2.4 Change in EMS Rejected by LightSoft

Changes may be performed in the EMS which are not considered legal by LightSoft. For example, EXP
Mapping values can be changed via the EMS even while tunnels are defined on the specific CoS. Upon
upload, the EXP value change will be rejected. Hence the EMS and LightSoft will have different EXP
Mapping values. The Properties Consistency State parameter will have the value NMS/EMS Inconsistency
Reason.
The TE Mismatch parameter is unaffected, remaining Match, since there is currently no difference between
the properties and system preferences. (NMS/EMS Mismatch concerns the Consistency state, inconsistency
between the EMS and NMS, while TE mismatch refers to a difference between the PE and system
preference.)
To reject the illegal change from the EMS:
 Click Download TE parameters to EMS . It is enabled when the Consistency State is NMS/EMS
Inconsistency Reason. This will override the changes in the EMS, sending the current (old) LightSoft
object property value (not the system preference values) to the EMS.
Parent Topic

4.6.2.5 Download TE Parameters to EMS Icon
Click Download TE parameters to EMS to download the TE configuration of the PE or the link
endpoint ports to the EMS. It is available in the following windows:
 Properties for PE; see Viewing/Editing LE Properties.
 Properties for Link; see Properties for Link Toolbar.
The icon is enabled when:
1. The TE Mismatch value of the PE or link is:
a. Match, but the PE or link properties configuration does not equal the System Preferences values.
(When System Preferences values are changed, the PE or link is not updated automatically.) )
b. In this case you can:
 Click Download TE parameters to EMS . The TE Mismatch value becomes User

Defined Mismatch.
OR
 Click Default and Apply. The TE Mismatch value becomes Match (and the icon is
disabled).
OR
c. User defined mismatch, but the PE or link configuration equals System Preferences values. (When
System preferences values are changed, the PE or link is not updated automatically).
OR
2. The PE or link is inconsistent with the reason NMS-EMS mismatch (LightSoft and EMS values are not
equal).
Parent Topic
4.7 Maintenance Operations on Links

Maintenance operations (for example, loopbacks, AIS, and RDI) enable you to diagnose network problems.
You can perform these operations on specific ports and termination points used in trails and topology links
managed by LightSoft. These operations are performed in the Maintenance Operations window.
For operational instructions, see Maintenance Operations.
Parent Topic

4.8 Automatic Link Adaptation

Some NEs support automatic link and trail adaptation following port rate upgrade. When two STM-1 ports
are connected by an STM-1 link, if one port is reassigned in the EMS to STM-4, that port and the link initially
become inconsistent. After you change the other endpoint port to STM-4, the first port and the link
become consistent again and no further user intervention is required. LightSoft automatically performs the
corresponding link infrastructure changes - existing links are automatically upgraded to STM-4, existing
trails are automatically "moved" to the upgraded links, and internal resource maps are automatically
upgraded to reflect the STM-4 rate.
Parent Topic
4.9 Changing Ports and Links between

Non-Colored and Colored
You can reassign SDH ports and links to service optical trails, for example, in order to extend the usage of
existing equipment. Similarly, optical ports and links can be reassigned to service SDH trails.
NOTE: A “_c” (with underscore) suffix after an SDH rate (e.g. STM-16_c) denotes a colored
(optical) rate. This should not be confused with the “c” (no underscore) suffix (e.g. VC-4-4c)
which denotes concatenated contiguous signals.
To convert SDH ports and links to accommodate OCH trails:

1. Reassign ports to be colored:
Reassign SDH STM-16 or STM-64 ports in the EMS to an optical module; for details see the EMS User
Guide). The non-colored ports in LightSoft are automatically converted to colored with the optical
rate STM-16_c or STM-64_c, enabling them to serve as an endpoint for OCH trails.
Similarly, reassigning colored ports to non-colored in the EMS enables them to serve as endpoints to
high order or LP-STM trails.
Any links connected to the ports remain consistent throughout the process.
2. Ensure that links are connected to suitable ports:
For a link to function as colored (in OTN layer), both connecting ports must be colored.
For a link to function as non-colored (in SDH layer), one or both connecting ports must be
non-colored.
3. Reassign links to be colored:
If a link required for OCH trail purposes was originally created as SDH, it must be redefined as a
colored link. This is done by changing the links’ Associated Layer parameter in the Link Properties
window Advanced tab to OTN; see Link Properties - Advanced Tab. The link would then be considered
to have a colored rate (for example, STM-16_c) suitable as a server for an OCH trail.
Similarly, a link required for high order trail purposes that was originally created as optical must be
redefined as non-colored by changing its Associated Layer parameter to SDH.

NOTE: If the link required for optical purposes is already used by high order trails, then the
redefinition is not allowed. You must first remove the high order trails. Similarly, before a link
can be redefined for high order purposes, any OCH trails traversing it must be removed.
4. You can then define trails using the LightSoft Create Trail window, as follows:
 Colored links in the OTN layer can function as servers for OCH trails.
 Colored link in the SDH layer can function as servers for high order trails.
 Non-colored links in the SDH layer can function as servers for high order trails.
Parent Topic
4.10 Managing MS-SPRing Rings

Parent Topic
4.10.1 Understanding MS-SPRing Rings

MS-SPRing is a protection scheme in which the total traffic capacity in a multiplex section (MS) is divided
equally between working and protection channels. Working channels carry the active traffic signals while
protection channels are reserved for protection of the working channels. In case of a failure on the working
channels, traffic is switched to the protection channels. Once the problem has been resolved, traffic reverts
back to the working channels. MS-SPRing offers a cost-efficient means of protecting traffic in large network
configurations that include, for example, a large hub ME linked to many low-cost access NEs.
LightSoft offers users the option of creating MS-SPRing rings in which all nodes are managed by the same
EMS, or rings that cross EMS boundaries. The EMSs may be of different types, such as a mixture of
EMS-MPT and EMS-APT. MS-SPRing topologies that include only nodes from a single EMS may be managed
at the EMS level or at the NMS level. MS-SPRing topologies that include nodes from more than one EMS
must be provisioned at the NMS level since their member nodes cross EMS boundaries. Subsequent
management tasks could be completed at the EMS level, but that approach is inefficient since the same
task would have to be repeated in each of the participating EMSs. It is much more efficient to simply
continue to manage the ring at the NMS level, since a single command in LightSoft is completed
automatically within each of the participating EMSs.

The following figure displays a network that includes two different EMS regions. Traffic here is protected by
a combination of three different MS-SPRing rings. Two of the rings (green and orange) are limited to
members of a single EMS, while the third ring (blue) includes nodes from both EMSs. Note that network
nodes participate in more than one MS-SPRing ring.
Figure 4-30: Example of three MS-SPRing rings in a network
An MS-SPRing ring can include up to 16 nodes. The MS-SPRing windows list the nodes participating in a
selected MS-SPRing ring. Each MS-SPRing ring is identified by a unique NMS Ring ID number that is used by
the EMSs as well.
Users are able to:
 Create MS-SPRing rings
 Edit MS-SPRing rings attributes, including:
 Ring label
 Wait to Restore (WTR) time
 List of non-preemptible unprotected extra traffic (NUT) channels
 Repair MS-SPRing rings
 Activate MS-SPRing rings
 Deactivate MS-SPRing rings
 Delete MS-SPRing rings
 Export MS-SPRing data to CSV files
Parent Topic
4.10.2 Creating an MS-SPRing Ring

This section describes the steps required to create and configure an MS-SPRing protection ring. Creating a
new MS-SPRing ring is simple; one by one, select the links that will constitute the new ring. Work in order,
starting with the first link and then selecting the next link in turn so that a continuous path of links is
created. The last link selected connects back to the end of the first link selected, creating a ring. By default,
the node that connects the first link selected to the last link is assigned index number 0 and serves as the
virtual starting point for that ring.
The MS-SPRing management windows and fields used when creating and listing MS-SPRing rings are
described in detail in MS-SPRing Management Window Fields and MS-SPRing Properties and Operations.

Prerequisites
 An MS-SPRing ring can only be configured over existing physical links. Physical links between
compatible (STM-16/STM-64) ports must have already been created and configured before an
MS-SPRing ring can be created using those links.
TIP: If you realize that essential topology links are missing while you are in the middle of
creating a new MS-SPRing ring, LightSoft offers the convenient option of creating the missing
topology links directly from the Map View pane in the Create MS-SPRing window. Simply click
Create Topology Link in the main LightSoft toolbar and create the missing topology links as
needed. You can then finish creating the new MS-SPRing ring.
 MS-SPRing rings must be created using nodes from a single VPN. Users should be careful, if they
reassign nodes, to ensure that all nodes participating in an MS-SPRing ring remain members of the
same VPN. Otherwise it will be impossible to work with that ring because the user will only see a
partial ring. The nodes to which the user does not have access permission will not appear.
 MS-SPRing rings cannot be configured together with trails using TSI resources. If the user must work
with TSI-resource trails, the only option is to:
 Create a new MS-SPRing ring (or use one that is currently configured over the appropriate
topology).
 Configure the NUT channels for the new ring.
 Define new trails using TSI resources as needed over NUT channels.
 MS-SPRing ring maintenance is completed at the EMS level.
Creating an MS-SPRing Ring
To create an MS-SPRing ring:

1. In the main window Topology tab, in the Create group, click MS-SPRing. The Create MS-SPRing dialog
box opens; see MS-SPRing Management Window Fields.
2. In the Map View pane, select the first link in the ring. The selected link is highlighted in the map and
the Select Link with Direction window opens.
Note: If the link is part of a multilink, the Select Link window lists all the member links. Choose a
specific link from the list.

3. To select the ring direction, click the arrow next to the link endpoint that will serve as the new ring's
starting point.
The arrow is highlighted and LightSoft automatically fills in the node parameter values in the Node
List pane, based on the link attributes and ring direction.
NOTE: Since each link includes two endpoints, each new link selection adds information to
two rows in the Node List pane. Endpoint data is completed in a staggered fashion, with each
subsequent link selection adding information about an endpoint of the previous link selection.
All the endpoint data in each row is not filled in completely until you have selected the final
link in the list, thereby closing the new ring by connecting back to the first link selected. At
that point, information is completed for the endpoint connecting the first and last links.
4. In the Map View pane, click the next link in the ring, continuing in the direction selected in the
previous step. The previous Select Link window closes automatically and a new Select Link window
opens. Click on link in the window to select that link. LightSoft automatically fills in the node
parameter values in the Node List pane, based on the link attributes and ring direction.
TIP: When the Select Link window is open:

 If you click the next MS-SPRing link in the map, a new Select Link window opens,
identifying the link you just selected. The link endpoints are added to the Node List pane.
 If you click anywhere else in the map, the open Select Link window closes.
5. Continue to click on links in the Map View pane, selecting links in a continuous path around the ring
until the ring is completed. The last link selected should connect back to the first node at the end of
the first link selected.
NOTE: If you select an inappropriate link, LightSoft provides an informative error message
explaining why the link selection cannot be used.
6. In the Label field, enter a meaningful string identifying the new MS-SPRing ring. If you do not enter a
label, LightSoft assigns a default label value that combines the literal word Ring with the time the ring
was created (Ring_creation-time).
7. In the WTR field, select an appropriate Wait to Restore (WTR) value, in seconds, from the spin box.
After the network switches to protection mode, WTR configures the minimum amount of time that
must elapse before returning to (the repaired) regular traffic path. (Default 300 sec, listed in
60-second increments.)
8. In the NUT Channels field, specify which channels (if any) should be reserved for non-preemptible
unprotected traffic (NUT). The maximum number of channels depends on the rate supported, STM-16
or STM-64. Click Select NUT Channels at the side of this field to open a window displaying channel
assignments in a matrix format, indicating which channels are classified as working (W), protecting
(P), or NUT (N), and adjust the selections appropriately for this ring.

9. Click Apply to create the new MS-SPRing ring.

The ring creation process begins. LightSoft automatically fills in the ring parameter values as the new
ring is created.
At this point LightSoft completes a series of validation checks. If the new configuration is valid,
LightSoft creates the new ring. Note that creating a new MS-SPRing ring is not traffic-affecting.
10. By default MS-SPRing rings are created in an inconsistent state that requires table updates. A
message window opens, informing the user that two more steps are required before MS-SPRing
protection can be implemented. Click Calculate to complete the ring creation process. This may
take some time. At the end of the process the ring state is consistent and ready to be activated.
11. By default MS-SPRing rings are created in a disabled state. Click Activate to enable the selected
MS-SPRing protection scheme.
Note: Rings can also be recalculated and activated through the MS-SPRing List window. An advantage
of activating rings through the MS-SPRing List window is that multiple rings can be selected and
recalculated or activated at one time.
12. If the new configuration is not valid, an error message is displayed. The Ring State Reasons pane
identifies the nodes involved in the ring validation failure and lists the reasons for the failure.
13. To configure a new ring, click Clear to clear the links selections in the Map View pane and start
over.
Parent Topic

4.10.3 Editing MS-SPRing Ring Attributes

This section describes how to edit MS-SPRing ring attribute settings.
To edit MS-SPRing ring attributes:

1. In the main window Topology tab, in the Lists group, click MS-SPRing List. The MS-SPRing List
window opens; see MS-SPRing Management Window Fields.
2. The Ring List pane lists the full set, or a selected or filtered subset, of MS-SPRing rings configured for
this network, including their key attributes. Select one MS-SPRing ring in the list. LightSoft
automatically fills in the ring attribute values in the Parameters pane.
3. Click Edit Attributes at the top of the Parameters pane to edit any of the following individual
attribute fields.
 In the Label field, edit the string identifying the MS-SPRing ring.
 In the WTR field, click the spin box arrows at the side of the field to reset the Wait to Restore
(WTR) value.
Note: LightSoft lists WTR values in 60-second increments. If an MS-SPRing ring was created at
the EMS level and uploaded to LightSoft, the initial WTR value may not be an exact multiple of
60, since the value could have been set otherwise at the EMS level. However, if you are editing
the WTR value in LightSoft, you must select one of the preset values in increments of 60.
 In the NUT Channels field, specify which channels (if any) should be reserved for
non-preemptible unprotected traffic (NUT). The maximum number of channels depends on the
rate supported, STM-16 or STM-64. Click Select NUT Channels at the side of this field to open a
window displaying channel assignments in a matrix format, indicating which channels are
classified as working (W), protecting (P), or NUT (N), and adjust the selections appropriately for
this ring.
4. Click Save Attributes to save the new attribute values for the selected MS-SPRing ring.
5. Changes to MS-SPRing ring attribute values may lead to inconsistencies in the ring and node
configurations at the NMS and EMS levels. One of the following conditions may occur:
 An error may be listed in the Ring State field. The Ring State Reasons pane identifies the nodes
involved in the failure and lists the reasons for the failure. Check the reason and correct the
error condition accordingly.
 Changes that trigger a trail inconsistency are indicated by a TCI icon in the LightSoft main
window. These inconsistencies can be cleared through the standard synchronization
procedures, described in Performing Trail Synchronization.
 If you have made changes to the NUT channel assignments, click Repair to complete the
attribute editing process.
Parent Topic

4.10.4 Editing the MS-SPRing Ring Topology

This section describes the steps needed to edit MS-SPRing ring topologies by inserting or removing MEs.
Note that MS-SPRing ring topologies cannot be edited at the NMS level. To add or remove MEs from an
MS-SPRing ring configuration, you must edit the ring at the EMS level, with associated steps completed at
the NMS level in LightSoft. For convenience, the necessary steps are described here.
NOTE: Since MS-SPRing rings can only be edited at the EMS level, rings that span multiple
EMSs cannot be edited. If you wish to make changes to the topology of an MS-SPRing ring that
includes nodes from more than one EMS, you must delete the original ring and recreate it
using the appropriate set of nodes.
To add an ME to an active MS-SPRing ring topology:

1. Temporarily divert traffic from the link to which you wish to add an ME node. At the EMS level, apply
EMS Force switch actions on the ports of the nodes adjacent to the target link, to switch traffic off the
link before inserting the ME.
2. Add a new node to the MS-SPRing ring at the EMS level. See the appropriate EMS User Guide for
specific instructions.
3. Insert the new ME into the appropriate link at the NMS level, as described in Inserting Elements in
SDH Links.
4. In the main LightSoft window Topology tab, in the Lists group, click MS-SPRing List.
5. Click Repair to update and synchronize the ring topology and configuration.
6. Restore traffic to the newly-updated link by removing the Forced Switch settings at the EMS level.
To remove an ME from an active MS-SPRing ring topology:

1. Temporarily divert traffic from the links from which you wish to remove an ME node. At the EMS
level, apply EMS Force switch actions on the ports of the nodes adjacent to the target node, to switch
traffic off those links before removing the ME.
2. Remove the ME from the links at the NMS level, as described in Removing an Element from a Link.
3. Remove the node from the MS-SPRing ring at the EMS level. See the appropriate EMS User Guide for
specific instructions.
4. In the main LightSoft window Topology tab, in the Lists group, click MS-SPRing List.
5. Click Repair to update and synchronize the ring topology and configuration.
6. Restore traffic to the newly-updated link by removing the Forced Switch setting at the EMS level.
Parent Topic

4.10.5 Deactivating or Deleting an MS-SPRing Ring

This section describes how to deactivate or delete MS-SPRing rings.
To deactivate an MS-SPRing ring:

1. In the main window Topology tab, in the Lists group, click MS-SPRing List. The MS-SPRing List dialog
this network, including their key attributes. Select one MS-SPRing ring from the list. LightSoft
automatically fills in the ring parameters in the Parameters pane.
3. Click Deactivate to deactivate the selected ring.
To delete an MS-SPRing ring:

1. In the main window Topology tab, in the Lists group, click MS-SPRing List. The MS-SPRing List dialog
this network, including their key attributes. Select one MS-SPRing ring from the list. LightSoft
automatically fills in the ring parameters in the Parameters pane.
3. Click Delete to delete the selected ring. You are not allowed to delete an active ring; the ring
must first be deactivated.
Parent Topic

4.10.6 MS-SPRing Management Window Fields

The MS-SPRing windows provide a graphical representation of all or preselected nodes in the SDH topology
layer, as well as information and configuration panes.
The MS-SPRing List window in the following figure lists all STM-16 MS-SPRing rings that have been
configured for the network. Select an MS-SPRing entry in the list to highlight that ring's component objects
and properties.
Figure 4-31: MS-SPRing List window
The Create MS-SPRing window is very similar to the MS-SPRing List window, with fields that are used to
create an MS-SPRing ring.
NOTE: MS-SPRing rings are managed through a set of windows used to create, list, and edit
MS-SPRing topology elements. Most of the fields in these windows are the same; they are
therefore all being described within this topic. Not every field listed here is found in each
MS-SPRing window.

The MS-SPRing windows include the following panes:

 Map View pane: Graphical representation of selected network objects (elements and links) in the SDH
topology layer. Right-click an LE in the Map View for a convenient shortcut menu of MS-SPRing
operations.
When the user opens the MS-SPRing List window, the objects displayed in the Map View pane may
vary, depending on the user preferences that were configured (MS-SPRing Preferences). Options
include:
 If the user opens the MS-SPRing window with no topology objects selected, the Map View pane
(depending on the user preferences) either displays the complete network topology or displays
only objects relevant for MS-SPRing rings in the network. The Ring List pane lists all the
MS-SPRing rings currently defined in the network
 If the user opens the MS-SPRing window with specific network objects selected, the Map View
pane displays only the selected objects. The Ring List pane lists only the MS-SPRing rings
associated with the selected objects.
 If the user clicks on one of the links in the Map View pane, all objects that belong to whatever
MS-SPRing rings that link participates in are 'filled in' and displayed in the Map View pane.
Depending on user preferences, other Map View objects not participating in the selected link's
rings may continue to be displayed or may be hidden.
 If the user selects an MS-SPRing ring in the Ring List pane, all objects that belong to the selected
ring are 'filled in' and displayed in the Map View pane. Depending on user preferences, other
Map View objects not participating in the selected ring may continue to be displayed or may be
hidden.
 Ring List pane: Lists the full set, or a selected or filtered subset, of MS-SPRing rings configured for this
network, including their key attributes.
An information ribbon at the bottom of this pane indicates the total number of all MS-SPRing rings in
the network as well as the number of filtered rings displayed and the number of rings currently
selected by the user.
Select one or more MS-SPRing entries in the list by checking the entry's checkbox. Highlight one of the
MS-SPRing entries in the list and the corresponding objects are highlighted in the Map View pane,
with the relevant object properties listed in the other window panes. (Appears in MS-SPRing List
window only.)
Figure 4-32: MS-SPRing ring list pane
 Parameters pane: Detailed information about the MS-SPRing ring highlighted in the Ring List pane.
Parameter fields are explained in detail in MS-SPRing Properties and Operations.

In the MS-SPRing List window, these fields are all read-only.

Figure 4-33: MS-SPRing Parameters pane
In the Create MS-SPRing window, the user defines a meaningful label for the new MS-SPRing ring and
configures WTR and NUT Channel values. These fields can also be edited through the MS-SPRing List
window. The rate is determined by the links that the user selects, either STM-16 or STM-64,
depending on the link capacity. The other fields are set automatically by LightSoft. See MS-SPRing
Properties and Operations for a detailed description of each field.
 Node List pane: Lists the nodes participating in the selected MS-SPRing ring with their key attributes,
including the node's index and ID numbers, LE name, and MS-West/MS-East ports. Node List columns
can be sorted, moved, resized, and hidden, as in most LightSoft parameter list tables.
A node's index number identifies its location in the ring. To provide a common orientation, the
null-index node (Node 0) is always used as a 'virtual starting point' in the ring, with subsequent nodes
numbered sequentially from 0.
The following figure displays a Node List pane for a ring with three nodes. Since this is from the
MS-SPRing List window, these fields are all read-only.
Figure 4-34: MS-SPRing node list pane (2)

 Toolbar/Context Menus: Convenient set of toolbar buttons and right-click menu options for
MS-SPRing operations. MS-SPRing management windows provide the following toolbar options.
Table 4-11: MS-SPRing management window toolbars

MS-SPRing List window
Show Trails Show trails associated with selected MS-SPRing.
Show Links Show links associated with selected MS-SPRing.
Activate Activate selected MS-SPRing ring(s), enabling MS-SPRing protection
scheme.
Note: Multiple MS-SPRing rings can be selected and activated at once.
LightSoft only activates rings that are in a valid ring state (complete,
consistent, or mixed-active).
Deactivate Deactivate selected MS-SPRing ring(s), disabling MS-SPRing protection
scheme.
Repair Calculate and/or repair selected MS-SPRing ring.
Export Export selected MS-SPRing ring(s) configuration to CSV format.
Print Print selected MS-SPRing ring(s).
Delete Delete selected MS-SPRing ring(s).
Select All Select all MS-SPRing rings.
Clear All Unselect all MS-SPRing rings.
Refresh Refresh MS-SPRing list.
Hide/ Alternately hides or shows the left-side details panes, leaving only the Ring
Show List and Map View panes.
Maximize/ Alternately maximizes and minimizes the Map View pane.
Minimize
Filter selector Enable selection of a predefined or user defined view filter. Options
include:
 All rings
 No rings
 STM-16 rings
 STM-64 rings
 Temporary: Subset of rings relevant for selected objects
Default Filter Sets the selected filter as the default; see Applying a Filter and Setting It as
Default.
Help Open context sensitive help page
Save Attributes Save current parameter values for this MS-SPRing ring.
Edit Attributes Edit current parameter values for this MS-SPRing ring.


Select NUT Select channels to be designated as Working (W), Protecting (P), or
Channels non-preemptible unprotected traffic (NUT).
Create MS-SPRing window

Clear Clear all selections in the Map View pane.
Apply Configure and create the new MS-SPRing ring.
Activate Activate selected MS-SPRing ring(s), enabling MS-SPRing protection

scheme.
Deactivate Deactivate selected MS-SPRing ring(s), disabling MS-SPRing protection
scheme.
Calculate Calculate and/or repair selected MS-SPRing ring.
Hide/ Alternately hides or shows the left-side details panes, leaving only the Ring
Show List and Map View panes.
Select NUT Select the NUT channels for this MS-SPRing ring.
Channels
Help Open context sensitive help page
Parent Topic
4.10.7 MS-SPRing Properties and Operations
NOTE: MS-SPRing rings are managed through a set of windows used to create, edit, and list
MS-SPRing ring elements. Most of the fields in these windows are the same; they are
therefore all being described within this topic. Not every field listed here is found in each
MS-SPRing window.

Table 4-12: MS-SPRing ring parameter fields
Field Description
Basic MS-SPRing Parameters
ID Unique MS-SPRing NMS Ring ID number assigned automatically by

LightSoft that also indicates the EMS(s) managing that MS-SPRing ring.
Label User defined label string, up to 32 characters.
Rate Rates supported by this ring. Values may include:
 STM-16
 STM-64
Type 2-Fiber type only.
Revertive Mode Revertive mode only.
WTR Wait to Restore value, in seconds. After the network switches to protection
mode, WTR configures the minimum amount of time that must elapse
before returning to (the repaired) regular traffic path. Default 300 sec.
NUT Channels List of numbers indicating which channels are reserved for
non-preemptible unprotected traffic (NUT). Maximum number of channels
depends on the rate supported, STM-16 or STM-64.
In the Create MS-SPRing window, clicking Select NUT Channels at the side
of this field opens a window displaying channel assignments in a matrix
format, indicating which channels are classified as working (W), protecting
(P), or NUT (N).
States
Active State Indicates if this MS-SPRing protection was activated. Values include:
 Enable (all participating nodes enabled)
 Disable (all participating nodes disabled)
 Mixed (participating nodes include a mix of states)

Field Description
Agg. Maint State Represents the aggregate maintenance (protection switch) states of all the
nodes participating in the MS-SPRing. Values include:
 Yes
 No
Ring State The current status of this MS-SPRing. Values include:
 None
 OK
 Incomplete
 Inconsistent
Ring State Reason String identifying the reason for the current ring state. If relevant, identifies
specific problematic nodes, when known.
General Parameters
Creation Time Date and time this MS-SPRing ring was created.
Modification Time Date and time this MS-SPRing ring was last modified.
Created By Indicates if this MS-SPRing ring was originally created at the NMS or EMS
level.
Node List
Index Uniquely identifies the node location in the ring. Values may range from
0 to 15, where 0 represents the 'virtual starting point' in the ring.
ID Unique node ID number assigned automatically by LightSoft.
LE name Name of the ME on which this node is located.
MS-West P2P MS port used by this node in the West direction. Configured and
editable by user.
MS-East P2P MS port used by this node in the East direction. Configured and
editable by user.
Active State Indicates if this node was activated. Values include:
 Enable
 Disable

Field Description
Maint Active Indicates if a maintenance (protection switch) operation is active for this
node. Values include:
 Yes
 No
Parent Topic
4.11 Creating Link Windows

The following section describes the attributes in the Create Link windows.
Parent Topic
4.11.1 Create Topology Link Dialog Box

This section describes the Create Topology Link dialog box, used to create topology and internal links; see
Creating Topology Links. The dialog box shows the details of slots and ports of two selected objects (MEs,
LEs, UMEs, or groups). If only one object is selected, for example a single ME/LE for an internal link, the two
panes would both show details of the same object.
Figure 4-35: Create Topology Link dialog box
By default, an endpoint is bidirectional. A unidirectional endpoint is indicated in the tree with a or

icon, depending on whether it is a transmit or receive endpoint. A bidirectional endpoint has no
indication.
Ports on which a link is already defined, or which are otherwise inappropriate for the link being configured,
cannot serve as endpoints. LightSoft indicates that these ports are unavailable for selection through use of
a grayed-out icon .

Some circumstances would cause a port to be disabled and unavailable for selection as an endpoint.
(Clicking on the port shows the reason in the Status field). For details, see Endpoint Selection for Links.
The following are some circumstances that may cause a Warning or Failure:
 Protection group incompatibility; see Protection Group Object (PGO).
 Forward Error Correction (FEC) incompatibility; see Forward Error Correction (FEC) in OCH Trail
Endpoint Validations.
 Frequency (Channel) incompatibility; see Channels.
Table 4-13: Create Topology Link dialog box fields
Field Description
Select Type Select a type of port. This is a filter for the rates. It can be selected
and changed as required, and opens with the last selected rate type.
If you select only MEs as endpoints, you can select a rate which then
filters out the ports that are not of the selected rate.
Label Name of the link; by default, a concatenation of the two port names.
Can be changed as required.
Build VC-4 Server Trail When selected, VC-4 server trails are automatically built. Used only
in very specific cases.
Status Shows information about the selected ports. For example, in the link
creation process, the connection state of ports will change. As this
occurs, the message "One of the selected ports was updated: (port
name)" is indicated.
This field also shows why ports cannot be connected. For details, see
Endpoint Selection for Links.
Progress bar Indicates that processing is in progress. While this is happening,
Close is disabled. Note that unrelated LightSoft operations may be
performed concurrently.
The following toggle settings are available in the dialog box View and Settings menus. They are used to turn
information about endpoints on or off in the tree views, or to display the selected rate the next time the
window is opened.
Table 4-14: Hide/Show toggle settings in Create Topology Link dialog box

View
Show Rate Displays the rate of the port.
Show Band Displays the band used by the port. Applies to OTN multiplex section
ports only.
Show Protection Group Indicates whether the port is defined as the parent of a protection
group, for example, MS-SPRing or LAG.
Show Frequency Shows the current tuned frequency of an optical port.


Show Usage Shows the type of the port and layer, as in this example.
The values are based on:

 Interface Type (I-NNI, E-NNI, UNI)
 Ethernet Port Type (ETY/MoT/MoE)
 Supported Tunnels (L, E, S, LE, ES, LS, LES, N/A); see Tunnel
Mode.
Settings
Save Last Selected Rate Saves the rate last used. This rate will be used when the window is
opened again.
Parent Topic
4.11.2 Create Topology Link Advanced Attributes
To display advanced attributes:

 From the Create Topology Link dialog box, select the endpoints and click More. The window expands
to display additional link attributes. For optical links an additional tab is displayed.

Table 4-15: Create Topology Link dialog box
General Tab
Technology Layer Technology layer of the link. Read only for all port types. A rare exception
is when a selected port exists in more than one technology layer, in which
case you must select the technology layer.
Media Type The media type of the selected ports: Electrical, Fiber, or Virtual. (Read
only)
Media Subtype Displays a list of subtypes, related to the selected media type. You can also
enter your own text.
Ring Name Name of the ring associated with this link. It can be assigned manually in
this field when the link is created, or modified later via the link properties.
It may also subsequently be system-assigned if MS-SPRing protection
applies; see Managing MS-SPRing Rings. See Link Properties - General Tab.
The following ring management functions are available:
 Show Ring to identify all links that share the same ring name.
 Expand Ring in New View to identify links that share the same ring
name in a separate map view.
 Show Trails of Ring to identify trails associated with links that share
the same ring name.
See the option descriptions in Viewing Topology Link Information.
Note: These functions are case sensitive on the ring name. Only exactly
matching ring names are considered as shared.
Length (km/mile) The length of the link in kilometers or miles. When assigned, this value is
used for path searching optimization to determine the shortest path. If
connectivity type is internal, value is fixed at 0.
Protection Type of link protection, for example, MS-SPRing, MS, external protection,
or unprotected. If external protection is used, specify the type.
SRLG (Ducts) Shared Risk Link Group. Scrollable entry fields allow you to specify the
shared resources for the link. The PathFinder algorithm uses this
information when calculating diversity paths; see Shared Risk Link Groups
(SRLGs).
User-defined SRLGs can be added or removed in the link's properties; see
Link Properties.
S-VLAN Registration checkbox (ETY I-NNI links only) Automatically adds the S-VLAN registration to the link
as part of the ETY link creation process and downloads it automatically to
each existing service in the PB network for service discrimination
purposes. See Distinguishing Between Services.
RSTP must be enabled at both endpoints. The link ports are automatically
added to the relevant VSIs.
An existing ETY link can also be S-VLAN registered through a Link List
window option. See S-VLAN Registration from a Link or Trail.
Performing S-VLAN registration at the link level avoids having to S-VLAN
register each network service individually. See Automatic S-VLAN
Registration.

Assigned Cost Enter a value for the cost based on your local evaluations of cost on a
(1-1000) nondenominational scale of 1-1000. A low number indicates a less
expensive link. When using the Cost constraint, this value is used for
optimizing trails; the system selects the least expensive links for the trail.
Quality Select the quality of the link, from 1 (best quality) to 5 (worst quality).
(Best 1..5 Worst) When the Quality constraint is selected, this value is used for optimizing
trails.
Dispersion (ps*nm/km) Dispersion rate in ps/nm. User-entered value, not calculated.
Span Loss (dB) Span loss in decibels. User-entered value, not calculated.
Comment Free-text for entering information about the link.
Path Trace Configuration Available only for an SDH link when both endpoints support J0 handling
and you are creating a SDH link.
Enables you to set the J0 values of endpoints of a physical connection.
For more information, see Path Trace Configuration Dialog Box.
Optics Tab
Fiber Loss Amount of signal loss for this link, for traffic running in the A-Z (forward)
for A to Z (dB) direction. Possible values = 0-100; default =0; resolution = ±0.1
Fiber Loss for Z to A (dB) Amount of signal loss for this link, for traffic running in the Z-A (reverse)
direction. Possible values= 0-100; default =0; resolution = ±0.1
N/A for unidirectional links.
Allowed Fiber Loss Margin Sets the maximum fiber loss margin that is acceptable for traffic on this
(dB) link. If exceeded, an alarm is raised. Possible values:0-7; resolution = 0.1.
 If connectivity type is External, default = 3.
 If connectivity type is Internal, the value is fixed at 1.
PMD (ps) Sets the maximum level of polarization mode dispersion (PMD) that is
acceptable for traffic on this link. Possible values: 0-40; default = 0;
resolution = ±0.1.
If connectivity type is Internal, the value is fixed at 0.
Parent Topic

4.11.3 Path Trace Configuration Dialog Box

The Path Trace Configuration dialog box (accessed by clicking Path Trace Configuration in the advanced
parameters of the Create Topology Link dialog box), enables you to set the J0 values of endpoints of a
physical connection. It is only available if you are creating an SDH link and both endpoints support J0
handling.
Figure 4-36: Path Trace Configuration dialog box
Table 4-16: Path Trace Configuration dialog box fields

Path Trace Monitor Select whether to enable path trace monitoring or not. This is the J0
section trace (affects RS-TIM/TIM-S alarm detection).
Path Trace Received Actual value of the path trace (J0) as read in the element. This value is
not automatically updated. Click Refresh to obtain it from the ME.
Path Trace Expected Expected path trace string:
 Current Value – value presently in the element. (Read only)
 Set New Value – enables you to set a new value.
If one of the fields is shaded, it indicates the current value saved for the
link. You can enter a new value in the Set New Value field. Modifying this
value updates the Set value in the matching pane of the other endpoint.
Modifying the Expected in one port will change the Sent in the other and
vice versa.
The length of Path Trace Expected and Path Trace To Send is 15
characters.
Path Trace to Send  Current Value – the value presently in the ME. (Read only)
 Set New Value – enables you to set a new value.
Parent Topic

4.12 Port Properties

You can view or edit the properties of ports.
The following is the Properties for Port dialog box for a selected port.
Figure 4-37: Properties for Port dialog box
For the supported ETH/MPLS port types, see Supported ETH/MPLS Port Types.
To view the properties of a port:

1. In the topology view, right-click a multilink and select Expand. The Actual Links Between Two
Elements dialog box opens.
2. In the record corresponding to the link, right-click a port name (for example, Port 1 or Port 2) and
select Properties. The Properties for Port dialog box opens, displaying the General tab.
3. To view Optics properties, click the Optics tab.
NOTE: You can also display the Properties for Port dialog box by right-clicking a slot node in
the Inventory tree (main topology view) and selecting Properties.
4. Enter changes to editable parameters (having white backgrounds) as needed.

When a parameter is edited, an asterisk appears in the tab selector. The asterisk disappears when you
click Apply to save the changes.
5. Click Apply to save the changes in all tabs.
Parent Topic

4.12.1 Supported ETH/MPLS Port Types

ETH/MPLS ports are represented by two LightSoft layer characteristics:
 Physical layer, configured at the EMS level, including:
 EoS ports (Ethernet over SDH trails).
 ETY ports (Ethernet at the physical layer).
 MoT ports (MPLS ports over SDH trails), identified as being MPLS I-NNI interfaces.
 MoE ports (MPLS ports over Ethernet). Interface type not relevant.
MoE ports apply to P2P, P2MP, or MP2MP services. Also supports MoE LAG functionality.
(Rooted MP on MoE virtual link is restricted for services.)
 MoG ports (MPLS over Generic Routing Encapsulation). This port is used to transport data
over an IP network.
 PSI ports (Packet Switch Interface). Physical ports connecting two MPLS cards over the NE
fabric. The PSI port is displayed in the tree view of the LightSoft interface at the same level as
the other MPLS port types. Users can right-click the PSI port icon in the tree to open Current
Alarms or PM windows for that port.
Physical PSI ports on an NE card represent the aggregate capacity of all the logical MoF ports
configured on that NE card. For example, an MCS50_10P card includes a single physical PSI
destination port with a capacity of up to 10G. This PSI port represents the logical MoF ports
grouped on that card. LightSoft automatically connects each PSI port in an NE through logical
MoF port links to every other PSI port in that NE, with the exception of a second PSI port located
on the same card. This enables automatic creation of a full mesh of connectivity within that NE.
Note that the cumulative capacity of all the logical MoF ports grouped under a PSI port cannot
exceed the physical capacity of that PSI port.
 Ethernet logical layer, including:
 ETY and EoS ports, identified by type as one of the following logical interfaces:
 UNI (User Network Interface) ports connect a user to the network. The frames on a
UNI port are either untagged or C-VLAN tagged, and are associated with a service on the
basis of C-VLAN with multiple C-VLANs defining a single service. CoS is assigned. Policing is
performed by service.
 E-NNI (External Network-to-Network Interface) ports connect ports of different

networks. The frames on an E-NNI port are S-VLAN tagged; each S-VLAN denotes a service.
CoS Mapping is supported. Policing is performed per service.
 I-NNI (Internal Network-to-Network Interface) ports connect ports of the same

network. The frames on an I-NNI port are S-VLAN tagged. The S-VLAN ID determines the
Ethernet service. Policing is not performed.
 Intercard MoE ports . Backplane connectivity via vertically adjacent slots. Intercard MoE
ports function like physical MoE ports.

 MoF (MPLS over Fabric) ports . Connectivity between MPLS cards via the internal NE fabric.
Since all cards in the NE can communicate directly, NE resources can be grouped together into a
single high-capacity matrix flow domain.
MoF ports and links are similar to IC-MoE ports, in that IC-MoE ports are used to connect two
adjacent MCS cards via the backplane and MoF ports are used to connect multiple hybrid cards
within the same NE via the internal fabric.
LightSoft manages MoF links and ports automatically, enabling simplified provisioning and
management of complex full mesh topologies. MoF ports are functionally equivalent to IC-MoE
ports, nested within a shelf group. See Working with Groups.
In the LightSoft tree, a port is sometimes referred to by its joint type:
 ETY called ETY UNI port
 ETY called ETY E-NNI or ETY I-NNI port
 EoS called EoS UNI port
 EoS called EoS E-NNI or EoS I-NNI port

For information about the logical interfaces used for service creation, see Understanding Ethernet Service
Endpoints and their Interfaces.
MPLS Network Port Types

LightSoft-supported MPLS ports are MoT, MoE, MoG, and MoF ports. 1Net-capable PEs and their ports are
listed directly under the MPLS layer root in the inventory tree.
In the case of old-capability PEs, an "old-style" MPLS network is automatically created when MoT ports are
connected. (The network does not need to be declared as an MPLS network.) These networks are
automatically phased out when all its associated PEs and EMSs are upgraded.
Ethernet Network Port Types

A PB network uses EoS trails or ETY links with endpoints in a PB LE (such as EIS card).
L1 SDH ports (such as DIO card) can be connected to the PB network, but are not considered part of the
network (in a PB network only L2 ports are allowed). The Admin group in the MPLS layer permits collecting
these ports into one group.
An L2 card (such as EIS and MCS) comprises SDH ports, a bridge, and Ethernet (ETY physical) ports.
EoS trails, ETY links, and Ethernet services are created independently.
L1 Ports
The ports on L1 cards (such as DIO) connect an SDH trail termination with Ethernet interfaces. The EoS trail
is created directly to the port, entering as SDH and leaving as Ethernet. When an EoS trail is created from
an SDH network, the L1 service already exists, encapsulated in the same port.
EoS ports enable the use of SDH cards in PB networks. The root and leaf remote endpoints can also be
connected for GbE or FE.
Parent Topic

4.12.2 Properties for Port Toolbar

Properties for Port dialog boxes have the following toolbar options.
Table 4-17: Properties for Port dialog box icons

Open Opens a GCT session for this port; see Accessing EMSs.
Alarms Shows the alarms applying to this object; see Viewing Object-Related
Current Alarms.
Reconnect MAC Not relevant for ports. For information about how to deal with a MAC
Address address problem concerning a port; see MAC Address Problems in Link or
Port.
Apply Saves edit changes; see Viewing and Editing Object Properties.
Close Closes the Properties dialog box.
Parent Topic

4.12.3 General Tab

The General tab parameters are also common to most other port types. Exceptions are shown in context.
Fields with a white background are editable (see the parameter descriptions).
Figure 4-38: Properties for Port - ETH/MPLS dialog box - General tab
Table 4-18: Properties for Port dialog box fields - General tab
Field Description Applies to:

Port Name Port name (slot, port type, and number). Same value as All port types
nativeEMSname. Editable for UME only.
Status Usability state (for example, OK) or alarm severity (e.g., All port types
Major, Minor) of the port. See also Object Status Color
Indications.
Assigned Port Label Label of the port. Default same as port name. Editable. All port types
Port Rate Rate of the port. All port types
Tip: LightSoft automatically performs the link infrastructure
changes consistent with port reassignments from STM-1 to
STM-4 in the EMS; see Automatic Link Adaptation.
Holder Slot number, for example, Slot I3. All port types
Topology Link(s) Labels of topology links connected to the port. All port types
LE(s) Names Name of the LE to which the port is related. (Usually a single All port types
LE, but can be more on hybrid ports).


ME Name Name of the ME to which the LE is related. All port types
DCC/GCC DCC/GCC configured on the port (if any). Editable for OTUk All port types
ports on OMLT equipment. except data ports.
Values: GCC, GCC0, GCC1, GCC2, Transparent (for DCC
Through), DCC Terminated, Disabled, or blank (default).
Associated Layers Technology layer associated with this port. All port types
Media Type Optical, Electrical, Radio, or Logical. Based on the physical All port types
layer of the PTP.
Port Protection Type of protection applying on the associated link, for SDH and optical
example, MS-SPRing, MS Linear, External protection, or ports
Unprotected.
MSP Linear protected optical links can have the following
values:
 1+1 if the protection is non-revertive, or
 1+1 Main or 1+1 Protecting if the protection is
revertive.
For more details, see MSP Linear Link Protection for OCH
and LP Trails.
Port Location Location of the port in a platform. According to standard All port types
EMS/LightSoft interface notation.
Service State Indicates whether the port is in or out of service. All port types
Consistency State Consistency between LightSoft and the respective EMS for a All port types
specific link. Available states: Consistent or Inconsistent.
When the link is inconsistent, the inconsistency reason is
shown with the consistency state. There can be several
reasons for inconsistency. For more information, see the
Consistency State description in Link Properties - General
Tab.
Trail Trace Monitor Indicates current state of Trail Trace Monitor for relevant SDH and OTN only
ports. This attribute is not relevant for OCH trails based on
XDM/NPT equipment only. Value is determined by
analyzing the Trail Trace Monitor states of all participating
trail endpoints, either On (enabled), Off (disabled, default),
or Mixed.
ASON Metric ASON Metric code associated with the port for PathFinder SDH, ETH/MPLS
purposes. The value can be changed manually, or updated
with the system preferences default value; see ASON
Configuration Preferences in the Getting Started &
Administration Guide. This is done using the link properties
Reconnect; see Properties for Link Toolbar (page 4-135).
Parent Topic

4.12.4 Optics Tab

The Optics tab lists the relevant optical port properties. The properties table in this section includes the
complete set of optics properties; however, note that not all properties are relevant for all types of optical
ports. Where not relevant, the property field is either disabled or not included in the window.
Fields in the Optics tab may also apply to optical SDH ports and data MoE and ETY port types (GbE-C and
10GbE-C rates). This tab is not applicable to MoT, EoS, or DIO ports. The following figure shows the Optics
tab associated with optical ports used by OCH and LP trails.
Figure 4-39: Properties for Port - OTN - Optics
Table 4-19: Properties for Port dialog box fields - Optics tab
Tx Tuned Frequency Indicates the configured transmission frequency/channel. Optical ports and
Editable for colored ports. Values may be: SDH/Ethernet colored
 N/A (default) ports.
 0
 Any of 88 DWDM channels (THz)
 Any of 8 CWDM wavelengths (nm)

Copy to Rx When checked, the frequency selected for the Tx field is Apollo equipment only.
checkbox automatically copied to the Rx field and cannot be
changed by the user. When the Tx frequency is
downloaded to the EMS level, the corresponding Rx
frequency is downloaded as well.
When unchecked, the user enters a value for the Rx field
independent of the Tx field value.
Rx Tuned Frequency Indicates the configured reception frequency/channel. Optical ports and
Editable for colored ports. Values may be: SDH/Ethernet colored
 N/A (default) ports.
 0
 Any of 88 DWDM channels (THz)
 Any of 8 CWDM wavelengths (nm)
Laser Configuration Indicates if the laser is On, Off, or N/A (default). Editable. Optical ports and
You can view or modify the current state as required any SDH/Ethernet colored
time, manually overriding LightSoft’s action if needed. For ports.
more details, see Laser Configuration in the Getting
ALS State Automatic laser shutdown feature, may be either: Ports with optical
 Enabled transceivers.
 Disabled
 N/A (default)
Actual Laser State Current laser state, may be either: Ports with optical
 On transceivers.
 Off
Port Coherency Port coherency mode, may be either: Ports with colored
 Coherent optical transceivers.
 Non-coherent (default)
Must be consistent for the ports at both ends of a link or
trail.
ASON Interface Interface type for OTN port. Possible values: OTU ports
Type  Unconfigured (default)
 NNI
 UNI
 N/A (not compatible with ASON).
ASON Interface Link consistency between the LightSoft database value OTU ports
Type Consistency and the network value. Possible values:
OK or Inconsistent.

GCC Working Mode Defines the working GCC mode. Editable for OTUk Apollo Relevant only for Apollo
ports only. ports that can work in
 N/A (default) either mode.
 Standard
 XDM/NPT
Band Shows the band or sub-band of frequencies to for the port OTS (OMS trail) ports
is defined. For example: only.
 C or L: Frequencies on the C band or L band.
 C&L: Frequencies on both the C and L bands.
 Red: Frequencies on the Red sub-band of the C band.
 Blue: Frequencies on the Blue sub-band of the C
band.
 Red&Blue: Frequencies on both the Red and Blue
sub-bands of the C band.
 CWDM, CWDM-SL, CWDM-C:
CWDM frequencies.
 C Extended 44: 44-channel C band range.
 C Extended 88: 88-channel C band range.
 Unrestricted.
 N/A.
Number of Number of channels that the port supports. OTS (OMS trail) ports.
Channels
FEC Displays the FEC (Forward Error Correction) setting from Optical ports.
the EMS. Values may include:
 FEC
 EFEC
 UFEC
 EFEC I8
 EFEC4
 EFEC7
 SD-FEC
 EFEC7-10
 EFEC7-13
 Disabled
 Transparent
 N/A (default)
Editable for OTUk Apollo ports, with the values FEC,
EFEC4, and EFEC7 only.
FEC Rx Ignore Indicates that FEC value is to be ignored on Rx ports. Optical ports.
 True
 False (default)

Line Code Code for digital data transport purposes. Values include: Optical ports and
 RZ (return to zero) SDH/Ethernet colored
 NRZ (non-return to zero) ports.
 NRZ-PDPSK
 RZ-DQPSK
 DP-DQPSK
 N/A
Over Clocked Rate Used for carrying Ethernet and fiber-channel clients with Optical ports and
full transparent mapping into 10G lambda. Performing this SDH/Ethernet colored
mapping method requires increasing the standard OTU2 ports.
rate (10.709):
 OTU2e (11.0957 Gbps, 10GbE client)
 OTU2f (11.3176 Gbps, FC1200 client)
 OTU3e (44.6 Gbps, 40GbE client)
 Transparent
 N/A (default, if the layered parameter does not exist)
OCH trail rules require that both trail endpoints have the
same overclocking. You cannot create an OCH trail
between endpoints with two different rates, such as OTU2
and OTU2e.
R/W for UME ports.
Frequency Spacing Identifies the frequency spacing between two consecutive Optical ports and
OCH channels as presented in the EMS; see also Channel SDH/Ethernet colored
Frequencies and Wavelengths. (Default N/A) ports.
Frequency Spread Identifies the spread of the spectrum on an OCH channel Optical ports and
as presented in the EMS; see also Channel Frequencies SDH/Ethernet colored
and Wavelengths. (Default N/A) ports.
Client Rate Rate of the port, for example ODU1. Optical ports and
SDH/Ethernet colored
ports.
Directionality Bidirectional, UnidirectionalSrc, or UnidirectionalSnk. SDH Optical ports and
ports are bidirectional. SDH/Ethernet colored
ports.

Bi-directional Admit If this parameter is enabled on a port, the acquisition Optical ports and
Trail process creates a bidirectional optical trail. SDH/Ethernet colored
ports.
Bidirectional trails are implemented using paired ports.
For each port, the identity of the partner port is found in
the Paired Port parameter (described in the following
row). If the Bi-directional Admit Trail parameter is
disabled, the Paired Port parameter value is ignored.
If optical trails are being acquired (see Optical Trail
Acquisition by Synchronization and Creating Optical Trails
Through Discovery) rather than created "top-down", and
you require pairs of unidirectional trails (rather than
bidirectional trails), before starting the trail acquisition
process, you must disable this parameter on every
relevant endpoint port of the trail. This disables the
automatic linking between Snk and Src ports and causes
unidirectional trails to be created.
This parameter value is editable.
Paired Port Optical ports and
For uni-directional ports that are configured to work in
SDH/Ethernet colored
sets of two as paired (Snk/Src) ports, identifies the partner
ports.
port; see Defining a Relationship between Ports or Cards.
Note that this value is used only when the Bi-directional
Admit Trail parameter (described in the preceding row) is
enabled. Otherwise the value is ignored.
For bidirectional ports with ODU0s connection
termination point (CTP), indicates the port with the
ODU0s partner.
OSC Peer Port Native name (label) of the OSC peer port for this port, as OTN ports
presented in the EMS.
OSC Wavelength Wavelength for OSC management traffic over this port. OSC ports.
Displayed only for OSC ports. Values include:
 1510 nm
 1310 nm
 196.2 THz
 None (default)
OSC bitrate Bitrate for OSC management traffic over this port. OSC ports.
Displayed only for OSC ports. Values include:
 2M
 100M
 STM-1
 None
 N/A (default)

Passive Equipment Indicates that the selected port is passive, such as ports on Optical ports and
Artemis cards in Apollo platforms. Values include: SDH/Ethernet colored
 Passive ports.
 Not Passive
 Unknown
 N/A (default)
Parent Topic
4.12.5 Radio Tab

The following Radio tab applies to radio ports.
Table 4-20: Properties for Port dialog box fields - Radio tab
Channel BW (MHz) Configured bandwidth Radio port

Modulation Type The actual (current) modulation with which the Radio port
equipment is working

ODU Temperature The temperature of the Outdoor Unit Radio port
ODU Lo/Hi The low and high configuration of the Outdoor Unit Radio port
Tx Frequency (MHz) Configured Tx transmission-carrier frequency Radio port
Rx Frequency (MHz) Configured Rx transmission-carrier frequency Radio port
Spacing (MHz) The frequency spacing Radio port
Frequency Band (MHz) Transmission group Radio port
ODU Name The name of the Outdoor Unit equipment Radio port
Max Payload The maximum number of CTPs that can be Radio port
configured on the radio port in string format (e.g.
84xE1)
Max Payload BW (Mbps) The maximum number of CTPs that can be Radio port
configured on the radio port in Mbps format (e.g.
182.64 Mbps)
Configured Payload The number of the configured CTPs on the radio port Radio port
in string format (e.g. 29xE1)
Configured Payload BW (Mbps) The number of the configured CTPs on the radio port Radio port
- in Mbps format (e.g. 77.29 Mbps)
Actual Payload The number of occupied (actual used) CTPs on the Radio port
radio port in Mbps format (e.g. 10.43 Mbps)
Actual Payload BW (Mbps) The occupied (actual used) bandwidth of the radio Radio port
port in string format (e.g. 4xE1)
Radio Protection The radio port protection type Radio port
Associated Data Port The name of the EoR port that is associated with the Radio port
radio port.
This is an empty field, if there is no association to an
EoR port
Parent Topic

4.12.6 Radio Tab for EoR Ports

The following Radio tab applies to EoR radio ports.
Table 4-21: Properties for Port dialog box fields - Radio tab
Max Ethernet Payload BW The maximum bandwidth of Ethernet services, in EoR port
Mbps, which the EoR port can carry
Configured Ethernet Payload The bandwidth of the configured Ethernet services, EoR port
BW in Mbps, which the EoR port is carrying
Actual Ethernet Payload BW The occupied bandwidth of the actual Ethernet EoR port
services, in Mbps, which the EoR port is carrying
Associated Radio port The name of the radio port that is associated with EoR port
the EoR port
Parent Topic

4.12.7 L1 Connectivity Tab

The L1 Connectivity tab applies to the data port types that are "at least" L1, including EoS, ETY, MoT, MoE,
MoG, MoF, and PSI. It does not apply to pure Ethernet ports (DIO). The parameters available differ
according to the port type. The following shows the tab that applies for an MoT port.
Figure 4-40: Properties for Port - ETH/MPLS dialog box - L1 Connectivity tab - MoE
Table 4-22: Properties for Port dialog box fields - L1 Connectivity tab

Port Type A supported ETH/MPLS port type; see Supported ETH/MPLS All data ports
Port Types. Values:
 L2 ETY MoE
 Intercard MoE
 MoF
 MoT
 MoG
 PSI
 L2 ETY
 L2 EoS
 L1 ETY
 CES
Interface Type A supported ETH/MPLS interface type; E-NNI, I-NNI, NNI, or ETY, EoS only
UNI, depending on context. See Supported ETH/MPLS Port
Types.
Port Enabled Enabled, Disabled. Editable or read only, depending on the Not relevant for
context. MoT or EoS


VCG Granularity Layer of the VCs in the VCG granularity. Editable unless port is MoT, EoS, DIO only
trail endpoint.
Number of VCs Number of VCs in the VCG Allocated VCs. Editable. MoT, EoS, DIO
Allocated
Active Size Rx Indicates the number of Rx resources (VCs) that are MoT, EoS, DIO only
configured as active (Data Active) in the EMS.
Active Size Tx Indicates the number of Tx resources (VCs) that are MoT, EoS, DIO only
configured as active (Data Active) in the EMS.
Ethernet Actual Port Rate limit for client in Mbps. ETY ports only. All port types
Rate
Encapsulation Type PPP or LAN Emulation from the EMS. Values are MoT, EoS (GFP-F),
HDLC PPP, GFP Transparent, GFP Frame Mapped, TMPLS DIO
FCS Generation Enabled, Disabled, or Unknown (default). MoT, EoS only.
LCAS Indicates whether LCAS is enabled or disabled on the virtual MoT, EoS, DIO only
link. Editable.
LCAS Type If LCAS is enabled, shows the LCAS type. Editable. Values: MoT, EoS, DIO only
LCAS, Proprietary-LCAS, or DPC.
OAM Enabled Enabled, Disabled. Editable. OAM enables single Ethernet link MoE, ETY, DIO only
monitoring, loopback testing and fault detection and
signaling.
Note: OAM Enabled is enabled/disabled in the Create Tunnel
window Advanced Tunnels Parameters Pane. All the other
OAM attributes displayed are set in the EMS and provided as
read-only in LightSoft. The OAM attributes refer to the Link
OAM feature implemented according to standard IEEE 802.3
Clause 57.
OAM Local Mode Active, Passive, Editable. An Active port initiates OAM and MoE, ETY, DIO only
does not respond to an OAM remote loopback command
from a Passive peer. Values: Active, Passive.
OAM Remote Mode Yes, No, as set in the EMS. Editable. Indicates whether OAM MoE, ETY, DIO only
may be enabled with a peer port in Active mode. Values:
Active, Passive.
OAM Remote Enabled, Disabled, Editable. Whether the peer port is in OAM MoE, ETY, DIO only
Loopback loopback state. L1 ETY, EoS ports only.
OAM Local Loopback Enabled, Disabled. Whether the port is in OAM loopback MoE, ETY, DIO only
state.
CFM MAC Address MAC address in string format (if not exist in the port shall be All data except DIO
taken from MFD).
Gateway to PB Shows the PB network name, if applicable. DIO only
Parent Topic

4.12.8 ETH/MPLS Tab

The ETH/MPLS tab applies to the ETH/MPLS layer ports types (excluding DIO).
NOTE: The parameters displayed in the tab may differ according to the port type. For
example, the LAG properties are only displayed when LAG is enabled for that port.
MPLS ports refer to MoT, MoE, Intercard MoE, MoF, and MoG ports.
Figure 4-41: Properties for Port - ETH/MPLS - ETH/MPLS tab
Table 4-23: Properties for Port dialog box fields - ETH/MPLS tab
Supported Tunnels Whether L-LSP and/or E-LSP and/or signaled tunnels are MPLS ports
supported. Values are:
See Tunnel Mode.


Tagging Format Q in Q, EIS Q in Q, or None, as set in the EMS. EoS only. ETY, EoS
Double-tagging (VLAN Stacking) enables service providers to
use a single VLAN to offer IP-based service support to
customers with multiple VLANs.
S-VLAN Mode Values Tagged or Untagged, according to whether the MoE MPLS ports,
port is tagged or untagged, as reflected in the EMS. except MoT
Port Based VLAN Block untagged, Forward untagged, PVID for Untagged, PVID ETY, EoS
Mode for priority tagged.
Port Based VLAN ID VLAN ID value. Editable. ETY, EoS
Port Based VLAN ID C-VLAN priority of the PVID. ETY, EoS
Priority
Dual Homing Peer LE name and port label of peer. Only ETH ports of dual homed All data except
MPLS-PE. DIO
Gateway to PB PB network name displayed if the EoS trail has an endpoint in ETY, EoS.
a PB. (For DIO, see
same parameter
in L1 tab.)
STP Type Type of Spanning Tree Protection. For more details see Link ETY, EoS
Properties - Advanced Tab.
Values: None, RSTP, MSTP (from the MFD).
STP Enable Enable, Disable. Editable. ETY, EoS
STP Port Priority STP Port Priority. ETY, EoS
STP Port Cost RSTP port cost used by the STP mechanism. Different values ETY, EoS
may exist for each endpoint. EoS port only. For more details,
see Link Properties - Advanced Tab.
LAG Type Identifies the type of LAG configured here, Load Sharing or ETY, EoS, MoE,
Protection (1:1). Default value empty. MoF, MoG, PSI
LAG Distribution Enabled or Disabled. Not relevant if LAG Type is empty. ETY, EoS, MoE,
MoF, MoG, PSI
LAG Role If LAG Distribution is set to Enabled for the port, then LAG Role ETY, EoS, MoE,
is set to either Master or Slave. Not relevant if LAG Type is MoF, MoG, PSI
empty.
(Previously LAG Configuration.)
LAG Priority Values are Primary (port default active), Secondary (port ETY, EoS, MoE,
default standby), or empty (default). Corresponding (linked) MoF, MoG, PSI
LAG ports must share the same priority value. Relevant only if
LAG Type is Protection.
LAG Protection State Values are Active, Standby, or empty (default). Relevant only if ETY, EoS, MoE,
LAG Type is Protection. MoF, MoG, PSI
LAG Remote PE ID Global PE ID of the second LAG port (corresponding partner for ETY, EoS, MoE,
this port). Relevant only if LAG Type is Protection. MoF, MoG, PSI


LAG Key Identification key assigned to both partner ports in a LAG ETY, EoS, MoE,
Protection 1:1 configuration. Relevant only if LAG Type is MoF, MoG, PSI
Protection.
LAG Master Port ID Name of master port (if applicable). Empty if port is not part of ETY, EoS, MoE,
LAG. Not relevant if LAG type is empty. MoF, MoG, PSI
LAG Members List of ports (native names) participating in the LAG. Not ETY, EoS, MoE,
relevant if LAG type is empty. MoF, MoG, PSI
LAG Redundancy Possible values: MoE
 Maximum Active Ports: maximum number of active ports
in a LAG for MoT CAC. Used to calculate MFD counters
and MoT CAC.
 Minimum Active Ports: minimum number of LAG active
links with which the LAG is considered Up.
 Standby Links: total number of LAG member ports that
are used for redundancy.
Source MAC Address MAC address format. Can be changed using Reconnect. MoE
NH MAC Address MAC address format. Zeros indicate a MAC address problem. MoE
For details, see MAC Address Problems in Link or Port.
LLCF Capability Indicates whether LLCF is supported for this port. Values are ETY, EoS, MoE,
Supported or Not Supported. MoF, PSI
LLCF Role Values are Source and Sink, Source, Sink, or None (default). ETY, EoS, MoE,
The LLCF role can be changed if LLCF Capability is Supported MoF, PSI
and the port is not I-NNI.
PSI Name Label (native name) of the PSI port. MoF
MoF Paired Port Label (native name) of the corresponding MoF port. MoF
Intercard MoE paired Label (native name) of the corresponding intercard MoE port. Intercard MoE
port
MoF Paired Port Native name (label) of the paired (partner) port for a logical MoF ports
MoF port.
PSI name Native name (label) of the PSI port associated with this MoF MoF ports
port.
For more information about LAG, see LAG Support.
Parent Topic

4.12.9 IP Tab (port properties)

The IP tab applies to the MoG port type only.
Figure 4-42: Properties for Port - IP tab
Table 4-24: Properties for Port dialog box fields - IP tab

IP Address MoG port
MoG port IP address
Peer IP Address IP address of the IP network/ third party vendor access port. MoG port
Mask MoG port mask address MoG port
Destination IP IP address of destination MoG port. MoG port
Address
Information is read-only and is set at the EMS level.
Parent Topic

4.13 Link Properties

You can view or edit the link properties in the Properties for Link dialog box. Click the tabs, such as General
and Advanced to view and edit the parameters. The tabs vary depending on the type of link. For example,
the following figure is a Properties for Link dialog box for a selected MoT link.
Figure 4-43: Properties for Link - MoT - General tab
Parent Topic
4.13.1 Properties for Link Toolbar

All link types have the same toolbar icons unless otherwise indicated.
NOTE: MPLS links refer to MoT virtual links, MoE and MoG physical links, and Intercard MoE
and MoF backplane connections.
Table 4-25: Properties for Link dialog box

Alarms Shows the alarms applying to this link; Opens the Current Alarms
window showing the alarms on the selected link. You can also show the
alarms for all the links in the multilink by right-clicking the multilink and
selecting Current Alarms. See also Viewing Object-related Current
Alarms. For more information about alarms, see Viewing Alarms.


Availability Shows availabilities of the link resources; see Availability for Link.
For the OTN Link type, shows the state of channels through the OMS trail
traversing this link; see Viewing Optical Channel Availability.
Update Next Hop Enabled to assist dealing with an inconsistency due to a MAC address
MAC Address problem; see MAC Address Problems in Link or Port or Port relevant for
MoE links only.
Update Enabled to assist dealing with an inconsistency due to a IP address
Destination IP problem. Relevant for MoG links only.
Address
Download TE Downloads the link's TE parameters to the ports in EMS.
Parameters to EMS The icon becomes enabled when TE parameters are edited and the TE
Mismatch value becomes User defined mismatch, AND one of the
following also apply:
 If a problem is encountered sending it to EMS (an error message
opens), OR
 A system preference is edited.
Applicable to: MPLS links.
For details about how to use this icon, see Download TE Parameters to
EMS Icon.
Apply Saves edit changes; see Viewing and Editing Object Properties.
Refresh Refreshes the dialog box fields.
For MoE links: Enabled when the link is inconsistent with MAC-Mismatch
reason; see MAC Address Problems in Link or Port. Updates the Next
Hop MAC address of both endpoints according to the MAC address
value.
For ASON links: Enabled when the ASON Metric Mismatch value of the
link is Mismatch; see parameter in Link Properties - General Tab.
Updates the link's ports with the ASON Metric value from the system
preferences; see ASON Configuration Preferences in the Getting Started
& Administration Guide. After this is done, the ASON Metric Mismatch
parameter will change to Match.
Note: You can also update the Metric for multiple selected links at a
time; see Reconfiguring the Metric for ASON Links.
Close Closes the Properties dialog box.
Default Loads default values, for example, system preferences TE parameters
values.
Applicable to: MPLS links.
Note: You must click Apply to apply the change.
Parent Topic

4.13.2 General Tab

The General tab parameters are common to most link types. Exceptions are shown in context. Fields with a
white background are editable (see the parameter descriptions).
Figure 4-44: Properties for Link - MoT - General tab
Table 4-26: Properties for Link dialog box fields - General Tab

Link Name Name of the link. (Editable for physical links) All link types
Endpoints Endpoints of the link. All link types
Trail ID Trail ID associated with the virtual link. MoT and EoS virtual
links
Rate Rate of the link. All link types
Type  Physical: Real links (typically LAN links) created between All link types
ports.
 Virtual links: "Created" from EoS, MoT, MoE, or OCH/LP
trails.
 Backplane connection: Created for intercard MoE and
MoF links.
See also Link Types.
Status Usability state of the link (for example, OK) or alarm severity All link types
(e.g., Major, Minor) of the port with the most severe alarm at
either end of the link; see Object Status Color Indications.


Link Protection Type of link protection, for example, MS-SPRing, MS Linear, All link types except
Unprotected. Editable for SDH and optical physical links. MoE, MoF, and ETY
On virtual links, the protection scheme is derived from the physical links
underlying trail.
On physical topology links, the protection scheme is derived
through EMS port configurations, for example, MS-SPRing,
MS Linear.
Otherwise, Unprotected appears and the field is editable. If
some other kind of external protection applies (unmanaged
by LightSoft), you can set the protection description to
External Protection for information purposes. (Editable for
physical links where protection is not defined in the EMS.)
MSP Linear protected optical links can have the following
values:
 1+1 if the protection is non-revertive, or
 1+1 Main or 1+1 Protecting if the protection is revertive.
For more details, see MSP Linear Link Protection for OCH and
LP Trails.
Ring Name Name of the ring associated with this link. Editable. May be Physical links
assigned in two ways:
 Manually as a free text identifier, originally assignable at
link creation (see Create Topology Link Advanced
Attributes) or assignable/modifiable in this field.
 System-assigned name and ID (for example “Name:1”) if
the link involves MS-SPRing protection; see Managing
MS-SPRing Rings. In this case the field is read-only.
The following ring management functions are available:
 Show Ring to highlight in the current map view all links
that share the same ring name.
 Expand Ring in New View to highlight in a separate map
view all links that share the same ring name as the
current link.
 Show Trails of Ring to show the trails associated with
links that share the same ring name.
See the option descriptions in Viewing Topology Link
Information.
Note: These functions are case sensitive on the ring name.
Only exactly matching ring names are considered as shared.
Service State Operational state of the link. Values are In Service or Out of All link types
Service. The latter applies when the Maintenance State
parameter is set to Manual Maintenance or in the presence
of a fatal alarm.


Consistency State Consistency between LightSoft and the respective EMS for a All link types
specific link depending on the actual status.
Available states: Consistent or Inconsistent.
MoE links may also show MAC Address Mismatch; see MAC
Address Problems in Link or Port.
When the link is inconsistent, the inconsistency reason is
shown with the consistency state. There can be several
reasons for inconsistency:
 Deleted from EMS, when a link is deleted in the EMS but
cannot be deleted in LightSoft (for example, when a trail
passes through the link without the EMS being aware).
 Config Control Conflict, for example, when LightSoft
creates a link between a SYNCOM element and an
XDM/NPT element, and a different link is created via the
EMS to a different element using the previously created
link's endpoint.
 Validation Rules Conflict, for example, when a valid link
created in EMS-SYNCOM is incompatible with the rules
of LightSoft.
 Manual Out of Service, an indication that the link was
manually put out of service; see Maintenance State
parameter. This prevents the creation of new trails or
receipt on any notifications on the link.
Pre-existing traffic is not affected.
Note: Links that traverse inconsistent elements are also
rendered inconsistent.
Maintenance State Indicates whether the link is in service (None) or out of Physical links
service (Manual Maintenance). Editable. The latter setting
prevents the creation of any new entities or receipt of any
notification on the link. Pre-existing traffic is not affected.
ASON Maintenance Indicates whether the link is in maintenance mode (Enabled)
State or in service (Disabled). Editable. (see Placing an ASON NE or
Link in Maintenance Mode).


ASON Metric Values Match, Mismatch, based on comparative ASON Metric
Mismatch values at the link endpoints.
Mismatch indicates a difference in ASON Metric between the
link endpoints. The ASON Metric value of an endpoint can be
viewed and changed in port and link properties windows;
see:
 Link Properties - Endpoints Tab. This window
conveniently shows both ports of the link side by side.
 Port Properties - General Tab.
You can also correct the mismatch for the current link by
clicking Reconnect . This will download the system
preference value of the ASON Metric to the current ports;
see the parameter in ASON Configuration Preferences in the
ASON Data Link
(Optical links) Indicates the state of the OCH data link:
State
Values: Active, Pending, Inconsistent, None, or N/A.
Comments Displays a comment. Editable. All link types
Parent Topic
4.13.3 Advanced Tab

The following are Advanced parameters of SDH links. Certain fields are editable (see the parameter
descriptions).
Figure 4-45: Properties for Link - SDH - Advanced Tab

The virtual link property definitions for SRLG, Length, Assigned Cost, and Link Quality differ slightly from
those of physical links.
Table 4-27: Properties for Link dialog box fields - Advanced Tab
Associated Layer Technology layer of the link. All link types

Used in the process of changing an SDH link to
accommodate optical trails, or an optical link to
accommodate SDH trails; see Changing Ports and Links
between Non-Colored and Colored.
Editable for physical links only in (rare) cases for manually
associating the layer of the ports when both ports are
hybrid.
Media Type Media type of the selected link. All link types
 Logical (backplane connection)
 Virtual (EoS, MoT, or generic)
 Electrical
 Optical
 Other (inconsistency between port media types)
See link types description in General Tab.
Media Subtype Select a media subtype in the list. Available options Physical links
depend on the media type. Editable.
Length (km/mile) The length of the link in kilometers or miles. This value is All link types
used for path searching optimization to determine the
shortest path.
For virtual links, Length is an aggregation (the sum of the
real link segments that the trail traverses).
Editable for physical links.
Directionality Unidirectional or bidirectional. Physical links
SRLG (Ducts) Shared Risk Link Group. Scrollable entry fields allow you to Physical links
specify the shared resources for the link. The PathFinder
algorithm uses this information when calculating diversity
paths.
User-defined SRLGs can be added or removed.
Automatically assigned SRLGs are removed automatically
if the MoT trail using the link is removed. For more
information, see Shared Risk Link Groups (SRLGs).
If MoT trails currently using a link have protecting bypass
tunnels, then adding/removing SRLGs on the link is not
allowed. You must remove the bypass tunnels first. See
Deleting Tunnels.
For virtual links, this field is read only and displays the
accumulated SRLGs of the underlying technology links.
Editable.

Assigned Cost Enter a cost value based on your local evaluations of cost Physical links
(1-1000) on a nondenominational scale of 1-1000. A low number
indicates a less expensive link. This value is used for
optimizing trails; the system selects the least expensive
links for the trail path.
For virtual links, Assigned Cost is the accumulated cost
across the segments that the trail traverses. (Not
applicable to Ethernet virtual links.) Editable.
Link Quality Select the quality of the link for QoS applications. The Physical links
(Best 1..5 Worst) available range is from 1 (best quality) to 5 (worst quality).
This value is used for optimizing trails; the system selects
links for the trail path according to the selected quality
constraint.
For virtual links, Assigned Quality is the minimum quality
across servers. Editable.
Dispersion (ps*nm/km) Dispersion rate of the signal in pico seconds x nano meters Physical links
per kilometer (ps*nm/km). User-entered value, not
calculated. Editable.
Span Loss (dB) The span loss in decibels. User-entered value, not Physical links
calculated. Editable.
Creation Time Date/time the link was created. Physical links
Created By Management system where this link was created (NMS or Physical links
EMS).
Parent Topic

4.13.4 Optics Tab

The Optics tab in the Link Properties dialog box lists the properties relevant for optical ports and colored
SDH/Ethernet ports.
Figure 4-46: Link properties - optics tab
Table 4-28: Link Properties dialog box - Optics tab

PMD (ps) Sets the maximum level of polarization mode dispersion (PMD) that
is acceptable for traffic on this link. Read-only for links with Internal
Connectivity Type.
Values may include:
 0 (default)
 0-40, with resolution of ±0.1
Allowed Fiber Loss Margin (dB) Sets the maximum fiber loss margin that is acceptable for traffic on
this link. Read-only for links with Internal Connectivity Type.
Values may include:
 1 (default)
Expected Fiber Loss for A to Z (dB) Amount of signal loss for this link, for traffic running in the A-Z
(forward) direction.
Values may include:
 0 (default)
Expected Fiber Loss for Z to A (dB) Amount of signal loss for this link, for traffic running in the Z-A
(reverse) direction.
Values may include:
 0 (default)
 N/A for unidirectional links.
Connectivity Type  Internal
 External
Parent Topic

4.13.5 ETH/MPLS Tab

Figure 4-47: Link Properties: ETH/MPLS tab
Table 4-29: Properties for Link dialog box fields - ETH/MPLS tab

Supported Tunnels Whether L-LSP and/or E-LSP and/or signaled tunnels are All MPLS links
supported. Values are:
See Tunnel Mode.
TE Mismatch Identifies the current Traffic Engineering mismatch status. All MPLS links
LAG Type Identifies the type of LAG configured here. Values include: ETY, EoS
 Load Sharing
 Protection (1:1)
 Empty (default)
For more information, see LAG Support.
LAG Distribution Values include: ETY, EoS
 Enabled Only relevant if
 Disabled LAG is in use
LAG Role Values include: ETY, EoS
 Master Only relevant if
 Slave LAG is in use
 Unknown


LAG Priority Values include: ETY, EoS
 Primary Only relevant if
 Secondary LAG is in use
 Unknown
LAG Protection State Values include: ETY, EoS
 Active Only relevant if
 Standby LAG is in use
 Unknown
STP Type Values include: ETY only
 None
 MSTP
 RSTP
STP Cost Integer value (1 to 200,000,000) ETY only
Parent Topic
4.13.6 Endpoints Tab

The Properties for Link window Endpoints tab is divided into two halves, each half listing the properties of
one endpoint. Each endpoint side includes three tabs, displaying the relevant General, L1 Connectivity,
Optics, and/or ETH/MPLS parameters of the endpoint ports associated with the current link. For MoG links,
the additional IP tab is displayed.
The same parameters are available in the corresponding Properties for Port window. They are included in
the Link Properties window for user convenience, with parameters of all the link's associated ports listed
side by side. This presentation enables operators to more easily determine why a link is inconsistent, or to
troubleshoot link problems such as different number of VCs on the ports.

For the parameter descriptions, see Port Properties.
Parent Topic

4.13.7 SRLGs Tab

The SRLGs tab shows the SRLG relations of MoT virtual links.
Several physical links in a specific segment may traverse a common duct. To avoid PathFinder choosing
physical links for main and protection paths that traverse the same duct when creating a trail, you can code
all those links with a common SRLG string. PathFinder then avoids selecting such a link for the protection
path as first priority. For more details, see the SRLG (Ducts) parameter in Link Properties - Advanced Tab.
An MoT trail is an SDH trail that traverses physical links. Being a virtual link, it does not show SRLG
indications - only physical links can be coded with SRLG strings. The SRLGs tab assists by providing the
following information about MoT trail relations to SRLGs:
 SRLG List pane: All the SRLGs associated to physical links used by the current MoT trail.
 SRLG Members pane: For each of these SRLGs, all the other MoT trails (besides the current trail) that
traverse links with the same SRLG.
The PathFinder automatically refers to this list and avoids choosing MoT trails from the SRLG Members
pane to protect each other. This tab is for information purposes only and can be used to clarify how
PathFinder's protection path choice was influenced by SRLG considerations.
This issue does not apply to any other MPLS links, except for MoT.
Figure 4-48: Properties for Link - MoT - SRLGs tab

Table 4-30: Properties for Link dialog box fields - SRLGs tab
Column Description
SRLG List
Type Auto or Manual (automatically or manually created SRLG per physical link).
SRLG Name Name of the SRLG. Unique name per network.
 Automatic SRLGs: SRLG name is the link name.
 Manual SRLGs: User-defined name; see SRLGs parameter in Link Properties -
Advanced Tab. (For MoT virtual links, manual SRLGs are added at the physical or
SDH level.)
SRLG Members (per selection in SRLG List pane)
Type Type of link having the same SRLG as selected in the upper pane.
Member ID Link identification of link having the same SRLG as selected in the upper pane.
Parent Topic
4.13.8 Radio Tab

Radio links have a Radio tab in the Properties for Link dialog box for the parameters specific to the radio
technology. Most of the radio link configuration is done in the EMS-BGF and then uploaded to LightSoft. For
further information, see the EMS-BGF User Manual.

Table 4-31: Properties for Link dialog box fields - Radio Tab
Actual Modulation The actual (current) modulation with which the Radio/EoR link
equipment is working. This is a dynamic attribute based
on the port Modulation Type attribute.
Remaining BW (Mbps) The bandwidth size that is not occupied by LO trails. Radio/EoR link
Min. ACM Working Point Minimum modulation level that the rink can work in. Radio/EoR link
Actual ACM Mode The link ACM Mode Radio/EoR link
Values: Enabled (on), Disabled (off)
Scheduled ACM Mode The desired ACM Mode. Radio/EoR link
This field is Read/Write only if the Scheduled Mode
value is Configured.
Actual Link Capacity (Mbps) The maximum bandwidth of the link. Radio/EoR link
This is a dynamic attribute based on the port Max
Payload BW attribute.
Scheduled Link Capacity The desired link capacity. Radio/EoR link
This field will be Read/Write only if the Scheduled
Mode value is Configured and ACM Mode is Enabled.
Scheduled Time Mode Values: Configured, Not Configured Radio/EoR link
If there is a scheduled configuration in the EMS, then
this field value is Configured and it is read-only.
(Canceling the scheduled configuration is only available
from the EMS.)
Scheduled Time The scheduled time Radio/EoR link
dd/mm/yyyy hh:mm:ss
Radio Protection The protection type of the ports (if exists) Radio link
Parent Topic

4.13.9 CAC Tab

The CAC values applied to MPLS ports when a new link is created in the MPLS layer are defined in the
Preferences window TE Configuration workspace; see TE Preferences in the Getting Started &
The CAC configuration on each endpoint port on an existing MPLS link can be changed through the
Properties for Link window CAC tab. For detailed parameter descriptions, see CAC Preferences in the
TIP: You can change CAC parameters for several links at a time via the Link List window; see
Configuring Link TE Parameters.
NOTE: For CESR 9700/9600 ports, the total bandwidth values (appearing in the Total (%)
column) are defined in STMS, and cannot be set in LightSoft. When modifying CAC for
CESR 9700/9600 ports, only the CAC ratio between reserved BW and reserved shared BW can
be modified in LightSoft. To change the Total % values, change the CIR values in the
appropriate Queue blocks in STMS.
Figure 4-49: Properties for Link - MoT - CAC tab

NOTE: MoG ports are used to connect to an IP MPLS network, and connects to the L3 VPN
service. It is possible for the bandwidth of the L3 VPN service to be smaller than port rate. In
such cases, the user must adjust the CAC table in the MoG port to match the L3 VPN
bandwidth.
For MoG ports, the sum of the Port Res BW (%) and Res Shared BW (%) should be adjusted to
the layer 3 VPN bandwidth/rate.
Parent Topic
4.13.10 TE Other Tab

The general TE configuration parameters for ports on new links in the MPLS Layer is defined in the
Preferences window TE Configuration workspace; see TE Preferences in the Getting Started &
The TE configuration on each endpoint port on an existing MPLS link can be changed through the
Properties for Link window TE Other tab. The TE Other tab also provides pathfinding parameters per
link-port.
TIP: You can change TE parameters for several links at a time via the Link List window; see
Figure 4-50: Properties for Link - MoT - TE Other tab

Table 4-32: Properties for Link dialog box fields - TE Other tab
Field Description
FRR Parameters (applying per link endpoint)
FRR Mode Sets how FRR switching from the protected tunnel is performed on each port of the
link. The default mode for the network is set in system preferences; see TE
It can be changed here in the same way on a per-port basis.
Reversion Sets how reversion back to the protected tunnel is performed on each port of the
link. The default mode for the network is set in system preferences; see TE
Hold-Off Time Number of seconds delay (0 to 10 seconds in 0.1 second increments (default 0 sec))
(sec) before FRR switching to protection is implemented. The default mode for the
network is set in system preferences; see TE Preferences in the Getting Started &
Wait to Restore Number of seconds delay (0 to 12 minutes in 1 minute increments) before automatic
Time (min) reversion from the Bypass back to the protected tunnels after a failure is repaired.
The default mode for the network is set in system preferences; see TE Preferences in
the Getting Started & Administration Guide.
Default Sets the FRR parameters back to their system preference default values; see TE
Does not affect the Link TE Metric and Link Length values.
Path Finding Parameters (applying per link)
Link TE Metric A link's Link TE Metric is the cost of the link. It is used in Min Metric tunnel
optimization process that would yield a minimum tunnel cost in tunnel pathfinding.
The same cost applies to both link directions. It is automatically calculated as:
TE Reference Rate / Port Rate, where:
 TE Reference Rate - highest possible port rate, as defined in MPLS TE Parameter
Preferences; see TE Preferences in the Getting Started & Administration Guide.
 Port rate - nominal port rate assigned in the EMS.
For example, link cost = 10000/2500 = 4.
Thus the lower the port bandwidth, the higher the implied link cost. This value can be
edited to override the calculated value. Takes the highest possible rate port, and
divides this by the nominal rate of the port. So the smaller the port rate, the higher
the resulting metric. For details of how Min Metric uses this, and the other
parameters involved in the process, see Minimizing Tunnel Cost in the Getting
Tip: The Link TE Metric can be adjusted for several links at a time via the Link List
window Reconfigure Link Metric option; see Operations on Link or LE List Objects.
Link Length Length of this link; the sum of cable segments through which this link traverses.
Parent Topic

4.13.11 EXP Tab

The Link Preferences window EXP tab enables you to change the EXP mapping values on MPLS ports (color
combinations of the CoS per tunnel direction) on an existing MPLS Layer link, or assign a different mapping
to In EXP and Out EXP per port.
The window automatically acquires the EXP values set in the system preferences; see EXP Mapping
Preferences in the Getting Started & Administration Guide, and uses the same value for both In EXP and
Out EXP.
In EXP and Out EXP refer to the inside and outside EXP mapping parameters of the port (In EXP for tunnels
incoming to the port, and Out EXP for tunnels outgoing to the port).
EXP Mapping configuration is relevant only for MPLS links supporting EXP Mapping and traversing E-LSP
tunnels; see Tunnel Mode.
TIP: You can change EXP parameters for several links at a time via the Link List window; see
Figure 4-51: Properties for Link - MoT - EXP tab
Table 4-33: Properties for Link dialog box fields - EXP tab
Field Description
For each endpoint - Port as a whole and each CoS of the port:
Select CoS Opens a dropdown list showing 16 CoS - color combinations opens (CoS 0 to 7
x colors green and yellow). The currently selected CoS-color combinations are
checkmarked. You can change the selections as needed. Up to eight
combinations may be selected at any one time. For more details, see
Configuring EXP Mapping.
CoS and Color CoS - color combination for which an EXP mapping is defined, as determined
by Select CoS dropdown list selections.

Field Description
In EXP In EXP mapping corresponding to a CoS - color combination, applying to the
selected endpoint port. The mapping can be changed per In port and Out port
on an existing link using the EXP selector icon. For more details, see
Configuring EXP Mapping.
Out EXP Out EXP mapping corresponding to a CoS - color combination, applying to the
selected endpoint port. Same details apply as for In EXP.
Default Sets the system preferences default values; see EXP Mapping Preferences in
Parent Topic

5 Provisioning SDH and EoS/MoT Trails
This section describes how to create SDH and SDH-based Ethernet trails in the Create Trail window and
planned trails in the Plan Trail window, using a variety of trail creation options and protection mechanisms.
Optical trail creation is described in Provisioning Optical Trails.
NOTE: You can define how trails are created in LightSoft, which fields are visible in various
parameter windows, and how PathFinder should rank the various optimization criteria when
creating a new trail. See Trail Creation Management Preferences in the Getting Started &
SDH-based Ethernet trails comprise:

 Ethernet over SDH (EoS) trails, which are SDH high order (HO) and low order (LO) trails and are the
infrastructure for L1 and L2 Ethernet services.
 MPLS over Transport (MoT) trails, which are SDH HO and LO trails and are the infrastructure for MPLS
tunnels.
NOTE: Creating EoS trails that traverse the OTN layer (as needed in the case of certain data
combiners) is done in one of the following ways:
 By Discovery using the Discover Optical Trails feature. The EoS trail that traverses the
optical layer is created in addition to the optical trails. See Creating Optical Trails Through
Discovery.
 By admitting the HO SDH trail using the Trail Consistency Indicator window; see
Performing Trail Synchronization.
OPTIONAL FEATURE: The SDH and EoS trail provisioning mechanism is subject to the SDH
layer being enabled. This is an optional feature. If not purchased, the functionality and related
menu options are unavailable.
Trails have a rate and a payload based on their endpoints (for example, a rate of VC-3 and a payload of E3).
For a list of supported trail rates and payloads, see Supported Rates and Payload Types in the Supporting

LightSoft® User Guide Provisioning SDH and EoS/MoT Trails
5.1 Trail Concepts

Some key trail concepts are described here. Others are explained in context.
Parent Topic
5.1.1 Trails and Virtual Links

Trails that provide a logical connection for a client technology layer are displayed as virtual links in the
client layer - a special type of topology link which is logical, not a physical connection on the native layer.
For basic information about virtual links, see Link Types.
Virtual links are created either automatically or with some user intervention. The following are some
examples.
SDH as Client of Optical Automatic Virtual Links

SDH networks can include path segments where direct physical connections are impractical because of
distance or need for aggregation. In such cases, optical WDM segments are introduced into the SDH
network. When an optical LightPath (LP) trail with SDH payload type is created, a virtual link is created
automatically in the SDH layer if the LP is bidirectional and has both endpoints in the SDH layer. This allows
a consistent logical SDH link, even where there is an underlying WDM network, and allows easy navigation
between the SDH network and the underlying WDM network.
Ethernet Layer as Client of SDH Virtual Links for L1 and L2 (EoS) Endpoints
When EoS trails are defined in the SDH layer, virtual links can be created in the ETH/MPLS layer, assisting
users to visualize data services between data ports:
 Layer 2 (EoS and MoT) port endpoints - a virtual link is created automatically.
 Layer 1 EoS port endpoints - virtual links are user-driven. You can create a virtual link by selecting the
EoS trail's View on ETH/MPLS Layer checkbox; see EoS/MoT Configuration Pane.
Ethernet as Client of Optical Optional Virtual Links

When an LP trail with GbE or other non-SDH payload type is defined, virtual links are user-driven. You can
create a virtual link in the ETH/MPLS layer by selecting the LP trail's View on ETH/MPLS Layer checkbox;
see Provisioning LP Trails. If the GbE/10GbE payload type is MoE or L2 ETY, the virtual link is not user-driven
and is always visible.

X and Y Virtual Links

X and Y trails project X and Y virtual links on other layers:
 OCH X and Y trails as virtual links in the OCH layer; see OCH X and Y Virtual Links.
 LP X and Y trails as virtual links in the Ethernet and SDH layers; see LP X and Y Virtual Links.
NOTE: The View on ETH/MPLS Layer checkbox can be selected in the Create Trail window in
the course of individual LP trail creation, or selected later by opening the trail in the Trail List
window's Basic Trail Parameters Pane standard view.
The option cannot be selected using the trail Edit window.
Parent Topic
5.1 Trail Concepts
5.1.2 SRLG and Other Shared Resource Minimization in Path

Selection
LightSoft promotes diversity paths in route selection. For example, wherever possible, the PathFinder
algorithm avoids routing protection paths on resources with the same shared risk link groups (SRLGs) (as
well as other shared network resources - MEs, cards, or links) as the paths they protect. When this is
unavoidable, you are notified of the unprotected area. PathFinder similarly avoids setting diverse routes on
VCAT trails that traverse the same network resources. Resource-sharing avoidance rules are applied in the
same way for both protection path and diverse route selection.
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. If an event involving the common entity
occurs, all the links of an SRLG could potentially be disrupted. For details how SRLGs are specified in
LightSoft, see Shared Risk Link Groups (SRLGs).
The presence of SRLGs and other types of resource sharing have implications for LightSoft PathFinder trail
route selection processes, as described in this section. For tunnel PathFinder implications, see SRLG
Avoidance in Bypass Path Selection.
Resource-sharing avoidance rules are not enforced for trail acquisition or manual path selection. However,
information about each type of resource-sharing involving a trail can be viewed, regardless of how the trail
was created; see the Number of Shared MEs, Links, SRLGs, and Cards parameters in the trail parameters
Trail Properties Pane.
For various methods of viewing diversity in the network, see Viewing SRLG and Other Diversity Information.
Parent Topic
5.1 Trail Concepts

5.1.2.1 Protected Trail SRLG Intersection Minimization

When evaluating potential protection paths, the PathFinder algorithm first looks for routes with the lowest
SRLG intersections with the main path, then those that reduce other protection-affecting attributes, and
finally those that satisfy user-defined criteria, as follows:
1. PathFinder first looks for a subset of paths that minimize SRLG. In the following example, the topmost
route 1-2-3-4-5 is the Main path, while the other two routes are possible protection paths. The route
1-6-7-8-5 has two SRLG intersections with the main path (S1 and S2). Route 1-9-10-11-12-5 has only
one SRLG intersection (S1). The latter, having fewer SRLG intersections, is preferred at the cost of
extra hops.
2. If potential protection paths are equivalent in terms of SRLG intersections, the algorithm minimizes
intersections in other protection-affecting attributes, in the following order of priority:
 Segments
 Server trails
 MEs
 Optical segments (optical trails if searching for SDH trails)
 Card locations (ports in different cards preferred over ports in the same card)
If paths in a characteristic are equivalent, the next characteristic is checked until the preferred paths
are identified. The characteristics and their order of priority always apply in the indicated order.
3. After a subset of least-intersection paths is identified, the paths are then checked against
user-specified criteria and their associated tolerances, until the optimal path that PathFinder uses for
the trail is identified; see Trail Management SDH Constraint Preferences in the Getting Started &
Parent Topic
5.1.2 SRLG and Other Shared Resource Minimization in Path Selection

5.1.3 Connection Admission Control (CAC)

Connection Admission Control (CAC) mechanisms ensure effective QoS delivery by MPLS networks.
At the MoT trail level, CAC ensures that SRLG diversity-increasing operations, or bandwidth-decreasing
operations that would leave insufficient bandwidth for existing tunnels on the virtual link, are avoided. As
well, potentially CAC-affecting actions on MoT links (including indirect actions such as changes to a server
trail used by the link) protected by bypass tunnels are always disallowed; the bypass tunnels must be
deleted first.
TIP: The bypass tunnels can be deleted as a batch operation through export to XML, then
reimported after the potentially CAC-affecting action is completed. For details about exporting
and importing tunnel data, see Batch Tunnel Operations.
Parent Topic
5.1 Trail Concepts
5.1.4 LAG Support

LightSoft supports link aggregation groups (LAG) used for two types of purposes:
 Load Sharing LAG divides the traffic load between two LAG ports located on a single card, enabling
higher bandwidth connectivity. Load Sharing LAG is assigned to EoS or ETY ports and links via the EMS.
In Load Sharing LAG, multiple parallel EoS trails or ETY links are treated as a single (virtual) link.
Services can only be defined on the LAG master port, which serves as the service endpoint. In
LightSoft map views, the LAG link is displayed as a multilink with a label indicating the number of trails
involved. The LAG multilink behaves like a single link for service provisioning.
Load Sharing LAG can be used to link an MPLS network and a PB network through multiple local EoS
trails or ETY links, provided they are all members of the same LAG. For this purpose, the multiple trails
or links are considered a single link; see Typical Valid Network Topologies.
If Load Sharing LAG is used in the context of dual homing protection, only EoS or ETY I-NNI ports can
be used and the LAG master ports must be connected before slave ports. LAG can be configured for
any leg of any protection mechanism (such as ERP or BPDU tunneling). However, only the LAG master
link is used for service management purposes, and slave links are ignored. For information about LAG
configuration in a BPDU tunneling network topology, see Creating Internetwork Dual Homing.
 Protection LAG (1:1) provides protection at the service level (similar to MS Linear protection on the
SDH level). LAG 1:1 sends all the traffic through the primary port. If that port fails, then all traffic is
shifted to the secondary port. Compatible equipment currently supports protection LAG on ETY ports
only.
In Protection LAG, the two participating ports are both located on a single card.Both ports are
configured as master ports.
For both Load Sharing and Protection LAG, LightSoft indicates if a data port is a member of a LAG group, the
name of that group, as well as all the ports belonging to the same LAG group; see the LAG parameters in
ETH/MPLS Port Types ETH/MPLS Tab.

Note that LAG services can only be configured for ports located on cards that support these services. For
example, Protection LAG 1:1 is supported by the MCS30 and MCS50 card families. Ports are first configured
at the EMS level, and only then can the trails and services be provisioned at the LightSoft level. The
following general conditions apply to LightSoft trail and service creation with LAG:
 LAG compatibility is required. Both links must utilize endpoints that are all members of the same LAG.
If any of the participating endpoints is later removed from that LAG, the link becomes inconsistent and
unavailable for service provisioning. (Note that this compatibility rule does not apply if one end of the
link is located in a UME. The UME does not have to meet the LAG compatibility standard.)
 Endpoints must be consistent: both masters, or both slaves, or both with the same priority, depending
on the type of LAG.
Parent Topic
5.1 Trail Concepts
5.1.5 CNM and Trail Provisioning

The CNM feature provides an infrastructure that meets the needs of both SP and CNM users, as reflected in
the view and mode of operation in various LightSoft modules; see VPNs and CNMs and Provisioning Mode.
CNM users have access to an SDH Server Trail topology layer, which provides a graphically convenient view
of the high order VC-4 server trail topology as virtual links consistent with CNM resource permissions. The
SDH Server Trail layer allows a more meaningful view of the SDH topology used by low order traffic, as it
represents the logical connectivity of the high order VC-4 network. This is useful when the CNM user plans
new trails or edits trails.
For example, suppose the SP user creates a high order trail between the CNM's elements A and B that
traverses a non-CNM element Z.
In the SDH layer, the CNM user sees only the two elements, A and B, with no connecting link since the
element Z is not part of the CNM. Although the CNM user can create a client trail by selecting A and B
endpoints, specific resources cannot be chosen since the link is not visible.
In the SDH Server Trails, CNM user sees the A and B endpoints and virtual link between them.
The CNM user is then able to create a client trail over A and B. Specific segments and resources can be
selected on the virtual link, exactly as when the SP creates a trail. Although the CNM user does not have
permissions over element Z, he is able to create a client trail between elements A and B since client trails
only need permissions over endpoints.
Parent Topic
5.1 Trail Concepts

5.1.6 Subnet Uploading from the EMS level

When network operators provision a new trail through LightSoft, the trail can only be provisioned using NE
objects that are currently recognized and synchronized between the EMS and NMS levels. LightSoft must
be fully informed of the underlying NE status, including knowledge of all ports and cross connections
configured in the NE [subnetwork data], before being able to use those ports and cross connects to
provision a trail. If the NE information has not been uploaded from the EMS to the NMS, then provisioning
attempts using those objects will fail.
Therefore, LightSoft provides operators with a simple visual sign indicating if the MEs on the map are not
up-to-date and therefore not yet available for trail provisioning. The ME icon is outlined with an extra dark
blue border around the NE or LE icon, clearly indicating that this object should not be selected for
provisioning at this point. The outline is also added to group icons that include the not-yet-uploaded nodes.
Icons are so marked on all map layers.
By default, NE information is uploaded automatically to LightSoft every time a connection is established (or
re-established) between LightSoft and the NE. If for some reason the NE information is not current, the
operator can force an ME data upload using one of the commands in the Force Upload group on the
System tab.
Parent Topic
5.1 Trail Concepts
5.1.7 LightSoft ASON Support

This introduction provides a general explanation of an ASON network, and then outlines our unique ASON
offering.
An Automatically Switched Optical Network (ASON) is a dynamic signaling-based policy-driven control over
OTN and SDH networks via a distributed (or partially distributed) control plane, which provides
auto-discovery and dynamic connection set-up.
An ASON network provides:
 Improved support for current end-to-end provisioning, re-routing and restoration.
 New transport services such as bandwidth on demand, rapid service restoration for disaster recovery,
and switched connections within a private network.
 Support for a wide range of narrowband and broadband clients signals, such as: SDH, IP, Ethernet,
ATM, Frame Relay, ESCON, FICON, Fiber Channel, and Audio/Video.

The XDM/NPT ASON card enables the configuration of advanced traffic protection and reactive restoration
that takes into account the current state of the transport network.
LightSoft’s ASON implementation enables the configuration of LightSoft-provisioned trails with ASON
protection schemes. LightSoft displays the ASON domain in the physical layer topology, and provides a
variety of monitoring tools.

An example of an ASON implementation scenario is shown in the following figure.

Figure 5-1: ASON sample implementation scenario (Source ITU-T)
An example of an ASON implementation scenario is shown in the following figure.

Figure 5-2: ASON sample implementation scenario (Source ITU-T)

NOTE: LightSoft's ASON implementation uses a control plane mechanism, inherent in

ASON-enabled NEs, to seamlessly activate ASON in the network. The control plane manages
protection and restoration of ASON trails in the network.
During the time that traffic is restored via the control plane, ASON-associated entities are
controlled exclusively by ASON, independent of EMS or LightSoft management systems.
LightSoft's role with respect to the problematic path is then limited to being informed about
the alternative path that ASON found - monitoring and displaying reroute or other changes
(see Monitoring the ASON Domain), thereby enabling the operator to correct the problem.
After the problem is corrected, ASON automatically frees the resources for the alternative
path, and all associated services/traffic revert to the original LightSoft-provisioned path.
During all of this process, LightSoft's management control over all other network objects is
unaffected.
For more information about ASON, see the ASON User Guide.
Parent Topic
5.1 Trail Concepts
5.2 Trail Creation Options

A wide range of features and granularities are available for trail creation, including:
 Rich user-customizable PathFinder optimization criteria.
 EoS/MoT concatenated trails with VC-4, VC-3, and VC-12 granularity.
 Diverse routing for EoS/MoT trail paths, taking full advantage of Link Capacity Adjustment Scheme
(LCAS) by configuring the EoS/MoT trail to carry traffic over different nonshared fibers.
 Extra traffic routes to select pre-emptable resources within MS-SPRing configurations. Supported for
EoS trails (all rates) and VC-4 trails.
There are several methods for creating SDH or Ethernet trails:
 Using the Create Trail or Plan Trail windows, as described in Creating SDH and EoS/MoT Trails and
Planned Trails.
 Acquiring trails from the EMS as described in Synchronizing Trails.
 XML Import, as described in Importing Trails.
Creating Trails Using the Create Trail Window

The Create Trail window enables you to quickly create SDH or EoS/MoT trails. You can create a trail by just
selecting trail endpoints and accepting default values. You can also specify detailed trail parameters if
needed. Many of the parameters are retained from the previous trail creation operation, for example, rate
and protection. Other values are calculated by the system, for example, the trail label. The Create Trail
window procedure includes the following capabilities:
 Provisioning Bundle Trails: Multiple SDH trails can be built automatically in a single operation using
endpoints on the same cards. After you select the cards and the number of trails to be set up (Bundle
Size), LightSoft sequentially creates the trails without further operator intervention until the series is
completed, a card runs out of free ports, or a resource runs out of free capacity (whichever comes
first).

 Coupling Trails: Two more trails may be associated as a single service using the Private ID attribute.
You should assign the same ID to the trails. When viewing the trails in the Trail List window, sort the
list lines by Private ID to group the trails that have the same Private ID; see Sorting List Lines.
Creating Planned Trails

LightSoft enables networks to be designed ahead of time through "planned" trail operations. The Plan Trail
window enables you to fully provision new trails for future use even while their prospective resources are
still occupied. Trails can similarly be planned for editing or removal without immediately affecting the
network. The trail definitions are exported to XML for implementation at a later time; see Planned Trails
and Exporting Trails.
Acquiring Trails from the EMS

For SDH trails, see Synchronizing Trails.
Importing Trail Definitions from XML

Trail definitions of trails to be created can be imported from an XML file that contains the new trail
parameters. The XML files can be imported either through LightSoft or via UNIX; see Importing Trails.
Parent Topic
5.3 Creating SDH and EoS/MoT Trails

You can define SDH and EoS/MoT trails directly from LightSoft using the Create Trail window; see Creating
a Trail. Similar windows are used for editing or viewing existing trail parameters; see Performing Actions on
Trails and Links. (For information about Optical trail creation, see Introduction to Optical Trail Provisioning.)
Creating a trail or trail bundle between linked elements in LightSoft consists of the following main steps:
 Defining trail parameters
 Selecting trail endpoints
 Assigning resources
You can create a trail by simply accepting default parameter values or you can select specific values. The
new trail is built by the PathFinder algorithm according to the selected optimization criteria; see Trail
Management SDH Constraint Preferences in the Getting Started & Administration Guide.
New trails created using the Create Trail window are generally for immediate implementation in the
network, but can also be exported to XML to be implemented later. However, it may be more practical to
use the Plan Trail window for network planning purposes as this allows using occupied resources in the
provisioning process; see Planned Trails.
MoT and EoS trail creation and editing may warn about or disallow actions that would result in invalid
topologies in the MPLS layer. Specific validation rules may be disabled on a system-wide basis to support
unanticipated topologies.
A low order SDH trail is a client of a VC-4 server trail. Therefore, VC-4 server trails must be created before
you can create SDH client trails.

NOTES:
 SYNCOM NEs may require links at the EMS level in order to define trails on them.
 When creating a trail, LightSoft uses only objects in resource domains assigned to your
user group (allowed by your user group's profile).
 EoS/MoT trails may require actions at the EMS level before starting and after completing
the trail creation steps; see EoS/MoT Configuration Pane.
Parent Topic
5.3.1 Before Starting EoS/MoT Trail Creation

EoS/MoT trail provisioning assumes that ports are configured correctly in the EMS. The following are some
attributes that you should verify are set up correctly:
 Granularity (server layer type – VC-4, VC-3, VC-12): Verify that the configured granularity is correct.
The default may be changed via the EMS.
 VCs allocated: Define the number of VCs allocated (# of VCs in a VCG).
 Other: Check that the default values in LightSoft are correct for the current circumstance. As part of
EoS/MoT trail creation, the LCAS mode and tagging format should be verified for consistency.
 LCAS type (LCAS, Proprietary LCAS, or DPC) and enabled/disabled status.
 RSTP: Enabled or disabled.
 Tagging format: QinQ or EIS QinQ.
See also ASON Trail Provisioning.
TIP: Direct interaction with the EMS system is often not necessary, since many attributes:
 Come with defaults specifically designed for the majority of cases and seldom do you need
to implement different values.
 Are validated by LightSoft as part of the trail creation process.
Parent Topic

5.3.2 Creating a Trail

SDH, EoS/MoT, and ASON trails are created in the Create Trail window; see Create Trail Window.
When creating a trail, LightSoft uses only objects in resource domains assigned to your user group (allowed
by your user group's profile); see Managing User Groups.
Conditions apply for trail creation in a LAG configuration, such as pre-configuration of ports in the EMS as
LAG. For details, see LAG Support.
Creating ASON-protected trails in LightSoft is similar to SDH trail creation, using the same windows, with
only minor differences in procedure. The specific inputs required for ASON are set in the Basic Trail
Parameters pane; see Basic Trail Parameters Pane. ASON trails are created using the SDH or Physical layer.
Conditions apply to ASON trail provisioning; see ASON Provisioning Conditions.
To create a trail using the Create Trail window:

1. Select the SDH topology layer.
You can also start SDH (including ASON) or EoS/MoT trail creation in the Physical (site) layer if the
User Preferences (Trail Management) window Default Provisioning Layer parameter is set to SDH.
(See Trail Management Appearance Preferences in the Getting Started & Administration Guide.)
2. Optionally select in the main window the objects containing the endpoints of the intended trail. This
opens the Create Trail window with those objects and their associated links. Otherwise, the window
opens with all the objects in the current view (for example, the currently expanded group).
(When the PathFinder algorithm searches for trails, it relates to the relevant topology, not only to the
displayed elements.)
3. On main window Trails tab, in the General group, click Create Trail. The Create Trail window opens;
see Create Trail Window. The first time the Create Trail window opens in a session may take longer
than it does subsequently.
4. Enter the trail parameters. In particular, check the trail rate. You can accept the default values (for
example, if the required trail rate is the same as the previously defined trail rate), or specify other trail
parameters, as follows:
 Basic Trail Parameters Pane
 Advanced Trail Parameters Pane
 EoS/MoT Configuration Pane
NOTE: You can create additional trails with the same route details on the same segment
without having to re-enter the trail parameters; see Step 8.
5. In the Path Completion Method pane, select either Auto Complete (default) where PathFinder will
automatically suggest an optimal path for the trail based on your minimum link selections, or Explicit
Selection where PathFinder only relies on your link specifications and does not attempt to look for a
path; see Path Completion Method.
6. In the window map, select endpoints for the trail. Endpoint details are automatically listed in the
Endpoints List pane as each endpoint is selected; see the procedure in Endpoints List Pane.

7. (Optional) Select the links and resources that you want the trail to use. You can either fully select all
the segments of the trail, or let PathFinder find the route based on a partial selection of segments or
no selection at all. If any required segments are not selected, LightSoft creates the trail according to
PathFinder optimization considerations.
If you want to select some or all segments for the trail:
a. If the trail is protected, in the window toolbar, select the path for which you want to select
segments, whether Main or Protection, or Both.
.
b. In the window map select the specific segments that you want the trail to span (using the SHIFT
key). This is useful if you are creating a long trail that spans more than one segment. Select the
resources for the trail (according to their availability):
High order trail - see the procedure in Select Segment Pane.
Low order trail - see the procedure in Select Server Trail and Services Panes.
As you select the topology links that the trail will use, they are highlighted in the map view and listed
in the Resource Tree pane; see Resource Tree Pane. Protection trail links are listed under the
Protection node.
8. (Optional) Click Complete trail . LightSoft searches for a path using your selections. When one is
found, its details are displayed for you to review. You can go back and modify the trail parameters if
needed.
At the end of the Complete processing, a message window describes the result of the operation and
lists nonfatal errors. See Performing Trail Operations.
If the Complete step fails, perform the verifications listed in the section Diagnosing a Create Trail
Failure.
9. (Optional) You can create an additional trail with similar route details on the same segment without
having to redefine the trail properties:
 After completing the current trail (previous step), click Store current trail as template .
 Activate or export the trail, as described in the next two steps.
 Create an additional trail, as described in the final step.
NOTE: Do not close the Create Trail window before creating the additional trails, as this
erases the template.
10. If you want the new trail (or SDH trail bundle) to be implemented immediately, click Activate trail
.
If you want to export to XML instead, postpone activation and go to the next step.
Bundled trails (SDH trails): The Progress bar lists the current trail just built and the number of trails
built so far. Click Abort to stop the bundle operation if necessary.
At the end of the Activate processing, a message window describes the result of the operation and
lists nonfatal errors. See Performing Trail Operations.
If the Activate step fails, perform the verifications listed in Diagnosing a Create Trail Failure.

NOTE: If Complete Trail was not performed before or if it is followed by any potentially
path-affecting action (such as a change of endpoint), then it is automatically
performed/repeated as part of the Activate process. (If no such actions follow the Complete
step, a fast activation process applies that does not duplicate the Complete processing.)
The message "Resource allocation failed after complete" may mean:
 LightSoft failed to assign concrete resources after trail path completion.
 Resources that were free at path completion became occupied prior to activation.
 Internal problem prevented LightSoft assigning the resource.
0)
11. If you want the new trail (or SDH trail bundle) to be exported to an XML file for implementation in the
network at a later time, click Export in the window toolbar. The Export Trails dialog box opens.
Continue the procedure as described in Exporting Trails at Step 4.
12. If you want to create an additional trail with the same route details (you clicked Store current trail as
template after the trail was completed):
a. Select Clear trail contents to clear the trail contents. (This step is required if Show
Activated Trails is set to ON.)
b. Click Restore trail from template .

c. Select the endpoints again.
d. On the links connecting to an ME/UME, select the TUs.
e. Perform Step 4 through 10 to implement (or export) the additional trail. The trail parameters and
route selection will already be set to the previous trail's settings. You only need to implement the
differences in settings, if any.
f. If another similar trail is required, repeat this step.
Parent Topic
5.3.3 Implementing Diverse Routes

In diversely routed VCG with LCAS protection, each VC in the VCG is routed via a different path. If one or
more of the VCs fail to reach their destination due to a failure in the network, the LCAS mechanism
reestablishes the trail with the remaining VCs, enabling service to continue at a capacity which is less
effective. This scheme provides protection for part of the capacity without using any of the capacity for
protection. By offering LCAS-based service, the operator provides a guaranteed and BE service without
allocating any extra bandwidth or resources for protection, thereby enabling a more flexible and efficient
cost structure.
LCAS functionality enables configuration of the EoS/MoT trail to carry traffic over different nonshared fibers
(diverse routes).

When Diverse Routes is selected in conjunction with Current protection, all the diverse routes are SNCP
protected. Specific trail resources can also be assigned to separate route numbers. In this case, the
Resource Tree categorizes resource information by route number instead of by Main/Protection. If Diverse
Routes is not selected, all resources are allocated to the same route or link (Route #1).
For data trails with diverse routes, DRI protection can also be implemented (see Creating a Data DRI Trail).
To create a Diverse Route:

1. In the Create Trail window, select the trail endpoints.
2. In the Basic Trail Parameters area enter the following:
 VCAT Size: enter a VCAT size greater than 1.
3. In the EoS/MoT Configuration area, select the Diverse Routes checkbox and enter the following
information:
a. In the dropdown box select either At Least or Exactly, and in the adjacent box, select the
number of routes that you want to create. (This number cannot exceed the specified VCAT size.)
b. In the Min VC paths/route field, enter the minimum VC size of each route. (This number cannot
be greater than VCAT size multiplied by the number of routes).
c. (Optional) In the MS-SPRING Extra Traffic Routes field, enter the number of routes that require
extra traffic.
4. To define a route:
a. In the Path area, select a path type.
b. In the Endpoints & Paths tab Select Segment area, in the Belongs to route No field, enter a
number for the route.
c. Select the segment(s) that you want to include in the route and the associated resources, if
required (see Create trail).
5. Repeat the previous step for each route you want to define. The routes are displayed in the Resource
Tree.
Parent Topic

5.3.4 Diagnosing a Create Trail Failure

If the Create Trail operation fails, perform the following verification steps.
If the action failed at the Completion stage

1. Verify the message shown immediately after the failure or the error message in the Operational
Results Info window.
2. Check if all the segment selections and endpoints are correct (MSP, resources, etc.).
3. Verify that all the relevant elements and subnets are uploaded and managed by LightSoft; see Subnet
Uploading from the EMS level. This is apparent from the Usability State of the element as reflected in
the map view or in the applicable object properties window. You can also open a UNIX window and
run the NMSState utility.
4. Check the parameters selected in the Create Trail window.
If the trail failed at the Activation stage (Completion succeeded)

2. Check if all cross connects were created at the EMS level.
3. Verify that all the relevant subnets are uploaded in EMS and LightSoft. To do this, open a UNIX
window and run the NMSState utility.
4. Check the TCI counter flag in the LightSoft main window. If it is red, perform trail synchronization and
check the differences between LightSoft and the EMS or a red flag in EMS-SYNCOM. The elements
that the XC failed on will be shown in the Result window, described in Performing Trail Operations.
5. If an NE in the trail was disconnected during trail creation or a craft connected and the resulting trail
is in an incomplete state, use Reconnect to send the missing XCs to the network.
Parent Topic

5.4 Create Trail Window

The Create Trail window provides a graphical representation of all or preselected LEs in the currently active
topology layer, as well as information and configuration panes.
Figure 5-3: Create Trail window
The Create Trail window map view provides a graphical representation of all or preselected objects in the
currently active topology layer. The window includes configuration panes, organized in two tabs:
Trail Parameters tab

Figure 5-4: Trail Parameters tab
 Basic Trail Parameters Pane : Enables configuration of trail parameters, for example, rate,
directionality, and protection characteristics.
 Advanced Trail Parameters Pane : Enables configuration of more specific optional attributes of the
new trail.
 EoS/MoT Configuration Pane : Sets the parameters of EoS and MoT trails.
 Trail Properties Pane : Displays detailed information about a selected trail after it is completed or
activated.

Endpoints & Path tab

Figure 5-5: Endpoints & Path tab
 Path Completion Method : Offers a choice of automatic or manual path completion methods.
 Endpoints List Pane : Shows the trail endpoint selections.
 Select Segment Pane : For selecting the segment from which trail resources are selected.
 Select Server Trail and Services Panes : Appear when a low order rate is selected in the Basic Trail
Parameters pane. Used for selecting resources for the low order trail and showing the trails on the link
not currently serving as server trails.
 Select Resource Pane : For selecting trail resources.
 Resource Tree Pane : Displays resources for a trail in a tree hierarchy under Main and Protection
categories.
 Resource List Pane : Lists details of selected trail resources individually or by category.
NOTE: This section focuses on creating SDH and EoS/MoT trails. The Create Trail window
includes different fields and options when creating optical trails. For information about optical
trail creation, see Introduction to Optical Trail Provisioning.
Parent Topic
5.4.1 Create Trail Toolbar

The window includes the following toolbar components:
 Path selector - selects the type of path (route) to which the selected new trail attributes will apply:
Main, Protection, or Both.
 Toolbar icons – commands applicable to the Create Trail process.
 Information bar - shows your current Basic Trail Parameters pane selections. These remain visible
when the panes are scrolled. The trail Label and Customer are shown in brackets.
 Progress bar (under the map) - lists the current trail just built and the number of trails built so far
(applicable only if bundled trails are being created).
 Abort – in the progress bar, for stopping the bundle provisioning operation if needed.

Table 5-1: Create Trail window toolbar icons

Remove all resources Removes all resource selections (for example, endpoints
and trail paths), but keeps any user changes to trail
parameters (for example, Rate, Protection, Label,
Customer, and Directionality).
Clear trail contents Clears all trail selections.
Reset trail parameters to Resets the parameters of the trail to the system's original
original defaults defaults.
Export to XML Exports the trail configured in the Create Trail window to
an XML file, leading into the export procedure described
in Exporting Trails. Exported data can be imported to
create trails at a later time if resources are available; see
Importing Trails.
Show operation results Displays detailed results of the last operation; see
information Performing Trail Operations.
Store as template Stores the current trail route as a template, enabling you
to create similar additional trails during the current
session. (The template is stored in temporary memory of
the user session and is not saved.)
Restore from template Restores a trail from a template, enabling you to create
additional trails with similar resources and routes as the
selected stored trail during the current session.
Show activated trail If selected (toggled on), by default, the trail is shown in
the window map immediately after activation.
Complete trail Causes the PathFinder algorithm to search a route for the
trail based on the current selections and network
configuration. If successful, the complete path appears in
the map with its associated resources (whether entered
manually or assigned automatically). Nothing is saved to
the database at this point or sent to the EMS, and cross
connects are not yet created.
Activate trail Causes implementation of the new trail in the network. If
Complete Trail was not yet performed, it is included
automatically in the Activate process.
Activate causes the EMS to send information to the
element itself, cross connects to be created in the
element, and trail information saved in LightSoft and EMS
databases. Live traffic can now traverse the trail.
Parent Topic

5.4.2 Map View

The map view provides a graphical representation of all or preselected LEs in the currently active topology
layer. It is used in the process of trail endpoint selection, and assists visualization of the Create trail process.
You can also perform operations on selected objects and links in the map view using shortcut menu options
in the same way as from within the LightSoft main map view, as described in Managing Elements and
Groups.
Parent Topic
5.4.3 Trail Parameters Tab

The Trail Parameters tab provides trail parameter entry panes.
 Basic Trail Parameters Pane : Enables configuration of trail parameters, for example, rate,
directionality, and protection characteristics.
 Advanced Trail Parameters Pane : Enables configuration of more specific optional attributes of the
new trail.
 EoS/MoT Configuration Pane : Sets the parameters of EoS and MoT trails.
 Trail Properties Pane : Displays detailed information about a selected trail after it is completed or
activated. An example is shown in the Trail Properties pane. For detailed information about the pane
contents and associated procedures, see Trail Properties Pane in the Trail List Window.
Parent Topic

5.4.4 Basic Trail Parameters Pane

The Basic Trail Parameters pane enables you to configure the most basic attributes of the trail. You can
create a trail by specifying only the Label, Customer, and Rate, and accept the default values/parameters
described in the other panes.
This pane also includes the configuration of the new trail's protection scheme.
NOTE: VC-4-4v and VC-4-16v trails do not support DNI and/or DRI patterns. Do not select the
DRI and DNI checkboxes for them (LightSoft will find such routes but the trail activation will be
rejected).
Table 5-2: Basic Trail Parameters pane fields
Field Description
Label Name for the trail. Enter a name or select one in the list (of recently used labels). If
no name is specified, a name is automatically assigned that includes details from the
link and endpoints. (Optional)
Customer Enter a label describing the trail customer. If no name is specified, the name is left as
blank. (Optional)
Protection Select the layer for the protection trail (Mandatory; default is selection from last
created trail):
 Unprotected: Trail is unprotected.
 Underlying: Trail is protected due to the layer it traverses. For example, traffic in
MS-SPRing configurations is protected. If a trail (for example, VC-4 rate) uses this
ring, the trail is protected on the underlying (MS-SPRing) layer. Alternatively, if a
link of type SDH is protected in the OTN layer due to transponder protection,
then all trails using that link are underlying protected (protection may be
partial).
 Current: Protection exists on current layer only.
 Current and Underlying: Trail is protected on both the current and underlying
layers.

Field Description
ASON Protection Enables ASON protection.
For information about SDH ASON protection types, see ASON Protection and Priority
Schemes for SDH Trails (page 5-52).
For information about Optical ASON protection types, see ASON Optical Trail
Protection)
For ASON SDH trails, the protection type selected for the trail implies the following
ASON protection behavior:
 Unprotected: Implies 1+R protection, as described in 1+R (Mesh/Shared
Restoration) Protection Scheme.
 Underlying: Supplements 1+R protection with the applicable underlying
segment protection method.
In ASON Version 1.0 External or MSP 1+1 and MS-SPRing not currently restored
via ASON. If the Underlying protection scheme is chosen for an ASON trail traffic
runs, however both MSP 1+1 and MS-SPRing topologies are not considered part
of the ASON domain and are not subject to ASON protection.)
 Current: Implies 1++ protection, as described in 1++ Protection Scheme,
together with LightSoft current SNCP-type Path protection (i.e. unprotected over
External or MSP 1+1).
 Current and Underlying: Supplements 1++ protection with underlying or current
protection, applied based on LightSoft optimization criteria.
In ASON Version 1.0 External or MSP 1+1 and MS-SPRing not currently restored
via ASON. If the Current and Underlying protection scheme is chosen for an
ASON trail traffic runs, however both MSP 1+1 and MS-SPRing topologies are not
considered part of the ASON domain and are not subject to ASON protection.)
Rate Select the transmission rate of the trail. (Mandatory; default is selection from last
created trail.)
For information about the supported rates, see Supported Rates and Payload Types.
ASON trails - ASON supports the following high order server and service trail rates:
 Server trail rates: VC-4 (Term or TST). Special conditions apply; see ASON Server
Trail Notes.
 Service trail rates:
- EoS-VC-4 (with or without diverse routing)
- MoT-VC-4 (with or without diverse routing)
- VC4
Note: VC-12 and VC-3 low order trails cannot be defined directly in ASON. Low order
traffic can be delivered over ASON by uploading low order trails over a high order
server trail. The traffic then traverses the server trails. See also ASON Server Trail
Notes.

Field Description
VCAT Size Virtual Concatenated paths, indicating the number of resources that can be used on
a single trail segment (EoS/MoT trails only).
Maximum VCAT size depends on the selected trail rate and protection type; see
Supported Rates and Payload Types EoS/MoT Trails.
The selected VCAT Size may limit the number of diverse routes that can be set for a
trail; see Diverse Routes At Least/Exactly parameter in EoS/MoT Configuration pane.
If VCAT size is decreased and diverse routes are present, LightSoft balances the
reduction between the paths. Decreasing VCAT size below what is consistent with
existing diverse routes may cause some or all diverse routes to be eliminated.
Directionality Unidirectional or Bidirectional. (Mandatory; default selection from last created trail.)
ASON trail: Select Bidirectional. ASON does not support unidirectional trails.
Bundle Size Number of SDH trails that should automatically be provisioned by LightSoft based on
parameters entered for the current trail. VC-12=252, VC-3=192, VC-4=64.
Protection Criteria
DRI When selected, DRI protection (two NEs to bridge two rings) is used. DRI is available
for trails protected on current or current and underlying layers (fully protected
trails).
Max DRI Bridges Maximum number of DRI bridges that the PathFinder algorithm locates when
creating a trail.
For trails that have DRI bridges with diverse routes, specifies the maximum number
of DRI bridges in each route.
DNI When selected, DNI protection (one NE to bridge two rings) is used. DNI protection
can be configured according to your requirements. Contact your local Customer
Support representative for further information.
Extra Traffic Requests use of Extra Traffic (ET) resources within MS-SPRing configurations. After
the checkbox is selected, the system attempts to use ET resources on a best effort
basis.
A section of ET resources is enabled in the Select Server Trail pane and Select
Resource pane. For EoS Diverse Routes-enabled trails, the number of non-user
selected ET routes may be specified.
Important: When using ET resources, be sure to verify that the Resource Tree pane
contains the ET-marked resources you intend to use. Unintended ET-marking can be
canceled using the Extra Traffic shortcut menu toggle available for route (Diverse
Route EoS) or path (Main/Protection).
ASON checkbox Activates the ASON protection scheme for the current trail, whereby the protection
types assume ASON protection definitions, as described in the Protection parameter.
After it is selected, other protection criteria options are disabled.
Enabled when a VC-4 rate is selected and the trail is bidirectional.
Note: If the ASON checkbox is not selected, regular SDH-based protections apply.
Headend Priority Enabled when ASON checkbox is selected.
High (default) gives the trail a best chance of finding an available restoration path.
Low with Delay indicates that trail restoration should be attempted after a specified
delay in seconds.
For more information, see Low Priority Delay.

NOTES:
 For MS-SPRing protection, the ring may either be created through LightSoft (Creating an
MS-SPRing Ring) or, if all participating nodes are managed by the same EMS, in the
corresponding EMS. For details, refer to the relevant EMS User Guide.
 If changes are made to MS-SPRing configurations (existing rings are edited or new rings
are created) in the EMS, activate a forced upload for all MEs affected by the change. For
details, see Forcing an ME Upload.
Parent Topic
5.4.5 Advanced Trail Parameters Pane

The Advanced Trail Parameters pane allows you to configure more specific optional attributes of the new
trail.
Figure 5-6: Advanced Trail Parameters pane
Table 5-3: Advanced Trail Parameters pane fields
Field Description
Comments Free text about the trail.
Service Indicator Non Service, Service, Bronze, Silver, Gold. Provided for information
purposes only.
Private ID Private ID assigned to the trail. User-configurable free text identification
string, which may be downloaded to some EMSs.
The Private ID attribute may be used to associate two more trails as a
single service; see Trail Creation Options.
Alarm Master Mask The Alarm Master Mask (AMM) determines whether faults on objects in
the trail path generate alarms. Available options:
 Apply: Select to enable trail object masking in the EMS for all trail
objects regardless of any specific EMS settings (alarms are generated
on all trail objects). The option is normally enabled.
 Do not change: Select to leave the AMM on trail objects unchanged.
Alarms are received on specific objects in accordance with current
EMS settings.
The AMM can also be applied when reconnecting a trail; see Reconnecting
Trails.

Field Description
User Usage State Enables you to set a user-configured usage state regardless of the system
calculated usage state, as follows:
 Idle: Sets the trail to Idle even if the actual state is Active. Idle trails are
not connected to traffic, and can therefore be deleted in the Trails
pane; see Deleting Trails (only if the system usage state is also idle.)
 Active: Sets the trail to Active even if the actual state is Idle. Active
trails are connected to traffic and therefore cannot be deleted.
Parent Topic
5.4.6 EoS/MoT Configuration Pane

The EoS/MoT Configuration pane allows you to set parameters of Ethernet over SDH (EoS) and MPLS over
Transport (MoT) trails. The pane becomes enabled when an EoS or MoT rate is selected in the Trail
Parameters pane.
Figure 5-7: EoS/MoT Configuration pane
Table 5-4: EoS/MoT Configuration pane fields
Field Description
Common
View on ETH/MPLS Indicates that the trail should be visible as a virtual link on the ETH/MPLS layer.
Layer checkbox For more information about virtual links, see Trails and Virtual Links.
Automatic and unavoidable for MoT trails and EoS trails with L2 port endpoints.
These trails are always visible as virtual links in the ETH/MPLS layer.
For EoS trails with L1 port endpoints, enabled and selected by default at
creation time and clearable if needed, or selected/cleared later via the Trail List
window's Trail Properties pane Standard View; see Trail Properties Pane.
Note: This checkbox cannot be edited in the trail Edit window. You can edit it in
the Trail List window Trail Parameters pane; see Trail Properties Pane.

Field Description
S-VLAN Registration (EoS trails only) Automatically adds the S-VLAN registration to the virtual link as
checkbox part of the EoS trail creation process and downloads it automatically to each
existing service in the PB network for service discrimination purposes. See
Distinguishing between Services.
An existing EoS trail can also be S-VLAN registered through a Trail List window
option. See S-VLAN Registration from a Link or Trail.
Performing S-VLAN registration at the trail level avoids having to S-VLAN
register each network service individually. See Automatic S-VLAN Registration.
Activate Bandwidth Activates the bandwidth of the EoS trail, opening it to data traffic immediately
checkbox after activation. This can be postponed and the bandwidth activated later,
either specifically or during trail reconnection; see Activating Trail Bandwidth or
Reconnecting Trails.
Bandwidth can be deactivated in the trail edit process; see Editing Trails.
Diverse Routes Primarily used to allow LCAS functionality, enabling configuration of the
checkbox EoS/MoT trail to carry traffic over different nonshared fibers (diverse routes).
The Diverse Routes checkbox is enabled when the VCAT size is greater than 1. It
applies to any EoS/MoT trail rate is selected and protection choice.
When Diverse Routes is selected in conjunction with Current protection, all the
diverse routes will be SNCP protected.
When Diverse Routes is selected, specific trail resources can be assigned to
separate route numbers using the Belongs to Route No. field; see Select
Segment Pane.
In this case, the Tree View categorizes resource information by route number
instead of by Main/Protection; see Resource Tree Pane. (The resources are
categorization by route if at least one route is labeled other than Route #1.)
If Diverse Routes is not selected, all resources are allocated to the same route
or link (Route #1).
Selecting the checkbox enables the parameters in the rest of the Diverse Routes
area.
At least/Exactly (Enabled when Diverse Routes is selected)
Minimum or exact number of diverse routes you want defined for the EoS/MoT
trail (as allowed by LightSoft according to indicated VCAT size and EoS/MoT trail
rate, with a maximum of three).
The maximum number of separate routes that can be set depends in the trail
rate and specific equipment port limitations. For example, on MCS-X cards this
can be up to:
 EoS/MoT VC-4X = max. 64
The maximum of routes is additionally limited by the lesser of:
 Belongs To Route No. selection; see Select Segment Pane.
 VCAT size assigned to the trail/Min VC paths per route.
Min VC paths/route (Enabled when Diverse Routes is selected)
Minimum number of VC paths (resources) you want per diverse route. Links
with lesser capacity are excluded from PathFinder search consideration.

Field Description
Extra Traffic routes (Enabled when Diverse Routes is selected)
Number of diverse routes that use extra traffic (ET) resources on MS-SPRing.
This enables selection of ET resources in the Select Server Trail and Select
Resource panes. You can specify the number of non-user selected ET routes for
EoS Diverse Routes-enabled trails.
Important: When using ET resources, be sure to verify that the Tree View tab
pane contains the ET-marked resources that you intended. Unintended
ET-marking can be canceled using the Extra Traffic shortcut menu toggle
available for route (if DR EoS) or path (Main/Protection).
Note: Extra traffic routes are set up once the trail is defined. This parameter
cannot be changed after the trail is created.
RSTP Enabled (EoS trails only, not applicable for MoT)
If selected, the EoS trail will be controlled by the RSTP configuration.
See Viewing RSTP/ERP Information.
For RSTP to be operational, it must additionally be enabled at the port level via
the EMS.
RSTP is generally disallowed for P2P service creation in PB networks. It can be
allowed, for example, to implement P2P "back door" protection; see
Configuring PB P2P Services between MCS Cards. In this case, the User
Preferences - Services window Selectable I-NNI Links for Manual S-VLAN
Registration parameter must also be set to RSTP Enabled; see Service
Management Preferences in the Getting Started & Administration Guide.
For PB P2P services, whether or not RSTP Enabled trails will be employed, the
RSTP Enabled checkbox selection and the User Preferences - Services window
Selectable I-NNI Links for Manual S-VLAN Registration parameter selection
must always match (i.e., both RSTP Enabled or both RSTP Disabled). Otherwise
the PB P2P service will not complete.
Cost Enabled when the RSTP Enabled checkbox is selected. Enter the Cost associated
with the EoS trail for RSTP purposes.
This cost is assigned automatically to both endpoint ports when the trail is
created, or the cost is modified through the Edit Trail window.
If the costs associated with the two ports should differ (for example, due to an
EMS modification), the Cost field in LightSoft will be blank.
Parent Topic

5.4.7 Trail Properties Pane

The Trail Properties pane displays the attributes of the selected trail. It is empty when the trail is being
created and filled with information after the trail is completed or activated.
The same pane is available in the Trail List window, showing information for a selected trail and modifying
its attributes. For detailed information about the pane contents and procedure for editing attributes, see
Trail List Window - Trail Properties Pane.
Figure 5-8: Trail Properties pane
Parent Topic
5.4.8 Endpoints & Path Tab

The Endpoints & Path tab enables selection of endpoints and resources for the trail.
 Path Completion Method : Offers a choice of automatic or manual path completion methods.
 Endpoints List Pane : Shows the trail endpoint selections.
 Select Segment Pane : For selecting the segment from which trail resources are selected.
 Select Server Trail and Services Panes : Appears when a low order rate is selected in the Basic Trail
Parameters pane. The Select Server Trail pane is used for selecting resources for the low order trail.
The Services pane shows the trails in the link that are not currently serving as server trails (because
they are flex or virtual concatenated trails, or in failure state).
 Select Resource Pane : For selecting trail resources.
categories.
Parent Topic

5.4.9 Path Completion Method

LightSoft trail creation offers automatic (Auto-complete) or manual (Explicit Selection) path completion
methods.
Figure 5-9: Path Completion Method pane
Explicit Selection is not available if SNCP-protected Diverse Routes apply, that is, when Diverse Routes is
implemented in conjunction with Current protection; see the Diverse Routes parameter in EoS/MoT
Configuration Pane.
When Auto-complete (default) is selected, PathFinder automatically suggests an optimal path for the trail
based on the minimum user selections – endpoints and the trail rate, and in accordance with applicable
user preferences (see Trail Creation Management Preferences in the Getting Started & Administration
Guide). In this mode, you can additionally select some links the path should include (in the Resource Tree
pane), thereby limiting the trail route alternatives considered by PathFinder.
With Auto-complete, if all the links of the path are pre-specified, PathFinder will still look for an optimal
path, and eventually choose the one possible (pre-specified) path. If you want to explicitly specify the entire
path, you can save processing time by setting the path completion method to Explicit Selection. Then
PathFinder only relies on user link specifications and does not attempt to look for a path. (If your selections
are insufficient to fully define a trail between the endpoints, an Invalid Input message is displayed.
PathFinder does not attempt to complete the trail.
Regardless of the completion option selected, resource pre-selection remains optional and PathFinder
automatically selects resources for the trail if needed. As well, all regular trail validations are applied.
The Path Completion Method pane is also used when configuring OCH, LP, and ODU optical trails; see the
specific procedures in Introduction to Optical Trail Provisioning. In the case of OCH Multi Route trails, multi
route-specific parameters also apply; see Provisioning OCH Trails.
TIP: The Path Completion Method pane allows you to improve performance when path
finding is not needed. The Complete process is faster if PathFinder is not run. This is because
path finding takes longer even if all segments are already selected by the user.
Parent Topic
5.4.10 Endpoints List Pane

The Endpoints List pane shows the endpoints selected for the new trail. As an endpoint is selected, its
details appear in the list.
Figure 5-10: Endpoints List pane

Table 5-5: Endpoints List pane fields
Column Description
Endpoint Name Name of the endpoint, comprising three components:
 ME name
 Physical Termination Point (PTP) name
 Connection Termination Point (CTP) name
Before a trail is completed, only the ME name appears.
Mode Indicates whether the endpoint functions as Add, Drop, or Add and Drop.
Path Indicates whether the endpoint applies to the main path, protection path, or both.
C2V Checkbox Select to enable Contiguous Concatenation to Virtual Concatenation (C2V)
functionality on the trail endpoint.
Relevant only when a virtual concatenation trail rate is selected making C2V
functionality possible (VC-4-4v or VC-4-16v.
Note: For the checkbox to appear, the endpoint must be manually selected at the
VC level within the port and not at the port itself. Automatic endpoint selection
should not be used.
C2V allows contiguous signals that start and terminate outside the managed
network to traverse a managed network where some elements do not support
contiguous signals (such as SYNCOM elements). When entering the network, the
contiguous signal is converted to a virtual concatenated signal for its passage
through the network, and converted back to a contiguous signal upon leaving the
network.
The Endpoints List pane in the Trail List window additionally includes a Decrease checkbox column for
decreasing the bandwidth at endpoints of existing trails. For details, see Endpoints List Pane.
Right-click an endpoint in the Endpoints List pane for the following shortcut menu options.
Table 5-6: Endpoints List pane shortcut options
Option Description
Open Opens a GCT to the endpoint port's EMS card view.
Properties Opens the Properties for Port dialog box for that endpoint port; see Port
Properties.
Remove Removes the selected endpoint, enabling you to replace it with another.
Remove All Removes all endpoints, enabling you to restart the endpoint selection process.
Parent Topic

5.4.10.1 Selecting Trail Endpoints

You can select a group, element, or port as an endpoint. If a group or element is selected, the first available
resource is used.
When a bundle of trails is being created (in the Basic Trail Parameters pane, the Bundle Size is greater than
1):
 Endpoints for each additional trail are automatically assigned based on the next available port or
termination point in the sequence.
 The number of bundled trails that are built is limited by the number of available ports and the starting
port (if any) selected for the first trail. For example, if the first trail is manually assigned port #3,
subsequent trails are automatically allocated the ports starting with #4 - the resources #1 and #2, even
if available, remain unoccupied. If the remaining ports are insufficient, not all the trails in the bundle
are built.
NOTE: Endpoint selection is mandatory. (In most cases it is sufficient to select an NE - the
endpoint port is automatically selected.)
To select groups or elements as endpoints for SDH trails:

 Select the groups/elements at the terminating point of the trail. (Only elements with compatible ports
are available for selection.) The specific endpoints (ports or termination points) are found
automatically. Optimization of endpoints is not performed. (If a selected element has no compatible
ports, no selection is made.

To select specific ports or termination points as endpoints:

1. In the Create Trail window map:
a. Click an LE. The first available port consistent with the trail rate selection is automatically selected
and listed in the Endpoints List pane. )
b. Repeat for the next required endpoint (a trail needs two endpoints).
OR
2. In the Create Trail window map, right-click an LE and choose Select Endpoint or double-click the LE.
The Select Endpoint dialog box opens. The available endpoints are listed in a tree structure.
Double-click a node to expand or collapse the tree.
Figure 5-11: Select Endpoint dialog box
The root of the tree is the selected ME. All available ME endpoints are listed in the tree.
The geometric-shaped icons next to the port names are the same as used in the Inventory Tree. For
the definition of each icon, see Inventory Tree.
Potential endpoints (ports and termination points) in the Select Endpoint window tree are shaded if
unavailable (for example, already in use or blocked). If an endpoint cannot be used for the selected
rate of the trail, it is not displayed in the tree. The selected endpoints are listed in the Endpoints List
pane.
NOTE: When you select endpoints for a planned trail via the Plan Trail window, every
rate-compatible resource is regarded as available, even if it is currently occupied.

a. Select the endpoint's Add/Drop mode as follows:

 For unidirectional trails, the Add and Drop fields are enabled.
 For bidirectional trails, the mode is typically Add&Drop (default). If the object selected is a
termination point, all fields are enabled and the mode may be Add, Drop, or Add&Drop.
b. Select the protection scheme for the endpoint: Main, Protection, or Both.
c. Select an endpoint by drilling down to the endpoint node to select it and then click Select or
double-click the node. Click Close to close the dialog box without selecting an endpoint.
NOTE: The specific endpoint names are displayed in the Endpoints List pane only after the
trail is completed.
d. After you have finished specifying an endpoint, click Close to close the dialog box.
e. Proceed with another endpoint, if required, by repeating from Step 1. (A trail requires two
endpoints.)
Parent Topic
5.4.10.2 EoS and MoT Endpoint Compatibility

EoS trails can be created between two Ethernet over SDH ports (EoS) ports - with VCG and Ethernet layer in
a physical or logical port. MoT trails can be created between two compatible MPLS over SDH (MoT) ports -
with VCG (Fragment layer) and MPLS layer in a logical port. For more details, see Typical Valid Network
Topologies.
The selected endpoints must also be compatible in the following ways:
 LCAS Compatibility: Both selected endpoints must have LCAS either enabled or disabled. If LCAS is
enabled, both endpoints must have the same type of LCAS (according to the NE support for LCAS). If
not, the trail is disallowed. (Endpoints of UMEs are not checked for compatibility.)
 LAG Compatibility: Both endpoints must be members of LAG groups; see LAG Support.
 Double-Tagging Format Compatibility: Both endpoints must have the same double-tagging format
(both QinQ or EIS QinQ or None) set in the EMS.
 RSTP Compatibility (EoS Only): Spanning Tree mode setting must be same for all endpoints. Values
may be RSTP, MSTP, or None. (Not all NEs support MSTP.)
 Port Type Compatibility: Port interface types must be valid and compatible. The endpoint type is
displayed and the interface compatibility is validated.
E-NNI (external) interface type connects a service to a non-managed network.
I-NNI (internal) interface type connects PB and MPLS networks.
NNI type ports may be used for both E-NNI and I-NNI.
For a description of these interfaces, see Supported ETH/MPLS Port Types.
You can differentiate between UNI and NNI ports through different Select Endpoint
window tree symbols. (E-NNI and I-NNI use the same symbol.)

Table 5-7: EoS endpoint selection rules for NNI types
Trail between: Endpoint A Endpoint B

Endpoints in same PB network I-NNI or NNI I-NNI or NNI
PB port (EoS) to PE port (EoS) I-NNI or NNI I-NNI or NNI
PE (EoS) to L1 ETY E-NNI or UNI or NNI L1 ETY
PB to L1 ETY E-NNI or UNI or NNI L1 ETY
PE port (EoS) to PE port (EoS) I-NNI I-NNI
PB port (EoS) to PB port (EoS) E-NNI E-NNI
PE port (EoS) to PE port (EoS) E-NNI E-NNI
Parent Topic
5.4.10.3 Network Topology Validity

Validation rules apply to trail creation, which have consequences for network topology validity. See:
 Typical Valid Network Topologies
 Trail Patterns Within/Between Networks
 Invalid Network Topology Indications
Parent Topic
5.4.11 Select Segment Pane

The Select Segment pane is used to optionally select resources for a trail. (Selecting specific resources for a
trail is optional. If no segment is selected, LightSoft automatically selects the first available resource in the
first segment that spans the selected endpoints.) This pane shows the same fields as for Topology Links,
described in Viewing Topology Link Information.
The pane may include a Belongs to route No. selector for specifying a route number to a selected resource
for an EoS/MoT diverse routed trail (enabled if VCAT Size greater than "1" in the Basic Trail Parameters
pane and the Diverse Routes checkbox is selected in the EoS/MoT Configuration pane).
Figure 5-12: Select Segment pane

When a bundle of trails is being created (in the Basic Trail Parameters pane, the Bundle Size is set greater
than 1), capacity for each additional trail is automatically assigned based on the next available resource in
the matrix.
The number of bundled trails that are built is limited by the segment capacity and the starting resource (if
any) selected for the first trail. For example, when Bundle Size = 16 is specified on an STM-16 link, if the first
trail is manually assigned the resource #3, subsequent trails are automatically allocated the resources
starting with #4, even if the resources #1 and #2 are available. The resources #1 and #2 will remain
unoccupied and only 14 trails will be provisioned. The completion message at the end of the process states
that capacity was not available.
To select specific resources for a trail:

1. In the Create Trail window Trail Parameters pane, select the required rate:
 High order rate, for example VC-4
OR
 Low order rate, for example VC-12 or VC-3
2. In the Create Trail window map, right-click a topology link or multilink and choose Select Segment.
The Select Segment pane shows the available segments in the link.
3. For a diverse routed EoS/MoT trail – do the following for each required diverse route:
a. Select an applicable route number in the Belongs to Route No. selector .

b. Provision resources for a selected segment, as described in Steps 4 to 7.
You can view the new resource-to-route association in the Resource Tree pane; see Resource Tree
Pane.
Once a resource-to-route association is confirmed in the Resource Tree pane, any new Belongs to
Route No. selection applies to a following route and does not affect previously provisioned routes.
You can change an association by deselecting it or removing it; for details, see Select Resource Pane.
Any number of resources can be assigned to a specific route number.
The route # can be any number. For the trail to be recognized as diverse routed, at least one route
number must be other than route #1 – for more information, see Resource Tree Pane.
The maximum number of separate routes that can be assigned depends on:

 Diverse Routes parameter At Least/Exactly selection; see EoS/MoT Configuration Pane.

 VCAT Size assigned to the trail; see parameter description in Basic Trail Parameters Pane.
 If the number of separate routes selected exceeds these limits, the trail is not completed.
4. In the Select Segment pane, click the row of a segment to highlight it.
5. In the selected segment row:
 Double-click a port cell (unidirectional selection) or the link cell between the two ports
(bidirectional selection).
OR
 You can right-click the required port or link cell, or in the shortcut menu, select one of the
following. The specific option offered depends on the rate selected in Step 1.
 Select Resource if you are creating a high order trail.
OR
 Select Server Trail if you are creating a low order trail.
Note: The small arrow represents the segment. Clicking the link cell alternately selects/deselects
both link segments (turning the arrow color on or off ). This feature is available for high order
rates only.
6. You will now select resources for the segment(s) that you want to provision, using the applicable
pane:
 High order trail: Use the Select Resource pane; see Select Resource Pane.
 Low order trail: Use the Select Server Trail pane; see Select Server Trail and Services Panes.
7. After you have finished selecting resources, scroll back to the Select Segment pane. In that pane, the
corresponding resource symbol/s (above the segment name) become colored (for example, change
from to ) according to the type of path selected - purple for "both", pink for Main (or
unprotected), or blue for (protection link).
8. You can view details about the segment that LightSoft will use to create the trail in the Resource Tree
pane; see Resource Tree Pane.
Parent Topic
5.4.12 Select Server Trail and Services Panes

The Select Server pane is used to select resources for a low order trail - relevant when a low order rate (for
example, VC-12) is selected in the Basic Trail Parameters pane. It lists the available server trails:
 Server trails with available resources can be selected.
 Server trails where the resources are fully occupied are grayed out.
The Services pane shows high order trails on the link which are service trails, or otherwise cannot serve as
server trails because, for example, they do not conform to normal trail patterns (flex trails) or are virtual
concatenated trails or in a failure state. These trails are presented for informational purposes only and
cannot be selected.

To select specific resources for a low order (client) SDH trail:

1. Complete Steps 1 to 6 of the procedure described in Select Segment Pane to select a low order rate
and select a segment. The Select Server Trail pane now shows server trails for one or both ports of
the segment.
2. Double-click a server trail (or right-click a server trail and choose Select Resource). The Select
Resource pane now shows available resources (light gray indicates availability), enabling you to select
a resource. (Resources are colored purple when selected.)

NOTE: If you want the resource to be selected automatically, in the Select Server Trail pane
click a server trail (instead of double-clicking). The PathFinder will automatically choose an
appropriate TU after the trail creation procedure Complete step.
When resource selection is being performed for a planned trail via the Plan Trail window,
every rate-compatible resource is regarded as available, even if it is currently occupied.
3. Select resources for the server trail(s) you want to provision, as described in Select Resource Pane
Step 2.
In the Select Segment dialog box, the corresponding resource symbol(s) (above the port name)
change from to .
4. You can view information about the segment that LightSoft uses to create the trail in the Resource
Tree pane; see Resource Tree Pane.
5. To quickly learn more about a specific server trail, right-click the server trail path in the Resource Tree
pane and select Show Trail (or double-click its line in the Resource Tree pane). Another instance of
the Trail List window opens, showing only the selected server trail and its path, as well as other
characteristics (for example, where it starts and ends).
Parent Topic
5.4.13 Select Resource Pane

The Select Resource pane enables you to select sources for a high order trail.
To select resources for a high order trail:

1. Complete Steps 1 to 6 of the procedure in Select Segment Pane to select a high order rate and select
a segment. The Select Resource pane now shows the available resources for one or both ports of the
segment. The pane contains a resource selection graphic, with squares representing resources, as
follows.
 Purple - current new selection (as in square 3).

 Lightest gray - available for selection.
 Light gray - unavailable in either direction because used by other trails (as in square 2).

 Dark gray - Blocked in both directions (as in square 1). A resource may be blocked if it is being
used to provide protection. So the protecting resources are blocked. User will never be able to
select them.
NOTE: When resource selection is being performed for a planned trail via the Plan Trail
window, every rate-compatible resource is regarded as available, even if it is currently
occupied.
2. Select resources for one or both directions, or separate resources for each direction, as follows:
 To choose resources for one direction: Select a specific port. The resource selection graphic
appears to the left or right side of the pane with a directional arrow below it. Click an available
resource for that single direction (the square turns purple).
 To choose resources for both ports: Select the link cell between the ports. The graphic is
centered in the pane.
 To choose the same resources for both directions of the segment, just click an available
resource (the square turns purple).
 If you want to choose different resources for each direction, click Unmerge at the bottom
of the pane. Two resource selection graphics appear in the pane. Select the required
resource for each direction.
Merge can be used to subsequently remerge the graphics if required to select the
same resources for both directions. Any asymmetrical selections that you made in the
current session will be discarded, while all symmetrical selections will be preserved.
A confirmation window appears. The action is implemented only if you enter OK.
To remove resources after selection:
 If diverse routes apply, in the Select Segment pane, select the required route number in the
Belongs to Route No. selector.
 In the Select Resource pane, click the selected resource in the graphic to deselect it. You can
then select different resources by clicking as needed.
 In the Resource Tree pane, select a resource from the required resource category (main or
protection, or the applicable route); see Resource Tree Pane , and in the Resource List pane,
right-click the required resource and select Remove; see Resource List Pane.
3. Continue the procedure described in Select Segment Pane Step 7.
Parent Topic

5.4.14 Resource Tree Pane

The Resource Tree pane displays selected resources for a trail in a tree hierarchy under Main and
Protection categories (where applicable). In the case of concatenated trails with diverse routing, each route
has a branch. Each line contains indications of the applicable protection type.
Figure 5-13: Resource Tree pane
In general, resources are categorized according to Main and Protection. For EoS/MoT diverse routed trails,
resources are categorized according to route number (e.g., Route1, Route2). This applies when the Diverse
Routes checkbox is selected; see Diverse Routes description in EoS/MoT Configuration Pane , and at least
one route number besides Route #1 is specified for a trail resource; see Select Segment Pane.
Figure 5-14: Resource Tree pane showing diverse routes
Segments with the following special statuses are identified by icons:
 DRI bridge-associated segments. The bridge number is shown under the bridge icon. A tooltip also
shows the source endpoint from which the path-search algorithm is instructed to reach the source of
the bridge link.
 Resources with Extra Traffic (ET) status.
 Segment in process of bandwidth decrease.
For Optical ASON trails, the Provisioned and Restoration routes are indicated in the Resource Tree:
Parent Topic

5.4.15 Resource List Pane

The Resource List pane displays details of selected trail resources individually or by category (All, Main, or
Protection).
Figure 5-15: Resource List pane
Resources with the following special statuses are identified by icons:

Working channel segments associated with MS-SPRing configurations.
Resources with Non-preemptible Unprotected Traffic (NUT) status.
Table 5-8: Trail Paths pane - Resource View fields
Field Description
Resource Used resource/time slot.
Segment/Server Trail Topology segment/trail path label.
Both topology segment and trail path have a direction icon :
 In the case of a trail path, the direction of the arrow DOES NOT indicate the
"from-to" direction of the trail but serves to distinguish between the forward
path and the backward path.
 In the case of topology segments, the direction of the arrow DOES indicate the
from-to direction of the segment with respect to the connected elements
left/right map location.
For a server trail path, if there is no information about occupied resources, the
"[N/A]" prefix is attached to the path's label.
A tooltip over the direction icon shows the direction of the topology
segment/server trail path in the format "SRC to SNK", where SRC and SNK are the
originating and destination termination points (respectively) of the path element.
Path Main or Protected. (This column is not displayed if diverse routing applies.)
Route If diverse routing applies, the route to which the resource is assigned is indicated.
(This column is displayed if diverse routing applies.)
Parent Topic

5.4.16 Information About a Specific Server Trail

To quickly learn more about a specific server trail, in the Resource Tree pane, double-click the trail. Another
instance of the Trail List window opens, showing only the selected server trail and its entire path and other
characteristics (for example, where it starts and ends).
Right-click a server trail to open a shortcut menu with the following options. (Options vary according to
whether the menu is opened in the Create Trail, Edit Trail, or Trail List window.)
Table 5-9: Server trails shortcut menu options
Option Description
DRI Bridge Displays Define DRI Bridge dialog box used for creating bridges; for
more information, see DNI/DRI Protection.
Remove Low order trails: Disassociates selected server trail from selected client
trail, thereby removing the server trail from the list.
High order trails: Disassociates selected resource from selected link
segment, thereby removing the link segment from the list.
Remove All Low order trails: Disassociates all server trails from selected client trail,
thereby removing all server trails from the list.
High order trails: Disassociates all resources from the selected link
segments, thereby removing all link segments from the list.
Collapse All/ Collapses/expands the tree.
Expand All
Move to Protection/ When protection applies, these toggle options enable you to edit a
Move to Main protection trail segment to main, or a main trail segment to protection;
for more information, see Path Protection Switching.
Add Main to Protection/ Adds the selected segment to the main/protection path.
Add Protection to Main
Parent Topic
5.5 ASON Trail Provisioning

LightSoft’s ASON implementation enables the configuration of LightSoft-provisioned trails with ASON
protection schemes. For an introduction to ASON, see LightSoft ASON Support.

Creating ASON-protected trails in LightSoft is similar to SDH trail creation, using the same windows, with
only minor differences in procedures; see Creating a Trail. ASON trails can only be defined on ASON
topology links between ASON enabled NEs. ASON links have an STM-16 or STM-64 link rate.

NOTE: If a link intended for ASON is created in LightSoft, it must be set as ASON in the EMS
before use in LightSoft.
Trails protected by any protection scheme may be routed through the ASON domain. But those trails will
not benefit from ASON protection in the event of a failure.
Pre-existing trails can be converted to ASON by individual or batch editing; see Converting Preexisting Trails
to ASON.
When a previously non-ASON network is configured as ASON, the LightSoft topology is affected such that
topology links that qualify as ASON take on ASON properties.
Parent Topic
5.5.1 Before Starting ASON Trail Creation

Prerequisite steps in the EMS
Provisioning ASON protection in LightSoft must be preceded by the following ASON network configuration
steps in the EMS (refer to the EMS user guide for detailed procedures):
 Disable Auto Link Discovery.
 Back up the existing network configuration and confirm hardware compatibility.
 Set EMS Preferences for ASON and connect the Signaling Communication Network (SCN), including NE
gateway configuration, if required.
 Install and configure an ACP card in each NE that is to participate in the control plane, including
enabling the MS RDI alarm to trigger restoration.
 Define the links that the ASON authorized network is to use.
 Configure the trails that serve the traffic that you want to protect via ASON.
NOTE: After the ACP is configured in an NE, its SIO cards can still be used for non-ASON
purposes. The NE remains a regular NE with regular-purpose SIO cards, accommodating
regular trails.

ASON Network Using LDL Links

If your ASON network uses both regular data links and LDLs, the routing that you configure should strive to
avoid using LDL links, as LDL bandwidth should generally be reserved for restoration purposes over a
non-ASON domain. This is an especially useful to remember when scarce LDL links traverse a third party
network.
If you rely on LightSoft’s PathFinder to automatically choose a path, it is recommended that you change the
PathFinder criteria for trail provisioning to be both Assigned Cost (1st Priority) and Number of MEs (2nd
priority); see Trail Management SDH Constraint Preferences – Criteria Selection in the Getting Started &
Administration Guide. PathFinder by default considers LDLs at 10 times higher cost than regular data links,
thereby avoiding LDLs being favored over regular data links in the path selection process.
If you do not set the criteria as described above and an LDL link is automatically selected for the trail path,
you can change the path to bypass the LDL before activating the trail.
Parent Topic
5.5.2 After the ASON Trail is Activated

After an ASON trail is activated, while LightSoft manages the network, the trail is monitored by ASON:
 If a failure occurs on any fiber/link that the provisioned path traverses (for example a fiber cut), a new
trail path is automatically found by the ASON control plane. The ASON control plane automatically
reroutes the traffic to the new trail’s path. The new trail path becomes visible. TCI, performed in the
background, dynamically informs LightSoft about ASON-initiated rerouted trail connections.
 After the fiber cut is repaired, the trail automatically reverts to the initial trail path, and the bandwidth
is released for use by other services. (Reversion settings are configured in the EMS.)
LightSoft's role concerning the trail path is limited to monitoring and displaying reroute or other changes,
with a view to correcting the problem to allow eventual reversion to the originally provisioned path. For a
description of the available monitoring tools, see Monitoring the ASON Domain.
The originally provisioned path can be changed to another path if needed. Redefining the provisioned path
may reflect a decision not to immediately repair the originally provisioned path and to release its resources
for other purposes. See Redefining an ASON Provisioned Path (Admit).
Parent Topic
5.5.3 Converting Preexisting Trails to ASON

Preexisting trails in LightSoft can be converted to ASON by checking the ASON checkbox using the Edit Trail
window; see Editing Trails. The checkbox is enabled when a trail is set as bidirectional and with a VC-4 rate;
see the ASON checkbox description in Basic Trail Parameters Pane.
The conversion can also be performed for multiple trails at a time by XML Export in Edit mode and Import;
see Editing Trails and Batch Trail Operations.
Conditions specific to ASON must be satisfied for ASON trails to be created successfully (see ASON
Provisioning Conditions), in addition to conditions normally applying to non-ASON trails.

Trails that fail to be activated by the batch process are listed in XML import log file; see Batch Trail
Operations. The activation failure cause must be determined and the underlying problem resolved before
conversion of those trails is attempted again.
When the conversion is by XML import, it is advisable to also have available a set of XML files that can be
used to restore the pre-ASON trails if needed.
Parent Topic
5.5.4 ASON Provisioning Conditions

The following sections describe conditions applying to ASON trail provisioning.
Parent Topic
5.5.4.1 General ASON Trail Prerequisites

The following prerequisites must be satisfied for an ASON trail to activate:
 The link that the ASON trail traverses must be an ASON link. A link created in LightSoft must be
configured as ASON in the EMS before use in LightSoft (see Associating ASON Links to the ASON
Domain). The link rate must be STM-16 or STM-64.
 At least one segment along the trail path must be ASON protected.
 If current layer 1++ protection applies, both main and protection paths must include at least one ASON
segment.
 For diverse routed data trails, each route path must include at least one ASON segment.
NOTE: If a link intended for ASON is created in LightSoft, it must be configured as ASON in the
EMS before use in LightSoft, see Configuring an ASON Network in the EMS.
Parent Topic

5.5.4.2 ASON Server Trail Notes

The following applies to ASON server trails:
 Low order traffic carried by a server trail is protected via the server trail over which it traverses. Low
order traffic can enter through a server trail that begins either within or outside the ASON domain.
 A server trail may be ASON-protected if it includes at least one ASON trail segment.
 ASON supports Terminated Server Trail (TST or Term.) segments. ASON performs recovery of the low
order trails carried over a TST.
 Concatenated VC-4-4c and VC-4-16c trails cannot run over LDL.
Parent Topic
5.5.4.3 Non-ASON NEs Connecting ASON NEs

A trail is designated as an ASON protected trail when it passes through at least one ASON data link. An
ASON data link is created when NEs on both sides of a link are connected to ASON nodes (i.e., an NE with
ACP card).
An ASON trail can also traverse parts of the network that contains non-ASON NEs, or third party equipment.
In a mixed network, ASON trails traverse third party services built over SNCP protection mechanisms. ASON
protection and restoration is provided only for the ASON links on the trail.
LightSoft supports a trail traversing ASON and non-ASON domains provided the non-ASON NEs are standard
SDH equipment.
While services are ASON protected end-to-end, other protection types (such as MS-SPRing) may apply to
parts of the trail outside the ASON domain. ASON restoration applies only to the parts of the trail that
traverse the ASON domain via ASON NEs. Therefore, if a failure occurs in the MS-SPRing part of the trail,
ASON restoration does not operate and traffic transmission stops.
When working with a mixed network (ASON and non ASON NEs), traffic can run between ASON domains via
non-ASON NEs. The ASON domains act as separate domains for restoration purposes, unless the non-ASON
NEs correspond with DWDM transport wavelengths, as illustrated in the following figures.
Figure 5-16: Mixed network including ASON and non-ASON NEs

However, as LightSoft allows ASON links to traverse DWDM NEs with J0 transparency, in the event that the
non-ASON NEs are DWDM transport wavelengths, all ASON NEs are considered a single domain.
Figure 5-17: Trail traversing mixed network with non-ASON DWDM NEs
Parent Topic
5.5.4.4 MS-SPRing and ASON

MS-SPRing is an efficient shared protection mechanism that is widely used for protection of ring topologies
in SDH networks.
MS-SPRing and ASON protection mechanisms can coexist on the same network. ASON NEs in a mesh
network can also interconnect with an MS-SPRing configuration.

If a segment that is protected by MS-SPRing is located in the middle of an ASON domain, traffic can pass
through it unobstructed (as shown in the following figure).
Figure 5-18: Network with MS-SPRing and ASON protection
Each protection type protects its relevant part of the trail

While services are ASON protected end-to-end, MS-SPRing protection applies only to the part of the trail
that traverses the MS-SPRing. ASON restoration applies to the part of the trail that passes via ASON NEs
outside the MS-SPRing.
ASON protection applies only to ASON trails

ASON protection operates on links traversed by a trail only if the trail is defined as ASON protected.
ASON trails traversing non-ASON domains are still ASON protected

An ASON trail can be created or edited to be ASON protected end-to-end, even though it may traverse
(start or end at, or include) non-ASON NEs (for example, starting in an MS-SPRing). The trail remains
defined as ASON-protected. ASON restoration applies whenever a free ASON link is found for the trail path.
(ASON protection does not operate with respect to the non-ASON links.)
ASON NEs located on MS-SPRing can be head/tail of ASON trails

An ASON NE located on the MS-SPRing can serve as the head or tail of an ASON trail provided the trail does
not actually terminate on it. That is, the tail should be on the ingress point of the MS-SPRing (head on the
egress point), connected to other fibers leading outside the MS-SPRing.
ASON trail can be forced to traverse MS-SPRing

An ASON trail can be forced to traverse an NE that is within an MS-SPRing domain. You define this during
the provisioning process by manually selecting links along the trail path. Otherwise, by default, LightSoft
tries to find a path that comprises only ASON links.

ASON and MS-SPRing protection cannot coexist on the same link

When an ASON trail is created on a mixed topology, traversing ASON and non-ASON (MS-SPRing) links,
ASON protection applies only to the ASON links (where an ACP is present at both sides of the link).
However, when the ASON NEs (ACPs) are within the MS-SPRing domain, ASON protection does not operate
between them. A link cannot be both ASON and MS-SPRing.
Implementing MS-SPRing protection on an ASON link is disabled unless you first exclude the link from the
ASON domain; see Excluding a Link from the ASON Domain in the EMS User Guide. You can then define
MS-SPRing on the link; see Configuring MS-SPRing in the relevant EMS User Guide.
Similarly, implementing ASON protection between ACP NEs that currently participate in an MS-SPRing
requires you first to cancel the MS-SPRing on the link; see Releasing MS-SPRing or MSP 1+1 in the EMS User
Guide. You must then manually associate these links to ASON; see Associating ASON Links to the ASON
Domain in the EMS User Guide. (Links between ACP elements are automatically configured as ASON
through automatic link discovery for first-time fiber connections only.)
One leg of an SNCP-protected trail should pass outside MS-SPRing domain

If the ASON trail traverses MS-SPRing, it is recommended to define the trail protection as Current and
Underlying, with current protection provided by SNCP and underlying protection provided by MS-SPRing.
The two SNCP paths should be set as follows:
 One path (either main or protection) forced to traverse the MS-SPRing domain by manual segment
selection.
 One path set outside the MS-SPRing, and therefore ASON protected.
In this way, if two MS-SPRing links fail, traffic will recover on the ASON link. This avoids a single point of
failure situation where both paths traverse MS-SPRing. ASON always tries to restore the traffic.
Parent Topic
5.5.4.5 MSP1+1 and ASON

In an MSP 1+1 segment, MSP protocol (K1, and K2) protect the service in the event of a failure. In this
version, an MSP 1+1 link can also be defined as an ASON link. To define MSP1_1 as an ASON link, first
configure the MSP1+1 link and then create the ASON data link.
When protected by ASON, ASON views both main and protection links logically as a single MSP1+1 link. A
trigger for ASON restoration occurs only in the event that both main and protection MSP1+1 links are cut
(the ASON link is cut). Revertive restoration is triggered only when the main MSP1+1 link is repaired.
MSP linear can also be part of an LDL. To include MSP linear as part of an LDL, first configure MSP1+1, and
then configure the segment as LDL.
When creating a trail, LightSoft tries to find a path that comprises only ASON links, by default. However an
ASON trail can be forced to traverse an NE that is within an MSP 1+1 domain by manually selecting links
along the trail path during the provisioning process.

The following figure shows an MSP 1+1 segment located within the ASON domain.
Figure 5-19: MSP1+1 - logical view as single ASON data link
One leg of an SNCP-protected trail should pass outside MSP 1+1 domain
If the ASON trail traverses MSP 1+1, it is recommended to define the trail protection as Current and
Underlying, with current protection provided by SNCP and underlying protection provided by MSP1+1. The
two SNCP paths should be set as follows:
 One path (either main or protection) forced to traverse the MSP 1+1 domain by manual segment
selection.
 One path set outside the MSP, and therefore ASON protected.
In this way, if two MSP1+1 links fail, traffic will recover on the ASON link. This avoids a single point of failure
situation where both paths traverse MSP 1+1. ASON always tries to restore the traffic.
NOTE: The termination point of the SNCP and the MSP 1+1 must not be on the same NE. In
general the MSP 1+1 is located in the middle of the trail. It cannot be the end.

Figure 5-20: MSP 1+1 and ASON path placement
Parent Topic
5.5.4.6 1++ Protection on Terminated Shared Segment

When the main and protection paths share a terminated segment, 1+R protection must be implemented on
that segment. 1++ protection can be implemented only on non-shared segments, or shared segments that
are not terminated.
If you attempt to apply 1++ protection to a long trail where main and protection paths share a terminated
segment, LightSoft will advise you to separate the long trail into two short trails. For example, the trail A-E
should be divided as:
 One trail on the segment adjacent the VC-4 (TST) endpoint (A-B in the example) set with ASON 1+R
protection (Unprotected)
 One trail on the remainder of the path (C-E and D-E in the example) set with ASON Protected (1++)
In this way, the segment adjacent the VC-4 (TST) endpoint that includes shared resources is not 1++
protected. (1++ protection over a shared resource segment is allowed when the segment is in the middle of
a long trail.)
Figure 5-21: Segment adjacent the VC-4 (Term.) endpoint that includes shared resources is not 1++
protected

NOTE: Using 1+R protection on the A-B segment (instead of 1++), and splitting the traffic at B,
saves resources since only one VC-4 is needed on the A-B segment instead of two. If the fiber
at A-B should fail, restoration time would not be different.
Parent Topic
5.5.4.7 ASON and FRR Protection

ASON restoration and reversion interacts with MoT FRR protection in the following ways.
When a fiber is cut on which an MoT trail is running:
 Traffic first switches to FRR protection (<50ms).
 ASON then takes control after the FRR WTR time has elapsed. A hit is experienced (<50ms) when
moving from the FRR to ASON.
When the fiber is repaired:
 Traffic reverts directly from ASON to the MoT. A single hit is experienced (<50ms). FRR is not involved.
Parent Topic
5.5.5 ASON Protection and Priority Schemes

ASON provides up to four CoS options with high and low priority trail provisioning, in addition to the
existing SNCP and MSP1+1 protection schemes. Each ASON head end can handle the failure of up to 256
VC-4s concurrently in a single direction. For this reason, no more than 256 VC-4 trails should be assigned to
a head end NE in a single direction. In addition, to optimize the network, and to minimize restoration time,
we recommend that no more than 256 trails run over the same duct, because a duct may include multiple
fibers.
IMPORTANT: An x86 station is required to handle multiple trails. If using a SPARC station, it
should be replaced.
ASON CoS and priority provide much flexibility, enabling you to provide a range of differentiated services
(per VC-4 trail), including:
 1++ (Gold): Provides <50ms SNCP-based restoration. Creates a "VC-4 Protected 1++ Bidirectional trail"
for high priority services. In this scheme, the main and protection paths are explicitly user-defined in
LightSoft. In the event of a problem on the main path, traffic is switched to the protection path within
50 msec. An alternative protection path is also searched for in advance, to be ready for any
subsequent problem on the same path. Sub-50 msec restoration times are maintained "forever" for
any number of failures, as long as valid restoration paths are available.

This protection scheme is an extension of the traditional 1+1 path protection, with failure in the main
or protection path resulting in restoration of the failed path. 1++ protection has the advantage of
providing recovery from multiple consecutive failures. In the event of a failure, 1++ restores the failed
path via the control plane and builds a new protection trail, thereby remaining ready to deal with any
subsequent failures. 1++ Restoration is an addition to protection at the SDH layer, which continues to
be performed in less than 50 msec.
This option exceeds 'five nines', providing high service availability, with no service downtime. ASON
continuously builds a new protection trail after each fiber cut. This protection scheme is the most
bandwidth consuming, since traffic is duplicated at all times.
 1+1+R (Silver): first cut is <50ms SNCP-based restoration. ASON does restore the path after the first
cut and any subsequent fiber cuts are restored within a few seconds. This option is less bandwidth
consuming than 1++, providing additional protection while allowing for efficient use of network
resources.
 1+R (Bronze): 1+R (Bronze) protection creates an unprotected 1+R bidirectional trail. In the event of a
problem on the main path, the system finds an alternative path using existing free resources. There is
no SNCP switching and traffic is restored dynamically within a few seconds.
Recovery paths are protected in the same way as the main path. New recovery paths can be
implemented as long as additional paths satisfying current criteria can be found. 1+R is also known as
reroute restoration.
1+R is an improvement over the corresponding unprotected option of regular SDH in that service is
restored dynamically on an alternate path within seconds, without operator intervention. Typically,
traffic is restored within one to two seconds. In more complex restoration topologies that contain a
large number of ASON nodes, restoration time can reach up to four seconds maximum.
 Extra Traffic (Iron) (LightSoft V7 and higher only): Extra traffic provides unprotected traffic resources
that can be used preemptively by ASON to provide extra bandwidth during the restoration of gold,
silver, or bronze trails. In the event of a failure of a trail with higher protection, ASON can use extra
traffic resources. An alarm is raised to show that the trail is preempted. Once the failure is restored,
extra traffic resources are released and resume the original trail.
You can use all available bandwidth for preemptive best effort services (extra traffic), or define a
limited number of VCs from the available bandwidth (partial extra traffic). Partial extra traffic ensures
some bandwidth always remains, so that even the lowest priority best effort services are never shut
down completely. Partial extra traffic can only be defined when using an EoS or MoT rate.
All ASON CoS can be used in conjunction with underlying protection (for example, MSP1+1)
Non-ASON protection can also exist on an ASON network:
 1+1 Protection (Current layer): Standard SNCP protection. If protection trail fails, service ends.
 Unprotected: No protection.
Protection schemes are defined in LightSoft, providing that the relevant trail conditions are met (see
Creating and Managing ASON Trails in the NMS). ASON operates with high order interfaces only.
In addition, a priority level is applied to trails in each protection class (see ASON Priority Schemes).
Parent Topic

5.5.5.1 ASON Priority Schemes

In the event of a failure, several trails may be affected. The head end (HE) ASON node is responsible for
coordinating the redirection of each trail, one-by-one. ASON enables you to prioritize trail redirection
through the use of priority levels, in addition to the use of ASON CoS. Trail priority can be either:
 High: After a fiber cut, find an alternative path for the trail immediately.
 Low with delay: After a fiber cut, wait x seconds before finding an alternative path, to enable all high
priority paths to be restored.
Priority levels can be used to provide a greater variety of options to customers. They can also be used to
provide a higher quality of service for selected trails when opting for lower protection levels. Priority levels
are set during ASON trail creation. The default priority delay is set via the Preferences window. (See ASON
Configuration Preferences in the Getting Started & Administration Guide.)
Parent Topic
5.5.5 ASON Protection and Priority Schemes
5.5.5.1.1 ASON CoS Table

The following table displays the available CoS for ASON protection schemes.
Table 5-10: ASON CoS Priorities
Service Type Restoration Time Priority Restoration Time (First Restoration Time (Second
Failure) Failure)
1++ (Gold) High 50 msec 50 msec
Low
1+1+R (Silver) High 50 msec Few seconds
Low
1+R (Bronze) High Few seconds Few seconds
Low
Extra Traffic N/A No restoration No restoration

(Iron)
Parent Topic

5.5.5.1.2 ASON Alternate Path Selection Process

After a fiber cut on an ASON provisioned path or any restoration path, the following recovery behavior
occurs:
 1+R “unprotected” trail: An alternate restoration path is searched to which traffic is redirected.
 1++ protected trail: A direct (50 msec SNCP) switch of traffic to a predefined protection path occurs.
An alternate protection path is then searched to be ready for any subsequent problem on the same
path.
In both cases, the alternate path is searched in the following way:
 First failure (Provisioned path was cut): ASON implements an optimal routing, which can be
established on any free segments which do not currently carry traffic. The recovery takes a few
seconds.
 Second failure (Restored path was cut):
ASON first searches for a path that traverses totally disjoint segments (not part of the previous failed
path). If found, recovery takes a few seconds.
Otherwise, ASON tries to find a path along some segments of the previous path on the same timeslot
as before. This reuse possibility saves on network resources allocated for possible restoration
purposes.
NOTE: In the latter case, the recovery is implemented one minute after the restoration
process starts.
See also LDL Restoration Path Selection Process.
Parent Topic
5.5.6 Creating an ASON Trail

ASON trails are created using the SDH or Physical layer.
ASON-protected trails can only be defined on ASON topology links between ASON-enabled NEs. ASON links
have an STM-16 or STM-64 link rate. If the link was created in LightSoft, it must be associated with the
ASON domain in the EMS before use in LightSoft.
Trails protected by alternative protection schemes can be routed through the ASON domain. However, they
do not benefit from ASON protection in the event of a failure.
To migrate an existing trail to ASON or to change its ASON protection level, see Migrating to a Different
Protection Scheme.
NOTE: Provisioning an ASON trail is part of the process of creating a trail. For further details,
see Creating A Trail in the LightSoft User Guide.

To create an ASON trail:

1. In the LightSoft Create Trail window, click the Trail Parameters tab. The Trail Parameters tab is
displayed.
Figure 5-22: Create Trail window displaying Trail Parameters tab
2. In the Advanced Protection area, click the ASON checkbox. The Protection dropdown list is updated
to display ASON protection options.
3. Select the relevant ASON protection scheme (see ASON Protection and Priority Schemes for SDH
Trails).
4. In the Rate field, select an ASON-compatible VC-4 trail rate in the dropdown list (resolution of ASON
trails is always VC-4). ASON supports the following high order server and service trail rates:
 Server trail rates: VC-4 (Term. or TST). Special conditions apply; see ASON Server Trail Notes.
 Service trail rates:
 EoS-VC-4-X (with or without diverse routing)
 MoT-VC-4-X(with or without diverse routing)
 VC-4 (not applicable for partial extra traffic)

NOTE: No more than 256 trails should be assigned to a single ASON head-end NE.
VC-12 and VC-3 trails cannot be defined directly in ASON. Low order traffic can be delivered
over ASON by uploading low order trails over a high order server trail. The traffic then
traverses the server trails (see also ASON Server Trail Notes).
5. (Optional) In the VCAT Size field, enter the VCAT size.

6. In the Directionality field, select Bidirectional in the dropdown list (unidirectional trails are not
supported by ASON).
7. In the Head End Priority dropdown list select a priority level for the trail.
8. In the WTR (mins) field, enter the Wait To Restore time for the trail (between 1-1440 min). If no value
is entered, the default value is used, as defined in the system preferences.
9. In the Restoration dropdown list, select the restoration behavior for trail (see Defining Regions for
Protection). Not applicable for Extra Traffic.
10. (Extra Traffic only) In the Extra Traffic VC field, enter the number of VCs that you want ASON to be
able to use preemptively during restoration.
11. Continue to create the ASON trail in the same way as for standard SDH trails. See the LightSoft User
Guide for further details of SDH trail creation.
Parent Topic
5.5.6.1 Viewing and Modifying the Low Priority Delay

Low Priority Delay defines the default delay period that is applied to low priority ASON trails in the event of
a failure before restoration is attempted. The default restoration delay is three seconds. View the current
delay period in the EMS. Modify the default delay in LightSoft.
To view the current priority delay:

1. In EMS, right-click the relevant ACP card and click Info. The ACP Info window opens.
2. Click the ACP CP Protocols tab. The Low Priority Delay field shows the current delay value.
To modify the default low priority delay period:

1. In LightSoft click Preferences. The Preferences window opens.
2. Click the System tab.
3. In the ASON Parameters area, click the Low Priority Delay dropdown list and modify the number to
the required delay (1-60 sec).
4. Click OK. The default delay is changed in the NMS only.
5. To propagate the new low priority delay value to all NEs in the network:

a. In the System tab of the LightSoft ribbon, click Low Priority Delay Download. A message is
displayed.
b. Click Yes to start download. A confirmation message is received when download is completed.
Parent Topic
5.5.6.2 Editing an ASON Trail

ASON trails are edited in the same way as described for other trail types in LightSoft. For details of how to
edit a trail, see Editing Trails in the LightSoft User Guide.
The following exception applies to low order trails on rerouted ASON server trails.
 If 1++ protection applies to the server trail:
a. Perform Admit on the server trail (see Synchronizing Trails in the LightSoft User Guide).
b. Edit the low order trail as required.
 If 1+R protection applies to the server trail: )
a. Perform Admit on the server trail (see Synchronizing Trailsin the LightSoft User Guide).
b. Edit the server trail to remove the provisioned path.
c. Edit the low order trail as required.
Parent Topic
5.5.6.3 CSPF
You can give each ASON or LDL link a different weight, according to the shortest hop, lowest cost, or
shortest length. The Constrained Shortest Path First (CSPF) algorithm calculates the fastest route according
to default metric, as defined the Preferences. CSPF preferences are set at the system level, as described in
the following section.
Link metrics are set at the link level. See Link Properties in the LightSoft User Guide. For LDL links, see
Defining LDL Link Metric Values in the LightSoft User Guide.
Parent Topic
5.5.6.3.1 Setting CSPF Link Preferences

You can specify the default metric with which the CSPF is calculated. Once the preferences are set, the
preferences must be propagated to the embedded links to take effect in the NMS.
NOTE: To define link metrics, see Updating Link Metric Values and Defining LDL Link Metric
Values in the LightSoft User Guide.

To set CSPF preferences:

1. In LightSoft, click the System tab, and then click Preferences. The Preferences window opens.
2. Click the System tab, and select ASON configuration in the tree.
3. In the ASON parameters area, in the Metric dropdown box, select the metric that you want to use to
calculate the shortest path, and click Apply. The default metric in the NMS is updated. Embedded
links are not automatically updated, and display a mismatch value in the Link List window, until an
update is performed.
Parent Topic
5.5.6.3 CSPF

5.5.6.3.2 Updating Link Metric Values

If the CSFP default metric is modified in the System Preferences window, the changes must be propagated
to the embedded links to take effect in the NMS.
To update the embedded links with the new metric value:

1. In LightSoft, select the Topology tab, and click Link List. The Link List window opens.
2. In the filter (top right of the window), select LDL & ASON Links. The list is filtered to display LDL and
ASON-related links only. The EP1ASON Metric and EP2 ASON Metric columns display current the
metric value for each link. If the metric value is not updated, the value Mismatch is displayed.
3. Select the checkbox in the row of each link you want to update, and click Reconfigure Link Metric
. The Result Dialog window shows the updated status.

4. To update the information displayed, click Refresh.
Parent Topic
5.5.6.3 CSPF

5.5.7 Redefining an ASON Provisioned Path (Admit)

After an ASON trail is activated, LightSoft manages the network and ASON monitors the trail. If a failure
occurs on any fiber or link along the provisioned path, a new restoration path is automatically found by the
ASON control plane. ASON automatically reroutes the traffic from the faulty fiber to the new path. After the
failure is repaired, ASON automatically reverts the trail to the original path.
NOTE: When the trail is rerouted following a fiber failure, the LightSoft Trail properties show
Inconsistent rerouted instead of Provisioned. This means there is inconsistency between
LightSoft’s perception of the trail path and the ASON-rerouted traffic flow. However the
rerouted traffic continues to flow normally between the service endpoints along an optimized
path. There is nothing essentially wrong with this condition. In general no manual intervention
is needed.
Why manually redefine a trail as provisioned?

You can use the procedure described in this section to manually define the current ASON-routed
restoration path as the new provisioned path (thereby “admitting” the trail). Here are some reasons why
you may want to do this:
 Guarantee restoration path resources: It may take time to repair the original provisioned path.
However, leaving the trail in restoration mode for any extended time can lead to suboptimal behavior.
For example, if an NE is reset due to a power interruption, LightSoft first tries to reinstate provisioned
paths based on information in the NE’s non-volatile memory (NVM). When it is recognized that a trail
was restored due to a fiber cut, LightSoft starts the restoration process over again. Additional time
may therefore pass before a restoration path is found. It is possible that, in that time, the former
restoration resources will have been taken for other trails and a different or no restoration path will
be found to restore the trail that is reset. So, if a trail path is needed for any length of time, you should
make sure that the trail is made provisioned as soon as possible to guarantee that its restoration path
and resources will not be occupied as a result of such a scenario.
 Decision that restoration path is preferred: After inspecting the routed path, you may decide that the
restoration path represents an optimal routing and is the preferred path.
 Need to edit the trail: You may need to edit other aspects of the trail besides the path (for example, to
change it from non-SNCP to SNCP). A trail can be edited in LightSoft only when it is Provisioned mode.
If it is currently in Restoration mode, you must first admit the trail to make it Provisioned. Then you
can edit it as needed.
 Need for different provisioned path: You may need the provisioned trail path to be different from the
current restoration path. For example, ASON may have restored the trail path to a needlessly
expensive leased line. In this case, first admit the existing restoration path to make it provisioned, then
edit the trail path as needed. You cannot edit the restoration trail directly.
 Want to reflect the current path in LightSoft: Admit is mainly used to reflect an intended provisioned
path in LightSoft. For example, when XCs are changed in the EMS, performing Admit reflects the
changed path in LightSoft. Since the EMS works NE by NE. XC by XC, but LightSoft considers
end-to-end, the LightSoft path does not otherwise reflect the path implied by the EMS XC.

NOTE: We do not recommend performing Admit, unless necessary.

 If the fiber is repaired, the provisioned path to which the trail will revert is an optimal
path. Editing is unlikely to yield a better result.
 The same functionality (maintenance, all alarms) is available in the reroute state as the
provisioned state. The alternative ASON path is also optimized for your network.
Trail Traversing a Mixed Topology

If the trail traverses a mixed topology (part of the link is ASON, part non-ASON), you can only admit the part
of the trail that ASON restored. The Admit function does not apply to non-ASON links. Non-ASON segments
of the trail path remain part of the original provisioned path.
VC-4 Server Trail (TST)

A VC-4 server trail (TST) cannot be admitted to become provisioned. (This is allowed only for VC-4 service
trails - non-TST.) In the case of VC-4 server trail (TST), if the rerouted path is required as the provisioned
path, it is recommended to:
 Wait for the fiber to be repaired and the trail to revert from rerouted back to provisioned.
 Then edit the trail path as needed.
You can also delete the original trail and create it again, although this is traffic affecting.
NOTES:
 Reroute functions that are part of ASON maintenance operations cannot be used to
change a provisioned path (Admit) as they do not change the path state. They perform a
controlled reroute, temporarily rerouting a trail that is to undergo repair. The reroute is
the same way as reroute upon failure, except that it is performed manually. For more
information, see Maintaining the ASON Domain.
 A VC-4 (Term.) server trail cannot be automatically redefined as provisioned. However the
operation is allowed for VC-4 service trails.
To change an ASON trail’s provisioned path:

 Admit the applicable trail through TCI acquisition (see Synchronizing Trails in the LightSoft User Guide).
NOTES: Admit must be performed one trail at a time. You are not allowed to admit multiple
trails together.
The path and XCs are accepted and activated by TCI in the same way as SDH trails, but based on control
plane provisioning.

Recommended workflow and settings to avoid admitting an incomplete

trail path:
1. Perform TCI acquisition with Use Connectivity Only set to ON.
2. The Network Trail Sequence floating window within the Trail Synchronization window lists the
applicable trails, or trail segments. Examine each candidate trail for acquisition, as follows:
a. Select a trail line.
b. Select Show Highlighted Trail on Map . A Create Trail window opens in read-only mode
indicating the trail parameter values. The trail path is highlighted in the window map, showing
the location of any discontinuities.
c. Look for the trail line that contains a complete set of server segments. Make sure that all server
segments of the rerouted trail path appear correctly. If you find the appropriate trail line,
continue to admit the trail (Step 3 below).
CAUTION: Make sure to find the line that represents a complete restoration path, including
both main and protection path routes. Otherwise the Admit action will not succeed.
d. If you do not succeed to find a complete restoration path (segments on the rerouted trail path
are missing):
 Return to the TCI and acquire the trail again, this time with Use Connectivity Only set to
OFF.
 Repeat steps (b) and (c).
 If you still cannot find a complete restoration path, do not continue the process. Contact
your local Customer Support representative.
3. If you find a complete restoration path, select the applicable trail line and click Activate to
admit the trail. (Continue the Admit operation as described in Performing Trail Synchronization in the
4. If the trail is admitted as a flex and Admit failure occurs, perform the appropriate Troubleshooting
step; see Troubleshooting, below.
The rerouted path is redefined in LightSoft as the provisioned path. The path does not revert to the
previous provisioned path when the failure is restored. The ASON control plane is informed of the change,
and no longer registers the path as a resource reserved for restoration.

Troubleshooting
In some cases, the trail acquisition process does not acquire all server trails or build the diverse routes of
data trails properly. This may cause the following types of problems in ASON trails.
Table 5-11: Provisioned path redefinition troubleshooting
Problem Solution
1 Data trails with several diverse routes: When Join all XC sets into a single XC set via the EMS and
signaling creates several XC sets on the same re-admit the trail in LightSoft.
ME, Admit may fail or the trail may be
reflected inappropriately.
2 Non-data trails: After Admit, the trail may be Edit the trail path, adding/removing segments as
flex and the trail segments incomplete or not needed to remedy the discontinuities; see Editing
continuous. The trail is not ASON protected Trails in the LightSoft User Guide. You may need to
(despite being shown as 1++ or 1+R). delete and recreate the trail.
Note: Editing a trail may be traffic-affecting since
LightSoft may create or delete XCs, or change their
internal order.
3 Same as problem 2, and in addition the Trail Perform Reconnect Trail; see Reconnecting Trails in
State is Incomplete due to improper deletion the LightSoft User Guide.
of XCs upon Admit. This may happen when an
incomplete trail path is acquired.
Parent Topic
5.5.8 Reconnecting ASON Cross Connects

Whenever ASON cross connects (XCs) are created, edited or deleted in the EMS for maintenance purposes
(or a XC is deleted by mistake when working in the EMS), the Trail State will become Incomplete and you
will have to reconnect the trail in LightSoft as described in this section.
For non-ASON trails, you can reinstate the cross connects and make the Trail State OK again by just
reconnecting the trail; see Reconnecting Trails in the LightSoft User Guide.
For ASON trails, the effects on the system, and the applicable reconnection procedure, vary according to
the trail type (ASON provisioned or ASON restored). Identify the trail type with which the XC is associated,
and then select the reconnection procedure that is appropriate to that trail type. You can determine the
applicable trail type as follows:
 ASON Provisioned trail: Deletion of a XC results in the LightSoft Trail State parameter in the Trail List
window Trails pane changing to Incomplete. (A service alarm may also be raised for the trail. For 1++
protected trails, this only occurs if XCs were deleted from both trail paths.)
 ASON Restored trail: Deletion of a XC results in traffic failure (no ASON protection).
If 1++ protection applies, ASON failure only occurs if the XCs were deleted from both trail paths. If XCs
are deleted from only one path, traffic continues to flow via the other path, but possibly with a traffic
hit. A UNEQ alarm on the trail in the LightSoft Current Alarms window is an additional indication of XC
deletion.
After identifying the ASON trail type, perform the appropriate reconnection procedure.

To reconnect ASON trail XCs for a provisioned trail:

1. Reconnect the trail in LightSoft to recreate the cross connects; see Reconnecting Trails in the LightSoft
User Guide.
2. Edit the trail in LightSoft to be non-ASON; see Editing Trails in the LightSoft User Guide.
3. Edit the trail in LightSoft to be ASON again; see Editing Trails in the LightSoft User Guide.
4. Verify that the Trail State parameter is OK.
To reconnect ASON trail XCs for a restored trail:

1. Perform the relevant Revert Force ASON Maintenance operation on this trail (Revert Force Main Path
or Revert Force Protection Path, or both may apply); see ASON Maintenance Operations.
2. After the WTR time has elapsed, verify that the LightSoft Trail State (Trail List window Trails pane) is
OK; see parameter description in Trails Pane Columns in the LightSoft User Guide.
3. Perform the relevant Reroute Manual ASON Maintenance operation on this trail (Reroute Manual
Main Path or Reroute Manual Protection Path, or both may apply); see ASON Maintenance
Operations.
Parent Topic

5.5.9 Associating ASON Trails
5.5.9.1 Automatically Associating a Trail (1++ only)
When a 1++ trail with multiple head ends is created, LightSoft automatically informs the head ends in the
Main path of the resources used by the ASON tunnel(s) in the protection path. It also informs the head ends
in the protection path of the resources used by the ASON tunnel(s) in the main path. This enables each
head end to exclude data links used by the other path during restoration, thereby maintaining path
diversity.
In a 1++ path that is purely ASON, there is only one head end required. If the path contains non-ASON
segments, the start of each ASON segment will have its own head end. This means each ASON trail can
have several head end nodes - up to a maximum of five per trail. Each head end node is responsible for
maintaining route exclusion table for the segment(s) that it manages. If more than five ASON segments are
separated from each other by non-ASON segments, an error message is displayed and trail association is
not performed.
NOTE: It is not necessary to associate Main and Protection paths for 1++ trails with a single
head end because they are already supported by the embedded ASON software.
When the user activates the trail, LightSoft downloads a list of tunnels that should be excluded to the head
end along the trail, including the head end’s IP address and the tunnel’s resources. Automatic Trail
Association is performed for the following trail types:
1++ (Gold) trails with multiple head ends only. ASON automatically associates 1++ trails with multiple
head ends. This ensures that in the event of a failure ASON does not restore traffic on a path that the
associated trail is located, unless no other alternative bandwidth exists with which to restore the
service.
 1++ (Gold) trails with a single head end. Always automatically associated.
 Automatic association of 1++ trails also applies to "1++ & Underlying" trails, including MSP-L links. It
applies to server and service VC-4 trails, including TST trails.
 If the main or protection path is modified for an associated trail, then the trail association is
automatically updated.
Limitations
Automatic Trail Association is not performed on 1++ trails if:
 There are more than five associated ASON tunnels on either the main or protection path of a 1++ trail.
A message is displayed after completion and ASON Configuration parameter in Trail Parameters tab
Basic tab.
 There are more than 850 resources in the Trail Info window.
 Trails are EoS and MoT VC-4 trails.
When upgrading to LightSoft V7 or higher, 1++ trails must be associated manually.
Parent Topic
ECI Telecom Ltd. Proprietary 5.5.9-1

5.5.9.2 Manually Associating a Trail (1+R only)

One of the scenarios in which the use of 1+R protection is of benefit is in the case of a TST server trail that
carries LO traffic, where each LO trail has underlying SNCP protection. The LO trails are protected and
traverse two separate 1+R TST trails. Associating these trails excludes the LO protection trails from ASON's
preferred restoration paths (unless no other restoration path is available). Associating the trail prevents the
main and protection TSTs from traversing the same segment in the event of a failure, i.e. it prevents both
LO trails from traverse the same path, unless no other restoration path exists.
Requirements
You can manually associate the main and protection path of any 1+R (Bronze) SDH trail that goes through
an ASON domain. In the event of a failure, ASON attempts to avoid using the links of associated trails.
To manually associate or disassociate a trail, the following conditions must be met.
 Manual association can be performed for bronze 1+R VC-4 high order trails only.
 The 1+R trail can be 1+R & Underlying, including MSP-L links.
 The ASON Path State parameter must be Provisioned.
 The ASON Association parameter must be Unassociated.
 The ASON Configuration parameter and the Trail State parameter must be OK.
 Trails must not overlap within the ASON domain (i.e., they must be fully diverse). This means a DL or
LDL used by one 1+R trail cannot be used by an associated trail.
Limitations
Manual trail association is not performed on 1+R trails if:
 There are more than five associated ASON tunnels on a trail.
 There are more than 850 resources in the Trail Info window.
To manually associate trails:

1. In the LightSoft Trail List window, select the two 1+R trails that you want to associate.
2. Right-click one of the trails and select Trail Operations > ASON Operations > Associate Trails (only
available when two trails are selected). The Associate Trails window displays the selected trails.
3. Click OK. LS associated the trails and a confirmation message is displayed. In the Trail List window, the
ASON Configuration parameter is listed as OK (Associated) for all associated trails.
Parent Topic

5.5.9.2.1 Disassociating a Trail

You can manually disassociate a trail. It is recommended that all trail associations are removed from a trail
before deleting the trail. When attempting to delete a trail that is associated, the following message is
displayed: "If the trail is deleted before the association is removed, then after deleting the trail, the ASON
Configuration parameter for the remaining trail is changed to Incomplete Association. If it is disassociated,
then the parameter is changed to OK (Unassociated)."
To manually disassociate trails:

1. In the Trail List window, select one or more 1+R trails that you want to disassociate.
2. Right-click one of the trails and select Trail Operations > ASON Operations > Disassociate ASON Trails
(only available when 2 trails are selected). The Associate Trails window displays the selected trails.
3. Click OK. LS associated the trails and a confirmation message is displayed. In the Trail List window, the
ASON Configuration parameter is listed as OK (Associated) for all associated trails.
Parent Topic
5.5.9.2.2 Updating Trail Associations

If the path of an associated trail is edited, you can update the related trail associations.
To update the trail association:

1. In the Trail List window, select the checkbox of the trail(s) that you want to update.
2. Right-click the trail and select Trail Operations > ASON Operations > Update Association.
3. The Update Trail Association window opens, displaying the trails that are to be updated.
4. Click OK. A confirmation message is displayed to show that the association is updated, and the ASON
Configuration parameter is updated accordingly.
NOTE: When reconnecting associated trails, the trail association is also updating
automatically.
Parent Topic

5.5.9.2.3 Updating Trail Association after Upgrading

When upgrading to LightSoft V7 or higher, it is necessary to manually associate 1++ VC-4 (non EoS/MoT)
trails.
To manually associate the trails:

1. After completing the LightSoft upgrade, in the Trail List window, select all VC-4 trails you want to
associate/update.
2. Right-click one of the trails and click Reconnect. All XCs are downloaded from LightSoft to the
relevant NEs, and the trail associations are updated.
Parent Topic
5.5.9.3 Viewing ASON Trail Association Status

You can view the status of an ASON trail association. Values include:
 Unassociated: ASON trail is not associated.
 Associated: 1++ trail has a single head end, or the ASON trail is associated successfully.
 Incomplete Association: an action was performed on the trail (e.g., edit, or delete) but the trail
associations are not updated.
 N/A: Not applicable.
To view trail associations:

1. In the Trail List window, select the checkbox on the trails that you want to view.
2. Right-click a trail and click Show and then click Show Associated Trails. The Show Associated Trails
window opens displaying the selected trail(s) and their associated trail(s).
Parent Topic

5.5.10 Defining Regions for Protection
5.5.10.1 Overview
Traffic Localization enables you to divide an ASON domain into administrative regions (up to a maximum of
16). Define a region by specifying which data links are associated with a particular region number. Data
links can belong to more than one region (for example, if they form the border between two regions), or to
no region, as required.
Once the regions are defined, when creating or editing a trail, you can specify the localized restoration
behavior for each trail (see Creating an ASON Trail).
During restoration of a trail, the embedded software attempts to use resources within the region(s) where
the failure occurred to reroute each ASON trail, according to the specified trail restoration categories:
 Strict Localization: use only the data links in the restoration region(s) to restore the trail. If the trail
passes through several regions, the segment of the trail that failed can only be restored using links in
the region in which the failure occurred.
 Not-localized (default): perform restoration without reference to regions. Use data links from any
region to restore the trail.
 Relaxed Localization: restoration occurs in two stages:
a. Apply strict localization rules: search for restoration options in the restoration region only.
b. Apply Not-localized rules: If no solution is found using strict localization, apply not Localized
restoration rules. Perform restoration without reference to regional restrictions.
NOTE: Restoration cannot be applied to Extra Traffic trails.
Parent Topic
5.5.10.2 Adding Links to a Region

You can add an individual data link to one or more region.
Once configured, the ASON Regions Association Status field indicates whether regional associations are
configured correctly. The status options are:
 OK: Regions are defined correctly at both endpoints.
 Inconsistent: Regions are inconsistent and not correctly defined for at least one endpoint.
NOTE: In MSP-L protected links only the Main link can be associated with ASON region(s).

To add a data link to region(s):

1. In the LightSoft map, right-click the data link and select Properties. The Properties for Link window
opens.
2. Click the ASON tab. A list of regions is displayed.
3. To add the link to a region, in the relevant row of the Associated column select True in the dropdown
list.
4. Repeat the previous step for all regions to which you want to add the link, and click Apply. The link is
added to the selected region(s) and a summary message is displayed.
Parent Topic
5.5.10.3 Associating Multiple Links to a Region
You can associate several links with one or more regions.
To associate several data links with a region:

1. In the LightSoft map, click the Topology tab and then click Link List. The Link List window opens.
2. In the filter area, select SDH Links. A list of SDH links is displayed.
3. Check the boxes of all links for which you want to specify a region and then click . The Configure
TE Parameters window opens displaying the ASON tab.
Figure 5-23: Configure TE Parameters window
4. To associate the links with a region, in the relevant row of the Associated column dropdown list select
True.
5. Repeat the previous step for all applicable regions and click Apply. The changes are saved and a
summary message is displayed.
Parent Topic

5.5.11 Migrating to a Different Protection Scheme

You can migrate trails that are non-ASON trails to ASON. You can also migrate an ASON-protected trail to a
different ASON protection scheme. Some priority schemes are not compatible and cannot be migrated to
ASON directly. For a list of compatible protection schemes, see Migration Options Supported in the
Migration can also be performed for multiple trails at a time by XML Export in Edit mode and Import (see
Editing a Trail, and Batch Trail Operationsin the LightSoft User Guide).
NOTE: To edit a client trail, ensure that the Trail State is OK and the Trail Type is not Flex.
To migrate a trail to a different ASON protection scheme:

1. In the LightSoft Trail List window, right-click the relevant trail and click Edit > Edit Highlighted. The
Edit Trail window opens.
2. (If migrating from a non-ASON trail to an ASON trail only) In the Trail Parameters pane, select the
ASON checkbox and edit the ASON-related parameters, as required (see Creating an ASON Trail in the
LightSoft User Guide).
3. In the Trail Parameters tab Protection dropdown list, select the relevant ASON protection scheme.
4. (If migrating from an unprotected to a protected trail only) Select the protection path segment(s) and
endpoints that you require. If no segments are selected, LightSoft automatically selects the optimal
protection trail.
5. Click Complete and then click Activate. The trail protection is updated. If server or client trails fail to
migrate, their Trail State changes to Incomplete Edit. If there are failed trails, reconnect the trail.
6. To reconnect a trail, in Trail List window, right-click the trail and select Reconnect.
Parent Topic
5.5.11.1 Migration Options Supported

Migration from non-ASON networks to ASON networks requires change existing trails from non-ASON to
ASON as well as changing the protection of the trail (e.g. from Unprotected to 1++). In addition, the
migration of a server trail often necessitates changes in its client trails.
HO SDH trails can be modified in any combination of the following two options:
 From unprotected to protected and vice versa.
 From non-ASON to ASON and vice versa.
The following table summarizes the possible changes. All operations are supported for server trails with or
without client trails, and for service trails.

NOTE: In the following table, Unprotected refers to Non SNCP protection, Protected refers to
SNCP protection.
Table 5-12: Protection Migration Options
Scenario Protection ASON Status
From To From To Examples
1 Unprotected Unprotected Non-ASON ASON  Unprotected to 1+R

 Unprotected to extra
traffic
2 Unprotected Unprotected ASON Non-ASON  1+R to Unprotected
 Extra traffic to
unprotected
3 Protected Protected Non-ASON ASON  Current layer to 1++
 Current layer to 1+1+R
4 Protected Protected ASON Non-ASON  1++ to current layer
 1+1+R to current layer
5 Protected Protected ASON ASON  1++ to 1+1+R
 1+1+R to 1++
6 Unprotected Protected Non-ASON Non-ASON  Unprotected to current
layer
7 Unprotected Protected ASON ASON  1+R to 1++
 1+R to 1+1+R
 Extra traffic to 1++
 Extra traffic to 1+1+R
8 Unprotected Protected Non-ASON ASON  Unprotected to 1++
 Unprotected to 1+1+R
9 Unprotected Protected ASON Non-ASON  1+R to current layer
 Extra traffic to current
layer
10 Protected Unprotected Non-ASON Non-ASON  Current layer to
unprotected
11 Protected Unprotected ASON ASON  1++ to 1+R
 1+1+R to 1+R
 1++ to extra traffic
 1+1+R to extra traffic
12 Protected Unprotected Non-ASON ASON  Current Layer to 1+R
 Current Layer to
Extra-Traffic

Scenario Protection ASON Status
From To From To Examples
13 Protected Unprotected ASON Non-ASON  1++ to Unprotected

 1+1+R to Unprotected
NOTE: The migration options listed are subject to the constraints of the destination trail. For
example, to modify a trail to 1+1+R protection, the main and protection trails must have a
shared head end.
Parent Topic
5.5.11.2 Migrating Multiple Trails to/from ASON Protection

You can migrate multiple non-ASON trails to ASON protected trails, or vice versa. You can add or remove
ASON protection for:
 trails with VC-4, EoS-VC4-X, or MoT-VC4-X rates
 VC-4 service trails
 VC-4 server trails, with or without client trails.
To migrate multiple trails to/from ASON protection:

1. In the Trail List window select the server trails that you want to migrate.
2. Right-click one of the selected trails and click Trail Operations and then ASON Operations, and then
either Add ASON Protection or Remove ASON Protection. The Add/Remove ASON Protection
window opens, displaying a list of the trails that are to be migrated.
3. Click OK. LightSoft migrates the trails. When migrating trails to ASON, unprotected trails are changed
to ASON 1+R (bronze) trails, and protected non ASON trails (current layer) are changed to ASON 1++
(gold) trails by default. A summary window is displayed, showing the total number of trails that
succeeded or failed the migration process.
Parent Topic

5.6 DNI/DRI Protection

LightSoft offers SubNetwork Connection Protection (SNCP) and Bidirectional Path Switched Ring (BPSR)
interworking using user-assisted and automatic methods. The following ring interworking methods are
supported:
 Dual Node Interworking (DNI) with a single NE to bridge two rings. DNI protection is configured
automatically by LightSoft when relevant.
 Dual Ring Interworking (DRI) with two NEs to bridge two rings:
 For SDH. Creating DRI protection for SDH trails is described in Creating SDH DRI Trails.
 For Data (EoS/MoT). Creating DRI protection for data trails is described in Creating a Data DRI
Trail.
The method selected depends on the network topology.
In this manual:
 DNI refers to node protection involving two (virtual) rings, with “dual” denoting the number of rings
and “node” denoting the closure of the rings being performed by a single node. This differs from ITU
standard usage where DNI suggests two nodes connecting two (virtual) rings.
 DRI refers to dual (virtual) ring architecture that uses two nodes to connect to another ring and has a
"bridge" between these nodes, for example, between mesh and ring.
The differences in meaning with standard usage reflect the enhanced interworking flexibility of
XDM/NPT NEs.
Parent Topic
5.6.1 Dual Node Interworking

DNI allows you to close two (virtual) rings in a single NE. The path protection of each virtual ring is
independent of the other ring. The Create Trail operation builds DNI cross connects in all nodes where the
main and protection paths enter and leave the NE on distinct topology links (wherever the links ports
support SNCP). The PathFinder algorithm avoids using a single node for main and protection path routes. So
to create a DNI in a specific route, you may need to select the links/server trails manually unless the
topology is such that only DNI paths are found by the PathFinder.
DNI provides the advantage of two inputs and two outputs, independent of each other. If one input fails,
two outputs continue to receive the signal.

When selected, DNI trails are created automatically during trail creation. LightSoft can also be configured to
always to create DNI where possible.
Figure 5-24: DNI bridging using a single NE
Figure 5-25: DNI bridging using two NEs
Parent Topic
5.6.2 Dual Ring Interworking

In many cases, a network is a complex mixture of interconnected elements (for example, mesh) with
several alternate protection bridging options. DRI trails essentially create virtual rings so that the trail is
capable of surviving independent virtual ring failures. LightSoft supports two types of DRI trails:
 User-assisted DRI, where you specify DRI bridges when selecting resources before invoking the
PathFinder algorithm. When selecting a DRI bridge, indicate the source endpoint for each link and its
role as Main or Protection. You can select more than one link per bridge; otherwise, their location may
not be optimal. This process varies for SDH and data DRI trails.
 Automatic DRI, where the LightSoft PathFinder mechanism selects the resources automatically,
including the bridges to use between the optimal main and protection paths.

DRI is configured during trail creation. You can also indicate the maximum number of bridges you want the
system to find between the main and protection paths.
Figure 5-26: DRI Bridging - bidirectional trail using two NEs
Figure 5-27: DRI Bridging - unidirectional trail using four NEs
Parent Topic
5.6.3 Creating SDH DRI Trails

DRI trail creation is an optional feature that can be configured during trail creation. Only the steps required
to create an SDH DRI bridge are described in this section. For details of the full trail creation procedure, see
Creating a Trail.
To create an SDH DRI trail, define the main and protection paths, define the bridge segments in the
direction(s) that you require, and then complete and activate the trail. You can create one or more bridges.
The maximum number of bridges that can be created depends on the topology and level of protection you
require.
NOTES: The procedure for creating a data DRI trail (using EoS/MoT rate) is slightly different
from the one outlined below. See Creating a Data DRI Trail.

To create a DRI trail:

1. Open the Create Trail window, as described in Provisioning SDH and EoS/MoT Trails.
2. In the Basic Trail Parameters pane (in addition to other trail creation settings):
a. Verify that the Protection field is set to Current or Current and Underlying.
b. Select the DRI checkbox.
c. In the Maximum DRI Bridges field: enter the maximum number of DRI bridges that you want to
create.
d. Select the Extra Traffic if extra traffic resources are desired in MS-SPRing rings.
3. In the Topology Map, select the NEs that act as endpoints; for details, see Endpoints List Pane.
From this point, the level of automation for selecting bridge segments is at your discretion. You can
either continue with Step 6, or allow the system to select all participating bridge segments as follows:
a. In the Create Trail window, click Complete Trail . LightSoft searches for a path using your
selections. When a path is found, it notifies you with a short message in the upper right-hand
corner of the Create Trail window.
b. Check whether the results are acceptable.
c. When the trail has been completed, click Activate Trail to activate the trail in the network.
(Clicking Activate Trail without first clicking Complete Trail prompts LightSoft to search for a
path.)
d. Click OK to approve.
4. In the Create Trail window, to select the bridge segments right-click the link and click Select Segment.
The Select Segment pane opens; see Select Segment Pane.
5. Right-click a resource (link name or specific link segments) in the list and then choose Select Resource
(or double-click the resource). Select a resource in the resulting panes as described in Select Resource
Pane.
6. Follow the same procedure for both the Main and Protection bridges. The link information appears in
the Resource Tree pane.
 If a trail comprises a number of contiguous links, follow Steps 5 and 6 for all links forming the
trail.
 If a trail is bidirectional, you must also select the endpoint that leads to the respective bridge
since, in theory, it may have to function in either direction.

7. In the Trail Paths pane Tree View tab, select the DRI bridge segment(s) for the main path, right-click
and select DRI Bridge. The Define DRI Bridge dialog box opens.
8. In the Source Endpoint pane, select the required endpoint and click OK.
In the Trail Paths pane Tree View tab, the bridge icon appears in the segment line and its
endpoint appears in the icon's tooltip.
9. Repeat Steps 7 to 9 for the protection path (or additional bridges).
10. Click Complete Trail . LightSoft searches for a path using your selections. When a path is found,
the system notifies you with a short message in the upper right-hand corner of the Create Trail
window.
11. When the trail has been completed, click Activate Trail to activate the trail in the network, and
click OK to approve. The trail appears in the map.
Parent Topic

5.6.4 Creating a Data DRI Trail

This section describes the steps required to create a Data DRI bridge. A data trail is defined as a trail that
uses EoS or MoT rates.
You can create one or more DRI bridges for data trails, and each bridge consists of one or more segment.
The maximum number of bridges that can be created depends on the topology and level of protection you
require. Data DRI creation also supports diverse routes. You can create the bridge either:
 Automatically: PathFinder selects the location of the bridge(s), and the resources.
 Using Autocomplete Bridge: Select one or more bridge segment, and allow PathFinder to complete
the trail and select the resources for main and protection, in both directions. The Auto complete DRI
bridge option enables you to create bridges for main and protection paths in both directions in a
single action for each segment.
 Manually: Select each bridge segment individually, define the endpoints and direction for each
segment you want to assign to the bridge, and select the resources that you want to use.
You can also apply any of the above methods to create a data DRI trail for diverse routes.
NOTE: DRI trail creation is an optional feature that can be configured during trail creation for
SDH and data trails. For details of the full trail creation procedure, see Creating a Trail.
Parent Topic
5.6.4.1 Automatically
DRI bridge creation using the Autocomplete path completion option is the simplest method of creating a
DRI bridge. PathFinder selects the main and protection paths, and the DRI bridge segments are completed
automatically for both main and protection paths.
To create a DRI bridge automatically:

2. In the main window select the objects containing the endpoints of the intended trail and in the Trails
tab, General group, click Create Trail. The Create Trail window opens displaying the selected
topology.
3. In the Create Trail map, select the trail endpoints.
 Protection: in the dropdown list, select either Current or Current and Underlying.
 Rate: select the relevant EoS or MoT rate.
 Select the DRI checkbox and in the Max DRI Bridges field, enter the maximum number of DRI
bridges that you want to create.
 (Optional) select MS-SPRing Extra Traffic, if required.

5. (Diverse routes only) To automatically create DRI bridges for all diverse routes:
a. In the VCAT Size field, enter a number greater than 1.
b. In the EoS/MoT Configuration area, select the Diverse Routes checkbox and enter the following
information:
1) In the dropdown box select either At Least or Exactly, and the adjacent box, select the
number or routes that you want to create. This number cannot exceed the VCAT size.
2) In the Min VC paths/route field, enter the minimum VC size of each route. (This number
cannot be greater than VCAT size multiplied by the number of routes).
3) (Optional) In the MS-SPRING Extra Traffic Routes field, enter the number of routes that
require extra traffic.
6. In the Endpoints & Paths tab, Path Completion area, select Auto-complete.
7. Click Complete Trail , and then click Activate Trail . PathFinder creates the Main and
Protection paths, and creates the optimal bridge(s) according to the PathFinder configuration.
Parent Topic
5.6.4.2 Using AutoComplete DRI Bridge

Use the autocomplete DRI bridge creation when you want to select one or more bridge segment, but you
want PathFinder to complete the remaining data DRI segments and select the resources. Creating a bridge
for main and protection paths in both directions involves assigning four separate bridge segments. The
Auto Complete DRI bridge option enables you to assign all four bridge segments in a single action. For data
trails, Autocomplete DRI protection can also be implemented for diverse routes.
To create a DRI bridge using Autocomplete:

topology.
 (Diverse routes only) VCAT Size: enter a VCAT size greater than 1.

5. (Diverse routes only) In the EoS/MoT Configuration area, select the Diverse Routes checkbox and
enter the following information:
extra traffic.
6. (Recommended) Define the main and protection route(s) and click Complete (see Creating a Trail).
7. In the Basic Trail Parameters area, select the DRI checkbox and in the Max DRI Bridges field, enter
the maximum number of DRI bridges that you want to create.
8. (Optional) select MS-SPRing Extra Traffic, if required.
9. In the Path area, click Both and in the Create Trail map, select two endpoints.
10. In the Path area, select the path on which you want to create the DRI bridge (Main or Protection).
11. In the Endpoints and Paths tab Select Segment area, click the Bridge tab and in the Bridge No. field,
enter an identification number for the bridge that you want to create.
12. (Diverse Routes only) In the Select Segment pane Bridge tab, select the route(s) to which you want to
add a bridge. To select more than one route, click the multi combo box dropdown box, and check
each route you want to include.
13. Select the Auto complete DRI bridge checkbox to ensure the bridge segment is automatically created
for main and protection paths in both directions automatically for each bridge segment that you
select.
14. To select a segment:
a. In the Create Trail map, right-click the segment that you want to include in the DRI bridge and
click Select Segment. The Select Segment pane displays details of the segment, including the
source endpoints, which indicate the direction of the traffic in relation to their ports.
b. To select the DRI segment direction, in the Port column, click the relevant port. The selected
port is highlighted. If the trail is a high order trail, the resource is selected automatically.
15. (Low order trails only). Right-click the port, and either:
 Click Auto Select Server Trails: PathFinder automatically selects a server trail.
OR
 Click Select Server Trail and then select the server trail that you want to use in the Select Server
Trail area.
16. Click Complete Trail and then Activate Trail. PathFinder completes the trails and creates the bridge(s)
according to the SDH constraints defined in the system Preferences.
Parent Topic

5.6.4.3 Manually
Manual DRI bridge creation enables you to specify the segments that you want to include in the bridge,
including the endpoints, direction, and resources. You can use a combination of manual and autocomplete
bridge methods to create a DRI bridge, if required. For data trails, DRI protection can also be implemented
for diverse routes.
NOTE: (Recommended) Before creating a DRI bridge manually, create the main and
protection paths.
To create a DRI bridge manually:

topology.
 (Diverse routes only) VCAT Size: enter a VCAT size greater than 1.
5. In the Basic Trail Parameters area, select the DRI checkbox and in the Max DRI Bridges field, enter
the maximum number of DRI bridges that you want to create.
6. (Optional) select MS-SPRing Extra Traffic, if required.
7. (Diverse routes only) In the EoS/MoT Configuration area, select the Diverse Routes checkbox and
enter the following information:
extra traffic.
8. In the Path area, click Both and in the Create Trail map, select two endpoints.
9. Define the main and protection route(s).
10. Click the Endpoints and Paths tab and in the Select Segment area, click the Bridge tab.
11. In the Bridge No. field, enter an identification number for the bridge that you want to create.
12. Ensure the Auto complete DRI bridge checkbox is not selected.
13. To manually select the DRI bridge segment:

a. (Diverse routes only) In the Select Segment pane Bridge tab, select the route(s) to which you
want to add a bridge. To select more than one route, click the multi combo box dropdown box,
and check each route you want to include.
b. In the Create Trail map, right-click the segment that you want to include in the DRI bridge and
click Select Segment. The Select Segment pane displays details of the segment, including the
source endpoints, which indicate the direction of the traffic in relation to their ports.
c. In the Path area, select the path on which you want to create the bridge (Main or Protection).
d. To indicate the DRI bridge segment source endpoint, in the Select Segment pane Source
Endpoint area, select a source endpoint.
e. To indicate the DRI bridge segment direction, in the Port column, click the relevant port. The
selected port is highlighted. If the trail is a high order trail, the resource is selected
automatically.
f. (Low order trails only). Right-click the port, and either:
 Click Auto Select Server Trails: PathFinder automatically selects a server trail.
OR
 Click Select Server Trail, select the server trail that you want to use in the Select Server
Trail area. (Optionally) To select the resource, right-click the server trail, click Select
Resource and in the Select Resource area, click the timeslot that you want to use.
g. Repeats steps b-e until the segment is assigned for all directions.
The segment appears under the relevant Bridge object (or Route object, if there are diverse
routes) in the Resource tree, showing the bridge icon ( ). Roll the mouse over the icon to
display details of the bridge endpoints.
14. Repeat the previous step for each bridge segment that you want to create manually.
15. Click Complete Trail and then Activate Trail. PathFinder completes the trails and creates the bridge(s)
according to the SDH constraints defined in the system Preferences.
Parent Topic
5.6.5 Removing a Bridge Segment

You can remove a DRI bridge segment.
To remove a DRI bridge segment:

 In the Create Trail window Resource Tree, expand the bridge icon and right-click the bridge segment
that you want to remove and click Remove. The bridge segment is removed.
To remove all segments in a DRI bridge:

 In the Create Trail window Resource Tree, right-click the bridge icon and click Remove. The bridge
icon and all segments associated with the bridge are removed.
Parent Topic

5.7 Planned Trails

The Plan Trail window enables you to design networks ahead of time by building "planned" SDH or
EoS/MoT trails. These may be new trails or edited versions of existing trails.
Figure 5-28: Plan Trail window
For information about the Plan Trail window fields, see Create Trail Window.
In contrast with the regular work mode using the Create Trail window, you can select ports and resources
for the new trail without regard to the actual resource state in the network. The trail can be fully
provisioned even while its prospective resources are currently occupied. The new trail (or edited details)
are exported to XML until needed and do not immediately affect the working network.
When the new network design is ready to be implemented (and occupied resources are free), planned trails
may be imported to LightSoft as part of the active network.
Parent Topic
5.7.1 Creating and Exporting a Planned Trail

Create and export a planned trail by following these steps.
To create and export a planned trail:

1. Access the Plan Trail window in the same way as described in Creating SDH and EoS/MoT Trails but
using the following access options:
 In the main window Trails tab, in the Utilities group, click Plan Trail. The Plan Trail window
opens.

You can also access the Plan Trail window in the Trail List window (the window panes show the
parameters of the selected trail), as follows:
 Select a trail and click Plan highlighted trail .

OR
 Right-click a trail and select Plan highlighted. The Plan Trail window opens.
These options are not enabled in the optical layer or in the physical layer if the User Preferences
window Trail Management preferences Default Provisioning Layer parameter is set to optical. (See
Trail Management Appearance Preferences in the Getting Started & Administration Guide.)
2. Follow the same procedures as described in Creating SDH and EoS/MoT Trails. The only exceptions
are as follows:
You can create only one planned trail at a time. The Basic Trail Parameters Pane does not
include a Bundle Size option.
However, the Store current trail as template option can be used to create additional trails with
the same route details on the same segment without having to redefine the trail properties.
(Use the same procedure as described in Create Trails, but omit the Complete and Activate
steps. After exporting a trail, return to the Plan Trail window to finalize the next required trail.)
Multiple planned trails can be appended in one XML file, as described in Exporting Trails.
a. Any rate-compatible port/termination point can be selected. The Endpoints List Pane shows
each endpoint as available, even if it is currently occupied.
b. Any resource in any segment can be selected. The Select Resource Pane shows each resource in
the segment's resource matrix as available, even if it is currently assigned.
c. Completing the trail is not necessary. The trail is automatically completed and activated when it
is eventually imported to LightSoft. (If the trail definition includes occupied resources, even
those that appear free for planning purposes, the Complete action will fail.)
d. Activate is disabled while creating a planned trail.
3. After the trail parameters are defined, export the trail as follows:
 Click Export .
OR
 Right-click a trail and select Trail Utilities > Export. The Export Trails dialog box opens.
4. Continue the procedure as described in Exporting Trails , from Step 4.
Parent Topic
5.7 Planned Trails

5.7.2 Importing Planned Trails

In order to import a planned trail, you must ensure that all the endpoints and segment resources that are
needed for the planned trail are currently unoccupied; else the import will fail.
To import planned trails:

 Import the planned trails as described in Importing Trails.
Parent Topic
5.7 Planned Trails

6 Performing Actions on Trails and Links
This section describes the trail and link management interface for ongoing trail-related and link-related
operations.
A full range of operations on existing trails can be performed using either Trail List window or the LightSoft
main window options, including viewing and filtering trail information, viewing trail alarms, reconnecting
trails, editing and deleting trails, and modifying or activating trail bandwidth.
Link operations described in this section focus on inserting/removing PEs into/from MoE links. These
operations on MoE links are conceptually similar to inserting/removing PEs into/from MoT trails. See
Inserting MPLS PEs into MoT/MoE Links and Removing MPLS PEs from MoT/MoE Links. For simplicity in
those sections, the generic word link is used to represent both MoE links and MoT trails.
6.1 Accessing the Trail List Window

The Trail List window (see Trail List Window) opens with different object combinations according to
preselections in the LightSoft main window:
 If no objects are preselected in the main window:
 The Trail List window Map view shows all objects in the network (consistent with your user
permissions); see Map View.
 The Trails pane includes trails based on the default filter; see Trails Pane.
TIP: Opening the Trail List window may take less time if you choose "No Trails" as the default
filter. You can then select a different filter. For details, see Applying a Filter and Setting It as
Default.
 If objects are preselected in the main window:

 The Trail List window map opens with only those objects and their immediately associated
links/elements.
 The Trails pane shows only the associated trails. In this case, a "Temporary" filter applies (the
default filter is disregarded). If required, you can create a new filter based on the temporary
filter objects; see Creating a Filter with Preselected Objects.
Regardless of preselections, if the Show one trail only option is selected in the User Preferences window,
after a trail is selected in the Trails pane, the Trail List window map shows only the associated elements
and links and hides all the others; see Trail Management Appearance Preferences in the Getting Started &
A wide range of filter options are also available; see Filtering the Trails Pane.
You can open multiple Trail List windows simultaneously, each one displaying a selected layer and elements
independently of other layers, having its own topology layer and view of the network, and allowing
different trail operations.

LightSoft® User Guide Performing Actions on Trails and Links
To open the Trail List window:

1. Select a topology in the main window Topology Layer dropdown list.
2. (Optional) For ease of work and improved performance in larger networks, you can open the Trail List
window with links running between a limited number of NEs and a corresponding limited number of
trails. To do this:
 Ensure that the appropriate trail filter is set as the default. For information about available
predefined filters and how to set one as the default, see Filtering the Trails Pane.
OR
 Select any combination of elements and links in the main window map or elements in the
Inventory tree. (If more than one view is open, the most recently opened view applies.) The
Trail List window map opens with only those elements and links and the Trails pane displays
only associated trails. In this case, the default filter is overridden.
3. In the main window Trails tab, in the General group, click Trail List.
To open the Trail List window with trails of a single LE:

1. In the Physical or Optical layer, select an LE in the View map.
2. Right-click and select Show Trails. The Trail List window opens showing only trails associated with the
selected LE.
Parent Topic

6.2 Trail List Window

The Trail List window enables viewing and filtering trail information and viewing alarms on trails. It features
a graphical representation of all or preselected objects in the active topology layer, a filtered list of existing
trails, and detailed information about a selected trail.
For information about how to open the window, see Accessing the Trail List Window.
Figure 6-1: Trail List window
The window’s Map view shows elements and links of the selected topology; see Map View.
The window displays information about selected trails in the active topology layer in the following panes
and tabs:
 Trails Pane : All or a filtered set of trails from all topology layers. You can select specific trails for
various operations.
Trail Parameters tab

 Trail Properties Pane : Detailed information about a selected trail; enables you to modify some
properties.
Endpoints & Path tab

 Endpoints List Pane : Endpoints of a selected trail.
categories.
These panes (except the Trails pane) are parallel to the same-name panes in the Create Trail process. You
can edit some non-path-affecting parameters in the Trail Properties pane.

Other panes from the Create Trail process (including path-affecting parameters) can be opened for editing
through the Edit Trail window; see Editing Trails. For a description of those parameters, see the following
sections in Creating SDH and EoS/MoT Trails :
 Basic Trail Parameters Pane
 Select Segment Pane
 Select Server Trail and Services Panes
 Select Resource Pane
 Advanced Trail Parameters Pane
 EoS/MoT Configuration Pane
Parent Topic
6.2.1 Trail List Toolbar

The following functions are available in the Trail List window toolbar. (You can access some of them from a
shortcut menu displayed by right-clicking a row in the Trails pane; see Trails Pane Shortcut Menu.)
Table 6-1: Trail List window toolbar

Path:
Selects the path (route) whose attributes are viewed (Main,
Protection, or Both).
Show highlighted trail Complete trail represented by the highlighted trail in Trails pane
on map highlighted on map. Extent of trail depends on the Path parameter
selection.
Edit selected trail Opens the trail highlighted in Trails pane for editing.
Plan highlighted trail Opens Plan Trail window, which enables you to design networks
ahead of time based on edited versions of existing trails; see
Planned Trails.
Show clients for Opens a separate Trail List window filtering the client trails of
selected trails server trails selected in Trails pane; see Viewing Associated Traffic
Entities.
Show servers for Highlights in the map the server trails of client trails selected in
selected trails Trails pane; see Viewing Associated Traffic Entities.
Show active trail (ASON trails only) Show the active ASON trail.
Reconnect selected Reconnects incomplete trails selected in Trails pane. Typically
trails required when a problem arises when creating a trail, for example,
if an NE included in a trail is disconnected. For more information,
see Reconnecting Trails.
Show current alarms Displays current alarms on trails selected in Trails pane; see
on selected trails Viewing Alarms for Selected Trails.


Show operation results Displays detailed results of the last operation, enabled only if not
information completely successful. For more information, see Performing Trail
Operations.
Open Trail Consistency Opens Trail Consistency Indicator window to synchronize trails
Indicator window for selected in Trails pane. (Trail synchronization reconciles
selected trails differences between trail definitions in the LightSoft database and
the EMS.)
Export selected trails to Exports trails selected in Trails pane to an XML file for network
file planning or backup purposes; see Exporting Trails.
Export to CSV Exports list data to a delimited format file like CSV for import to
Microsoft Excel or a relational database application. See Exporting
to CSV.
Print selected trails Prints contents of Trails pane or selected trails only.
Delete selected trails Deletes trails whose checkboxes are selected in the Trails pane. (If
no selected checkbox, deletes the highlighted trail. If trails are
selected, deletes only the selected ones.)
Select all trails Selects all trails in Trails pane.
Unselect all trails Unselects all trails in Trails pane.
Reload whole trail list Reloads the Trail List window and Trails pane, showing newly
created trails. All trails in Trails pane become unselected. Trails
continue to be listed according to the active filter.
Filters Trails pane according to selected filter.
Edit filter Edits a filter. Enabled only if objects were preselected in the main
window before the Trail List window was opened or a user-defined
filter is selected.
Set filter as default Sets a filter as default.
Create filter by trail ID Quickly filters trails by label and/or ID. This method defines a filter
and label (Quick Filter) for each use and does not involve a filter template. For more
details, see Creating a Quick Trail Filter.
Parent Topic

6.2.2 Map View

The map view shows the elements and links of the selected topology view, similar to the most recently
opened main window map view (but without alarm color coding).
You can perform operations on selected objects and links in the map view using shortcut menu options in
the same way as in the LightSoft main map view; see Managing Elements and Groups.
Parent Topic
6.2.3 Trails Pane

The Trails pane lists a filtered set of trails, regardless of topology layer. Clicking a trail in the pane makes it
the focus of the information provided by other panes. Highlighting a trail or marking the checkbox of one or
more trails, selects those trails for various trail operations.
The Alarm State column lets you easily identify alarmed trails, showing the worst alarm state of objects
participating in the trail.
Figure 6-2: Trails pane
The following trail statistics are shown in the status bar:

 Total trails: n/n (for example, 9/9) - number of trails filtered in/total number of trails that can be
displayed.
 Selected: n - total number of selected services (with marked checkboxes).
You can perform specific functions via the toolbar on the right.
To reload the Trails pane
 In the Trail List window, click Reload whole trail list . One-hundred filter-defined trails are
displayed.
To upload additional trails (up to a configurable limit):
 Click Load more trails (upper) or Load all trails (lower).

NOTE: For information how to configure the Load more trail limits, contact your local
Customer Support representative.
When you select a trail in the Trails pane and click Show highlighted trail , the trail and its endpoints
are highlighted in the map and information about the trail is shown in the window panes. Click Show
highlighted trail again to clear this information. The icon is selected by default when the window
opens.
NOTE: You can choose which columns to show in the Trails pane; see Getting Started Guide.
In the Ethernet Service List window click Reload to reload information for that window and the
Services pane.
Parent Topic
6.2.3.1 Trails Pane Toolbar

Table 6-2: Trails pane toolbar

Load More Loads an additional increment of filter-defined trails up to a
configurable limit. your local Customer Support representative
for information how to configure the Load more trail limits.
Load All Loads all filter-defined trails in the network.
Show highlighted trail When selected (default when the window opens) and a trail is
highlighted in the Trails pane, the trail and its endpoints are
highlighted in the map. Information about the trail is shown in
the window panes. Deselecting the icon disables highlighting a
selected trail's path in the map.
When the option is not selected, the Show Highlighted Trail on
Map toolbar option can be used to identify a selected trail in the
Trail List map view; see Trail List Toolbar.
Quick Filter Enables you to quickly filter the trails in the Trails pane by Label,
Trail ID, and/or Customer; see Creating a Quick Trail Filter.
Parent Topic
6.2.3 Trails Pane

6.2.3.2 Trails Pane Shortcut Menu

Some functions are available from a shortcut menu displayed by right-clicking a row in the list. For
descriptions of the associated icons, see Trail List Toolbar.
Table 6-3: Trails pane shortcut menu options
Option Suboption/Description
Edit Highlighted Opens the trail highlighted in Trails pane for editing.
Plan Highlighted Opens Plan Trail window, which enables you to design networks ahead of time
based on edited versions of existing trails; see Planned Trails.
Delete Deletes trails whose checkboxes are selected in the Trails pane. (If no selected
checkbox, deletes the highlighted trail. If trails are selected, deletes only the
selected ones.)
Reconnect Reconnects incomplete trails selected in Trails pane. Typically required when a
problem arises when creating a trail, for example, if an NE included in a trail is
disconnected. For more information, see Reconnecting Trails.
Current Alarms Displays current alarms on trails selected in Trails pane; see Viewing Alarms for
Selected Trails.
Current CP Alarms Opens the Current Alarms window showing Control Plane alarms on ASON trails.
Show Show Highlighted Complete trail represented by the highlighted trail
in Trails pane highlighted on map. Extent of trail
depends on the Path parameter selection.
Show Current Connections (Available to users with
Administrator/Configurator/Provisioning
capabilities only) Shows all current
connections/paths of an ASON trail in the
network. If the trail was rerouted, highlights the
new parts of the route. Otherwise, shows the
provisioned path; see Monitoring the ASON
Domain (page 6-28).
Show Clients Opens a separate Trail List window filtering the
client trails of server trails selected in Trails pane;
see Viewing Associated Traffic Entities.
Show Servers Highlights in the map the server trails of client
trails selected in Trails pane; see Viewing
Associated Traffic Entities.
Trail Operations Trail Consistency Opens Trail Consistency Indicator window to

synchronize trails selected in Trails pane. (Trail
synchronization reconciles differences between
trail definitions in the LightSoft database and the
EMS.)
Operation Results Displays detailed results of the last operation,
enabled only if not completely successful. For
more information, see Performing Trail
Operations.

Increase Highlighted Increases the bandwidth of a selected EoS trail
without having to recreate the trail. See
Increasing Trail Bandwidth.
Decrease Highlighted Decreases the bandwidth of a selected EoS trail

without having to recreate the trail. See
Decreasing Trail Bandwidth.
S-VLAN Registration Adds S-VLAN registration to an EoS trail, enabling
all services of the PB network to utilize the virtual
link represented by the trail. For more details, see
S-VLAN Registration from a Link or Trail.
Activate Bandwidth Activates the bandwidth of a selected EoS trail if it

was not activated when the new EoS trail was
created; see Activating Trail Bandwidth.
Split Trail Splits a "long" SDH server trail (a server trail that
spans more than a single segment) into two
server trails; see Splitting a Long Trail (page 6-49).
Trail Utilities Path Protection Switch Enables you to view and redirect traffic flow
across the main and protection paths, see Path
Protection Switching.
Maintenance Operations Diagnoses connections and ports problems; see
Maintenance Operations.
Performance Monitoring Current PM: Enables you to view current trail

performance for 15-minute or 24-hour intervals.
Set Trail PMH Enabled: Enable PMH data
collection for selected trail.
Set Trail PMH Disabled: Disable PMH data
collection for selected trail.
See Monitoring Trail Performance in the
Performance Monitoring Guide.
Optical Parameters Opens window listing optical parameters for OMS
or OCH trails; see Viewing and Editing Optical Trail
Attributes in the LightSoft User Guide.
Availability Enabled for Optical trails. Opens the Optical
Channel Availability window for the selected
OMS trail; see Viewing Optical Channel
Availability.
Export to XML Exports trails selected in Trails pane to an XML file
for network planning or backup purposes; see
Exporting Trails.

Export to CSV Exports list data to a delimited format file like CSV
for import to Microsoft Excel or a relational
database application. See Exporting to CSV.
Print Prints contents of Trails pane or selected trails
only.
Parent Topic
6.2.3 Trails Pane
6.2.3.3 Trails Pane Columns

You can choose which columns to show in the pane. Standard column sorting and ordering operations can
also be performed in the pane; see Getting Started Guide.
OPTIONAL FEATURE: The Trails pane Alarm State column is a fully integrated add-on
capability, available on a cost basis. If not purchased, this feature is deactivated.
Table 6-4: Trails pane columns
Column Description
Selects trails for various trail operations (as described in context).
The currently highlighted trail (whether or not the checkbox is selected) is the focus
of information shown in Trail List window panes.
Label Trail label, user-defined or assigned automatically by trail creation process; see
parameter description in Basic Trail Parameters Pane.
Customer User-defined trail customer.
Trail ID System ID for the trail, for example, "36(38)", formatted as
Unique ID Number (Managed System ID), where:
 Unique ID Number – ID of the trail sequentially assigned when creating the trail.
 Managed System ID – ID of the management system where the trail was created
(EMS or LightSoft).
Directionality Direction of trail: unidirectional or bidirectional.
Rate Transmission rate of the trail, for example, VC-4.
Payload Payload type for the trail - a value derived from the EMS according to the card's port.
For more information, see Supported Rates and Payload Types.
Comments Free text field for trail description.

Failure Analysis Reason the trail would potentially be affected if the object(s) included in the analysis
were to fail (see also Performing Trail Failure Analysis).

Column Description
Trail State State of the trail:
 OK: Trail is provisioned in the network and is consistent with LightSoft.
 Inconsistent: LightSoft network values are different from the values in the
EMS/network. Trail consistency operations or modification in the EMS may be
required.
To resolve this problem:
1. Force upload the relevant NEs.
2. Admit the trail from the network using Synchronization.
 Failed: LightSoft was unable to set up the trail in the network as defined due to
network limitations.
To resolve this problem: Check that the parameters are correct. Try to connect
the same XCs in the failed NE via the EMS.
 Incomplete: LightSoft was unable to set up the trail in the network as defined.
This problem typically arises during trail creation if an NE included in a trail is
disconnected or a craft terminal is connected, causing the resulting trail to be
incomplete.
To resolve this problem: After the NE is uploaded or the craft is disconnected,
reconnect the trail to send the missing cross connects to the network.
User Usage State  Idle – trail can be deleted from Trail List
 Active – trail cannot be deleted from Trail List
Private ID Private ID assigned to trail. A user-configurable free text identification string that
may be downloaded to some EMSs.
Service Indicator Non Service, Service, Bronze, Silver, or Gold.
Trail Purpose Whether the trail acts as a server or service trail:
 Server: Trail acts as server trail for other trails.
 Service: Trail acts as a client (service) trail carrying user traffic, for example,
PDH, or GbE.
Trail Expected
Signal
ETH Service Type Layer 1 or 2. An EoS trail is automatically considered a Layer 2 trail if one or both of
its endpoints are Layer 2 ports. If both endpoints are Layer 1 ports, the trail is
automatically considered a Layer 1 trail.
VCAT Size Virtual Concatenated paths, indicating the number of resources that can be used on
a single EoS trail segment. (For data trails only.)
Scheme Type of protection scheme configured for this trail. Principally for X or Y OCH trails:
 None if at least one PG is present in the trail.
 User Defined Protection if no PG is present in the trail. Therefore, regardless of
whether the Auto select sink-source partner and PG peer checkbox was
selected in the trail preferences, all required endpoints were manually selected,
without assistance from LightSoft.
Number of Routes Number of diverse routes over which EoS trail is configured to carry traffic through
different nonshared fibers. Shows "1" if there are no diverse routes defined and all
resources are allocated to the same route or link.

Column Description
View on ETH Layer Indicates whether this trail is visible as a virtual link on the ETH/MPLS layer. Default
values as follows:
 Enabled by default for EoS/MoT trails
 Disabled by default for LP trails
 Not relevant for SDH, OMS, OCH, and ODU trails
Main Channel DWDM frequency or CWDM wavelength used by an optical trail in the Main path;
see Optical Trail Parameters. Represents both frequencies of the forward and
backward directions of the main path.
Protection Channel DWDM frequency or CWDM wavelength used by a bidirectional optical trail in the
Protection path (if different from that used in the Main path); see Optical Trail
Parameters. Represents both frequencies of the forward and backward directions of
the protection path.
OSNR Weight Main Estimated OSNR value for main path of the trail, calculated internally by LightSoft,
based on the physical signal parameters.
OSNR Weight Estimated OSNR value for protection path of the trail, calculated internally by
Protection LightSoft, based on the physical signal parameters.
Trail Type  P2P - standard point-to-point trail with full connectivity between endpoints
 X - X-pattern trail involving four endpoints
 Y - Y-pattern trail involving three endpoints
 DR - diverse routes
 Flex - multiple cross connects that do not constitute a valid trail due to the lack
of full connectivity between the endpoints
Flex Reason Shows the reason for the trail having been classified as flex. Flex trails do not
conform to normal trail patterns. For more information, see Flex Trails.
Comm. Channel General communication channel state for OCH and ODU trails. Values include:
 GCC
 GCC0
 GCC1
 GCC2
 Disabled
 Mixed
 N/A
Only values relevant for the selected trail are displayed.

Column Description
FEC Configuration Type of Forward Error Correction (FEC) mechanisms used in standard OCH trails. This
attribute is not relevant for OCH trails based on XDM/NPT equipment only. Values
may include:
 Disabled
 FEC
 EFEC4
 EFEC7
 SD-FEC
 Mixed
 N/A
ODU Component Rate of ODU trail that is included as part of a stand-alone ODU trail, or as part of a
unified LP-ODU or OCH-ODU trail. When relevant, value is set to the appropriate
ODUk. Value set to None if not relevant.
Trail Trace Indicates current state of Trail Trace Monitor for NEs in an OCH trails. This attribute is
Monitoring not relevant for trails based on XDM/NPT equipment only. Value is determined by
analyzing the Trail Trace Monitor states of all participating OCH trail endpoints,
either On (enabled), Off (disabled), or Mixed.
Creation Time Time/Date when the trail was created.
Created Using Method used to create the trail (see description of Modified Using column).
Modification Time Time/Date when trail was last modified.
Modified Using Method used for modifying trail:

 NMS – via a different NMS
 GUI – via the LightSoft GUI
 XML – via an XML file
 Acquisition – using LightSoft to acquire cross connects created in an EMS
 Automatic Trail – VC-4s created automatically when creating the link
Created By User User who created trail.
Modified By User User who last modified trail.

Column Description
Protection Protection layer for the trail:
 Underlying: Trail is protected due to the layer it traverses. For example, traffic in
MS-SPRing configurations is protected. If a trail (for example, VC-4 rate) uses this
ring, the trail is protected on the underlying (MS-SPRing) layer. Alternatively, if a
link of type SDH is protected in the OTN layer due to transponder protection, all
the trails using that link are underlying protected (but protection may be
partial).
 Current and Underlying: Trail is protected both on current layer and underlying
layer.
Protection Quality Type of protection, if any, configured for the trail:
 Unprotected: There is no redundant path for transmissions if the main path
fails. All resources may be shared.
 Shared Resources: Some resources are shared between the main and protection
paths. Details of the common resources are available in the Trail Properties Pane
Statistics tab.
 Full: No trail resources are shared (full diversity) between the main and
protection paths. However, endpoints may be shared.
Shared MEs Number of MEs common to both main and protection paths.
For multi route trails: This and all other "Shared" object parameters show values
only if they are shared by all the routes. This assessment is made per direction, so for
example, a link is considered a Shared link if it is shared by all the routes in the
forward direction but not by all the routes in the backwards direction.
Shared Links Number of links common to both main and protection paths.
Shared SRLGs Number of SRLGs common to both main and protection paths.
Shared SRLG Names of SRLGs common to both main and protection paths.
Names Shown as a comma-separated string.
Shared Cards Number of cards common to both main and protection paths.
DNI Nodes Number of DNI nodes (applicable only to trails in which DNI
applies).
DRI Bridges Number of DRI bridges (applicable only for trails in which
DRI applies).

Column Description
ASON parameters
Note that some of these parameters only apply to ASON SDH trails.
 ASON Path State: Whether the ASON working path is the path originally
provisioned through LightSoft (Provisioned), or an alternative protection path
(rerouted or restored path), automatically found by the control plane
(Rerouted).
 ASON Protection: Protection scheme employed.
 ASON Configuration: Denotes that an ASON protection scheme applies. See also
ASON Protection and Priority Schemes for SDH Trails (page 5-52).
 ASON Restoration: Trail restoration behavior:
 Strict Localization: Use only the data links in the restoration region(s) to
restore the trail.
 Relaxed Localization: If data links are not available in the restoration region,
use any other data links to restore the trail.
 Not-localized (default): Use any data links to restore the trail.
 ASON Head End Priority:

 High: After a fiber cut, find an alternative path for the trail immediately.
 Low with delay: After a fiber cut, wait x seconds before finding an
alternative path, to enable all high priority paths to be restored. See also
ASON Protection and Priority Schemes (page 5-52).
 ASON Association: Status of an ASON trail association. Values include:

 Unassociated: ASON trail is not associated.
 Associated: 1++ trail has a single headend, or the ASON trail is associated
successfully.
 Incomplete Association: Action was performed on the trail (e.g., edit, or
delete) but the trail associations are not updated.
 N/A: Not applicable.
 ASON WTR: Wait to restore time (mins) for the selected trail. (Value = 1-1440)
 ASON Extra Traffic VCs: The number of VCs that ASON can use preemptively
during restoration.
Current Layer SNCP SNCP switching points at the same layer as the trail.
Underlying Layer SNCP switching points at the trail's underlying layer.

SNCP
MS-SPRing Links Number of MS-SPRing-protected links.
MSP-Linear Links Number of MSP-protected links.
Extra Traffic Number of pre-emptable links.
Resources

Column Description
Trail Statistics  Length of Shortest Route
 Route ID of Shortest Route
 Length of Longest Route
 Route ID of Longest Route
 Min. Number of Hops
 ID of Route with Min Hops
 Max. Number of Hops
 ID of Route with Max Hops
 Cost of Min. Cost Route
 ID of Route with Min. Cost
 Cost of Max. Cost Route
 ID of Route with Max Cost
 Worst Link Quality
Alarm State Worst alarm state of trail's objects; see Object Status Color Indications.
Trail Failure Traffic failure analysis data, when available.
Analysis
Expected Signal Label of the expected signal.
Label
Parent Topic
6.2.3 Trails Pane
6.2.3.3.1 Further about ASON Path State

If a failure occurs on the originally provisioned path and a rerouting to protection takes place, the trail state
changes from Provisioned to Rerouted. It remains Rerouted until the trail is either:
 Reverted back to its originally provisioned path (manually through ASON maintenance operations (see
ASON Maintenance Operations) or automatic reversion when the failure is repaired).
OR
 Redefined so that the current restored path is set as the provisioned path. This is done by admitting
the trail using TCI acquisition, then editing the trail to remove the old provisioned path. For more
information, see Performing Trail Synchronization.
The redefinition is reflected in the LightSoft database and ASON is informed of the change in the
trail’s LightSoft-provisioned path.

In this case, the trail will not automatically revert back to the old provisioned path after the failure is
repaired. (It remains part of the ASON domain and can be used as a protection path if available.)
Redefining the provisioned path may reflect a decision not to immediately repair the originally
provisioned path and to release its resources for other purposes.
NOTE: For ASON Optical trails, see ASON Optical Trail Protection and In the Event of a Failure
for optical trails.
NOTE: Currently, if the trail is rerouted, the Trail State is inconsistent because of different
paths reflected in LightSoft vs. the network.
TIP: The Show Current Connections right-click option shows all current connections/paths of
the ASON trail in the network. If the trail was rerouted, highlights the rerouted main and
protection paths in Dark Pink and Dark Blue, respectively; see Monitoring the ASON Domain.
Parent Topic
6.2.3.3 Trails Pane Columns

The Trail Properties pane in the Trail Parameters tab lists the main trail attributes defined in the Create
Trail process.
User Selection View

The User Selection view provides quick access to the most important attributes and enables you to set trail
preferences.
Figure 6-3: Trail Properties pane
Click Configure Attributes List (top right) to display the User Preferences window, where you can
configure the attributes included in this list and set other trail preferences. For more information, see Trail

Standard View
The Standard view (default) displays all attributes and enables you to edit certain parameters. Click Edit
Attributes (top right, enabled when a trail is selected) to set non-trail path affecting fields in each tab
to Edit mode. The icon changes to Save Attributes , enabling you to save changes.
Figure 6-4: Trail Properties pane Standard view
NOTE: You can edit trails using the Edit Trail window; see Editing Trails. You can also edit
additional trail parameters and characteristics generally present in Create Trail window panes.
Some parameters present in both the Basic Trail Parameters tab and the Edit window may be
editable only from one or the other location.
The Trail Properties pane Standard view lists trail attributes in the following tabs:
 Basic Tab
 Advanced Tab
 Protection Tab
 Statistics Tab
The same pane and tabs are available in the Edit Trail window; see Editing Trails. (That window enables you
to edit additional path-affecting trail parameters and characteristics that are present in Create Trail
window panes.) Some Trail Properties pane parameters present in both the Trail List and the Edit windows
may be editable only from one or the other location.
Parent Topic

6.2.4.1 Basic Tab

When the tab is in Edit mode, editable parameters appear white.
Figure 6-5: Trail Properties pane Standard view - Basic tab
For descriptions of the Trail Properties fields, see Trails Pane.
Parent Topic

6.2.4.2 Advanced Tab

When the tab is in Edit mode, editable parameters appear white.
Figure 6-6: Trail Properties pane Standard view - Advanced tab
Table 6-5: Trail Properties pane fields – Advanced tab
Field Description
Comments See descriptions in Trails Pane Columns.
User Usage State
Private ID
Service Indicator
Trail Purpose
ETH Service Type
Trail Type
View on ETH Layer Yes or No. Indicates whether this EoS/MoT trail is visible as a virtual link in
the ETH/MPLS layer. For more information, see the parameter description
in EoS/MoT Configuration Pane.
Flex Reason Shows the reason for the trail having been classified as flex. Flex trails do
not conform to normal trail patterns. For more information, see Flex Trails.
Creation Time See descriptions in Trails Pane Columns.
Created Using
Modification Time
Modified Using
Created By User
Modified By User
Ring Names Names of associated rings; see Ring Name parameter in Link Properties -
General Tab.
Parent Topic

6.2.4.3 Protection Tab

No parameters are editable in the Protection tab.
Figure 6-7: Trail Properties pane Standard view - Protection tab
Table 6-6: Trail Properties pane fields – Protection tab
Field Description
Scheme Principally for X or Y OCH trails:
 None if at least one PG is present in the trail.
 User Defined Protection if no PG is present in the trail. Hence,
regardless of whether the Auto select sink-source partner and PG peer
checkbox was selected in the trail preferences, all required endpoints
were manually selected, without assistance from LightSoft. For more
information, see OCH Endpoint Selection.
Number of Routes Number of diverse routes over which EoS trail is configured to carry traffic
through different nonshared fibers. Shows "1" if there are no diverse routes
defined and all resources are allocated to the same route or link.
Protection See description in Trails Pane.
Protection Quality See description in Trails Pane.
Shared MEs Number of MEs common to both main and protection paths.
For multi route trails: This and all other "Shared" object parameters show
values only if they are shared by all the routes. This assessment is made per
direction, so for example, a link is considered a Shared link if it is shared by
all the routes in the forward direction but not by all the routes in the
backwards direction.
Shared Links Number of links common to both main and protection paths.
Shared SRLGs Number of SRLGs common to both main and protection paths.

Field Description
Shared SRLG Names Names of SRLGs common to both main and protection paths. Shown as a
comma-separated string.
Shared Cards Number of cards common to both main and protection paths.
DNI Nodes Number of DNI nodes (applicable only to trails in which DNI applies).
DRI Bridges Number of DRI bridges (applicable only for trails in which DRI applies).
Current Layer SNCP SNCP switching points at the same layer as the trail.
MS-SPRing Links Number of MS-SPRing-protected links.
MSP Linear Links Number of MSP-protected links.
Extra Traffic Resources Number of pre-emptable links.
Path State Denotes that an ASON path state - Provisioned or Rerouted; see Trails Pane
Columns.
ASON Protection Denotes that an ASON protection scheme applies. See alsoASON Protection
and Priority Schemes for SDH Trails (page 5-52).
Headend Priority High or Low Priority Delay. See parameter description in Basic Trail
Parameters Pane (page 5-21). See also Low Priority Delay.
Parent Topic
6.2.4.4 Statistics Tab

This example shows the tab in Edit mode. No parameters are editable in this tab.
Figure 6-8: Trail Properties pane Standard view - Statistics tab

Multiroute trail statistics:

 Statistics for multiroute trails refer to routes in the whole trail not just those in one of the paths.
 Route ID is display examples:
- “Main Path - Primary Route” or
- “Protection Path - Secondary Route n”.
Table 6-7: Trail Properties pane fields – Statistics tab
Field Description
Length of Shortest Route Length of shortest EoS trail between diverse routes - sum of the
lengths of all links through which it passes, in the unit of measure
recognized by the system (for example, km or miles).
Route ID of Shortest Route Route ID of the shortest EoS trail.
Length of Longest Route Length of the longest EoS trail between diverse routes.
Route ID of Longest Route Route ID of the longest trail.
Min Number of Hops Fewest number of hops of an EoS trail between diverse routes.
ID of Route with Min. Hops Route ID of the trail with the fewest hops.
Max Number of Hops Highest number of hops of an EoS trail between diverse routes.
ID of Route with Max Hops Route ID of the trail with the most hops.
Cost of Min Cost Route Lowest cost of an EoS trail between diverse routes - the sum of the
lengths of all links through which it passes. Link cost assessments are
set in the link properties when it is created.
ID of Route with Min Cost Route ID of the lowest cost trail.
Cost of Max Cost Route Highest cost of an EoS trail between diverse routes - the sum of the
lengths of all links through which it passes. Link cost assessments are
set in the link properties when it is created.
ID of Route with Max Cost Route ID of the highest cost trail.
Worst Link Quality Lowest quality of link a trail may traverse. Link quality is set in the link
properties when it is created.
Parent Topic

6.2.5 Endpoints & Path Tab

The Endpoints & Path tab shows path aspects of the trail:
 Endpoints List Pane : Lists endpoints of a selected trail.

categories.
Parent Topic

The Endpoints List pane lists the endpoints of a selected trail. The Endpoints List pane fields are the same
as described in Endpoints List Pane.
Parent Topic
6.2.7 Resource Tree Pane

The Resource Tree pane displays selected resources for a trail in a tree hierarchy under Main and
Protection categories (where applicable).
In the case of concatenated trails with diverse routing, each route has a branch. Each line contains
indications of the applicable protection type.
Figure 6-9: Resource Tree pane
In general, resources are categorized according to Main and Protection.

For EoS/MoT diverse routed trails, resources are categorized according to route number (e.g., Route1,
Route2). This applies when the Diverse Routes checkbox is selected; see Diverse Routes description in
EoS/MoT Configuration Pane , and at least one route number besides Route #1 is specified for a trail
resource; see Select Segment Pane.
Figure 6-10: Resource Tree pane showing diverse routes
Segments with the following special statuses are identified by icons:
 DRI bridge-associated segments. The bridge number is shown under the bridge icon. A tooltip also
shows the source endpoint from which the path-search algorithm is instructed to reach the source of
the bridge link.
 Resources with Extra Traffic (ET) status.
 Segment in process of bandwidth decrease.
For Optical ASON trails, the Provisioned and Restoration routes are indicated in the Resource Tree:
Parent Topic
6.2.8 Resource List Pane

The Resource List displays details of selected trail resources individually or by category (All, Main, or
Protection). For detailed information about the pane contents and associated procedures, see Resource List
Pane in Create Trail window section.
Figure 6-11: Resource List pane
Parent Topic

6.3 Viewing Trail Information

Selecting a trail in the Trails pane makes it the focus of the detailed information provided in other panes. In
addition, associated trails can be highlighted in the map view, or associated alarms can be displayed.
Parent Topic
6.3.1 Viewing Information Detail

The Trail List window opens with several information panes, one of which is the Trails pane; see Trails
Pane.
When you click to select a trail in the Trails pane list, the trail becomes the focus of the information
provided by other panes.
When one or more trails are selected in the Trails pane, associated objects and links are highlighted in the
Trail List window map.
To view information about a trail:

1. In the Trail List window, select a trail filter that filters the trails you want listed in the Trails pane. For
information about trail filters, see Filtering the Trails Pane.
2. Click to select a trail in the Trails pane. By default, Show highlighted trail on the toolbar on the
right is selected and:
 The other information panes immediately show detailed information about the selected trail.
 The trail's associated elements and links are highlighted in the Trail List window map.
NOTE: When you select trails in the Trails pane and the Show one trail only option is selected
in the Preferences dialog box, the Trail List window map shows only the associated elements
and links, hiding all the others. For more information, see Trail Management Appearance
You can select trails in the Trails pane in two ways:

 Click and highlight the trail (as described in the previous procedure). Only one trail at a time can be
selected.
 Select (or deselect) the checkboxes of any number of trails. This method is used for operations such as
delete, export, reconnect, show current alarms, TCI, print, and some others. See Performing Trail
Operations for more details.
In this section, "selecting a trail" means selecting its checkbox.
Parent Topic

6.3.2 Viewing Associated Client or Server Trails

You can view which client and/or server trails are associated with the specific trail you are working on.
Show clients for selected trails : open a Trail List window filtering the client trails of server trails
selected in the Trails pane, according to one of the following topology layers:
 Low order SDH/EoS trails traversing selected high order trails.
 High order trails traversing selected LP trails.
 LP trails traversing selected OCH trails.
 OCH trails traversing selected OMS trails.
Show servers for selected trails : highlight the server trails of client trails selected in the Trails pane in
the map, according to one of the following topology layers:
 High order SDH trails through which selected Low order SDH/EoS trails are traversing.
 LP trails through which selected high order trails are traversing.
 OCH trails through which selected LP trails are traversing.
 OMS trails through which selected OCH trails are traversing.
You can also view other traffic entities associated with selected trails:
 MoT trails associated with a tunnel; see Viewing Tunnel Information - Show Associated Trails, Services,
or Protected Tunnels.
 Trails associated with selected services; see Viewing Service Information - Viewing Associated Traffic
Entities.
To view associated client or server trails:

1. In the Trail List window Trails pane, select the checkboxes of the trails for which you want to view
associated trails.
2. In the window toolbar:
 Click Show clients for selected trails or Show servers for selected trail .
OR
 Right-click the trail and select Show Clients or Show Servers.
A new Trail List window opens. The Trails pane lists the server or client trails associated with the
selected trails.
Parent Topic

6.3.3 Viewing Alarms for Selected Trails

You can view all the alarms that affect selected trails. These alarms are displayed in the Current Alarms
window; see Viewing Alarms for Selected Traffic Entities.
You can also view the trails affected by a selected alarm; see Viewing Traffic Entities Affected by an Alarm.
Parent Topic
6.3.4 Monitoring the ASON Domain

ASON domain trails and elements trails can be monitored in a variety of ways.
ASON links can be identified in map windows by an icon on the link line. .
LightSoft provides the following ways for monitoring ASON:
 Show Trails: Opens the Trail List window to display the trail path in the network (right-click a link in
any map view and click Show Trails). For more details, see Viewing Trail Information.
 Show Highlighted: Displays the provisioned trail path for a trail selected in the Trail List window. (In
the Trail List window, right-click any link in the map view and select Show Highlighted.) The links are
colored as follows:
 Pink - provisioned main path
 Blue - provisioned protection path
 Purple - both the provisioned main and protection paths traverse the same route
Figure 6-12: Provisioned trail paths

 Show Current Connections: Displays the current paths, routes, and connections of an ASON trail in the
Trail List window. The links are colored as follows:
 Pink - rerouted main path.
 Blue - rerouted protection path.
 Purple - both rerouted main and protected paths traverse the same segment of the path (occurs
when ASON is not able to find a different route for the protection path).
Figure 6-13: Restoration trail paths
 Show ASON Domain (accessed by right-click any ASON object in the view): Marks all ASON-based
entities (elements and links) in the current map view.
Figure 6-14: Show ASON Domain from Trail List window
NOTE: When two ASON “domains” are connected by non-ASON equipment, while the entire
topology is visible in the view, only the ASON objects are marked. Currently multiple ASON
“domains” are viewed as part of a single domain. In future versions, they will be differentiated
by serial numbers.
 Expand ASON Domain in New View: Same as Show ASON Domain, but opens the objects in a new
window.
 ASON Maintenance Operations: Reverts the trail path to either the provisioned or protection path, or
reroutes the current main or protection path to an alternate route found by ASON, and
allowing/inhibiting these actions on specified ASON trails; see Maintaining the ASON Domain.

 Availability Map and Availability for Link: Show the link utilization status and extent of spare
resources in the ASON domain; see Viewing Resource Availability on Links in the LightSoft User Guide.
It is important that ASON networks consistently maintain spare capacity over and above ordinarily
required resources, sufficient to overcome multiple failures with heavy bandwidth. We recommend
setting a threshold spare capacity consistent with operator priorities and policy on a case-by-case
basis. The link utilization tools enable monitoring the current spare capacity and ensuring that the
policy threshold level is maintained.
Parent Topic
6.4 Viewing Availability Map Information

You can view resource availability information directly from the Create/Edit Trail window. Relevant
information is displayed for the selected topology, and topology layer (see also Viewing Resource
To view resource availability:

1. In the relevant topology layer Create/Edit Trail window, in the Rate dropdown, select the relevant
rate, and if required, in the Capacity dropdown box, select the capacity.
2. Click . The Availability Map view is displayed.
3. Click again to return to the Create/Edit Trails view.
Parent Topic

6.5 Performing Trail Operations

This section describes how to perform trail-related operations and view operational results.
To perform a trail operation:

1. Select the trails by selecting their checkboxes in the Trails pane.
2. Select a Trail List window toolbar option or right-click a trail in the Trails pane and select a shortcut
menu option.
3. Continue the operation as described in the corresponding procedure in this section. At the conclusion
of the operation:
A message window opens showing the operation results. If any part of the operation was not
successful, information is shown about the failed operations. If multiple trails were involved, the
window includes results for each trail.
The Operational Results Info icon in the Trail List window toolbar is enabled when an operation
is not completely successful. You can revisit the last results message window by clicking this icon.
The icon remains enabled until another operation is performed. If the second operation is completed
successfully, the icon is disabled. If it is partially successful, it displays the detailed results for that
operation.
Parent Topic

6.6 Filtering the Trails Pane

You can filter the Trails pane (determine the trail records that are displayed) according to any combination
of trail attributes and objects activated from either predefined or created filters. You can also filter client or
server trails associated with specified trails.
Figure 6-15: Trails pane
The "Total trails" statistic (number/number) in the status bar is the number of trails filtered into the view
vs. the total number of trails that can be displayed.
(The status bar also shows the total of trails having checkboxes selected.)
LightSoft supports the following predefined trail filters:
 All: All trails are displayed (no filter is applied). This filter is enabled only for an Admin user.
 No Trails: No trails are filtered in. (When this is the default filter, the Trail List window initially opens
quickly without any trails. Another filter should then be applied; see Applying a Filter and Setting It as
Default.)
 High Order: High order SDH trails are filtered in.
 Low Order: Low order SDH trails are filtered in.
 EoS/MoT Trails: Ethernet EoS/MoT trails are filtered in.
 Optical Trails: Optical OMS, OCH, and LP trails are filtered in; see Optical Trails.
 Data over WDM: Optical EoS trails are filtered in; see Optical Trails.
 LDL Trails: Displays ASON trails composed of logical data links.
 ODU Component: Display the underlying ODU components included within unified LP-ODU or
OCH-ODU trails; see Optical Trails.
Filter options in the main window and Trail List

Filter options can be activated from either the LightSoft main window or the Trail List window.
In the LightSoft main window

You can use the Trails tab (General group) Trail Filters option to:
 Create or edit a new filter according to any combination of trail attributes or objects; see Creating and
Editing Advanced Filters.
 Edit, rename, or delete a filter that you created, or set the filter as the default (which automatically
activates it when the Trail List window opens); see Renaming, Deleting, and Setting Default Filter
Actions.

The Trails pane can automatically be opened with trails corresponding to preselected objects in the
LightSoft main window; see Creating SDH and EoS/MoT Trails.
In the Trail List window

You can:
 Click Quick Filter to quickly filter by label, customer, and/or trail ID; see Creating a Quick Trail
Filter.
 Activate a specific filter through the Filter selector dropdown list . You can also
click Set Filter as Default to set the currently selected filter as the default (automatically activated
when the Trail List window opens); see Applying a Filter and Setting It as Default. (The icon is disabled
if the currently applied filter is already the default.)
 Click Edit Filter to:

 Create a new filter with preselected objects; see Creating a Filter with Preselected Objects.
 Edit a user-defined filter; see Another Way to Edit a Filter.
Parent Topic
6.6.1 Creating a Quick Trail Filter

The Quick Filter function enables you to filter the trails either currently in the Trails pane, or throughout
the database, by Trail ID, Label, and/or Customer. This method does not involve a filter template and is
defined per use. It uses a Quick Filter field bar in the Trails pane.
Figure 6-16: Quick Filter field bar on Trails pane
To filter trails by trail ID, label, and/or customer:

1. Open the Trail List window, as described in Accessing the Trail List Window.
2. In the Trails pane, click Quick Filter . A quick filter field bar opens at the top of the pane.
3. Enter a text string to the relevant fields to filter in trails with field values that include this text. See the
field descriptions in Trails Pane Columns.
You can enter partial strings to identify all trails with this text anywhere in the fields. For example,
enter xy to find all trails with xy anywhere in the field value. (Wildcard character is not used.)

NOTE: The text field filter is case sensitive.
TIP: The Customer filter can contain several customer names separated by commas. Thus a
filter for customers "a,b,c,d" will yield trails associated with customers "a", OR "b", OR "c", OR
"d".
 The table immediately adjusts to show trails previously in the table that satisfy the filter criteria.
OR
 To filter the entire database (instead of the current table contents), enter a string to each
relevant field and then click Force Filter .
TIP: You can filter incrementally:

First perform a Force Filter search of the entire database.
Then apply multiple incremental filters to the current table contents, adjusting the filter
criteria on-the-fly to change the composition of trails displayed.
 Click Info to display an Info Tip describing the use of this filter type.
 Click Clear Filter to clear the current quick filter selections. (You can also backspace to
empty a filter field.)
4. Click Close Filter to close the quick filter field bar.

After the field bar is closed:
 If Force Filter (database search) had been used, the list reverts to its contents before the filter
was applied.
 Otherwise, if a table search was performed, the latest filtered contents are retained in the list.
TIP: In the case of a table search (no force filter), a temporary filter is automatically created
(in the same way as when objects are preselected before opening the Trail List window) which
you can use as a base for other filter actions; see Creating a Filter with Preselected Objects.
Parent Topic

6.6.2 Working with Advanced Trail Filters

Advanced filters enable you to view a subset of the trails in the Trail List window according to any
combination of:
 Trail attributes (like specific rates)
 Selected objects (all trails traversing specific objects)
 Only trails that terminate at or go through objects
New filters can be created from scratch or based on an existing user-defined filter. A new filter can be
created that uses preselected map window objects. You can also edit, rename, or delete the filters that you
create. Saving a filter after a create or edit operation automatically applies the filter settings to the open
Trail List window. Any other filter can be applied as needed at any time.
This section contains the following topics:
 Applying a Filter and Setting it as Default
 Creating and Editing Advanced Filters
 Another Way to Edit a Filter
 Creating a Filter with Preselected Objects
 Rename, Delete, Set Default Filter Actions
Parent Topic
6.6.2.1 Applying a Filter and Setting it as Default

Any filter (predefined or user-defined) can be applied, immediately changing the trails listed in the Trails
pane. In addition, the currently applied filter can be set as the default, defining the trails that the Trail List
window automatically displays in a new session.
TIP: Opening the Trail List window may be time consuming if many trails are filtered in. If you
choose "No Trails" as the default filter, the window quickly opens initially without any trails in
the Trails pane. You can then apply a different filter.
To apply a filter and (optionally) set it as default:

1. Open the Trail List window.
2. Select a filter in the Filter dropdown list .

The filter is immediately applied, reflected in trails listed in the Trails pane.
3. You can optionally set the current filter as the default by clicking the Set filter as default icon
. The Trail List window now automatically opens any new session with this filter.
Parent Topic

6.6.2.2 Creating and Editing Advanced Filters

Advanced filters are used to search the database for trails that satisfy the filter criteria. The following
describes how to create or edit a filter that includes advanced criteria combinations.
NOTE: The procedure includes a resource object-selection step. In this case, objects
preselected in a map window are not relevant. For information about how to create a filter
with object preselections in the LightSoft main window map, see Creating a Filter with
Preselected Objects.
NOTE: ABOUT TEXT FIELD ENTRIES

Text filters are case sensitive.
If filtering by Label and Customer text entry fields, use the wildcard character * to filter in all
trails where the field value includes a specified string, for example:
 xy* to filter in all trails with the field value starting with xy
 *xy* to filter in all trails with xy anywhere in the field value
 *xy to filter in all trails with the field value ending with xy (this pattern is not
recommended).
OR
If filtering by any other text fields, or if any resource objects are selected in the Topology Tree
area (see next step), enter xy to find all trails with xy anywhere in the field value. (Wildcard
character is not supported.)
Click Info to display an Info Tip summarizing these rules.
To create or edit a filter:

1. In the main window Trails tab, in the General group, click Trail Filters.
The Trail Filters dialog box opens. (You can view a summary of parameters for an existing filter by
selecting the filter in the Filters pane.)

2. Click New to create a new filter.

OR
Select a user-created (non-predefined) filter that you want to modify in the Filters pane and click Edit
(enabled when a user-created filter is selected). The Create Filter or Edit Filter dialog box opens.
3. Click Show Tree to open the Topology Tree pane. The button changes to Hide Tree for hiding
the tree if not required. This is used for filtering by selected objects in Step 5.
4. In the Filter Name field, type a name for the new filter (for example, MyFilter).
OR
If you are editing, this field is disabled. You can save the modified filter as a different name, if needed.
5. If you want to filter by parameters:
a. In the Filter By area, select the parameter checkbox.
b. Specify the required value. While a parameter is highlighted, the Value area shows either:
 Text entry field (see the note about the text field entry below)
 Dropdown list of possible values
 From/To date/time entry fields

 Radio buttons
Specify the required value.
c. If multiple dropdown list selections are required for a parameter, open the list again and select
additional values. The multiple selections are displayed in the Value area.
d. Repeat the previous steps for as many parameters as needed. (You can remove a selected value
by selecting it again.)

6. If you want to filter by selected resource objects to which trails are associated, move objects from the
Topology Tree area to the Topology tab, as follows:
a. In the Topology Tree area:
 Select the topology layer for the filter: Physical (Site), SDH, Optical, or ETH/MPLS
(double-click the root of the tree to refresh its elements).
 Select the objects for which you want to filter trails (drill down in the tree). To select
multiple objects, press SHIFT and click.
b. In the Topology pane, click Add to move selected objects from the Topology Tree area to the
Topology tab. Click Remove to remove objects not required for the filter.
NOTE: If you are filtering with text entry fields as well as resource object selections, see the
note in the previous step for the entry rules that apply.
7. If you want to filter by resource role, in the Resource Role dropdown list, select:
 All Trails (default): To include only trails that either end in or traverse the selected objects.
 Terminating: To include only trails that end in the selected objects.
 Through: To include only trails that traverse the selected objects.
 Intersecting: To include only trails that start at end at the selected objects.
8. To save the new filter (or save the edited filter under the same name), click Save.
OR
To save the edited filter under a different name, click Save As. A Save As dialog box opens where you
can enter a new name for the filter. Click OK to complete the operation.
The Create Filter dialog box closes. The new filter is automatically activated and included in the Filter
selector dropdown list.
9. Click Close to close the Trail Filters dialog box.
Parent Topic

6.6.2.3 Another Way to Edit a Filter

You can also select a user-defined filter for editing via the Trail List window.
To edit a filter via the Trail List window:

2. In the Filter dropdown list, apply a user-defined filter .
3. Click Edit Filter . The Edit Filter dialog box opens with the criteria for the selected filter.
4. Continue to edit the filter as described in Creating and Editing Advanced Filters , from Step 3.
Parent Topic
6.6.2.4 Creating a Filter with Preselected Objects

You can create a new trail filter with objects selected in the LightSoft main window map. This avoids having
to select the elements again when creating the filter. Those objects are automatically reflected in the Trail
List window map and in a "Temporary" filter which you can build on.
To create a filter with preselected objects:

1. In the LightSoft main window map, with the desired topology layer selected, select any objects that
you want to include in a new trail filter.
2. Open the Trail List window: In the main window Trails tab, in the General group, click Trail List.
The Trail List window opens with the selected objects and with the Temporary filter preselected in
the Filter selector dropdown list.

3. Click Edit Filter (enabled only if objects were preselected in the main window before the Trail
List window was opened). The Edit Filter dialog box opens with the preselected objects already
selected in the Topology pane.
Parent Topic
6.6.2.5 Rename, Delete, Set Default Filter Actions

This section describes how to rename a filter, delete a filter, or set a filter as default (automatically applied
when the Trail List window opens).
To rename or delete a filter, or set a filter as default:

1. In the main window Trails tab, in the General group, click Trail Filters. The Trail Filters dialog box
opens.

2. Select a filter and select one of the following options:

 Rename to rename a non-predefined filter. A Rename Filter dialog box opens. Enter the new
name and click OK to complete the action.
 Delete to delete a non-predefined filter. A Confirm dialog box appears. Click OK to complete the
action.
 Set Default to set any selected filter as the default. Another method is described in Applying a
Filter and Setting it as Default.
New and Edit are used to create and edit filters; for details, see Creating and Editing Advanced Filters.
3. Click Close to close the Trail Filters dialog box.
Parent Topic
6.7 Reconnecting Trails

You may sometimes need to reconnect a trail. This is typically required if a problem arises during the trail
creation process. For example, if an NE included in a trail is disconnected at the time it is created, the
resulting trail is left in an incomplete state. In this case, reconnecting the trail sends the missing cross
connects to the network. The same remedy applies if cross connects of an existing trail are inadvertently
deleted in the EMS.
If ASON trail cross connects are deleted by mistake in the EMS, additional procedures apply; see
Reconnecting ASON Cross Connects.
The Reconnect dialog box includes two checkboxes for the following exceptional cases:
 Enable Alarm Master Mask (AMM) checkbox (default unselected): Select to ensure that trail object
masking is enabled in the EMS for all trail objects regardless of any specific EMS settings (alarms are
generated on all trail objects). Enabling AMM operates in the same way as when you select Alarm
Master Mask "Apply" option when the trail is created in the Create Trail window Advanced
Parameters pane; see Advanced Trail Parameters Pane. If the AMM settings for specific objects was
changed for troubleshooting or maintenance purposes, Enable AMM avoids having to return to each
object to manually reinstate its AMM setting before the trail is brought back into service.
If the checkbox is not selected (default), the current AMM settings are left unchanged for all objects
in the trail path. Any adjustments to settings that were manually performed in the EMS are retained.
 Activate Bandwidth (EoS/MoT trails only - default unselected): Select to activate the trail bandwidth
(if it is not already activated), in the same way as the Activate Bandwidth feature; see Activating Trail
Bandwidth.
If the checkbox is not selected (default), the trail's bandwidth state is unaffected.
Bandwidth can be deactivated in the trail edit process; see Editing Trails.

To reconnect a trail:
1. In the main window Trails tab, in the General group, click Trail List. The Trail List window opens.
2. Select the checkboxes of the trail/s you want to reconnect.
3. Click Reconnect . The Reconnect dialog box for trails opens.
4. Select the Enable Alarm Master Mask checkbox if you want to enable the feature. For more
information, see Advanced Trail Parameters pane.
5. (EoS/MoT trails only) Select the Activate Bandwidth checkbox if you want to activate the trail
bandwidth (if it is not already activated). For more information, see Activating Trail Bandwidth.
6. Click Yes to continue. A completion message appears, describing the operation result and listing
nonfatal errors. For more information, see Performing Trail Operations.
Parent Topic

6.8 Editing and Deleting SDH, Optical, and

EoS/MoT Trails
This section describes how to edit or delete selected trails. The actions can be implemented in the network
either immediately or postponed to a later time. When the actions are for future use, their details are
exported to an XML file and are put into effect by importing the file into LightSoft.
NOTE: Edit or Delete operations may fail due to one of the following circumstances:
 LightSoft network values are different from the values in the EMS/network. Trail
consistency operations or modification in the EMS may be required.
2. Admit the trail from the network using Synchronization.
LightSoft is unable to set up the trail in the network as defined. This problem typically arises
during trail creation if an NE included in a trail is disconnected or a craft terminal is connected,
causing the resulting trail to be incomplete.
To resolve this problem: After the NE is uploaded or the craft is disconnected, reconnect the
trail to send the missing cross connects to the network.
NOTE: Optical trail deletion is traffic affecting.

The laser is turned on/off by default when an optical trail is created/deleted; see Laser
Configuration in the Getting Started & Administration Guide.
If Functional Topology Map (FTM) is installed, OCH trails should be created or deleted in the
EMS using FTM and uploaded to LightSoft. For more details, see FTM/PELES and OCH
Link/Trail Creation in LightSoft - Workflow.
OCH trail creation or deletion may have Power Control or PELES channel implications; see
Power Control Channels and Trail Creation/Deletion.
Parent Topic

6.8.1 Editing Trails

The Edit Trail window described in this section provides extensive trail editing options, including access to
path-affecting parameters and characteristics present in Create Trail window panes. Trails can be edited for
either immediate or future effect in the network.
Figure 6-17: Edit Trail window
Trail parameters can be edited provided the correct user capabilities are present. Trails can be edited even
if the edit operation is traffic-affecting.
Server trail endpoints cannot be edited.
NOTE:
 Certain non-path-affecting parameters can be edited from either the Edit window or the
Trail List window panes, for example, using the Trail Properties pane Edit Attributes
function, available from both windows; see Trail Properties Pane.
 Some parameters that are present in the Trail Properties pane in both the Trail List and
Edit windows may be enabled for editing only from one or the other location (for
example, certain EoS trail parameters).
You can edit trails for either immediate or future effect in the network. When the editing is for future
application, the edit changes are exported to an XML file and put into effect by importing the file into
LightSoft; see Exporting Trails.

NOTES:
 When a trail is edited, the Activate Bandwidth checkbox is automatically cleared. If
needed, select it to ensure bandwidth remains activated. Bandwidth can also be activated
as described in Activating Trail Bandwidth and Reconnecting Trails.
 The View on ETH/MPLS Layer checkbox cannot be selected using the trail Edit window.
You can select it instead through the Trail List window's Trail Properties Pane Standard
View.
 Moving endpoints and changing the route of an unprotected trail are always traffic
affecting.
 The user security capability required to perform traffic-affecting trail edits is not the same
as that for normal trail editing.
It is sometimes possible to change equipment endpoint configurations (for example, from GbE to FC-1G), or
modify the rate setting of the TRP_C, without editing the trail from LightSoft. In such cases the payload
type, calculated when the trail was created in LightSoft, is not updated automatically. You must perform
Edit Trail with activation to invoke the attribute completion to assign the new payload type. (You do not
have to actually change any trail parameter.)
Editing an MoT trail is disallowed if it:
 Has tunnels traversing it and the editing affects the trail's resources (endpoints).
 Is protected by bypass tunnels and the new trail path uses different path. The tunnels must be
removed first.
Editing a VC-4 server trail that has client trails with tunnels traversing it or bypass tunnels protecting it is
disallowed. The tunnels must be removed first.
Editing VC-4 server trails that have clients may take some time.
To edit a trail:
1. You may want to open the Edit Trail window with only selected NEs of the view and the links running
between them, rather than showing all the objects in the current view. To do this, select the MEs or
LEs in the LightSoft main window view map.
2. Select the required topology layer, as described in Step 1 of the Creating and Exporting a Planned Trail
procedure.
4. In the Trails pane:
 Select a trail and click Edit highlighted trail .

OR
 Right-click a trail and select Edit highlighted. The Edit Trail window opens, showing the trail
path.

TIP: When a Protected trail is selected, the Main/Protection/Both selectors enable you to
identify and select the main or protection trail segments or the combined main and protection
trail.
5. Make the required changes to trail parameters, topology segments, and/or endpoints. The window
contains essentially the same panes and parameters as the Create Trail window. For details, see
Create Trail Window.
NOTES:
 When Protection applies, you can change a Protection trail segment to Main or a Main
trail segment to Protection. Do this by right-clicking the server trail path or topology
segment in the Resource Tree pane and selecting the Move to Main or Move to
Protection menu option.
 You can edit trails from Unidirectional to Bidirectional without first clearing the previous
selections. The endpoints are automatically changed from Add or Drop to Add&Drop.
 OSNR Weight values that are calculated automatically by LightSoft for certain types of
underlying equipment cannot be changed by the user. However, OSNR Weight values for
other types of underlying equipment, such as Packet-OTS platforms, are based on default
LightSoft settings, and these values can be edited by the user.
6. If you are editing a DRI trail, perform the following actions:

a. Remove all bridge segments.
b. Change the protection layer to Current & Underlying.
c. Select all main TUs manually (starting from the main direction).
d. Select all protection TUs manually (starting from the protection direction).
e. Define all main bridge segments as Bridge (with the correct direction) and EP (ensure that the
number of bridges in that window is always 1).
f. Define all protection bridge segments as Bridge (with the correct direction) and EP (ensure that
the number of bridges in that window is always 1).
7. (Optional) Click Complete trail . LightSoft searches for a path using your selections. When a path
is found, the details are displayed for you to review. You can go back and modify the path if required.
At the end of the Complete processing, a message appears listing the result of the operation and any
warnings or nonfatal errors; see Performing Trail Operations. If the Complete step encounters a
problem, see Diagnosing a Create Trail failure in Creating SDH and EoS/MoT Trails.
8. If you want to activate the edit changes on the network immediately, click Activate trail .
The Progress bar shows the progress of bundle trail processing (if applicable). Click Abort to stop the
operation if necessary.
At the end of the Activate processing, a message appears listing the result of the operation and any
warnings or nonfatal errors; see Performing Trail Operations. If the Activate step encounters a
problem, see Diagnosing a Create Trail failure in Creating SDH and EoS/MoT Trails.

NOTE: If Complete Trail was not previously performed or if it was followed by any potentially
path-affecting action (like a change of endpoint), it will automatically be performed/repeated
before the trail is activated on the network.
OR
9. If you want to implement the edited trail in the network only at a later time, perform the following to
export the edit details to an XML file:
 Click Export .
OR
 Right-click a trail and select Trail Utilities > Export. The Export Trails dialog box opens.
Continue the procedure as described in Exporting Trails , from Step 4.
For information about how to eventually implement the edited trail in the network, see Importing Trails.
Parent Topic
6.8 Editing and Deleting SDH, Optical, and EoS/MoT Trails
6.8.2 Deleting Trails

You can delete trails in the Trail List window. You can delete several trails at the same time by selecting
them all simultaneously. All trails are deleted the same way, whether they were created in LightSoft or
created in the EMS and later uploaded to LightSoft using trail synchronization.
When a trail is deleted, all cross connects defined for each NE in the trail are also automatically deleted. If
this does not occur (for example, if one of the NEs was disconnected at the time the trail is deleted), the
trail remains in the Trail List window in an Incomplete or Failed state. The trail is removed from the list
when all resources are deleted.
You can delete trails for either immediate or future effect in the network. When the deletion is for future
application, its details are exported to an XML file and put into effect by importing the file into LightSoft at
a later time; see Exporting Trails.
NOTE: A server trail cannot be deleted if client trails are still traversing it - client trails must be
deleted before their server trails. When deleting client and server trails in the same operation
(whether for immediate or future effect), first sort the Trails pane records so that the client
trails come before the server trails. This ensures that the trails that you select for deletion are
processed in the right order.
NOTE: MoT trails cannot be deleted if:

 Tunnels use virtual links resulting from the MoT trail.
 Bypass tunnel protection applies (next hop or next-next-hop).You must first remove the
tunnels or bypass tunnels.

EoS trails can be deleted even if Ethernet services are defined on the resulting EoS virtual links. In this case,
the related services become incomplete (they are not deleted). It is the user's responsibility to ensure that
any remaining services on the trail are not required.
When the EoS trail carries S-VLAN or C-VLAN registered services, a confirmation is required before the trail
is deleted.
The EoS or MoT trail delete processing may take some time as the network topology and status may be
changed.
To delete a trail:
2. If client and server trails are to be deleted, sort the client trails to come first.
3. In the Trails pane, select the checkboxes of the trail/s you want to delete.
4. If you want the delete action to take effect immediately:
 Click Delete Selected Trails .

OR
 Right-click any selected line in the Trails pane and select Delete. A confirmation window opens.
a. When the EoS trail carries services where S-VLAN Registration or C-VLAN Registration has been
configured at either end, a warning message opens:
"This action may result in Traffic Disconnection or may be Traffic Affecting". Do you want to
continue".
Select Yes to continue. A confirmation window opens.
b. Click OK to confirm. A completion message appears, describing the operation result. For more
information, see Performing Trail Operations.
OR
5. If you want the trail deletion to be implemented in the network at a later time, save the action in an
XML file, as follows:
 Click Export .
OR
 Right-click one of the selected trails and select Trail Utilities > Export. The Export Trails dialog
box opens.
Continue the procedure as described in Exporting Trails , from Step 4.
For information about how to eventually implement the deletion in the network, see Importing Trails.
Parent Topic
6.8 Editing and Deleting SDH, Optical, and EoS/MoT Trails

6.9 Splitting a Long Trail

You can automatically split a "long" SDH server trail (a server trail that spans more than a single segment)
into two server trails. The trail is split at the point where it traverses a selected ME. All the low order trails
passing through the VC-4 trails are also handled, enabling them to use both server trails. Cross connects at
low order level are created in both the split server trails via spanned elements. This enables extending the
trail from the segment that is common to both original trails to the new segment.
This feature applies only to server (non-service) trails. The Trail List window Trail Purpose parameter
identifies a trail as either Server or Service. Service trails include low order trail, concatenated trails, and
flex trails (not having a pattern that LightSoft recognizes - a flex trail is a service regardless of its rate). The
long trail can include both MEs and UMEs, and can be split at either an ME or a UME.
To split a long trail:

1. In the Trail List window Trails pane, click a long trail to highlight it in the list. Click Show Trail to
highlight its segments in the map view.
2. In the map view, select the element where the long trail should be split.
3. Right-click the ME in the map view.

OR
Right-click the trail in the Trails pane and select Trail Operations > Split Trail.
4. A warning appears that the operation may be traffic-affecting. Click OK.
Depending on the volume of trails, the operation may take a few minutes. The Progress bar indicates
that processing is in progress.
5. After the processing is completed, a Confirm message appears, indicating that the split succeeded. If
you want to reload the Trail List window to observe the result, click Yes. (Reload may be
time-consuming. You can click No to postpone reloading at this time.)

When the Trail List window is reloaded (now or later), observe that the original trail is now listed as
two trails in the Trails pane, having the same label as the former unsplit trail but with a "Split" suffix.
You can click one of the trails in the Trails pane and observe its segment(s) and termination points in
the map view.
You can now drop low order trails traversing the long server trail in the ME where it was split.
Parent Topic
6.10 Relocating SDH Client Trails

You can migrate or relocate the client trails on a single server trail to a target server trail. For example, this
feature can be used to relocate client trails on a short server trail to a long server trail. When migrating
from one server trail to another, both server trails must share an NE with the same endpoint.
You can select the client trails that you want to relocate based on the path that is carried by the source
server trail. For example, you can choose to relocate only protected client trails whose main path is carried
by the source server trail.
NOTES:
 This operation may be traffic affecting.
 Relocation can be performed on bidirectional client trails only.
 Relocating trails may affect the distribution of resources used for the trail routes. For
example:
 If an MoT trail carrying tunnels was relocated, this may result in a situation where the
Protected and Bypass tunnels utilize shared resources.
 Even if the two paths of the client trail were diverse before relocation, this diversity
may be lost when both paths are moved to a single long server trail.
 Relocation cannot be performed on DNI- and DRI-protected trails.

To migrate client trails to a different server trail:

1. In the Trail List window, right-click the source server trail and click Trail Operations and then Relocate
Client. The Relocate Client window opens displaying the source server trail.
2. In the Target server trail ID field, enter the Trail ID of the server to which you want to migrate the
clients.
3. Select one of the following options and then click OK:
 Relocate all client trails
 Relocate only unprotected trails
 Relocate only main paths of protected trails
 Relocate only protection path of protected trails
LightSoft validates the target server trail and attempts to relocate all selected client trails on the
source server trail to the target server trail. A message is displayed indicating the relocation status of
each trail, including a detailed description of all relocated client trails, and the reasons for failure of
non-relocated trails, if applicable.
Parent Topic

6.11 Managing Data Trail Bandwidth

You can increase or decrease the bandwidth of an existing EoS or MoT trail without having to recreate it.
You can also activate the bandwidth of an existing EoS trail, opening it to data traffic for the first time.
(When a new EoS trail is created, bandwidth activation can be postponed by not selecting the Activate
Bandwidth checkbox in the Create Trail window EoS/MoT Configuration pane. For more information, see
EoS/MoT Configuration pane).
Parent Topic
6.11.1 Increasing Trail Bandwidth

This section describes how to increase the bandwidth of an EoS/MoT trail.
Increasing an MoT trail's bandwidth is disallowed if:
 The trail is protected with bypass tunnels. The bypass tunnels must be removed first.
 The action results in additional topology links or routes being used. If SRLG diversity increases, the
operation is disallowed. (Changes to shared bandwidth are otherwise allowed.)
NOTE: Before starting the LightSoft procedure, ensure at the EMS level that LCAS has been
enabled and the number of allocated VCs has been increased for the relevant ports.
To increase the bandwidth of an EoS/MoT trail:

1. In the Trails pane of the Trail List window, right-click an EoS or MoT trail and select Trail Operations >
Increase. The Increase Trail Bandwidth window opens (on top of the Trail List window) showing the
Basic Trail Parameters pane.
2. In the Basic Trail Parameters pane, select a VCAT Size multiple (greater that the current VCAT size).
The maximum allowed multiple depends on the currently applicable Rate. (The Protection field is also
enabled for changes if needed.)

3. In the EoS/MoT Configuration pane, select the Activate Bandwidth checkbox if you want the
additional bandwidth to be available and operational immediately. (This can be postponed to a later
time.)
4. Click Complete to simulate the change. If a Trail Completion Failed error message appears:
a. Evaluate the resources on the segment - they may be insufficient for the increase in VCAT size.
To see the state of free resources in a segment, select the segment in the Resource Tree pane
and view the associated resources in the Resource List pane. For information about adding
resources to a trail, see Select Resource pane.
b. Evaluate the routing configuration. Consider configuring (or expanding the configuration of)
diverse routes. If diverse routing is not defined, all resources are allocated to the same route or
link (Route #1). The diverse routing options are enabled when the Diverse Routes checkbox is
selected. For details, see EoS/MoT Configuration Pane.
c. Click Complete to again simulate the change. If the completion still fails, reevaluate the
resource allocation and diverse routing configuration.
5. Click Activate to save the new settings to the database and download the new bandwidth to the
EMS. If the Trail Completion Failed error appears, perform (or repeat) the remedial procedures listed
in Step 2.
NOTE: The increased bandwidth is not operational unless it is activated. If you did not select
the Activate Bandwidth checkbox (in Step 3), make sure to activate the new bandwidth later;
see Activating Trail Bandwidth. (If not, only the previous bandwidth level will be operational.)
Parent Topic
6.11.2 Decreasing Trail Bandwidth

This section describes how to decrease the bandwidth of an EoS trail.
NOTE: Decreasing trail bandwidth may require additional actions at the EMS level:
 Before starting the LightSoft procedure, ensure that LCAS has been enabled for the
relevant ports.
 After completing the LightSoft procedure, you may wish to decrease the number of
allocated VCs for the relevant ports.

To decrease the bandwidth of an EoS trail:

1. In the Trails pane of the Trail List window, right-click an EoS trail and select Trail Operations >
Decrease. The Decrease Trail Bandwidth window opens (on top of the current Trail List window)
showing the Basic Trail Parameters pane.
2. In the Basic Trail Parameters pane, select a VCAT Size multiple (less than the current VCAT size, but at
least "1").
3. (Optional) Specify exactly the resources you want to decrease:
a. Select the endpoints of the trails from which you want to decrease resources. If one endpoint is
selected, the pair of endpoints is automatically regarded as selected.
OR
b. Highlight a path in the Resource Tree pane, and select the corresponding resources (timeslots
used by the trail) to be decreased in the Resource List pane.
OR
c. Right-click a path in the Resource Tree pane and select Decrease. The corresponding resources
are automatically selected for decrease.
There is a one-to-one relation between pairs of endpoints and resources. When an endpoint or
resource is selected, the corresponding resource/endpoint is implicitly selected.
If no endpoints/resources are selected (or if the ones selected are not sufficient to achieve the VCAT
reduction you indicated), LightSoft automatically decreases additional resources. If Diverse routing is
used, LightSoft balances the reduction between the paths.
If too many endpoints/resources are selected for the indicated reduction in VCAT size, an error
message appears.

4. (Optional) Click Complete to simulate the change. The endpoints and corresponding resources
are reduced according to your selections and/or completed by LightSoft. If a Trail Completion Failed
error message appears, verify that your endpoint/resource selections are logical.
5. Click Activate to activate the decreased bandwidth and save the new settings to the database. If
a Trail Completion Failed error message appears, verify that your endpoint/resource selections are
logical.
The portion of bandwidth that is decreased is automatically deactivated. The bandwidth that is left
remains activated.
Parent Topic
6.11.3 Activating Trail Bandwidth

This section describes how to activate the bandwidth of an EoS trail if it is not done when creating the trail,
or when bandwidth has been increased. Bandwidth can also be activated, if needed, in the process of
reconnecting a trail; see Reconnecting Trails. Bandwidth can be deactivated in the trail edit process; see
Editing Trails.
To activate the bandwidth of a data trail:

1. In the Trails pane of the Trail List window, highlight an EoS or MoT trail, or select checkboxes of
multiple trails.
2. Right-click and select Trail Operations > Activate Bandwidth. A confirmation prompt appears.
3. Click Yes.
Parent Topic
6.12 S-VLAN Registration from a Link or Trail

S-VLAN registration can be performed by LightSoft automatically at the ETY link or EoS trail level. S-VLAN
registration at the link level enables all PB network services to utilize that link. S-VLAN registration at the
trail level enables all PB network services to utilize the virtual link represented by that trail.
Adding the S-VLAN registration to an ETY link or EoS trail automatically downloads the associated link
information to each existing service in the PB network. Performing S-VLAN registration at the link or trail
level avoids having to S-VLAN register each network service individually. For information about S-VLAN
registration at the service level, see Automatic S-VLAN Registration.
Parent Topic

6.12.1 Adding and Removing S-VLAN Registration for ETY

Links
To add S-VLAN registration during link creation:
 Select the S-VLAN Registration checkbox in Create Topology Link Advanced Attributes.
To add S-VLAN registration to an existing link:

1. In Link List window Links pane, right-click an ETY link and select
Link Operations > S-VLAN Registration. A confirmation window opens.
2. Click Yes. The registration is completed.
To deregister the S-VLAN from a link:

1. In Link List window Links pane, right-click an ETY link and select
Link Operations > S-VLAN Deregistration. A confirmation window opens.
2. Click Yes. The deregistration is completed.
Parent Topic
6.12.2 Adding and Removing S-VLAN Registration for EoS

Trails
To add S-VLAN registration during trail creation:
 Select the S-VLAN Registration checkbox in the EoS/MoT Configuration Pane.
To add S-VLAN registration to an existing trail:

1. In Trail List window Trails pane, right-click an EoS trail and select
Trail Operations > S-VLAN Registration. A confirmation window opens.
2. Click Yes. The registration is completed.
To deregister the S-VLAN from a trail:

1. In Trail List window Trails pane, right-click an EoS trail and select
Trail Operations > S-VLAN Deregistration. A confirmation window opens.
2. Click Yes. The deregistration is completed.
Parent Topic

6.13 Inserting MPLS PEs into MoT/MoE Links

The Insert PE option inserts an MPLS PE into an existing MoT/MoE link. The process is not traffic affecting
provided the applicable tunnels are protected by bypass tunnels. The steps required to insert a PE into an
MoT/MoE link are as follows:
 Split the original MoT/MoE link into two links, each terminating on the inserted PE.
 The old link (which traversed link AB) is shortened and now runs from PE A to the inserted PE (Z) (AZ).
The label for this link is the original label with "SplitMot_1" appended.
 A new link is created, running from PE B to the inserted PE (Z) (ZB). The new label is the same as the
original label before the split with "SplitMot_2" appended.
Figure 6-18: Insert PE process
 Traffic is diverted to the applicable bypass tunnel (for example, AY-YB) while the PE is inserted.
 The link's tunnels are updated to the new path (AZ-ZB). After this is done, traffic reverts to the new
main path.
 All bypass tunnels protecting tunnels on the link into which the PE is inserted (AY-YB) are invalidated
and deleted. (Any affected bypass tunnels that fail to be deleted become irrelevant and must be
deleted manually.)
For a detailed description of the actions executed by the Insert PE process, see What Insert PE Does.
The process is subject to constraints – see the conditions described in Insert PE Results Summary Status
Area.
After the process is completed, for each of the two new links, you must manually create new bypass
tunnels and perform FRR Update, in order to reinstate the intended tunnel protection. For example:
 For new link AZ, the new bypass tunnel may traverse links AY-YB-ZB.
 For new link ZB, the new bypass tunnel may traverse links AZ-AY-YB.
These manual procedures are described in detail within the Insert procedure; see Insert PE into MoT/MoE
Procedure.
TIP: If the replaced link (AB) is traversed by a bypass tunnel protecting another unrelated
tunnel (say the tunnel on link YB was protected by a bypass tunnel on AB-AY), a new bypass
tunnel on valid links will be assigned automatically (for example, the tunnel on YB would now
be protected by a bypass tunnel on ZB-AZ-AY). No further manual intervention is required.
Parent Topic

6.13.1 What Insert PE Does

The Insert PE process executes the following detailed actions.
1. Validation of preconditions:
 Selected PE must have two configured free ports, each with matching granularity/rate
appropriate for the selected MoT/MoE link.
 Selected link must have its endpoint in the selected PE.
 MoT trail path traverses the inserted PE.
 If the MoT trail is diverse routed, all of the routes traverse the ME to which the PE belongs.
 MoT/MoE link state is consistent (OK or Incomplete); see Trail State in Trails Pane Columns.
2. Automatic pre-configuration actions:
 If Protection Desired: Current Protection applies to the MoT/MoE link:
 Force FRR Switch is applied on both MoT/MoE link endpoints.
 The protection path is removed – the link becomes Protection Actual: Unprotected or
Partially Protected at LightSoft and EMS (even if the operation fails at a subsequent step).
 If Underlying protection applies, no action is performed.
Failure of this step prevents the Insert PE from proceeding.
The actions cannot be roll backed, even if any subsequent steps fail.
3. Updates performed in the LightSoft database (description refers to diagram in Inserting MPLS PEs into
MoT/MoE Links):
 Old MoT/MoE link (traversing from A to B): Endpoint at B is released and a new endpoint
defined on the PE to be inserted (Z). The link now extends from A to Z.
 New MoT/MoE link created (traversing from Z to B) with:
 One endpoint on the PE to be inserted (Z), second on the released endpoint (B).
 Label set automatically with the default value.
 Affected bypass tunnels are deleted.
 Paths of tunnels of the MoT/MoE link are updated with new expected cross connects on the
inserted PE.
This step must be fully successful for Insert PE to proceed. Full rollback applies to any intermediate
failure. If successful, all relevant objects in the LightSoft database are updated and have appropriate
inconsistency state.
4. Downloads of relevant parameters to the EMS are performed. This step involves multiple operations,
since XC downloads are executed separately for each trail/link/tunnel. Failure on an individual object
does not cause the whole operation to fail.
Steps 3 and 4 may take some time. A progress indicator shows the operation progress. A Stop option is
available to abort the operation if needed.
Data regarding the whole operation is accumulated in a Results Summary window. Intermediate results are
indicated if a failure occurs. For more information, see Insert PE Results Summary.
Parent Topic

6.13.2 Insert PE Prerequisites

The following prerequisites apply when inserting a PE. Ensure that:
1. All participating links and PEs have been upgrade to LightSoft V6 or higher.
2. Selected PE and link can belong to any MPLS Net ID.
3. Selected link is consistent.
4. The additional resources required for tunnels in the selected link are available at the selected PE.
5. Matching BE CoS settings are configured for all participating ports.
6. Force FRR is automatically applied on selected link endpoints.
7. Loop prevention:
 Selected PE must not already be included in the path of any of the carried tunnels.
 In new topologies, two PEs can coexist on the same NE. However, when inserting a PE between
two existing PEs, the new PE cannot be located in the same NE as either of the PEs between
which it is to be placed.
8. MoT link:
 Main path of the link traverses the ME to which the PE belongs.
 If link is protected, the protection path is automatically removed during Insert PE.
 Selected link has no LCAS diverse route,
except when all routes traverse the ME to which the PE belongs.
 Selected PE has two configured free ports, each with:
- matching VCn granularity, and
- same/larger number of VCs as the selected link.
9. MoE with 2 ports:
 Selected PE has two free MoE ports configured, each matching the selected link in terms of link
connectivity rules, Ethernet port type, and technology layer.
10. In LightSoft v10 and higher bidirectional tunnels are supported. Earlier versions support unidirectional
tunnels only.
Parent Topic

6.13.3 Insert PE into MoT/MoE Procedure
NOTE: PEs can be inserted into MoT links only after the PEs associated ME is already inserted
into the corresponding physical link. Failure to follow this sequence can yield unexpected
results. For details about the Insert ME process, see Inserting Elements in SDH Links.
To insert an MPLS PE to an MoT/MoE link:

1. Select the ETH/MPLS topology layer.
2. In the topology map, select:
 The PE to insert and
 The MoT/MoE link where it should be inserted.
Press SHIFT while selecting the two objects.
3. In the main window Topology tab, in the Modify group, click Insert PE (enabled when a PE and
MoT/MoE link are selected).
4. If a multilink was selected, the Select single link dialog box opens, listing the links included in this
multilink. Highlight a link and click Select. (If no multilink is involved, the Insert PE window opens;
continue to the next step.)
5. The Insert PE dialog box opens; see Insert PE Window.

6. In the Create MoT/MoE Links pane, expand the two trees on the left and right sides and choose the
two ports through which the selected PE will be connected to the MoT/MoE link.

The port on the left-side tree is used to connect to the adjacent PE on the left side of the link. The
port on the right-side tree is used to connect to the adjacent PE on the right side of the link.
The Ports field above the trees lists the names of the two adjacent PEs. As you select a port from the
tree fields, the name is filled into the corresponding Ports field.
Ports are enabled for selection if they are available and have granularity and interface rates
compatible with (not less than) the MoT/MoE link rate. Ports that are inadequate or not relevant to
the selection are disabled.
7. (Recommended) After two ports are selected:
a. Select Show Carried Tunnels to be Updated to open the Tunnel List window showing the
tunnels traversing the MoT/MoE link. (The process will automatically recreate these tunnels to
traverse the PE over new links.)
Note the number of tunnels in the old trail (bottom-left corner of the window). At the end of
the process, you can verify that the new trail contains the same number of tunnels as the old
trail.
b. Select Show Bypass Tunnels to Invalidate and Delete to open the Tunnel List window
showing underlying bypass tunnels that will be invalidated and deleted by the Insert PE process.
Print out a listing of the bypass tunnels to be deleted, in order to be able to manually restore
them after the process is completed.
NOTE: This information will not be available in the same form after the process is completed;
see the icon description in Insert PE Results Summary.
8. (When inserting PE into an MoE link only) To prevent loss of traffic:

a. Right-click the MoE link and select Properties. The Properties window opens.
b. In the TE Other tab in the FRR Mode, select Forced Switch for both ports.
c. In the case of a CESR9700/9600 NEs only, in the Reversion field, select Non-Revertive.
d. Physically disconnect the fibers to which you want to connect the PE. Connect each end to the PE
that you want to insert and verify that each connection is clear of alarms.
9. Click Start (enabled after two ports are selected). The process may take some time. It includes
the automatic steps described in What Insert PE Does. The Operation Progress pane indicates the
progress.
You can click Stop Insert PE Operation to stop the process before it completes. This is not
recommended, as some changes already performed would not be rolled back and the affected
tunnels would have to be corrected manually.
10. When process is completed, the Insert PE Results window opens displaying summary results; see
Insert PE Results Summary.
Failure messages may appear in the Status area; see Insert PE Results Summary Status Area.

NOTE: The window icons assume different meanings after activation:
shows the tunnels that were updated.
shows the bypass tunnels that failed to delete.

For more information, see the icon descriptions in Insert PE Results Summary.
11. Close the Insert PE window.

12. The Insert PE process automatically invalidated/removed all bypass tunnels that protected tunnels on
the MoT/MoE link where the PE was inserted.
On each of the two new MoT/MoE links, create new bypass tunnels manually to reinstate link or node
protection according to your network configuration. Refer to the details you noted in Step 7. For
information about tunnel and bypass tunnel creation, see Provisioning MPLS Tunnels.
13. Tunnels on the two new links (formerly Fully or Node protected) now have Protection Actual: Partially
protected or Unprotected. Update the tunnel protection as follows:
a. Select the two new MoT/MoE links in the ETH/MPLS Map view.
b. Right-click and select Show Tunnels > All Tunnels. The Tunnel List window opens with the
tunnels on these MoT/MoE links.
c. Select the checkboxes of all the tunnels whose protection needs to be updated.
d. Right-click and select Edit > Protection > Update FRR Protection.
14. For CESR9700/9600, configure link properties TE Other tab Reversion field from Non Revertive to
Revertive, if required.
Parent Topic

6.13.4 Insert PE Window

The Insert PE window is used to insert a PE into a selected MoT/MoE link, as described in Insert PE into
MoT/MoE Procedure.
Figure 6-19: Insert PE window
Table 6-8: Insert PE window toolbar icons

Starts the Insert PE process. Enabled when two valid
Start Insert PE Operation
endpoints are selected.
Stop Insert PE Operation Stops the Insert PE process. Not recommended, as some
changes already performed are not rolled back and affected
tunnels would have to be corrected manually.
Show Carried Tunnels to be Opens the Tunnel List window showing the underlying
Updated tunnels traversing the MoT/MoE link.
The Insert PE process automatically creates these tunnels
again to traverse the inserted PE. This option assumes a
different meaning after the process completes; see Insert PE
Results Summary.


Show Bypass Tunnels to Opens the Tunnel List window showing the underlying
Invalidate and Delete bypass tunnels that would be invalidated and deleted by the
Insert PE process. After the process finishes, the user must
create new bypass tunnels manually. This option assumes a
different meaning after the process completes; see Insert PE
Results Summary.
Table 6-9: Insert PE window fields
Field Description
PE Name of PE to be inserted.
Link MoT/MoE link where PE will be inserted.
Ports of the selected PE used to connect to the MoT/MoE link.
Two ports are listed, one to connect to the adjacent PE on the left, and one to connect
Ports
to the adjacent PE on the right. A port is listed in this field only after it is selected from
the port 'trees' in the following field.
List of ports available on selected PE, arranged in tree structures. The tree on the left
side is used to select the port to use to connect to the adjacent PE on the left side. The
Left/Right Trees
tree on the right side is used to select the port to use to connect to the adjacent PE on
the right side.
Parent Topic

6.13.5 Insert PE Results Summary

At the conclusion of the Insert PE process, the Insert PE window includes a Results Summary pane where
the process results are displayed.
Figure 6-20: Insert PE results summary
If any part of the process failed, an Operation Failed message opens. The details of the failure are listed in
the Status pane; see Details Area.
Table 6-10: Results Summary toolbar icons

Show Updated Opens the Tunnel List window showing the underlying tunnels that
Carried Tunnels were updated.
(The icon has a different meaning before and after activation. Before
activation, this icon shows the underlying tunnels to be updated by
the process.)
Show Bypass Tunnels Opens the Tunnel List window showing the bypass tunnels that failed
not Deleted to be deleted completely from network. (Enabled only if some bypass
tunnels were not deleted.)
(The icon has a different meaning before and after activation. Before
activation, the icon shows the bypass tunnels to be deleted by the
process.)
Parent Topic

6.13.5.1 Status Area

This area contains information about process failures.
 Validation/Pre-config: Shows operation failure reasons as follows:
 Validation failed due to:
 Selected PE being an endpoint of the MoT/MoE link: The PE must not already be part of
the MoT/MoE link to which it should be inserted.
 Inconsistent MoT/MoE link state: The process is not allowed if the trail state is not OK.
 MoT trail main path not traversing the ME: The ME must be on the main path of the
protected trail, and not on the protected path.
 Diverse routed MoT trail with route not traversing the ME: All the routes of the trail must
traverse the ME to which the PE belongs.
 Operation terminated due to:
 Failure to remove protection from MoT/MoE link: The Insert PE process failed to remove
bypass tunnels.
 Failure to force FRR switching on MoT/MoE link endpoints: The Insert PE process failed to
switch the working path of the tunnel to the bypass tunnel in preparation for deleting the
original tunnel. Before deleting the bypass it goes to FRR switch, can do insert to PE, then
switches FRR back.
 Internal error, such as a loss of connection.
 Failure to update database: Some tunnels traversing the MoT/MoE link failed to update.
 DB Update: Result of the automatic update to the LightSoft database, described in Step 3 of What
Insert PE Does. Values are OK, Failed, or Not Applicable (if the process was not performed).
 Download to network: Result of the automatic download to EMS process, described in Step 4 of What
Insert PE Does. Values are OK, Failed, or Not Applicable (if the process was not performed).
Parent Topic

6.13.5.2 Details Area

This area contains information about process failures.
 Invalidated Tunnels:
 Total bypass tunnels invalidated by LightSoft: Verify that this corresponds to the number noted
in the Insert PE procedure at Step 7.
 Total bypass tunnels deleted successfully from the network.
 Total bypass tunnels failed to be deleted from the network: To view details, click Show Bypass
Tunnels not Deleted .
 Updated Tunnels:
 Total tunnels downloaded successfully: To view details, click Show Updated Carried Tunnels
Parent Topic
6.14 Removing MPLS PEs from MoT/MoE Links

The Remove PE function automatically removes a selected PE from the path of an MoT/MoE link and
merges the two adjacent 'sides' of that link into a single link. As a result:
 Transit tunnels (working or bypass) and P2MP subtunnels traversing the selected links have their
transit MPLS XC removed from the selected PE.
 Terminated (Head/Tail) tunnels (working or bypass) and P2MP subtunnels traversing the selected links
are deleted.
When the adjacent links are multilinks, the procedure must be performed for one link pair at a time.
After the process is completed, bypass tunnels must be manually applied to the newly created tunnels.
The following additional actions may be required after Remove PE is performed:
 If the process finishes successfully, but errors are observed, the incompletely processed entities must
be corrected manually; see Process Finished Successfully But With Some Errors.
 If the process fails or is stopped before completion, according to the step at which the process halted,
the process must either be completed manually or network-affecting process steps that were already
executed may need to be rolled back manually; see Manual Roll Back or Continue Upon Failure.
 If manual roll back is performed, then, the preexisting condition in the topology that caused the failure
must be resolved in order for Remove PE to succeed if tried again; see Reconstructing the Topology.
NOTE: Remove PE is a traffic-affecting operation. Working transit tunnels also undergo

Remove PE and experience traffic losses during the procedure. Services are disconnected from
tunnels traversing the selected links and terminating at the selected PE. Remove PE is
minimally traffic affecting to node protected tunnels.
Shared BW along network does not have to be updated.

Parent Topic
6.14.1 Remove PE Prerequisites

The following prerequisites apply when removing a PE.
1. Selected links are consistent.
2. The selected links have endpoints on the selected PE,
and they are either both unprotected or both protected.
3. MoT:
 Selected links have matching VCn granularity and total number of VCs.
 Selected links have no LCAS diverse routes,
unless if they match capacities for all routes (e.g., 3-2-2 VC4s for both links).
 The Main (Protection) paths of the selected links can share physical links or server trails,
respectively.
 The Main path of one selected link and the Protection path of the other selected link cannot
share physical links or server trails - NMS will automatically remove the MoT protection during
Remove PE.
 The two far endpoints of the two selected links belong to two different PEs.
 A single ME cannot be both endpoint of one link and intermediate point of the other.
4. MoE:
 The selected links have a matching Ethernet port rate.
5. All transit tunnels and transit sub-tunnels switch from one of the selected link to the other one.
6. In LightSoft v10 and higher bidirectional tunnels are supported. Earlier versions support unidirectional
tunnels only.
Parent Topic
6.14.2 Remove PE Procedure

The Remove PE function is enabled when a PE and two adjacent links are selected in the map view, where:
 The selected links have endpoints in the selected PE.
 The far endpoint of each selected link must belong to different PEs.
The Remove PE process is subject to the following constraints:
 The selected PE and links must not be state Inconsistent.
 The selected links must have:
 Endpoints on the selected PE are both unprotected or both protected.

 Matching granularity, rate, and/or total number of VCs (VCAT size), as relevant to the MoT or
MoE links.
 No LCAS diverse routes, or all the routes have identical capacities (e.g., 3-2-2 VC-4 trails for both
links).
 All transit tunnels and subtunnels must switch between the selected links (meaning, no transit tunnel
switches to an unselected link).
The process will not complete if a constraint is not satisfied.
To remove an MPLS PE from an MoT/MoE link:

1. Select the ETH/MPLS topology layer.
2. In the topology map, select:
 The PE to remove.
 The two adjacent links from which the PE will be removed.
Press SHIFT while selecting the three objects.
3. In the main window Topology tab, in the Modify group, click Remove PE (enabled when a PE and two
links are selected).
4. If one or both of the required links is part of a multilink, the Select single link dialog box opens, listing
the links in each multilink. (If no multilink is involved, the Remove PE window opens; continue to the
next step.)
a. Select the specific link on each side of the PE from which it should be removed.

NOTE:
 If one adjacent side has only one link, that link is selected automatically. You only have to
select a specific link from a multilink list.
 If both adjacent sides are multilinks, select one link from each adjacent side. (If more than
one link pair needs to be removed from the PE, the entire procedure must be repeated for
each link pair.)
)
b. Click Select and Continue to Remove PE.

5. The Remove PE window opens; see Remove PE Window.
6. (Recommended) Print out traffic List windows with details about entities that will be changed by
Remove PE:
 Show Transit Tunnels to Update shows tunnels traversing this path that will be updated.
 Show Tunnels to Delete shows tunnels that will be deleted.
 Show Traffic-Affected Transit Tunnels shows working transit tunnels that will
temporarily go down.
 Show Services to Disconnect shows services that will be permanently disconnected.

For more details, see the icon descriptions in Remove PE Window.
NOTE: It is strongly recommended to print out and reserve these reports showing the
pre-operation topology state. This information will not be available after Remove PE is started.
In the event of a failure, certain process steps are not rolled back automatically and it is the
user’s responsibility to do so as needed (see Manual Roll Back or Continue Requirements).
These reports will assist knowing what specific entities need to be reinstated manually. The
reports available after the process completes (or is halted) will reflect the post-processing
state; see the icon descriptions in Remove PE Results Window.
7. (When removing a PE from between an MoE link only) To prevent loss of traffic:
a. Right-click the MoE link and select Properties. The Properties window opens.
b. In the TE Other tab in the FRR Mode, select Forced Switch for all ports.
c. In the case of a CESR9700/9600 NEs only, in the Reversion field, select Non-Revertive.
8. Physically disconnect the fibers from the PE that you want to remove, connect the fiber to the
adjacent PE and verify that the new connection is clear of alarms.

9. Click Start . A warning message opens that the operation is traffic affecting.
10. Click Yes. The process begins and may take some time. Progress text and indicators appear in the
window.
The Progress panel shows the specific process step being performed. An error message appears if a
validation is not satisfied; see the conditions listed at the top of this section. Upon a Stop action or a
fatal failure, the currently displayed process step is halted and Remove PE terminates.
NOTE: Click Stop Remove PE Operation to stop the process before it completes. A
message appears warning that stopping Remove PE may cause reversible topology changes.
Click Yes to continue.
Stop should be used only in rare cases, for example, if it becomes apparent that a fault is
causing the process not to end. If the process is stopped in this way (or is otherwise halted
due to a failure), already executed network-affecting process steps are not rolled back and
must be reverted manually. For details about the required manual roll back or continue steps,
see Manual Roll Back or Continue Upon Failure.
11. At the conclusion of the processing, the Remove PE Results window opens showing the summary
process results. For the full window example, see Remove PE Results Window.
A popup window will accompany the Remove PE Results window:

a. When the process completes successfully or did not encounter fatal errors, a successful
completion message is displayed. Click OK to continue.
This message denotes that the PE was removed and the link reconstructed between the two
adjacent PEs.
However Remove PE Results window Status and Details areas may show that some entities did
not process completely. In this case, you must identify the entities that failed to process and
perform manual actions on them; see Process Finished Successfully But With Some Errors.
OR
b. If the operation failed, or was stopped by the user, a message to that effect is displayed. Click
OK to continue.
 In this case the process did not complete. Depending on the stage the processing reached,
some network-affecting actions may already have been performed which are not
automatically reverted. Then the process must either be rolled back or continued
manually to completion. For details, see Manual Roll Back or Continue Upon Failure.
AND
 If manual rollback actions are performed (rather than complete actions) the preexisting
conditions in the topology that caused the failure must then be resolved so that Remove
PE will succeed if tried again. For details, see Reconstructing the Topology.
12. Close the Remove PE and Remove PE Results windows.
13. If the process completed successfully (as described in Step 9.a), bypass tunnel protection must be
manually reapplied to the newly updated tunnels:
 Create new bypass tunnels if required; see Creating a Tunnel.
 Apply bypass tunnel protection to the newly updated tunnels; see Updating FRR/eFRR
Protection.
Parent Topic
6.14.3 Remove PE Window

The Remove PE window shows the selected PE and the selected links from which the PE will be removed.
Figure 6-21: Remove PE window

Table 6-11: Remove PE window information fields

Start Starts the Remove PE process.
Stop Stops the Remove PE process. It is used in rare cases, for example,
if it becomes apparent that a fault occurred that is causing the
process not to end.
Note: This option should be used with caution, as
network-affecting changes already performed are not rolled back.
Affected tunnels and services must be reverted manually. For
more information, see Manual Roll Back or Continue Upon Failure.
Show Transit Opens the Tunnel List window showing tunnels traversing this
Tunnels to Update path that will be updated by Remove PE.
Show Tunnels to Opens the Tunnel List window showing tunnels that will be
Delete deleted by Remove PE.
Show Opens the Tunnel List window showing working transit tunnels
Traffic-Affected that will temporarily go down during Remove PE.
Transit Tunnels
Show Services to Opens the Service List window showing services that will be
Disconnect permanently disconnected by Remove PE.
Table 6-12: Remove PE window information fields
Field Description
PE Name of PE to be removed from the selected links.
Link 1 Label and ID of the link to be disconnected from one side of the PE.
Link 2 Label and ID of the link to be disconnected from the other side of the PE.
Parent Topic
6.14.4 Remove PE Results Window

The Remove PE Results window displays the operation results. In the event of a failure, the Status section
shows which categories of processing actions were involved. Only Download to Network failures require
manual roll back actions before Remove PE can be attempted again. The Details area shows the number of
each entity for which network processing failed. The specific entities that were affected can be deduced by
comparing pre- and post-process list window printouts.

All failure types require resolving the underlying cause of the failure before in order for Remove PE to be
successful when it is attempted again.
Figure 6-22: Remove PE Results window
Table 6-13: Remove PE Results toolbar

Show Updated Tunnels Opens the Tunnel List window showing
tunnels traversing this path that were updated
by Remove PE.
Show Tunnels not Deleted Opens the Tunnel List window showing
tunnels that failed to delete completely from
the network in the following cases:
 The tunnels are not in the DB and cannot
be admitted.
 The tunnels have FRR Type = Undefined in
the DB and are not admittable or
imposable.
In both cases, the tunnels should be manually
deleted from the network.
Show Non-Conformant Services Opens the Service List window showing
services that became non conformant due to
Remove PE.
These services may be corrected through
manual editing or reconnection; see
Reconnecting Services.


Show Non-Conformant Transit Opens the Tunnels List window showing the
Tunnels transit tunnels or subtunnels that failed to be
switched between the selected links. This icon
is available only if transit tunnels failed
validation.
Table 6-14: Remove PE Results window information fields
Field Description
Operation PE and MoT trail details, repeated from Remove PE window, see Remove PE
Parameters Window.
Status Shows the state of categories of Remove PE processing:
 Validation/Pre-config: Validations are performed before the process start to
ensure that Remove PE will not fail for feasibility reasons.
Messages are OK or Failed (usually with a reason to assist troubleshooting).
 DB Update: Indicates if LightSoft database updates were performed
successfully.
Messages are OK, Failed (usually with a reason), or Not Applicable (if
Validation/Pre-config could not be completed).
 Download to network: Indicates if network updates were performed
successfully.
Messages are OK, Failed (usually with a reason), or Not Applicable (if DB
Update could not be completed).
Details Shows the number of tunnels and services successfully or unsuccessfully dealt with
by the Remove PE process.
If the Remove PE process finished successfully, but failures are observed in some
Details area categories, entities will need to me corrected manually; see Process
Finished Successfully But With Some Errors.
If the process failed or was stopped before completion, manual rollback or
completion actions will be required; see Manual Roll Back or Continue Upon Failure.
Parent Topic
6.14.5 Process Finished Successfully but With Some Errors

If the Remove PE process finished successfully but some failures are observed in Details area categories,
you should identify the entities on which the processing failed and perform remedial actions on them, as
follows:
Disconnected services that failed to disconnect:

1. Click Show Non-Conformant Services to list the services that became non conformant due to
Remove PE.
2. Reconnect the services; see Reconnecting Services.
Invalidated bypass tunnels that failed to delete from the network: 0)
1. Click Show Tunnels not Deleted to list tunnels that failed to delete completely from the
network.
2. Delete the invalid bypass tunnels; see Deleting Tunnels.
3. Create new bypass tunnels in their place; see Creating a Tunnel.
4. Update FRR or EFRR protection on working tunnels that lost their protecting bypass tunnels when the
latter were invalidated; see Updating FRR/EFRR Protection.
Deleted terminated tunnels that failed to be deleted from the network: 0)
1. Click Show Tunnels not Deleted to list tunnels that failed to delete completely from the
network.
2. Delete the terminated tunnels; see Deleting Tunnels.
3. Create new tunnels in their place; see Creating a Tunnel.
4. Update FRR or EFRR protection on working tunnels that lost their protecting bypass tunnels when the
latter were invalidated; see Updating FRR/EFRR Protection.
Updated transit tunnels that failed to download: 0)
1. Click Show Updated Tunnels to list tunnels traversing this path that were updated by Remove
PE.
2. Compare this with the list of tunnels to be updated (that you generated at Step 6 using Show Transit
Tunnels to Update ).
3. For the tunnels identified as not updated, impose the tunnels from LightSoft to the EMS; see
Performing Tunnel Synchronization.
4. Click Show Non-Conformant Transit Tunnels to list the transit tunnels or subtunnels that failed
to be switched between the selected links.
5. Release FRR or EFRR protection by either:
 Making the tunnel unprotected; see Make Unprotected in Editing Tunnel Protection ,
OR
 Leaving the tunnel’s desired protection as Protected but remove bypass assignments to it; see
Remove FRR Protection in Editing Tunnel Protection.
6. Reconnect the services; see Reconnecting Services.
7. Impose the tunnels from LightSoft to the EMS; see Performing Tunnel Synchronization.

NOTE: If the process failed or was stopped before completion, manual rollback or completion
actions will be required. Perform the instructions in this section in the context of the actions
described in Manual Roll Back or Continue Upon Failure.
Parent Topic
6.14.6 Manual Roll Back or Continue Upon Failure

The Remove PE operation changes the LightSoft database and the network. In the event of a failure or
manual Stop action while Remove PE is in progress, any network-affecting process steps that were already
executed must be cumulatively rolled back manually. For example, tunnels that were removed or services
disconnected by Remove PE must be manually recreated or reactivated. (LightSoft DB-affecting process
steps are rolled back automatically and do not require user intervention.)
The Remove PE window progress bar displays the specific process step currently being performed during
the Remove PE process. According to the step at which the process failed or was stopped, the
network-affected steps must either be rolled back manually or the process completed manually; see
Manual Roll Back or Continue Requirements.
Parent Topic
6.14.7 Reconstructing the Topology

After manually rolling back changes following a failed process, the preexisting condition in the topology
that caused the failure must be resolved in order for Remove PE to succeed if tried again. The cause of the
failure can be deduced from the progress bar message of the process step in progress when the failure
occurred, as well as the Results window Status messages and Detail statistics. Routine remedial actions
should be applied.
Parent Topic
6.14.8 Manual Roll Back or Continue Requirements

The table below shows the Remove PE process steps and the manual rollback or continue actions that
should be performed in the event of a failure or Stop action at any given step.
 Number column: Indicates the order in which a process step is performed.
 Process Step and Description columns: Show the action performed by Remove PE in a step. The
description also shows the required manual actions that must be performed if the process fails/stops:
 Manual rollback: The process is stopped during Steps 2 to 9.The system reverts back to before
performing any of the Remove steps.
 Manual completion: The process is stopped during Step 10 or later.
 Affected Location column: Shows the entity affected by a step (Network, LightSoft DB, or GUI).

Table 6-15: Process steps and manual roll back requirements

# Process Step Remove PE action and corresponding Manual Rollback/Continue actions upon Affected Location
failure or Stop at each step
1. Select User selects PE to remove, pair of links to merge. GUI

2. Validate Verifies that prerequisites are met. DB
3. Force FRR Forces FRR switching on far-end endpoints of the selected links. Network
Only applicable with Node protection.
Manual roll back action required:
Release FRR protection by either:
 Making the tunnel unprotected; see Make Unprotected in
Editing Tunnel Protection , OR
 Leaving the tunnel’s desired protection as Protected but
remove bypass assignments to it; see Remove FRR
Protection in Editing Tunnel Protection.
4. Disconnect Disconnects services from Head or Tail tunnels. Network
Services Manual roll back actions required:
 Reconnect the services; see Reconnecting Services.
 Also perform Step 3 manual rollback action.
5. Delete Transit Deletes transit MPLS XCs at the selected PE. Network
MPLS XCs Manual roll back action required:
 Impose the tunnels from LightSoft to the EMS; see
Performing Tunnel Synchronization.
 Also perform Step 3-4 manual rollback actions.
6. Delete Deletes the head-tail tunnels. Network
Terminated Manual roll back actions required:
Tunnels  Impose the tunnels from LightSoft to the EMS (as in Step 5);
see Performing Tunnel Synchronization.
 Also perform Step 3-4 manual rollback actions.
7. Invalidate Invalidates the node-protecting bypass tunnels (FRR Type DB
Bypass Tunnels becomes Undefined).
Manual roll back actions required:
 Perform Step 3-6 manual rollback actions.
8. Merge Links Deletes endpoints of the selected links at the selected PE. DB
Creates an endpoint for the merged link at the ME of the selected
PE.
Updates SRLG list for the link as the union of the SRLG lists of the
selected links.
Assigns the merged link with auto TE metric.
9. Update Transit Deletes MPLS XC from selected PE. DB
Tunnels Repeats for all other transit tunnels.

# Process Step Remove PE action and corresponding Manual Rollback/Continue actions upon Affected Location
failure or Stop at each step
10. Delete Invalid Deletes the invalidated Bypass tunnels. Network

Bypass Tunnels Manual continue actions required:
 Delete the invalid bypass tunnels; see Deleting Tunnels.
 Create new bypass tunnels in their place; see Creating a
Tunnel.
 Update FRR protection on working tunnels that lost their
protecting bypass tunnels when the latter were invalidated;
see Updating FRR/EFRR Protection.
 Also perform Steps 11-12 continue actions.
11. Impose Link Imposes the merged link. Network
Manual continue actions required:
 Impose the merged link; see Performing Tunnel
Synchronization.
 Also perform Step 12 continue action.
12. Release FRR Releases FRR switching at the merged link endpoints. Network
Manual continue action required:
Release FRR protection by either:
 Making the tunnel unprotected; see Make Unprotected in
Editing Tunnel Protection ,
OR
 Leaving the tunnel’s desired protection as Protected but
remove bypass assignments to it; see Remove FRR
Protection in Editing Tunnel Protection.
13. Results Provides results summary. GUI
Summary
Parent Topic
6.15 Batch Trail Operations

This section describes how to perform Create, Edit, and Delete trail operations in a batch by exporting and
importing trail definitions to/from an XML file:
 The Export operation enables you to save the data of selected trails into an XML file for either network
planning or backup purposes.
 The Import operation translates the data stored in the XML file and sends this information to LightSoft
according to the requested operation for each trail in the file.
Records in the XML file specify the commands and parameters of actions. For information about the XML
syntax, see Import/Export Traffic Syntax.

LightSoft automatically generates a log file documenting the import or export process. You can find this log
file in the ~nms/NMSTrails directory. The log file name is the same as the XML file, with the .log extension.
A Document Type Declaration (DTD) file defines the rules by which the XML file is structured, the applicable
keywords, and how to parse the file. If required, the names of the tags in the DTD file can be changed (for
additional information, contact your local Customer Support representative).
Parent Topic
6.15.1 Exporting Trails

This section describes how to export trail definitions to an XML file for network contingency planning and
design or backup purposes.
Exported trails are automatically implemented in the network by the Import function according to the
settings that were used to export them to XML.
You can export trails either to a new XML export files or accumulate (append) them at the end of an
existing XML export file.
Trail definitions either from the Trail List window or in XML file format can be converted to CSV for viewing
in a relational database program. For details, see Exporting Trails to CSV.
Exporting for network planning purposes

Exporting trails to XML for network planning purposes is performed in conjunction with the creation of
"planned" new trails, changes to trails, or removal of trails:
 Planned new trails are created using the Plan Trail window, where an individual new trail can be fully
provisioned even while its prospective resources are currently occupied - they must be freed only
when the new trail is actually implemented; see Planned Trails.
Trails for future use can also be created singly or in bundles using the Create Trail window, by
exporting after Complete (before the Activate step). However, in this case, the resources selected for
the trails must be currently unoccupied; see Creating SDH and EoS/MoT Trails.
In both these cases, in the process of exporting the trails to XML, you will use the Export Trails
window's Export for Create mode.
 Planned changes to an existing trail are created using the Edit Trail window; see Editing Trails. For this
purpose the trails are exported to XML using the Export Trails window's Export for Edit mode.
 Planned removal of existing trails is performed using the Trail List window; see Deleting Trails. For this
purpose the trails are exported to XML using the Export Trails window's Export for Delete mode.
In each case, the planned entities do not immediately affect the working network. They are exported to
XML until they are needed. When the new network design is ready to be implemented, the planned trails
may be imported to LightSoft as part of the active network.
Exporting for backup purposes

You can export trails so that they can be restored later though an import if inadvertently deleted or
corrupted. For this purpose the original trail must have been previously exported - selected from the Trail
List or Edit Trail window, and an export file created using the Export Trails window using the correct export
mode:

 To restore a trail that was deleted from the network, the original export file needs to have been
prepared using the Export for Create mode.
 To restore an existing trail that become corrupted, the original export file needs to have been
prepared using the Export for Edit mode.
Parent Topic
6.15.1.1 Export Trails Procedure

Trails can be exported to XML using the Export Trails window. This example shows the window accessed
from the Trail List window. It includes a list of trails selected for the export.
When accessed from the Create Trail or Edit Trail window, the list of trails is omitted since the export
operation involves only one trail.
XML records are exported in the order that they are displayed in the Trail List window, and are eventually
imported serially, in the same order.
It is therefore important that the records be sorted prior to export in the right order for the intended
import action since, records for which a prerequisite action was not performed will not be imported. For
example, when importing for Create, if a low order trail record is encountered before its high order trail,
the low order trail is not created, even if the high order record appears later in the file.
In order to avoid this problem, before exporting, be sure to sort the Trail List window records by rate, as
follows:
 If the XML file will be used for Create, sort all high order trails to appear first before the low order
trails.
 If the XML file will be used for Delete, sort the low order trails to appear first before the high order
trails.
You can also export separate files for low order and high order trails. Then make sure to import the high
order trail file first when creating trails and the low order trail file first when deleting them.

To export trails to XML:

1. If you are exporting trails for backup purposes:
 In the Trail List window, select one or more trails; see Performing Trail Operations.
OR
 In the Edit Trail window, select a trail (and optionally edit it, but do not activate the changes);
see Editing Trails.
OR
2. If you are exporting trails for network planning purposes:
 Creating a trail: In the Create Planned Trail or Create Trail window, complete (but do not
activate) a new trail; see Creating and Exporting a Planned Trail or Creating SDH and EoS/MoT
Trails.
OR
 Editing a trail: In the Edit Trail window, edit a trail and complete (but do not activate) it; see
Editing Trails.
OR
 Deleting trails: In the Trail List window, select one or more trails that should be deleted (but do
not click Delete); see Deleting Trails. Ensure the trails are sorted according to the intended
action - Create or Delete - see the previous note.
3. Click Export .
OR
Right-click a trail and select Trail Utilities > Export. The Export Trails dialog box opens.
4. Select an existing file name in the Files pane or enter a name in the File Name field.
NOTE: The following characters (separated by commas) are not allowed in the file name:
*, ?, !, |, \, /, ', ", {, },<, >, ;, <comma>, ^, (, ), $, ~, #, @, <space>, +, =, &
5. If the file already exists, the Append checkbox is enabled:

 Select the checkbox to add the selected trails at the end of the existing file (preserving its
previous contents).
OR
 Leave the checkbox unselected to overwrite the existing file.
6. Select the appropriate Export As option:
 If the window was opened from the Create Trail or Plan Trail window, the Export for Create
option is automatically applied.
 If the window was opened from the Trail List or Edit Trail window, select:
 Edit if the export is for network planning purposes (they include changes to be applied
later) or will serve as backup in case the existing trails must be replaced (for example,
because of a needed routing change).

 Create if the export is for backup purposes (in case the existing trails that are deleted
need to be restored).
 Delete if the trails being exported are slated for deletion from the network at a future
time.
7. Click Export. The trail definitions are saved as an XML file.
Clicking Abort at any time causes the operation to stop after the current trail is processed. An
Exporting Failed message opens. An export file will be produced containing definitions of the trails
that completed processing up to that point.
Parent Topic
6.15.1.2 Exporting Trails to CSV

LightSoft provides an application that allows you to export Trail List window data to a delimited-format CSV
file for subsequent import to Microsoft Excel or a relational database application. LightSoft also enables you
to export trails in XML files to CSV using a command line application.
To export trails to CSV:

 See the generic procedures in Exporting to CSV.
To export XML data to CSV:

 See the generic procedure in Exporting XML Data to CSV.
Parent Topic
6.15.2 Importing Trails

This section describes trail definition import from XML using LightSoft menu options. (You can also import
trail XML files via UNIX; see Exporting/Importing Traffic Entities via UNIX.)
NOTES:
 Before importing trails, ensure that all the required endpoints and resources are free and
available. If any are occupied, the Complete action, which is performed automatically by
the import, will fail.
 The records to be imported must be in the right order for the intended action, since
records for which a prerequisite action was not performed will not be acted upon. For
details, see the note in Exporting Trails.

To import trail definitions from XML files via LightSoft:

1. In the main window Trails menu, in the Utilities group, click Import Trails. The Import Trails dialog
box opens.
2. In the Files pane, select the file you want to import.

3. Select one of the following options, according to the required action:
 Only check that the file format is valid: Checks the XML file structure validity for trail import.
 Only check that the trails in the file can be completed successfully: Checks file syntax and
verifies that trail creation is feasible in accordance with network rules, availability of resources,
and so on. This action is similar to Complete in the Create Trail procedure.
 Associate, Update Association, or Disassociate the trails in the file: Checks file syntax and
associates, updates the association, or disassociates the specified trails in the network,
depending on the XML file mode. This action is similar to the same actions when accessed via
the Trail List window.
OPTIONAL FEATURE: This option is relevant only for ASON 1+R trails. ASON is a fully
integrated add-on capability, available on a cost basis. If not purchased, this feature and
related menu commands are unavailable.

 Create, Edit, or Delete the trails in the file: Checks syntax, finds a path, and either creates,
edits, or deletes the specified trails in the network. The choice of action is determined
individually for each trail listed in the file. For example, users may append a trail creation
request to a file containing a list of trails for deletion. Trail mode is set at the time of export.
Note that trail creation here is similar to Activate in the Create Trail procedure. Trail editing is
similar to Activate in the Edit Trail procedure. Trail deletion is similar to the same actions when
accessed via the Trail List window.
4. Click Import. Each trail object in the XML file is executed (sequentially) according to the selection
option.
 If Create/Edit/Delete was selected, the file is imported and the trails in it are created, edited, or
deleted from the database and network, as relevant.
 If Associate/Update/Disassociate was selected, the file is imported and the trails in it are
associated, re-associated, or disassociated, as relevant (ASON association).
 For Check file format or Check trail integrity, checks the XML file structure validity or verifies
that trail creation is feasible, as relevant.
The Status pane shows the total number of trails processed and the number that processed successfully or
failed.
Clicking Abort at any time causes the operation to stop after the current trail is processed. An Importing
Failed message opens. The trails that completed processing up to that point will be imported.
Parent Topic
6.15.3 Exporting/Importing Traffic Entities via UNIX

This section describes a simplified trail, tunnel and service definition export/import to/from XML via UNIX.
This may include prescheduling using the UNIX crontab command.
NOTES:
 The import or export script must be run from the server side.
 Running of the export import script requires user authentication with a valid LightSoft
username and password.
 The import files must reside in the fixed directory NMSTrails.
 After the import script is run, an output log file is created within NMSTrails, where the
user can check the success of the process.
 The TrafficXMLUtility function described in this section supersedes the old
TrailExpImpUtility function formerly used for trail export/import.
To export/import trail definitions from XML files via UNIX:

 You can import XML files with the SetCrontab utility. The following is an example UNIX command line:
TrafficXMLUtility -import file_name -user user_name -passwd user_password
The following usage and options apply:

TrafficXMLUtility [-export output_file_name]

[-import input_file_name]
[-trail] [-tunnel] [-service]
[-user user_name] [-passwd user_password]
(The minimum specification includes, besides the user name and password, one of [-import file_name]
[-export file_name] and one of [-trail] [-tunnel] [-service]).
Where:
Command Description
-export output_file_name Indicates that the requested operation is export of all trails, tunnels, or
services.
Trails, tunnels and services each have their own directory:
~nms/NMSTrails, ~nms/NMSTunnels, or ~nms/NMSServices.
-import file_name Indicates that the requested operation is import of all trails, tunnels, or
services.
-service Indicates that the operation is performed on all services.
-trail Indicate that the operation is performed on all trails.
-tunnel Indicates that the operation is performed on all tunnels.
-user user_name User name required to run this application. Must be a defined LightSoft
user.
-passwd user_password Password required to run this application. Must be a defined password.
Examples:
 To import a service stored in the service.xml from a filename:
TrafficXMLUtility -imp filename.xml -service
 To export a tunnel to a filename in tunnel.xml:
TrafficXMLUtility -exp filename.xml -tunnel
Parent Topic

7 Synchronizing Trails
The trail synchronization process reconciles differences between trail definitions in LightSoft and in an EMS.
It is also used to acquire optical trails defined at the EMS level. See Optical Trail Acquisition by
Synchronization.
7.1 Trail Synchronization Concepts

Inconsistencies between the LightSoft database and EMSs can develop over time for a number of reasons,
such as:
 Trails were created in LightSoft while the EMS was down.
 Trails connecting NEs in two different sites are managed by different EMSs. Each EMS uses an external
element to connect with the other site, but LightSoft shows this trail as a direct connection between
the sites without external elements.
 Cross connects were defined or changed at the EMS or craft terminal level.
It is recommended to deal with new trail inconsistencies as they occur and to keep the number of
outstanding inconsistencies low.
Synchronization can be performed in an automated fashion for all selected trails, or manually per trail:
 Automatically, using the Trail Consistency Indicator (TCI) window, in one of two ways.
 Impose (reconnect) trails from the DB (LightSoft) to the network (EMS).
 Admit (acquire) trails from the network to the DB (LightSoft acquires the trails).
 Manually, perform synchronization on selected trails in the Trail Synchronization. After completing
and activating the changes (impose, admit, or delete trails), you can refresh information in the TCI
window to confirm that the inconsistencies were resolved, thereby indicating that the synchronization
process was successful.
Generally, SDH layer inconsistencies must always be synchronized. However, optical layer inconsistencies
may not require synchronization as they may be caused by unused channels for which cross connects have
been defined automatically at the EMS level.
The synchronization process is used to admit trails that do not conform to normal trail patterns (flex trails)
to LightSoft's Trail Management subsystem.
Parent Topic

LightSoft® User Guide Synchronizing Trails
7.1.1 Trail Synchronization Exceptions

Trail synchronization functionality is available in accordance with user permissions. (It is not available for
CNM users; see VPNs and CNMs in the Getting Started & Administration Guide.)
SDH and optical inconsistencies are treated in the following ways:
 SDH trails: Both link and SNC inconsistencies are flagged.
 Optical trails: By default, only detected link inconsistencies are flagged. SNCs are not flagged since
they are generally not relevant to optical trail management.
NOTE: If flagging of optical SNCs is needed, the default can be changed. Contact your local
Customer Support representative for assistance.
Inconsistencies are listed according to the following guidelines:

 The LP & ODU flag shows the aggregation of all LP-ODU link inconsistencies.
 Changes to the path type in OCH trails are not included in the TCI Details pane inconsistency counts
because these trails are not protected.
 A TCI inconsistency count is generated (rises by 1), when a topology link is created in LightSoft
between OTN ports.
 When the created link is between ports that terminate two trail layers (OCH and LP), the inconsistency
is generated only for the LP layer (not the OCH)and is cleared after an optical trail is created between
the ports. If the created trail happens to be unidirectional, the counter is still reduced by 1 (as if a
bidirectional trail had been created).
 Admitting a trail from the EMS to LightSoft is disallowed if:
 An MoT trail is traversed by tunnels or protected by bypass tunnels. The tunnels must first be
removed.
 A high order VC-4 server trail has low order MoT trails. The tunnels must first be removed.
 TCI does not remove an MoT trail if it has tunnels or bypass tunnels protecting it. To remove the MoT
trail, you must manually remove the tunnels.
 AoC and ROADM-related trail inconsistencies are not reflected in the TCI window counters or listed in
the window’s Selected Objects pane.
Parent Topic

7.1.2 OCH and LP Trail Creation and TCI Counts

Link creation or SNC differences generates a TCI count.
Topology Links and TCI Counts

 If OCH and LP trails span two link endpoints, then:
 When the link is created, only the OCH trail TCI flag rises by 1 (OCH being a server trail to LP).
 When the OCH trail is created (by TCI or top down), the OCH trail TCI flag declines by 1 and the
LP trail flag rises by 1.
 When the LP trail is created, the LP flag declines by 1.
 If one link endpoint is a trail endpoint and the other a trail "through" TP with fixed SNC (e.g. OCH trail
traversing a ROADM with through TP between CMBRs).
 If a unidirectional trail is created, the counter is still reduced by 1 as if it was a bidirectional trail.
Subnetwork Connection (SNC) Differences

The counter increases (red flag) if Expected SNC (in LightSoft trail) and Actual SNC do not match, because of
differences in either:
 DNs of the TPs
or
 SPO members
General Rules and Guidelines

 TCI count does not change if the network change causes an alarm and/or the link becomes
inconsistent.
 Red flag occurs for a loss of connectivity in the network (for example, an expected XC does not have an
Actual).
 Yellow flag occurs when LightSoft does not represent a XC that exists in the network (missing
Expected).
The following settings or changes do not change the TCI count even if they prevent top down trail creation:
 Change of lambda for a CTP or PTP
 FEC setting
 RZ setting
 Change of Protection Group
 Modification of the link protection external type
 Change of sink source partner
Parent Topic

7.1.3 Flex Trails

The process by which a LightSoft trail is reconstructed from connectivity entities acquired from the EMS
involves a “Classification” step which:
 Gets entities which are "connected" to each other or have the same Trail ID.
 Discovers paths (including improper/flex paths).
 Attempts to classify the entities according to rules regarding directionality, path type, path pattern,
trail rate, and protection type (DRI/DNI/Diverse routing/VCAT).
When the classification rules are satisfied a LightSoft-supported trail is created from the implied paths.
Non-classified (flex) trails do not conform to normal trail patterns dictated by the classification rules and do
not support regular LightSoft functionality. (A non-conformant service is equivalent to flex for trails; see
Service Non Conformance Reasons in the Supporting Information Supplement.)
The Show Highlighted Trail on Map option of the Trail Synchronization window shows the flex trail path in
a read-only version of the Create Trail window; see Trail Synchronization Window. It shows, the location of
discontinuities and the trail parameters. This tool allows you to investigate the source of the problem with
the trail.
A trail might be deemed flex for a number of reasons. For example, multiple XCs may not constitute a valid
trail due to lack of full connectivity between the endpoints. The Trail List window Trail Properties pane Flex
Reason parameter shows a short reason for a trail being classified as flex; see the parameter description in
Advanced Tab.
The following table lists the most common flex reasons, each with the code that is shown in the Flex
Reason parameter tooltip. The list is not all-inclusive. Contact your local Customer Support representative
for information about reasons not listed below, citing the reason code and message
Table 7-1: Typical Flex Reasons
Code Reason Message Description

58 OCH Trail terminates OCH trail EPs should be on line ports. Otherwise trail would be
prematurely in CTP classified as flex.
59 Mismatched EP rates (either Endpoints have inconsistent rates. OTN only issue.
OTUn or EPs containing CTP
rates)
201 Inconsistent XC in Protection A PG expects the protection type of available XCs to match the
Group PG’s TP protection type. A trail is flex if the path types of a XC and
an EP belonging to a revertive PG are inconsistent.
304 Common bidirectional EP, A TP should be related to only the main or the protection path. A
inconsistent path types trail is flex if a bidirectional TP is an EP in both main path and
protection path in opposite directions. The trail is not flex when
both paths have the same path type (for instance BOTH).
305 Trail only has a protection A protected trail should have both a main path and a protection
path, no main path path. A trail with only a protection path is flex.
320 Forward and backward EPs The trail path should have only one port endpoint in both
have different PTP owners directions.


321 Forward and backward EPs If one (or both) trail sides have two ports, the trail is flex.
have different CTPs
322 Forward and backward EPs SDH only issue. (Valid topology for UMEs.)
have different CTPs and the
same PTP owners
401 Paths have mixed Trail paths should all be classified as either unidirectional or
directionalities bidirectional. A trail with mixed path directionalities is flex. OTN
Only issue.
402 Main and protection path Trail main and protection path types must be matching pairs.
types are not all matching pairs Generally this means the number of main and protection VC paths
must be equal, but also requires specific main and protection path
to be compatible. If this is not the case, the trail is flex.
403 Path consists of a single XC A trail without at least one segment is flex. OTN only issue.
405 Inconsistent protection group Trail has two revertive PGs where the path type is not aligned.
OTN Only issue.
406 Main and Protection paths Trail’s main path has at least one protection XC. OTN Only issue.
have inconsistent protected XC
408 Unidir paths do not have same Unidirectional paths with the same path type should all share a
source EP common Src endpoint. If one or more of these paths have
different source endpoints, the trail is flex. OTN Only issue.
411 Inconsistent EP termination An EP’s termination mode should be appropriate to the
modes corresponding path. If the termination mode is unidirectional
while the path is bidirectional (or vice versa), the trail is flex.
Relevant only for terminated server trails (Terminated EPs without
XCs). SDH Only issue.
501 Inconsistent DRI found The number of forward and backward DRI bridges should be
equal. If not, the trail is flex.
502 Inconsistent DNI found Data trail DNI protection must be implemented on main and
protection VC paths with same VCG ports. If DNI is implemented
on main and protection VC paths that belong to different routes,
the trail is flex. SDH only issue.
503 MSP Linear server has MSP Linear protection cannot be implemented where both main
SNCP/DNI and protection paths also traverse the main and protection paths
of an SNCP or DNI protected segment.

504 TSI in working MSSPRING If the timeslot changes along an MS-SPRing working trail path because
of TSI, the trail is flex.
505 Kissing hybrid server A bidirectional LO trail cannot traverse two X/Y server trails that are
connected via their split-side endpoints.
506 Invalid SNCP found Discovered SNCP with same path type (main-main,
protected-protected).
507 Invalid diverse route found Discovered pseudo diverse route which has same EP’s as another one.
551 Untraversed points Some entities (XC/servers) were not used by classification. Sometimes
caused by invalid topology (missing XC).
553 Missing server EP- data Classification failed to define EPs of the server/segment. This may
conversion failed. happen if required server data could not be uploaded from the EMS.
555 Missing trail EP A trail EP was missed during classification (Internal processing error).
556 Read/Write Database Classification encountered a Database exception (Internal processing
error - specific request to error).
database failed.
557 Trail creation failed Trail creation failure. Sometimes a result of invalid topology
specification.
560 Inconsistent connect state Sink source partner EPs have inconsistent connection state.
of snk src partner EPs
561 Snk src partner conversion Possible problem with Sink Source partner (Internal processing error).
failed
562 SPO group is incorrect SPO group has incorrect configuration. Master index does not match
master SPO port.
580 Trail resource creation Trail resource map creation failed (Internal processing error).
failed.
Parent Topic

7.2 Accessing Trail Inconsistency Information

You can access inconsistency information can be accessed via the following LightSoft main window
indication and option:
 The Trail Consistency Indicator (TCI) counter in the main window shows the number of
inconsistencies in all trails or in SDH trails only (click the counter to toggle between total and SDH +
EMS counts). The color of the flag indicates the worst inconsistency condition of the trails in the
selected count. For the count behavior upon link and trail creation, see Trail Synchronization
Exceptions.
 Click Trail Consistency, to open the Trail Consistency Indication (TCI) window, where you can view
detailed information about inconsistencies, in the main window Trails tab.
The Trail Synchronization feature is composed of the following windows:
 TCI window: Begins the trail synchronization process, providing warning flags with colors according to
the type of detected inconsistencies and counters adding up the number of inconsistencies on each
layer. See Trail Consistency Indicator Window.
 Trail Synchronization window: Performs various synchronization actions, both directly and via several
floating windows displayed with it; see Trail Synchronization Window.
Parent Topic
7.3 Performing Trail Synchronization

Trail synchronization can be performed for trail inconsistencies associated with selected multilinks or
objects (MEs, LEs, UMEs, groups, EMSs), links in a multilink, or specific trails.
Automatic impose and admit actions apply only to "non-match" trails, with no overlap/part match relations
with any trail in a counterpart window:
 If a trail exists only in the network, Auto Admit causes it to be acquired to the DB.
 If a trail exists only in the DB, Auto Impose reconnects it to the network.
If any relation exists between the trails, a manual impose or admit action is required. Manual operations
are also useful if you want to examine trails before performing an operation. For more information about
trail relations, see Color Indications in Database and Network Trails Sequence.
Impose and Auto-Impose are enabled only if Monitor mode is not selected (that is, Master mode applies)
since those actions are traffic-affecting.
NOTE: The number of network trails that can undergo synchronization operations at one time
(impose from the DB to the network, whether automatic or manual, or delete from the
network) is limited for system performance reasons (default 64). If more are needed, multiple
cycles of the TCI process should be performed. It is also possible to configure a different limit.
(LightSoft DB operations are not limited.) For more information, contact your local Customer

Only one LightSoft client can perform trail synchronization at any given time.
To perform trail synchronization:

1. In the LightSoft main window, select the required technology layer.
2. Open the Trail Consistency Indicator (TCI) window showing all trail inconsistencies associated with:
a. Selected multilinks and/or objects:
 Select specific multilinks and/or objects in the main window map.
OR
Do not select anything in order to display all inconsistencies for the current layer.
 In the main window Trails tab, in the General group, click Trail Consistency.
OR
b. Selected links in a multilink:
 Right-click a topology link and select Expand to display the Actual Links between Two MEs
dialog box.
 Select the links.
 Right-click the Link Name cell of any link and select Trail Consistency.
OR
c. Select specific trails:
 In the Trail List window Trails pane:
Select the trails (the checkboxes) which you want to synchronize.
OR
Click the single trail (to highlight it) that you want to synchronize.
 In the Trail List window toolbar, click .

OR
Right-click either the highlighted trail or one of the selected (check marked) trails, and
select Trail Operations > Trail Consistency.
The Trail Consistency Indicator window opens; see Trail Consistency Indicator Window.
3. Use the flags and counters in the TCI Details pane to determine which layers have inconsistencies that
need synchronization. Select the layer in the dropdown list at the top of the Parameters pane.
4. Click Show Selected Objects to show a list of the trails; see Selected Objects Pane. To close the
pane, click .
5. In the Parameters pane, make your selections for Automatic trail synchronization operation; see the
Parameters Pane description options.
NOTE: Manual operations can be specified on a per-trail basis at a later step.

6. To synchronize only some of the inconsistencies, select the checkboxes in the list of trails. Otherwise,
leave all checkboxes blank. You can select all checkboxes by clicking Select All or clear all by
clicking Clear All .
7. Click Start . A confirmation dialog box opens.

8. Click Yes. The process begins. This may take several minutes. Progress indicators appear in the right
pane of the window.
NOTE:
Selecting Stop discontinues processing after the current trail is checked, providing results
for only trails processed up to that point and enabling decision-making concerning
inconsistent trails in that group.
Selecting Abort discontinues the entire operation and no results are provided.
When the process is completed (it may take some time), the Trail Synchronization window opens; see
Trail Synchronization Window.
9. (Optional) In the Trail Synchronization toolbar:
a. Click Monitor Mode to switch from Monitor to Master mode (the icon changes to Master
Mode , ready to switch back if required). Use Master mode to impose trails on or delete
trails from the EMS. A warning appears that this step is traffic-affecting.
b. Click OK to confirm.
10. In the DataBase Trails Sequence and Network Trails Sequence windows, select one or more trail
checkboxes.
TIP: You can select a trail in the Database or Network window and click Show on Map
to open a Create Trail window in read-only mode, where the trail is highlighted in the window
map and the trail parameter values are indicated; see the icon description in Trail
Synchronization Window.
11. Select one of the following manual synchronization operations, if needed:

a. In the DataBase Trails Sequence window, click:
 Impose selected trail to Network icon, to impose the trail in the EMS (Master mode
only).
OR
 Delete selected trail from Database icon, to delete the trail from the LightSoft
database.
OR

b. In the Network Trails Sequence window, click:
 Admit selected trails to Database icon, to admit the trail from the EMS to LightSoft.
OR
 Delete selected trails from Network icon, to delete the trail from the EMS (Master
mode only).
The selected trails are moved to the Queue window; see Queue Window. An icon in each row
indicates the synchronization option applicable to the trail.
12. Review the list of trails and actions in the Queue window. If required, select the checkbox next to a
trail and click to return it to its original window.
13. When you have completed the list of trails for synchronization, click Activate . The trails in the
Queue window are synchronized according to the selected actions. When the operations are
complete, an icon appears next to each trail:
- operation successful
- operation failed
- operation already been performed
14. To clear the Queue window, select one of the following toolbar icons:
- to clear successfully synchronized trails
- to clear unsuccessfully synchronized trails
- to clear all trails

As successfully synchronized trails are cleared from the Queue window, imposed trails are displayed
in the Imposed Trails List window and admitted trails are displayed in the Admitted Trails List
window.
15. Return to the Trail Consistency Indicator window and click Reload. The flag for the layer that was
synchronized appears green and the counter is reset to 0.
Parent Topic

7.3.1 Trail Synchronization Procedure

Only one LightSoft client can perform trail synchronization at any given time.
To perform trail synchronization:

1. In the LightSoft main window, select the required technology layer.
2. Open the Trail Consistency Indicator (TCI) window showing all trail inconsistencies associated with:
OR
Do not select anything in order to display all inconsistencies for the current layer.
 In the main window Trails tab, in the General group, click Trail Consistency.
OR
dialog box.
 Right-click the Link Name cell of any link and select Trail Consistency.
OR
c. Select specific trails:
 In the Trail List window Trails pane:
Select the trails (the checkboxes) which you want to synchronize.
OR
Click the single trail (to highlight it) that you want to synchronize.
 In the Trail List window toolbar, click .

OR
Right-click either the highlighted trail or one of the selected (check marked) trails, and
select Trail Operations > Trail Consistency.
The Trail Consistency Indicator window opens; see Trail Consistency Indicator Window.
3. Use the flags and counters in the TCI Details pane to determine which layers have inconsistencies that
need synchronization. Select the layer in the dropdown list at the top of the Parameters pane.
4. Click Show Selected Objects to show a list of the trails; see Selected Objects Pane. To close the
pane, click .
5. In the Parameters pane, make your selections for Automatic trail synchronization operation; see the
Parameters Pane description options.

NOTE: Manual operations can be specified on a per-trail basis at a later step.
6. To synchronize only some of the inconsistencies, select the checkboxes in the list of trails. Otherwise,
leave all checkboxes blank. You can select all checkboxes by clicking Select All or clear all by
clicking Clear All .
7. Click Start . A confirmation dialog box opens.

8. Click Yes. The process begins. This may take several minutes. Progress indicators appear in the right
pane of the window.
NOTE:
Selecting Stop discontinues processing after the current trail is checked, providing results
for only trails processed up to that point and enabling decision-making concerning
inconsistent trails in that group.
Selecting Abort discontinues the entire operation and no results are provided.
When the process is completed (it may take some time), the Trail Synchronization window opens; see
Trail Synchronization Window.
9. (Optional) In the Trail Synchronization toolbar:
a. Click Monitor Mode to switch from Monitor to Master mode (the icon changes to Master
Mode , ready to switch back if required). Use Master mode to impose trails on or delete
trails from the EMS. A warning appears that this step is traffic-affecting.
b. Click OK to confirm.
10. In the DataBase Trails Sequence and Network Trails Sequence windows, select one or more trail
checkboxes.
TIP: You can select a trail in the Database or Network window and click Show on Map
to open a Create Trail window in read-only mode, where the trail is highlighted in the window
map and the trail parameter values are indicated; see the icon description in Trail

11. Select one of the following manual synchronization operations, if needed:

a. In the DataBase Trails Sequence window, click:
 Impose selected trail to Network icon, to impose the trail in the EMS (Master mode
only).
OR
 Delete selected trail from Database icon, to delete the trail from the LightSoft
database.
OR
b. In the Network Trails Sequence window, click:
 Admit selected trails to Database icon, to admit the trail from the EMS to LightSoft.
OR
 Delete selected trails from Network icon, to delete the trail from the EMS (Master
mode only).
The selected trails are moved to the Queue window; see Queue Window. An icon in each row
indicates the synchronization option applicable to the trail.
12. Review the list of trails and actions in the Queue window. If required, select the checkbox next to a
trail and click to return it to its original window.
13. When you have completed the list of trails for synchronization, click Activate . The trails in the
Queue window are synchronized according to the selected actions. When the operations are
complete, an icon appears next to each trail:
- operation successful
- operation failed
- operation already been performed

14. To clear the Queue window, select one of the following toolbar icons:
- to clear successfully synchronized trails
- to clear unsuccessfully synchronized trails
- to clear all trails

As successfully synchronized trails are cleared from the Queue window, imposed trails are displayed
in the Imposed Trails List window and admitted trails are displayed in the Admitted Trails List
window.
15. Return to the Trail Consistency Indicator window and click Reload. The flag for the layer that was
synchronized appears green and the counter is reset to 0.
Parent Topic
7.3 Performing Trail Synchronization
7.4 Trail Consistency Indicator Window

The trail synchronization process begins in the Trail Consistency Indicator window; see Performing Trail
Synchronization.
The window displays warning flags with colors according to the type of detected inconsistencies and
counters that total the number of inconsistencies at each layer. The color of the flag reflects the worst
inconsistency condition in that layer. For more details, see Trail Consistency Indicator Use Cases.
Figure 7-1: Trail Consistency Indicator window

Table 7-2: Trail Consistency Indicator toolbar

Start Starts process on selected trails.
Stop Stops process. The operation continues on the trails processed up to

that point, providing results for these and enabling decisions to be taken
concerning inconsistent trails in that group.
Abort Aborts process. The entire operation stops at once and no results are
provided.
Show Selected Opens Selected Trails pane that lists the trails selected when the TCI
Objects window was opened for consideration for the Synchronization process.
Close Show Closes Selected Trails pane.
Selected Objects
Refresh Reloads the trails in the list of trails.
Select all trails Selects (checkmarks) all the trails in the currently selected window.
Clear all trails Clears all the trails in the currently selected window.
Close Closes the Trail Consistency Indicator window.
Parent Topic
7.4.1 TCI Details Pane

The TCI Details pane displays the number and severity of inconsistencies between the LightSoft DB and the
network, and includes counters for inconsistencies in each layer including the optical layer (OMS, OCH, and
LP) and SDH layer server and client trails.
The EMS counter shows red flags displayed in an EMS because of an inconsistency between the EMS and
the NE it manages. Any inconsistency flagged should be resolved in the corresponding EMS.
Each layer counter has an associated flag with the following color coding:
 Red: Critical inconsistency.
 Yellow: Warning - less severe inconsistency, such as cross connects existing in the network that are
not used by the trails managed by LightSoft.
 Green: No inconsistency.
The following are the possible indications of each flag color. For more specific use cases applicable to each
topology layer, see Trail Consistency Indicator Use Cases.

Table 7-3: Indications of warning flags
Color Possible indications

SDH trails
Red Any of the following:
 Inconsistency of timeslots in Subnetwork Connections (SNCs)
 Trail SNCs existing only in LightSoft
 Not all SNCs were created successfully in the EMS
 Inconsistency of termination mode of VC-4
 Red flag in EMS-SYNCOM
Yellow Any of the following:
 Mismatch of path types (main or protection)
 SNCs existing in the network/EMS but not in LightSoft, or in the EMS but
not in LightSoft
Optical trails
Red Topology links exist in the OTN layer but have no trails defined on them.
Yellow All other cases related to SNC inconsistencies. This includes SNCs existing only
in the network.
Parent Topic
7.4.2 Parameters Pane

The Parameters pane enables you to define the synchronization process. Select the layer in which to
perform synchronization from the dropdown list or click the flag. Then select one or more of the following
checkboxes:
 Auto Admit Classified: Automatically adds standard pattern network trails not previously in the
database to LightSoft.
 Auto Admit Flex: Automatically adds network trails that have a nonstandard pattern to LightSoft.
 Auto Impose Classified: Automatically imposes to the network LightSoft-standard pattern trails not
previously in the network. Available only when Monitor Mode is not selected.
 Auto Impose Flex: Automatically imposes to the network trails whose pattern is not supported by
LightSoft. Available only when Monitor Mode is not selected.
 Auto Impose Trail Attributes: Automatically imposes to the network changes to trail attributes
defined in LightSoft. Available only when Monitor Mode is not selected. These changes are considered
minor and are not traffic-affecting.

 Use Connectivity Only:

 When selected, builds trails according to connectivity only. This is generally recommended for
TCI on most trails as it results in better performance and does not require rigorous trail
management.
 When not selected, builds trails according to connectivity and also merges by trail ID. This is
useful when multiple cross connects share the same trail ID and do not have connectivity with
all parts of the trail. Trails with no connectivity (for example, protected trails with no SNCP
point) as well as some optical trails/X diverse protected trails, should be run with an acquisition
process by deselecting this option.
 Monitor Mode: When selected, prevents trails from being imposed on the network. Trails can,
however, be imported (admitted) from the network into LightSoft.
Parent Topic
7.4.3 Selected Objects Pane

The Selected Objects pane of the Trail Consistency Indicator window lists the trails that had been selected
in the Trail List window when the Trail Consistency Indicator window was opened from that window. Trails
that you now select in the Selected Objects pane will be considered by the synchronization process. To
open the Selected Objects pane, click Show Selected Objects in the Trail Consistency Indicator
window toolbar. (To close the pane, click Hide Selected Objects .)
Figure 7-2: Trail Consistency Indicator window - Selected Objects pane

The full range of column information is described below. The columns displayed can be varied as required.
For more information, see Getting Started Guide.
Figure 7-3: Selected Objects pane
Table 7-4: Selected Objects pane of Trail Consistency Indicator window
Column Description
# Ordinal number of trail in the list.
Trail selection checkbox, used to select trails for synchronization.
Trail ID System ID for the trail, for example, "36(38)", formatted as:
 Unique ID Number – ID of the trail, sequentially assigned in the trail creation
process.
 Managed System ID – ID of the management system in which the trail was created
(EMS or LightSoft).
Description Free text description of the trail.
Object Name of the object that generated the inconsistency condition.
Severity Level of disruption that could result from the inconsistency:
 Indeterminate - Gray (initial value when inconsistencies are not yet indicated for
this layer)
 Critical - Red
 Minor - Orange
 Warning - Yellow
 Cleared - Green
Cause Probable cause of the inconsistency.
Detected At Time that the inconsistency was detected.
Comments Free text description of the trail.
Parent Topic

7.5 Trail Synchronization Window

The operations that you can perform in the Trail Synchronization window depend on the current mode. By
default, the window opens in Monitor mode, allowing trails to be admitted to LightSoft but preventing
them from being deleted from the network or imposed on it. This is done to prevent accidental
traffic-affecting changes to functioning trails.
Figure 7-4: Trail Synchronization window
Trails in the DB window may have counterparts in the network window which are exactly matching,
partially matching, or overlapping. When you select a trail in one window (DB or network), the
corresponding trail in the other window is highlighted with a color that indicates the relation between the
trails. Different treatment is required according to the condition implied by the color. For more details, see
Color Indications in Database and Network Trails Sequence.
Table 7-5: Trail Synchronization window toolbar

Path
Selects the path (route) type whose attributes will be viewed: Main,
Protection, or Both.
Tool Windows Opens a dropdown list of page arrangement options, as well as
options to hide/show specific floating windows.
Show highlighted trail on Opens a new Create Trail window in read-only mode where the trail
map that you selected in the Database or Network window. The trail
parameter values are indicated. As well, the trail path is highlighted
in the window map, indicating the location of discontinuities which
caused the trail to fail.


Monitor/Master mode Switches from Monitor to Master mode (the icon changes to Master
(toggle)
Mode ready to switch back, if required). Use Master mode to
impose trails on or delete trails from the EMS.
Impose selected trail to Imposes the trails selected in the Database Trails Sequence window
Network in the EMS (Master mode only).
Delete selected trails Deletes the trails selected in the Database Trails Sequence window
from Database from the LightSoft database.
Admit selected trail to Admits the trails selected in the Network Trails Sequence window
NMS from the EMS to LightSoft.
Delete selected trail Deletes the trails selected in the Network Trails Sequence window
from Network from the EMS (Master mode only).
Select all trails Selects (checkmarks) all the trails in the currently selected window.
Clear all trails Clears all the trails in the currently selected window.
Activate Synchronizes the trails in the Queue window according to the
selected actions.
Undo trails from queue Removes selected trails from the Queue window to the window that
it came from.
Clear all ok trails from Clears successfully synchronized trails from the Queue window.
the queue
Clear all error trails from Clears unsuccessfully synchronized trails from the Queue window.
the queue
Clear queue Clears all trails from the Queue window.
Parent Topic

7.5.1 Floating Windows

The Trail Synchronization window includes floating windows used in the synchronization procedure. These
are accessed by clicking Tool Windows to open a dropdown list of page arrangement options and
other options to hide or show specific floating windows. To display a window, select its checkbox in the
dropdown list.
Information about listed trails shown in the floating windows (except the Events List window) is described
in the following table.
Table 7-6: Trail Synchronization floating window columns
Column Description
Trail selection checkbox for selecting trails for some operations (described in context).
Other trail operations apply only to highlighted trails. A highlighted trail is the focus for
information shown in the Trail List window panes.
NMS ID Trail identifier.
Trail ID System ID for the trail, for example, 36(38), formatted as:
 Unique ID Number – ID of the trail, sequentially assigned in the trail creation
process.
 Managed System ID – ID of the management system in which the trail was created
(an EMS or LightSoft).
Label User-defined label for the trail.
Customer Customer associated with the trail.
Type  P2P - standard point-to-point trail with full connectivity between endpoints.
 X - "X" pattern trail, involving four endpoints.
 Y - "Y" pattern trail, involving three endpoints.
 DR - diverse routes.
 Flex - multiple cross connects that do not constitute a valid trail due to the lack of
full connectivity between endpoints.
Parent Topic
7.5 Trail Synchronization Window

7.5.1.1 Database and Network Trails Sequence Windows

Two windows contain information about inconsistencies:
 The DataBase Trails Sequence window (DB window) displays trails found in the LightSoft database.
The network may have similar or overlapping trails.
Figure 7-5: DataBase Trails Sequence window
 The Network Trails Sequence window (Network window) displays trails found in the network.
LightSoft may have similar or overlapping trails.
Figure 7-6: Network Trails Sequence window
In general, when a trail exists in one window but not in the other:
 If the network trail is missing, the DB trail should be imposed.
 If the DB trail is missing, the network trail should be admitted.
In these cases, automatic impose and admit operations are possible; see Performing Trail Synchronization.
If a trail is present in both the network and the DB, and the trails are not exactly equivalent (see Color
Indications in Database and Network Trails Sequence), they must be synchronized through manual impose
and admit actions.
Parent Topic
7.5.1.1.1 Color Indications in Database and Network Trails Sequence

Trails in the DB window may have counterparts in the network window which are exactly matching,
partially matching, or overlapping. When you select a trail in one window (DB or network), the
corresponding trail in the other window is highlighted with a color that indicates the relation between the
trails. Different treatment is required according to the condition implied by the color.
 Green: The trails are exactly equivalent, exactly matching in all their cross connects and no
synchronization action is needed.
 Yellow: The DB trail has more XCs than the network trail ("Part match" relation) and should be
imposed on the network. (The XCs that are common to the trail in DB and network are otherwise
exactly matching, with the same port configurations.)

The example in Database and Network Trails Sequence windows show a selected DB trail and the
corresponding network trail with a yellow indication, suggesting that the DB trail should be imposed.
NOTE: When XCs of a network trail are missing from one NE and not the other, the trail must
be imposed manually. (In this case the Automatic Impose action will not impose the trail.)
 Blue: Some XCs common to the trail at both network and DB are configured differently ("Overlap"
relation), for example, having different ports. The number XCs in each trail is not relevant. Blue may
also mean the DB trail has less XCs than the network trail.
In this case, the user must investigate further to determine which version of the trail is preferred (for
example, whether one trail is classified), and to impose admit, accordingly.
Parent Topic
7.5.1.1 Database and Network Trails Sequence Windows
7.5.1.2 Imposed and Admitted Trails List Windows

The Imposed Trail List and Admitted Trails List windows contain information about the results of trail
synchronization.
Figure 7-7: Admitted Trails List window
The Imposed Trail List window displays trails imposed on the network by LightSoft.
The Admitted Trail List window displays trails admitted by (acquired into) LightSoft from the network.
NOTE: When using the automatic admit and impose options in the Trail Consistency Indicator
window, no additional synchronization operations are needed. The results of these automatic
actions can be confirmed in the Imposed Trails List and Admitted Trails List windows.
Parent Topic
7.5.1.3 Queue Window

The Queue window is used for the synchronization process itself. It displays the trails selected in the
DataBase Trails Sequence and Network Trails Sequence windows which you want to synchronize; see Trail
Parent Topic

7.5.1.4 Events List Window

The Events List window displays information about problems that may be encountered in the
synchronization process; see Trail Synchronization Window.
Table 7-7: Events List window fields

Field Description
Type Type of event: Info, Warning, or Error (includes a graphical representation of the
respective type).
Date Date of the event.
Time Time of the event.
Info Short description of the event, for example, "Completion Aborted".
Description Detailed information of the event (when available), for example, "Insert element into
topology link" or "Create group <Group Name>".
NOTE: The completion message windows which appear at the end of an operation (whether
successful or not), provide detailed operational results information. Click Operational Results
Info in the Trail List window toolbar to revisit these results for operations that were not
completely successful. For more information, see Performing Trail Operations.
Parent Topic
7.6 Trail Consistency Indicator Use Cases

This section describes TCI inconsistency use cases applicable to all topology layers. The Trail layer
represents the type of cross connect. To switch layers, select the relevant Parameters pane dropdown list
option. When a red or yellow flag appears in the TCI window TCI Details pane, click the flag (the applicable
layer is automatically selected in the Parameters pane dropdown list) and click Show Selected Objects
to display the associated objects in the Selected Objects pane; see Trail Consistency Indicator
Window. The following table shows the possible inconsistency causes and their corresponding use cases.
Table 7-8: Trail consistency use cases - optical trail layer

Use case Flag color Suggested action
Inconsistency source: SNC
All or some XCs are in the LightSoft DB but not in Red Reconnect
the EMS DB.
There are XCs in both the EMS(s) and LightSoft DBs Yellow Reconnect
but with different path types (main, protection, or
both).
Inconsistency source: Link
Link is not synchronized. Yellow Acquisition

Table 7-9: Trail consistency use cases - SDH trail layer

Inconsistency source: SNC
All XCs are in the EMS(s) DB but not in the LightSoft Yellow Acquisition
DB.
All or some XCs are in the LightSoft DB but not in Red Reconnect
the EMS(s) DB.
The EMS DB contains more/different XCs than the Red Acquisition
LightSoft DB.
There are XCs in both the EMS(s) and LightSoft DBs Yellow Reconnect
but with different path types (main, protection, or
both).
There are XCs in both the EMS(s) and LightSoft DBs Red Reconnect
but with different VC-4s.
Inconsistency source: CTP
There are XCs in both the EMS(s) and LightSoft DBs Red Reconnect
but with different VC-4s.
The endpoint XCs exist in both the EMS(s) and Yellow Reconnect
LightSoft DBs but with different path types (main,
protection, or both).
The endpoint XCs exist in both the EMS(s) and Red Reconnect
LightSoft DBs but with different terminations
(termination mode: sink, source, or both).
Table 7-10: Trail consistency use cases - unidentified trail layer

Inconsistency source: EMS
EMS is not synchronized. Red In EMS-SYNCOM, run Trail
Reconstruction
Parent Topic

8 Provisioning MPLS Tunnels
This section describes how to create MPLS tunnels, which are the infrastructure for Ethernet services. The
procedures and features described pertain to MPLS networking, involving the broad range of compatible
equipment over a global MPLS layer topology.
NOTE: You can define how tunnels are created in LightSoft, the fields visible in various
parameter windows, and how PF ranks the various optimization criteria when creating a new
tunnel (see Tunnel Creation Management Preferences in the Getting Started & Administration
Guide).
LightSoft's highly integrated MPLS layer network topology, called 1Net, interconnects the range of
supported PEs under a single global MPLS layer domain connected by Label Switched Path (LSP) tunnels.
Due to network size limitations, PEs previously resided in disconnected MPLS networks (see Global MPLS
Layer).
Label switching enables different equipment with varying label ranges to coexist in a single network.
LightSoft also supports hybrid networks that include both static MPLS-TP and dynamic IP/MPLS regions. A
signaling gateway connects pseudowires across both static and dynamic regions.
H-VPLS functionality makes a large hierarchical network scalable by reducing the number of MPLS tunnels
required for a service to operate. Service endpoints do not all have to be connected by direct tunnels, so
significantly fewer tunnels and pseudo-wires are needed, compared to traditional full tunnel mesh
configurations.
OPTIONAL FEATURE: The Tunnel provisioning mechanism is subject to the ETH/MPLS layer
being enabled, which is an optional feature. If not purchased, the functionality and related
menu options are unavailable.

LightSoft® User Guide Provisioning MPLS Tunnels
8.1 MPLS Tunnel Concepts

LightSoft supports MPLS tunnels as part of its Virtual Private LAN Service (VPLS) management package.
VPLS enables connectivity for customer Ethernet sites geographically dispersed across a provider as if they
were connected with a LAN. The interconnected customer sites form an MPLS VPN.
The following figure shows three customer edge (CE) sites connected via a provider's MPLS VPLS network
comprising provider edge (PE) sites (Provider transit equipment is within the MPLS-PE perimeter). The CEs
communicate using standard Ethernet bridging and MAC learning as if they are all on a single LAN.
Figure 8-1: MPLS overview
Packet forwarding is enabled by a full mesh of MPLS (LSPs) or tunnels between the PE sites. Forwarding
over the tunnels is facilitated by label switching.
Parent Topic
8.1.1 Label Switching

Label switching capability on P2P tunnels enables different equipment with varying label ranges to coexist
in a single network. Labels received from other equipment will always be in the expected label ranges.
While P2P tunnels provide label switching support, P2MP tunnels continue to have a single label.
Label Switched Path (LSP)

A Labeled Switched Path (LSP) is a path created by the concatenation of one or more label switched hops,
allowing a packet to be forwarded by swapping labels from one MPLS node to another. LightSoft assigns a
free MPLS label at each PE along the LSP path.
When a customer Ethernet packet enters a tunnel, the source PE adds two MPLS labels to the packet:
 Virtual Circuit (VC) label , representing the VPN to which the packet belongs.
 Tunnel label , representing the tunnel to which the packet is mapped.

Based on the labels, the Destination PE determines that it is the tunnel destination (Tunnel label) and finds
out the packet VPN (VC label). It then removes the two MPLS labels and forwards the packet to the CE
port(s).
Figure 8-2: Illustration of label switching
Working P2MP LSPs and their subtunnels use a single label throughout the tunnel path. Label assignment
rules are maintained although no label swap is performed.
Parent Topic
8.1.2 P2P and P2MP Tunnel Types

A P2P tunnel originates at a source PE, traverses defined transit Ps, and terminates at a destination PE. The
following figure illustrates the label switching that facilitates the packet forwarding along the tunnel path.
Figure 8-3: P2P tunnel
A P2MP tunnel is comprised of subtunnels, each starting at the same source PE and ending at different
destination PEs. It involves a tree-and-branch structure where packet replication occurs at branching points
along the tree (P1 in the following figure).
Figure 8-4: P2MP tunnel
The subtunnels may share a branch (a link), enabling forwarding only one packet copy to that link. This
scheme can achieve high multicast efficiency since only one copy of each packet ever traverses an MPLS
link.
The P2MP tunnel in the figure shows the source PE (PE1), transit equipment (PE2 and P1), and destinations
(PE3 and PE4).
This tunnel has three subtunnels to PE2, PE3, and PE4, respectively, all sharing the link from PE1 to P1.
Therefore, only one packet copy is sent on that link.
Parent Topic

8.1.3 Underlying Link Types

The following types of links can be used as servers to support MPLS tunnels:
 MoE physical link
 MoT virtual link (MoT trail)
 IC-MoE (intercard MoE)
 MoF
 MoG (MPLS over GRE)
 MoE virtual link (LP trail)
You can provision Ethernet traffic (MPLS tunnels and Ethernet services) over WDM topology using
LightSoft. Ethernet/MPLS data networks can include path segments in which direct physical connections are
impractical because of distance or need for aggregation. In such cases, optical WDM segments are included
in the data network.
Data services run between two Ethernet or MPLS ports with the endpoints residing in the relevant data
layer. To provision Ethernet Traffic over WDM topology, a LP trail must be provisioned between the
endpoints. The LP trail is displayed as a virtual link in the Ethernet/MPLS layer. This ensures a consistent
logical Ethernet/MPLS link, whether or not the link includes underlying optical segments, and enables easy
navigation between the Ethernet/MPLS network layer and the underlying WDM network.
Parent Topic
8.1.4 Tunnel Mode

Tunnels can be configured in L-LSP or E-LSP modes, according to the desired traffic classification behavior
and as permitted by equipment. For this information, see:
 Capability LSP parameter in LE Properties - MPLS PE LE Properties.
 Supported Tunnels parameter in Link Properties - General Tab.
L-LSP (Label Only-Inferred LSP)

The L-LSP tunnel mode assigns each traffic class to a different tunnel. L-LSP tunnels are characterized by:
 A single CoS, inferred from the MPLS label (LSP Inlabel)
 Color, inferred from EXP bits
E-LSP (EXP-Inferred LSP)

The E-LSP tunnel mode enables different traffic classes (e.g., VoIP, video, HS Internet) to coexist on the
same tunnel. One common E-LSP tunnel can serve multiple traffic needs. E-LSP can transport up to eight
CoS values, making it more scalable than the L-LSP single CoS. E-LSP is the more common way of building
MPLS infrastructure and facilitating interworking between equipment.

Each CoS value is assigned its own color. The color of each CoS is inferred from EXP bits (the MPLS label is
not involved). The following figure illustrates an E-LSP with three CoS values:
 CoS0 with Yellow color
 CoS3 Green and Yellow colors
 CoS7 with Green color
Figure 8-5: E-LSP tunnel example
Bidirectional Tunnels
MPLS-TP bidirectional tunnels transport MPLS-TP traffic in both directions over E-LSP tunnels. These
tunnels are co-routed, meaning that the traffic in each directions is transmitted over the same path route,
through the same set of links and ports. Bidirectional tunnels enable important features such as MPLS-TP
tunnel OAM, based on Bidirectional Forwarding Detection (BFD), and fault management tools such as
Alarm Indication Signal (AIS), supporting Link Down Indication (LDI) functionality.
NOTES:
 Signaling is another possible tunnel mode. A signaled link can be created between
signaled ports is visible in the topology. Signaled links and ports are relevant for CESR
equipment and STMS.
 Depending on the network configuration, tunnel modes may be configured as:
 E-LSP (E)
 L-LSP (L)
 Signaled by LDP/RSVP (S)
 Any combination (LE, LS, ES, LES)
Parent Topic

8.1.5 Virtual RSVP Tunnels

LightSoft supports hybrid networks that include both static MPLS-TP and dynamic IP/MPLS regions. A
signaling gateway (Sig-GW) is used to connect MPLS-TP PWs with IP/MPLS PWs across a VSI.
The following figure illustrates a simple hybrid network with MPLS-TP and IP/MPLS regions. Tunnel T1 as
drawn in this figure can be either an MPLS-TP or RSVP-TE tunnel.
Figure 8-6: Hybrid network including both MPLS-TP and IP-MPLS regions

Typical service cases in a hybrid MPLS network are illustrated in the following figure:
 Service S1 uses one PW to pass through an MPLS-TP tunnel.
 Service S2 uses one PW to pass through an RSVP-TE tunnel.
 Service S3 uses one PW to pass through an RSVP-TE tunnel and then another PW to pass through the
MPLS-TP tunnel, switching regions at the Sig-GW PE.
Figure 8-7: Service case examples in hybrid network
LightSoft does not manage the IP/MPLS cloud directly; STMS does. LightSoft works at the level of Virtual
RSVP tunnels, virtual aggregates representing groups of RSVP-TE tunnels. All RSVP-TE tunnels originating at
one MPLS PE and terminating at another PE are represented in LightSoft by a single Virtual RSVP tunnel.
Virtual RSVP tunnel endpoints (tunnel source and destination PEs and service endpoints) are represented in
LightSoft by CESR MEs and VNEs (see Working with VNEs). Tunnel endpoints may both be VNEs, or CESR
MEs, or one of each, depending on the network configuration (see Configuring Virtual RSVP Tunnels).
Virtual RSVP tunnels are created using STMS or StubEMS, working through the LightSoft GCT. Virtual RSVP
tunnels are always P2P tunnels in E-LSP mode, and support P2P, MP2MP, P2MP, Freeform, VLAN Tree, and
CES PB MP2MP services created top-down through LightSoft.
Parent Topic

8.1.6 FRR Tunnel Protection

The Fast Reroute (FRR) protection mechanism protects a tunnel against link or node failure along its path. A
predefined unidirectional bypass tunnel goes around the failed link/node and remerges with the original
tunnel path at a downstream MPLS switch.
The following figures show a tunnel from PE1 to PE2 to PE3, with node protection at PE1. The standard
label switching mechanism described in Label Switching is extended - switching to a bypass tunnel involves
pushing a third MPLS tag (called FRR label ) into the packet, and removing it when the bypass tunnel
remerges with the original tunnel path.
Figure 8-8: FRR tunnel protection
A main advantage of FRR over other protection schemes (such as end-to-end protection) is speed of repair:
predefined bypass tunnels and fast physical layer-based failure detection enable FRR to provide sub-50
msec switching time, comparable to SDH protection mechanisms.
Any number of tunnels can be protected by one bypass tunnel – limited only by resource CAC
considerations; see CAC for MPLS Tunnels. This bypass tunnel scalability is also known as Facility FRR.
Switching from protected to bypass tunnels and reversion back to protected tunnels can be configured to
apply automatically upon failure of the protected port, and/or forced. For details, see the FRR Mode and
Reversion parameters in Link Properties - TE Other Tab.
The timing of FRR switching to protection or back to the protected tunnel can be configured to avoid
premature or too frequent switching (see the Hold-off time and Wait-to-restore time parameters in Link
Properties - TE Other Tab).
Parent Topic

8.1.6.1 FRR Protection Types

FRR is configured with respect to links and/or nodes. The MPLS switch upstream from the failure reroutes
the protected tunnel traffic to a bypass tunnel, which then merges with the original tunnel at the next hop
(NH) and/or the next next hop (NNH) for all MPLS switches, as follows:
 Link protection: Merges at the MPLS switch at the NH node; see FRR Link Protection.
 Node protection: Merges at the MPLS switch at the NNH node; see FRR Node Protection.
 Dual FRR protection: In a P2MP environment, merges at the NNH (or another node) to provide node
protection, and then hops back to the NH node to provide Link protection. In a P2P environment, Dual
FRR provides simple link protection. See Dual FRR for Link and Node Protection.
 Enhanced FRR protection: Protects against a series of concurrent failures within a ring; see Enhanced
FRR Protection.
Note that all bypass tunnels are by definition unidirectional.
Parent Topic
8.1.6.2 FRR Link Protection

The following figure shows a tunnel through the MPLS switches P1 to P2 to P3, where link protection is
applied between P1 and P2.
If P1 detects that the link to P2 failed, it switches the tunnel traffic to the link-protecting bypass tunnel. The
bypass tunnel remerges with the protected tunnel at the next hop (NH) node P2. If a link fails (say on
subtunnel S1), the MPLS switch upstream from it (P1) redirects traffic through a bypass tunnel whose
destination is the NH (P2).
Figure 8-9: FRR link protection
A bypass tunnel may be shared by both P2P and P2MP tunnels. The figure below shows a P2MP tunnel with
link protection from P1 to P2, where the traffic continues towards tail destinations PE3 and PE4.
Figure 8-10: FRR link protection for P2MP
Parent Topic

8.1.6.3 FRR Node Protection

The following figure shows a tunnel through the MPLS switches P1 to P2 to P3, where link protection is
applied between P1 and P2.
If P1 detects that the link to P2 failed, it switches the tunnel traffic to the link-protecting bypass tunnel. The
bypass tunnel remerges with the protected tunnel at the next hop (NH) node P2. If a link fails (say on
subtunnel S1), the MPLS switch upstream from it (P1) redirects traffic through a bypass tunnel whose
destination is the NH (P2).
Figure 8-11: FRR node protection
A bypass tunnel may be shared by both P2P and P2MP tunnels. The figure below shows a P2MP tunnel with
link protection from P1 to P2, where the traffic continues towards tail destinations PE3 and PE4.
Figure 8-12: FRR node protection for P2MP
NOTE: Node protection also provides link failure protection. If node protection is selected,
LightSoft tries to protect every node (MPLS switch) along the tunnel path. When this is not
possible (for example, on the last link of the tunnel if the destination PE fails), LightSoft tries to
provide link protection. Thus, a tunnel may have node protection at some hops and link
protection at others.
Parent Topic
8.1.6.4 Simple Node and Link Protection

A tunnel cannot be assigned both link and node protection at the same hop (i.e. link protection from P1 to
P2 and node protection from P1 to P3. The following configuration is not allowed:
Figure 8-13: Link and node protection at same hop not allowed

An exception occurs for P2MP tunnels when dual FRR protection is applied. Dual FRR can be used to
provide standard link protection for P2P tunnels (from P1 to P2), and in this case is permitted with standard
node protection from P1 to P3.
Figure 8-14: Dual FRR for link protection
However, the general use case for Dual FRR is to provide node and link protection to P2MP tunnels; see
Dual FRR for Link and Node Protection.
Parent Topic
8.1.6.5 Dual FRR

IPTV applications are characterized by P2MP tunnel drop-and-continue nodes, where termination and
through tunnels coexist on overlapping links. Link or node protection alone is insufficient to protect against
interruption to through traffic.
Figure 8-15: P2MP tunnel drop-and-continue nodes
Link protection can be defined to protect subtunnel S1, finishing at P2. In the event of a break on the link P1
to P2, the continuing traffic on the through tunnel S2 is not protected. Similarly, node protection alone at
P3 does not protect the through traffic interrupted between P1 and P2. Two bypass tunnels protecting the
same link is not supported.
For P2MP tunnels, the Dual FRR feature enables you to define a "point to dual point" bypass tunnel:
 A transit drop point at the penultimate hop (P3).
 A tail drop point at the ultimate hop (P2).
The bypass tunnel effectively provides link protection to subtunnel S1 and node protection to subtunnel S2.
Figure 8-16: Dual FRR example 1

Figure 8-17: Dual FRR example 2
NOTE: Dual FRR is generally used to provide node and link protection to P2MP tunnels, but
yields only simple link protection in the case of P2P tunnels. Used in this way, Dual FRR can
provide link protection together with standard node protection from the same Head node,
which is usually not allowed with regular link and node protection.
Parent Topic
8.1.6.6 Enhanced FRR Protection

When working with enhanced FRR (eFRR), each eFRR bypass tunnel protects a segment that includes
multiple consecutive nodes and links along the path of the working traffic tunnel.
The MPLS switch upstream from the failure(s) reroutes the protected tunnel traffic to an eFRR bypass
tunnel, which then merges with the original tunnel at the end of the segment. Protection is thereby
provided even in the event of multiple failures of nodes and links in the segment along the path of the
working tunnel.
The following figure demonstrates the differences between a link bypass tunnel protecting against a single
link failure between PE4 and PE5, a node bypass tunnel protecting against a failure in node PE4, and an
eFRR bypass tunnel protecting against a failure in any of the nodes or links along the protected segment,
including PE3, PE4, and the links between PE2, PE3, PE4, and PE5.
Figure 8-18: eFRR bypass configuration
eFRR protection improves on the efficiency and BW utilization of standard FRR, efficiently maintaining
traffic flow and providing protection against more simultaneous failures while requiring less BW allocation
for the bypass tunnels. The following figures illustrate some of the advantages of eFRR protection.

The following figure demonstrates how eFRR protection avoids the wasted BW required by a traditional
node bypass tunnel that runs all the way around the ring back to the other side of the failed node (PE1),
even though the actual traffic destination is at PE5.
Figure 8-19: eFRR protects without wasting BW
The following figure demonstrates how eFRR protects against multiple simultaneous node failures in the
ring.
Figure 8-20: eFRR protects against multiple simultaneous node failures

The following figure demonstrates how eFRR protects against two simultaneous failures in two tunnel
segments.
Figure 8-21: eFRR protects against two simultaneous failures in two tunnel segments
eFRR bypass tunnels can also be created as standalone tunnels, available for future use to provide
protection for working tunnels.
OPTIONAL FEATURE: Enhanced FRR protection is a fully integrated add-on capability,

available on a cost basis. If not purchased, this feature and related menu commands are
unavailable.
Parent Topic
8.1.7 CAC for MPLS Tunnels

Connection Admission Control (CAC) for MPLS tunnels ensures there is enough bandwidth on an MPLS link
to create a further tunnel and still provide the expected QoS for all connections. Tunnel CAC supplements
Ethernet service CAC mechanisms to facilitate effective QoS delivery by MPLS networks.
At the MoT trail or MoE link level, CAC ensures that SRLG diversity-increasing operations (or
bandwidth-decreasing operations that would leave insufficient bandwidth for existing tunnels on the virtual
link) are avoided. As well, potentially CAC-affecting actions on MoT/MoE links (including indirect actions
such as changes to a server trail used by the link) protected by bypass tunnels are always disallowed; the
bypass tunnels must be deleted first.
TIP: The bypass tunnels can be deleted as a batch operation through export to XML and then
reimported after the potentially CAC-affecting action is completed (see Batch Tunnel
Operations).

The changes that trigger tunnel CAC evaluation include:

 Creating a new tunnel.
 Changing parameters (for example, bandwidth) of an existing tunnel or an MoT trail or MoE link having
tunnels traversing it.
 Changing parameters that are resource limited.
CAC rejects the request if the change violates resource constraints or established LSP BW guarantees.
CAC consists of Resource and BW-specific checks.
Resource CAC
Resource CAC checks requests against available quantity-related resources, according to equipment type.
BW CAC
BW CAC is performed on all outgoing ports of all equipment along the tunnel path. As a result, the tunnel
provides the declared end-to-end QoS parameters. Bandwidth CAC checks requests against available
BW-related resources. Bandwidth can be allocated between CoSs with a fine granularity, down to two
decimal places, enabling fine tuning in increments of 1M.
Tunnel Level
The total bandwidth of all tunnels protected by a bypass tunnel is limited to the configured BW for the
bypass tunnel; see Allocated BW in Tunnel Parameters Status Parameters Pane and BW (Mbps) in Tunnel
Parameters Basic Parameters Pane. This limit does not apply for a CoS configured for Best Effort protection.
The Unreserved BW parameter indicates the bandwidth free for use per bypass tunnel. It is calculated as
BW minus Allocated BW; see Create Tunnel Window Status Parameters Pane.
Port and CoS Levels
Limits to bandwidth that can be assigned can be configured per port or per CoS per port:
 Separate limits can be set for tunnels (Res BW %) and bypass tunnels (Res Shared BW %).
 The combined BW (tunnel + bypass tunnel) can be up to the port rate (100%). (While the BW limit for
any one CoS cannot exceed the port rate, the sum of the eight separate CoS instances is not limited.)
 Basic BW allowed for additional configurations per port (or CoS per port) is the port limit minus any
already allocated bandwidth.
Bandwidth per CoS can be "overbooked", whereby the sum of defined service bandwidth can exceed a
link's bandwidth capacity; see Configuring Service Overbooking. The basic bandwidth allowed is adjusted by
a multiple per CoS.
For example, 1 denotes 100% coverage (no overbooking), 2 denotes 100% more bandwidth allowed than
strictly available. Traffic that exceeds the overbooked bandwidth at any one time is dropped according to
applicable criteria.
Bandwidth is automatically shared among bypass tunnels that do not have SRLGs in common; see
Bandwidth Sharing.
Parent Topic

8.1.8 MPLS-TP Tunnel OAM

MPLS-TP functionality, providing bidirectional tunnel service with MPLS-TP tunnel OAM, based on BFD.
MPLS-TP tunnel OAM for bidirectional tunnels is based on Bidirectional Forwarding Detection (BFD), a
simple Hello protocol used to verify connectivity between systems. A pair of systems transmits BFD packets
periodically over each path between the two systems. If a system stops receiving BFD packets for some
preconfigured period of time, a component in that particular bidirectional path to the neighboring system is
assumed to have failed. Our equipment supports BFD for MPLS-TP in bidirectional tunnels, enabling tunnel
OAM that monitors endpoints and PWs running over the tunnel.
Parent Topic
8.1.9 Tunnel Pathfinding

The tunnel PathFinder calculates an optimal path for a tunnel subject to tunnel constraints (such as
bandwidth and explicit path) and topology constraints (including CAC). Pathfinding occurs when a new
tunnel is set up.
Pathfinding tries to find an explicit path containing all cards and links through which the tunnel should
traverse - the shortest path (minimal sum of weights) from source to destination in a weighted graph,
considering multiple other constraints to which the tunnel may be subject.
The PathFinder considers:
 Current network topology: MPLS PE cards, and MoT and MoE links.
 Available resources: CAC constraints on cards and links, and existing tunnels.
 Required tunnel Parameters: Bandwidth, protection, explicit path, and others, including L-LSP or
E-LSP-related parameters.
Pathfinding comprises two basic steps:
 Pruning links or link directions that do not meet tunnel requirements, including FRR constraints.
 Calculating the shortest path from source PE to destination PE in the pruned topology. The path may
be subject to user optional explicit path constraints.
Parent Topic

8.1.10 SRLG Avoidance in Bypass Path Selection

Shared Risk Link Groups (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 (Shared Risk
Link Groups (SRLGs)).
SRLGs have implications for PathFinder tunnel path selection and tunnel CAC validity. For trail path
implications, see SRLG and Other Shared Resource Minimization in Path Selection.
In the figure in FRR Node Protection (reproduced here), if the links from P2 to P3 and the link from P2 to P4
belong to the same SRLG (for example, same fiber duct), bypass tunnel 2 would be of no use if that fiber
failed.
Figure 8-22: FRR node protection for P2MP
For this reason, the PathFinder's bypass tunnel path selection disqualifies links that share SRLGs with the
link or node they are protecting. This ensures that if the protected link or node fails, the bypass tunnel does
not fail too (assuming a single physical failure and no XDM/NPT failures).
The protected tunnel's SRLG Diverse field shows the SRLG status of the bypass path; see Protection
Parameters Pane. True indicates that the bypass tunnel path has no SRLG in common with the protected
link/node.
SRLG diversity is not mandatory for link-protecting bypass tunnels. If needed, the "no shared SRLGs" rule
can be suspended by selecting the Common SRLG Penalty checkbox in the Preferences window Tunnel
Constraints workspace; see Tunnel Management Constraint Preferences in the Getting Started &
Administration Guide. In this case, paths that share SRLGs with the protected path are not automatically
disqualified from bypass tunnel consideration (and in that case it may be easier for PathFinder to find
protection paths that sometimes use the same SRLG as the protected tunnels). Those paths are subject to
other optimization criteria, like other prospective paths. If needed, some impact of SRLGs can then be
factored into the PathFinder decision by specifying a penalty per shared SRLG to be added to the metric or
hops associated with each path (according to the optimization criterion that applies).
However, the protected node and all its links are always disqualified from node-protecting bypass tunnel
consideration.
Bypass tunnels without common SRLG IDs are allowed to share BW on common links; see Bandwidth
Sharing.
Parent Topic

8.1.11 Tunnel Traffic Engineering and QoS

Network traffic engineering facilitates best use of network infrastructure by offering QoS guarantees, such
as bandwidth and latency, without the need for dedicated lines. This section describes aspects of traffic
engineering supported by LightSoft.
Parent Topic
8.1.11.1 Class of Service (CoS) per Tunnel

Each P2P or P2MP tunnel is assigned a user-configurable CoS value (0 to 7); see BW parameter in Basic
Parameters Pane in the Supporting Information Supplement. In general, services traversing a tunnel with a
higher CoS receive better treatment than one with a lower CoS. The CoS value affects both throughput and
latency performance. See also CoS Mapping for Ethernet Services.
Parent Topic
8.1.11.2 Bandwidth Sharing

Each P2P or P2MP tunnel is assigned a user-configurable bandwidth in the range 1-2560 Mbps; see BW
parameter in Basic Parameters Pane in the Supporting Information Supplement.
Bypass tunnels whose protected tunnels have no common SRLG IDs automatically share BW on common
links. A Bypass BW sharing mode applies, which enables this without compromising protected BW. This is
possible because such L-LSP or E-LSP bypass tunnels protect protected tunnels whose route is on different
SRLGs and thus only one of the bypass tunnels is assumed to carry traffic at any given time. (The CAC
process then considers the maximum of the BWs involved, rather than their sum.)
Parent Topic

8.1.11.3 Additional Information in PF Decisions

Traditional IP routing-based networks forward IP packets based on the shortest or cheapest path to a
destination. Traffic engineering allows additional information in routing decisions, enabling additional
control over routes that MPLS packets take to a given destination.
Load Sharing Across Unequal Paths

In this example, large site A and B routers are connected directly by a high BW link (cost 10), while smaller
site C is connected to A and B with low BW links (cost 20 each).
Figure 8-23: Load sharing across unequal paths
In traditional IP routing, the traffic between A and B is always routed over the cheapest or least hop link
even when alternative links are largely unused. MPLS traffic engineering allows load balancing over the low
BW link based on traffic analysis. Two tunnels can be created (low BW and high BW), with router A
configured to pass one flow to B over the low BW tunnel for each three over the high BW tunnel. In this
case, unequal paths are utilized in relation to their BW.
Routing Based on Bandwidth Requirements

Similarly, MPLS traffic engineering can route flows according to application BW requirements. For example,
the three routers in the previous example can be connected with a 100 Kbps link or combined 200 Kbps +
200 Kbps links. Tunnels can be built for 100 Kbps vs. 200 Kbps traffic and routers routing traffic according to
application BW requirements.
Parent Topic

8.1.11.4 Overbooking and CIR

Overbooking (use of a booking factor > 1.0) enables statistical multiplexing with which the total reserved
BW is less than the sum of the tunnel BW. This is useful, for example, for internet traffic where customers
do not all demand their BW simultaneously.
In this scheme, the bandwidth that has to be reserved per CoS is defined as:
Committed Information Rate (CIR) = Sum (Tunnel BW)/Booking Factor
where:
 Tunnel BW = maximum bandwidth configured per tunnel
 Booking Factor = overbooking factor configured per CoS
For example, at a booking factor of 2.0, instead of having to reserve 100 Mbps for a CoS, only 100 Mbps/2.0
= 50 Mbps needs to be reserved. If the CoS includes 100 tunnels of 1 Mbps, 0.5 Mbps is guaranteed per
tunnel. (When all tunnels do not use BW simultaneously, each tunnel can be as large as 50 Mb.)
Parent Topic
8.1.11.5 Operations, Administration, and Maintenance (OAM) per

Tunnel
Tunnel OAM verifies that a tunnel has correct connectivity and delivers the required availability and QoS;
see Tunnel OAM in Advanced Tunnels Parameters Pane.
Parent Topic
8.1.11.6 Traffic Management in MCS

The MCS Traffic Manager (TM) ensures that each tunnel gets its assigned bandwidth and other QoS
parameters. The TM works on the egress port, that is, after packet classification and right before packets
are transmitted into the MoT/MoE line. Each tunnel undergoes the following TM functions:
 WRED at Tunnel, Class, and Port levels: Provides buffering and TCP-friendly congestion management.
Each tunnel is assigned a dedicated queue to ensure that the traffic of one tunnel does not affect
another (the basis for tunnel bandwidth guarantees in the MCS). Each queue is assigned a WRED drop
profile that consists of two WRED curves, one for green and one for yellow-marked packets.
 Shaping at the Class level: Each Class is assigned two rate limits, committed (CIR) and peak (PIR). The
CIR is automatically configured as:
Class CIR = Sum (Tunnel User BW)/CoS Booking Factor
where Tunnel User BW is the bandwidth configured by the user for the tunnel and CoS booking factor
is a user-configurable value per class per MCS to allow overbooking.
For example, if a class in port contains 10 tunnels of 1 Mbps and the CoS Booking Factor is 2, then
CIR = (10 x 1)/2 = 5 Mbps.
Parent Topic

8.1.11.6.1 Peak Information Rate

Peak Information Rate (PIR) is used to protect low priority packets. Bandwidth allocation based on PIR
reduces the likelihood of lower priority packets being starved out by high priority traffic. A threshold CoS is
assigned as high priority, making all CoS values above it considered high priority and those below it low
priority. Bandwidth is then allocated to CoS instances according to their PIR, where:
 High Priority CoS: PIR = CIR (same calculation as described in Traffic Management in MCS).
 Low Priority CoS: PIR = BW limited only by the port rate.
Thus, each low priority CoS tunnel can reach the port rate (default) if no other tunnel transmits in that port,
with high priority CoS packets limited to avoid starvation to low priority CoS packets.
Parent Topic
8.1.11.6 Traffic Management in MCS
8.2 Options for Creating Tunnels

You can create tunnels in several ways:
 Using the Create Tunnel window, as described in this section.
 Acquisition from the EMS (see Synchronizing Tunnels).
 Importing tunnel definitions from an XML file that contains the parameters of the tunnels to be
created. The XML files can be imported either through LightSoft or UNIX (see Importing Tunnels).
 Automatically, as described for multiple bypass tunnel creation and full mesh provisioning (see
Automatic Multi-Tunnel Creation).
Parent Topic
8.3 Creating Tunnels

You can define MPLS tunnels directly from LightSoft.
NOTE: Before creating the tunnels, verify that the MPLS links that the tunnel will traverse
already exist and have sufficient bandwidth to accommodate the new tunnels.
When working with Ports configured for LAG, tunnels can be created on the LAG master only.
In order to create the tunnels, follow these steps:

 Defining the Tunnel Parameters
 Selecting Endpoints for a Tunnel
 (Bypass tunnels only) Configuring Protected Ports for Bypass Tunnels
 (Optional) Assigning Tunnel Path Inclusions and Exclusions
 Activating the Tunnel

To view a list of tunnels, or to add or remove subtunnels, see Performing Actions on Tunnels.
You can create a tunnel by accepting default parameter values or selecting specific values. The new tunnel
is built by the PathFinder algorithm according to the selected optimization criteria; see Tunnel
As part of the creation process, you can export the new tunnel to an XML file for backup purposes or for
automatic assignment of bypass tunnels.
You can optionally modify the tunnel PathFinder parameters (and thereby the resultant tunnel paths) via
tunnel constraint preferences; see Tunnel Management Constraint Preferences in the Getting Started &
To view details about the Create Tunnel window and toolbar, see Create Tunnel Window.
Parent Topic

8.3.1 Defining the Tunnel Parameters

This section describes how to begin creating the tunnels by defining the tunnel parameters. To create them
automatically, see Automatic Multi-tunnel Creation.
LightSoft only uses objects in resource domains to which your user group has the required permissions.
NOTE: For P2MP tunnels, the same parameters are used by all subtunnels of the tunnel.
To create a tunnel:
1. From the Tunnels tab, click Create Tunnel. The Create Tunnel window opens; see Create Tunnel
Window.
2. (Optional) Enter the Tunnel Name and Customer. If no name is entered, the endpoints are set as the
name automatically.
3. In the Protection Desired field, select one of the protection types and then set the other relevant
values. Which values are relevant depend on which protection you select:
 Unprotected: Tunnel is unprotected.
When Unprotected is selected, you can set the LSP Type, Tunnel Type, and Directionality (If the
directionality is Bidirectional, then the LSP Type must be E-LSP and the Tunnel Type must be
P2P.)

 Protected - FRR: Each node/link of the tunnel can be protected by another tunnel.
When Protected - FRR is selected, you can set the LSP Type, Tunnel Type, and Directionality (If
the directionality is Bidirectional, then the LSP Type must be E-LSP and the Tunnel Type must be
P2P.)
(Optional) When this option is selected, in the Advanced Parameters Pane, you can select the
FRR Protection Mode as explained in the Setting the FRR Protection Mode.
 Protected - Linear (1:1): For every tunnel created, another tunnel is created as its protection.
When Protected - Linear (1:1) is selected, the next few parameters are disabled.
 Bypass: Tunnels used to provide FRR protection.
When Bypass is selected, you can set the FRR Type and the LSP Type. (Bypass tunnels are
always P2P and Unidirectional.)
NOTE: If you want to set Dual FRR protection, select Link protection and in the in the
Advanced Parameters pane, for the Dual FRR field, select Enable.
4. Configure the CoS and BW. For further instructions, see CoS, Color, and BW Selections for a Tunnel.
5. For bidirectional tunnels, you can configure BFD, LDI and other OAM parameters. (The OAM tab
appears only after selecting Bidirectional for Directionality. For further instructions, see OAM for
Bidirectional Tunnels.
6. For all other parameters, edit as required or leave the default values. For a full list of options, see
Tunnel Parameters.
Click Reset tunnel parameters to defaults to reset tunnel parameters to default values.
7. Continue with Selecting Endpoints for a Tunnel.
Parent Topic

8.3.2 Selecting Endpoints for a Tunnel

This procedure explains how to select the endpoints when creating a tunnel.
To select the tunnel endpoints:

1. Click the Endpoints & Path tab.
2. For unidirectional tunnels, select the endpoints as follows:
a. In the Tunnel map, click the NE that you want to set as the Head end (source) endpoint PE. The
NE is listed as Head.
(If you click on a group, the Select Endpoint dialog box opens, for you to select the NE to be the
endpoint.)
b. In the Tunnel map, click the NE(s) that you want to set as the Tail end (destination) endpoint
PE(s). The NE is listed as Tail. If it is a P2MP tunnel, you can select multiple tails.
3. For a bidirectional tunnel, in the Tunnel map, click the two NEs that you want to set as the two
endpoints. Both are marked as Head & Tail.
(If you click on a group, the Select Endpoint dialog box opens, for you to select the NE to be the
endpoint.)

4. For bypass tunnels, a message appears telling you to assign the protected ports. Click OK and follow
the procedure in Configuring Protected Ports for Bypass Tunnels.
5. Continue with Assigning Tunnel Path Inclusions and Exclusions.
Parent Topic
8.3.3 Configuring Protected Ports for Bypass Tunnels

After selecting the endpoints of a bypass tunnel, as explained in Selecting Endpoints for a Tunnel , a
message opens asking you to select a protected port. The following procedure explains how to configure
protected ports for bypass tunnels with Node, Link or FRR protection.
To configure protected ports for Bypass Tunnels:

1. Click the link outgoing from the source PE that is to be protected. The protected link is highlighted in
white and the Select Protected Port window opens.
2. Select the port direction of the icon outgoing from the source PE and then click anywhere in the map.
The Select Protected Port window is closed and the protected link and/or node is highlighted in black
on the map.
NOTE: The black color on the protected link (and node) shows that it is "excluded" from
PathFinder consideration as the bypass tunnel path. (PathFinder prunes the link when any FRR
protection applies. It additionally prunes the node when Node protection applies (see FRR
Protection Types.)

For Node or EFRR protection, a next next hop PE (NNH) protection is configured.
For link protection, a next hop (NH) PE is configured.
3. If implementing Dual FRR protection to provide simple link protection, no further node selection is
needed (see Simple Node and Link Protection).
To implement the standard Dual FRR use case where the protection path is “point to dual point”, you
must also explicitly include the bypass tunnel’s penultimate hop to correspond with another node
(either the protected tunnel’s NNH PE or some other node that would achieve the desired purpose).
See Dual FRR for Link and Node Protection. See step 6 for details how to explicitly include a PE in the
tunnel path.
Parent Topic

8.3.4 Assigning Tunnel Path Inclusions and Exclusions

You can select PEs and/or links that LightSoft must use (included) or avoid (excluded) when creating a
tunnel.
NOTE: This is an optional step. If you wish to skip it, continue with Activating the Tunnel.
To explicitly include/exclude PEs or links in the tunnel path:

1. In the Select field, click Exp. Path Include or Exp. Path Exclude.
2. To Include/exclude PEs, click each PE you want to include/exclude in the order they should appear in
the path (if you select PE1 before PE2 then the tunnel must traverse PE1 before PE2). Included PEs
appear in white in the map and excluded PEs appear in black. Each entry is listed in the relevant pane
in the Endpoints and Path tab.
3. To include/exclude links, click the links in the order they should appear in the path. For each link, the
Include/Exclude Link dialog box opens. Specify the link direction to be included/excluded. (The
example below shows direction from Port 2 as included.) Then click anywhere in the map to close the
dialog box.
4. To change the order of a PE in the Inclusion pane list, select the PE and click Move Up or Move Down.
NOTE: For P2MP tunnels, multiple Tail endpoint selections are allowed only if all Tail
endpoints have identical explicit path Include/Exclude lists (same link/node IDs and order).
The selected PEs and links are included/excluded in the path to Tail endpoints highlighted in
the Endpoints pane.
5. Continue with Activating the Tunnel.
Parent Topic

8.3.5 Activating the Tunnel

After defining tunnel details, you have to activate the tunnel.
To activate the tunnel:
1. (Optional) Click Complete Tunnel . LightSoft calculates the entire path and displays a completion
message with the operation results and any nonfatal errors. The path is displayed in pink
(unprotected links/nodes) or violet (protected links/nodes), and listed in the Path pane.
P2MP tunnels: If selected subtunnels have different explicit path lists, no path is highlighted in the
map.
2. Click Activate Tunnel . The tunnel is activated on the network. LightSoft computes the entire
path and displays a completion message with the operation results and any nonfatal errors. The path
is displayed in pink (unprotected links/nodes) or violet (protected links/nodes), and listed in the Path
pane.
P2MP tunnels: You can highlight a specific subtunnel in the map by selecting its Tail endpoint in the
Path pane.
If you unassigned bypass tunnels following a Complete operation, the associated tunnel hops are not
assigned bypass tunnels.
NOTE: If Complete Tunnel was not performed before, or if it was followed by any potentially
path-affecting action (such as a change of endpoint), it will automatically be
performed/repeated as part of the Activate process. (If no such actions followed the Complete
step, a fast activation process applies, that does not duplicate the Complete processing.)
If the Complete or Activate step fails, see Diagnosing a Create Tunnel Failure.
3. To export the tunnel in XML format, see Exporting Tunnels.
Parent Topic

8.3.6 Selecting Bypass Tunnels Manually

You may wish to manually select a specific bypass tunnel for each protected tunnel role (head, transit, and
tail nodes). The selected bypass tunnel is permanently associated with the working tunnel and not subject
to automatic change.
A bypass tunnel can be selected manually for an existing tunnel via the EMS.
NOTE: Manual Bypass tunnel selection does not support EFRR protection.
To select a bypass tunnel manually:

1. Ensure that the appropriate bypass tunnel exists in LightSoft.
2. Set up the required protected tunnel:
a. Configure parameters as described in Creating a Tunnel.
The CoS value of the tunnel and its intended bypass tunnel should be the same.
b. Click Complete to complete the tunnel. (Do not click Activate yet.)
In the Endpoints & Path tab, Path pane a bypass tunnel is automatically suggested for the
tunnel. It may or may not be the one you intended, and may be subject to automatic change
according to network circumstances.
3. In the Advanced Parameters pane, select the Manual Bypass Selection checkbox.
4. In the Protection Mode field, select Using Existing Bypasses. A Manual Bypass Selection pane opens
under the Path pane.
5. In the Path pane, click the endpoint line of the role to which the intended bypass is attached, for
example the Head role.

6. In the Manual Bypass Selection pane, click one or both of the following checkboxes:
 Node: Lists all suitable bypass tunnels for node protection.
 Link: Lists all suitable bypass tunnels for link protection.
The available bypass tunnels are listed in the table.
The automatically suggested bypass tunnel is shown as selected.
7. Click the relevant checkbox to select the required bypass tunnel.

8. If you need to select bypass tunnels manually for other tunnel roles (for example, transit of tail),
repeat the procedure for each from Step 4.
9. Click Activate to complete the process. The protected tunnel is created and is permanently associated
with the intended bypass tunnel.
Parent Topic
8.3.7 Setting the FRR Protection Mode

There are different categories of FRR protection available in LightSoft. Once you have selected
Protected-FRR in the Create Tunnel window, you can choose the FRR protection mode as explained in this
procedure.
NOTE: For more information about FRR, see FRR Tunnel Protection.
To set the FRR protection mode for a tunnel:

1. In the Create Tunnel window, in the Protection Desired field, select Protected -FRR.
2. In the Advanced Parameters pane, in the Protection field dropdown list, select one of following:
 Using existing Bypass tunnels: Using existing bypasses only, LightSoft selects the bypass tunnels
that provide the highest available protection.

 Use existing Guarantee full Protection: LightSoft provides protection using existing
unidirectional bypass tunnels only. Tunnel creation is only allowed if all hops are protected by
existing bypasses.
 Auto-create - FRR: If a hop is not protected, where possible, create new node or link bypasses.
Full FRR protection is not guaranteed because if a bypass cannot be created for one or more
hops, tunnel creation is still permitted.
 Auto-create - EFRR: If a hop is not protected, where possible, create new eFRR or link bypasses.
Full FRR protection is not guaranteed because if a bypass cannot be created for one or more
hops, tunnel creation is still permitted.
Parent Topic
8.3.8 Diagnosing a Create Tunnel Failure

If the Create Tunnel operation fails, perform the following verification steps.
If the Action Failed at the Completion stage

1. Verify the message immediately after the failure or the error message in the Operational Results Info
window.
2. Check if all the explicit path selections and endpoints are correct.
3. Verify that all the relevant elements and subnets are uploaded and managed by LightSoft. This is
apparent from the Usability State of the element as reflected in the map view or in the applicable
object properties window. You can also open a UNIX window and run the NMSState utility.
4. Check the parameters selected in the Create Tunnel window.

If the Tunnel Failed at the Activation Stage (Completion Succeeded)

1. Verify the message immediately after the failure or the error message in the Operational Results Info
window.
2. Check if all tunnel segments were created at the EMS level.
4. Check the TSC counter background color in the LightSoft main window; see Tunnel Segment
Consistency (TSC) Counter. Check the color in the Severity Breakdown Pane and perform the action
recommended in Tunnel Consistency Use Cases. For example, perform tunnel synchronization and
check the differences between LightSoft and the EMS. The elements that the tunnel segment failed
on are shown in the Result window described in Performing Tunnel Operations.
5. If an NE in the tunnel was disconnected during tunnel creation or a craft terminal connected, and the
resulting tunnel is in an incomplete state, use Reconnect to send the missing tunnel segments to the
network.
Parent Topic

8.4 Create Tunnel Window

The Create Tunnel window provides a graphical representation of all or preselected objects and their
associated MoT virtual links and MoE physical links, as well as information and configuration panes.
The Create Tunnel window includes the following sets of configuration panes:
 Map View: Graphical representation of all or preselected objects and their associated MoT virtual links
and MoE physical links, with the relevant Ethernet LEs automatically split out; see Map View.
 Tunnel Parameters tab: Tunnel parameter entry panes. For detailed information about the pane
contents, See Tunnel Parameters.
 Endpoints and Path tab: List of selected tunnel endpoints, the tunnel resources along its entire path,
and explicit path user selections comprising excluded and included nodes and links. See Endpoints and
Path.
 OAM tab: For bidirectional tunnels only. OAM configuration for bidirectional tunnels including BFD
and LDI. See Configuring OAM for Bidirectional Tunnels.
Parent Topic

8.4.1 Create Tunnel Menu and Toolbar

The following table lists the main functions available in the Tunnel List window menu and equivalent
toolbar. See Other Create Tunnel Options for additional functions.
Table 8-1: Create Tunnel menu and toolbar icons
Menu option Toolbar icon Description

Select options
When defining a tunnel path, define nodes as endpoints, or specify whether links/nodes should be
explicitly included/excluded in/from the tunnel path.
Endpoints Enables selection of endpoints. Once selected, click elements

in the map to specify endpoints. For Bypass tunnels, can select
the protected port (allowed after endpoints have been
selected).
Exp. Path Include Specifies that nodes and/or links selected in the map are to be
explicitly included in the tunnel path.
Exp. Path Exclude Specifies that nodes and/or links selected in the map are to be
explicitly excluded from the tunnel path.
Paint options
Highlights in the map either the tunnel path, or specific link/port inclusions and exclusions, or both.
Path Highlights in violet the nodes/links in the tunnel path

(following the last successful Complete or Activate action).
Explicit Path Highlights any nodes and links that had been explicitly
included or excluded in the tunnel path (exclusions in black,
inclusions in white).
Path & Explicit Path Highlights both the nodes/links traversed by the path and
those explicitly included/excluded (exclusions in black,
inclusions in white, the remainder of the tunnel path in violet).
Action menu
Clear Endpoints and Path Removes all endpoint selections (including explicit path
inclusions/exclusions) but keeps any user changes to tunnel
parameters.
Clear Settings Clears all endpoint selections (including explicit path
inclusions/exclusions) and restores all tunnel parameters to
system defaults.
Reset Parameters Restores tunnel parameters to system defaults.
Export to XML Exports the tunnel configured in the Create Tunnel window to
an XML file (see Exporting Tunnels). Exported data can be
imported to create tunnels at a later time.

Menu option Toolbar icon Description

Show Info Displays detailed results of the last operation; see Performing
Tunnel Operations.
Complete Causes the PathFinder algorithm to search a route for the
tunnel based on the current selections and network
configuration. If successful, the complete path is highlighted in
the map. Nothing is saved to the database at this point or sent
to the EMS.
Activate Causes implementation of the new tunnel in the network. This
option can be used even if Complete tunnel was not
performed.
If successful, the NMS sends information to the EMS, which
creates MPLS SNCs in the elements. Tunnel information is
saved in LightSoft and EMS DBs. Live traffic can now traverse
the tunnel.
Show Activated Tunnel If selected (toggled on), by default, the service is shown in the
window map immediately after activation.
Show On Demand Some tunnel parameters (for example, Tunnel Length) show
Parameters "On Demand" as their value when a tunnel is first loaded or
configured. Clicking this icon initiates a calculation process
which displays current values for all such parameters. (Process
may take some time.)
Show/Hide Details Panel
Toggle to show/hide the left-side details panes.
Parent Topic

8.4.2 Map View

The map view provides a graphic representation of all or preselected objects and their associated MoT
virtual links and MoE physical links, with the relevant Ethernet LEs automatically split out. It is used in the
process of tunnel endpoint selection, and assists visualization of the Create tunnel process.
in the same way as in the LightSoft main map view, as described in Managing Elements and Groups.
Parent Topic
8.4.3 Tunnel Parameters

The Tunnel Parameters tab provides tunnel parameter entry panes.
Figure 8-24: Tunnel Parameters tab
 Basic Parameters Pane : Configure basic tunnel parameters.

 Advanced Tunnels Parameters Pane : Configure more specific optional tunnel attributes.
 Protection Parameters Pane : Show tunnel FRR parameters.
 Status Parameters Pane : Show operational, alarm, bandwidth, and protection state-related
parameters.
 General Parameters Pane : Show general tunnel parameters.
Parent Topic
8.4.3.1 Basic Parameters Pane

The Basic Parameters pane enables you to configure the most basic tunnel attributes. Protection Desired
(and FRR Type for Bypass tunnels) are mandatory fields - defaults are the last entry values. Accept default
parameter values, or enter the value you require.
NOTES:
 Most of these fields are relevant for automatic tunnel creation as well; see Automatic
Multi-Tunnel Creation.
 Fields and/or options that are not relevant for a selected tunnel type or configuration are
either disabled or not displayed in the GUI.

Figure 8-25: Tunnel - Basic Parameters pane
For the CoS selection procedure, see CoS, Color, and BW Selections for a Tunnel.
Table 8-2: Basic Parameters pane fields
Field Description
Tunnel Name
(Optional) Name of the tunnel (not unique). Enter a name or select one from the list
(recently used labels). If not specified, a name is automatically assigned showing
endpoint details and timestamp.
When creating multiple tunnels automatically, enter a prefix string to represent all
the tunnels being created. The remainder of the tunnel name string is set
automatically, unique for each tunnel.
Customer (Optional) Customer associated with this tunnel (not unique). If not specified, the
name is left blank.

Field Description
Protection Desired Protection level (The previous selection is selected by default):
 Unprotected: Tunnel is unprotected.
When Unprotected is selected, you can set the LSP Type, Tunnel Type, and
Directionality (If the directionality is Bidirectional, then the LSP Type must be
E-LSP and the Tunnel Type must be P2P.)
 Protected - FRR: Each node/link of the tunnel can be protected by another
tunnel.
When Protected - FRR is selected, you can set the LSP Type, Tunnel Type, and
Directionality (If the directionality is Bidirectional, then the LSP Type must be
E-LSP and the Tunnel Type must be P2P.)
(Optional) When this option is selected, in the Advanced Parameters Pane, you
can select the FRR Protection Mode as explained in the Setting the FRR
Protection Mode.
 Protected - Linear (1:1): For every tunnel created, another tunnel is created as
its protection.
When Protected - Linear (1:1) is selected, the next few parameters are
disabled.
 Bypass: Tunnels used to provide FRR protection.
When Bypass is selected, you can set the FRR Type and the LSP Type. (Bypass
tunnels are always P2P and Unidirectional.)
When creating multiple tunnels automatically, this protection is configured for all
the tunnels being created.
FRR Type (Relevant only for bypass tunnels.) FRR protection mode of the bypass tunnel:
 Node protection: Protects against failure of a node and its subsequent link.
The diverted traffic remerges with the original tunnel at the next next hop
(NNH) MPLS PE downstream from the failure.
 Link protection: Protects against failure of a link. The diverted traffic remerges
with the original tunnel at the next hop (NH) MPLS PE downstream from the
failure.
 EFRR protection: Provides enhanced protection against multiple simultaneous
node or link failures, with more efficient BW utilization. The diverted traffic
remerges with the original tunnel at the end of the EFRR segment.
Note: If your bypass tunnel definition must provide Dual FRR protection, select Link
protection. This enables the Dual FRR field in the Advanced Parameters pane.
See FRR Protection Types.
LSP Type Tunnel mode (E-LSP or L-LSP) supported for this tunnel. The CoS & BW area varies
according to your selection. See Tunnel Mode.
Tunnel Type Options are:
 P2P (default).
(Bypass tunnels are automatically P2P.)
 P2MP
See P2P and P2MP Tunnel Types.
A read-only field representing a third type of tunnel, Virtual RSVP, only appears
when relevant. See Virtual RSVP Tunnel Type.
Directionality Unidirectional/Bidirectional (Tunnel Mode must be E-LSP for bidirectional tunnels)

Field Description
CoS & BW section for L-LSP mode
CoS Class of service, CoS0 to CoS7 (subject to equipment support limitations); see Class
of Service (CoS) per Tunnel.
BW (Mbps) Maximum bandwidth allowed for this tunnel. Select one of:
 1, 2, .. 32
 40, 48, .. 258 (increments of 8)
 288, 320 .. 1024 (increments of 32)
 1280, 1536, .. 7936 (increments of 256)
 10000
Bandwidth for LSP with a CoS defined as BE CoS must be 0.
CoS & BW Section for E-LSP mode
Select CoS button Opens a dropdown list of CoS choices (0 to 7).

Field Description
CoS/Color /BW table Up to eight CoS-color combinations can be defined for a tunnel. (Both Green and
Yellow associated with a CoS counts as two combinations.) Each CoS line selection
has the following parameters:
 CoS: As selected with the Select CoS dropdown list.
 Color: Default color applies for each CoS. (Modify if required; see CoS, Color,
and BW Selections for a Tunnel.)
P2MP tunnels usually carry multicast IPTV where BW should be marked
Green.
 BW (Mbps): Maximum bandwidth allowed for this CoS. Select one of:
 0.128, 0.256, 0.384, 0.512 (Supported by EMS-APT elements only, where
Hr-CoS bandwidth limit = none.)
 1, 2, .. 32,
 40, 48, .. 258 (increments of 8)
 288, 320 .. 1024 (increments of 32)
 1280, 1536, .. 7936 (increments of 256)
 10000
Bandwidth for LSP with a CoS defined as BE CoS must be 0.
No BW Limit/ BW An E-LSP tunnel can be defined with HR-CoS, which enables limiting the bandwidth
Limit (Mb/s) of the tunnel (see Hierarchical CoS (HR-CoS) Tunnels). To define an HR-CoS tunnel,
select BW Limit (Mb/s) and enter the BW limit. Not relevant for bidirectional
tunnels.
Comments
Comments Free text about the tunnel.
Parent Topic
8.4.3.1.1 CoS, Color, and BW Selections for a Tunnel

In L-LSP mode, a single CoS applies to a tunnel, with an associated bandwidth selection.
In E-LSP mode, up to eight combinations CoS and color can be selected per tunnel. For example, up to four
CoS values with Green and Yellow (a CoS with two colors counts as two combinations).
Bandwidth for a tunnel with a CoS defined as BE CoS must be 0.
P2MP tunnels usually carry multicast IPTV where BW should be marked Green.
You can edit the bandwidth of a CoS associated with an existing L-LSP or E-LSP tunnel; see Editing Tunnel
Bandwidth.

To select the CoS and bandwidth for an L-LSP tunnel:

1. Select L-LSP as the LSP type. CoS and BW dropdown lists open.
2. From the CoS dropdown list, select a CoS.

3. From the Bandwidth dropdown list, select a bandwidth.
To select the CoS and bandwidth for an E-LSP tunnel:

1. Select E-LSP as the LSP type. A selection table opens.
2. Click Select CoS to open a dropdown list of CoS choices.

a. Select one or more CoS.

b. A default color is associated with a selected CoS. Optionally use the Color dropdown list to
select a different color for this CoS/Color combination (Green, Yellow, or Green&Yellow).
c. Select a bandwidth in the Bandwidth dropdown list.
3. Repeat the previous step for up to eight CoS/color combinations. (Both Green and Yellow associated
with a CoS count as two combinations.)
4. If the tunnel is Bidirectional, the Enable asymmetric setting option is displayed.
If you do not select this option, the Cos/Color settings configured here are applied to both tunnel
directions (A2Z and Z2A).
If you select this option, two new tabs (A2Z and Z2A) appear, allowing you to configure the CoS/Color
for each direction separately.
5. If the tunnel protection selected is Linear (1:), the Enable partial protection setting option is enabled.
If you do not select this option, the Cos/Color settings configured here are applied to both the main
and protection tunnels.
If you select this option, two new tabs (Main and Protection) appear, allowing you to configure the
CoS/Color for each one separately.

6. If the tunnel protection selected is Linear (1:), you can select both the Enable partial protection
setting and he Enable partial protection setting options.
If you select both options, four new tabs (Main A2Z, Main Z2A, Protection A2Z, and Protection Z2A)
appear, allowing you to configure the CoS/Color separately for the main and protection tunnels in
each direction.
7. If the tunnel is PTP, you can choose whether or not to set a bandwidth limit.
Parent Topic

8.4.3.2 Advanced Tunnels Parameters Pane

The Advanced Parameters pane allows you to configure more specific working tunnel attributes and to
enable/disable OAM and alarms for the tunnel.
NOTES:
 Most of these fields are relevant for automatic tunnel creation as well; see Automatic
Multi-Tunnel Creation.
 Fields and/or options that are not relevant for a selected tunnel type or configuration are
either disabled or not displayed in the GUI.
Figure 8-26: Create Tunnel - Advanced Parameters pane
Table 8-3: Advanced Parameters pane fields
Field Description
Working Tunnel
P2P/P2MP options, set automatically, relevant for automatic tunnel creation.
Tunnel Type
Single Service Only When selected, tunnel restricted to only one service (VPN), regardless of service
type. Relevant for P2P tunnels and automatic tunnel mesh creation.
P2P Service Only When selected, tunnel restricted to P2P VPNs (one or more, subject to
bandwidth considerations). Relevant for P2P tunnels and automatic tunnel mesh
creation.
Guaranteed FRR Relevant only for automatic tunnel mesh creation.
Desired
Manual Bypass Enables you to manually specify the bypass tunnel to associate with the
Selection protected tunnel, overriding the usual automatic bypass tunnel selection
process; see Selecting Bypass Tunnel Manually. Only available when FRR
Protection Mode is set to Use existing bypass tunnels.

Field Description
Protection Mode FRR protection mode. Options are:
 Using existing bypass tunnels: Using existing bypasses only, LightSoft
selects the bypass tunnels that provide the highest available protection.
 Use existing - Guarantee full Protection: LightSoft provides protection using
existing unidirectional bypass tunnels only. Tunnel creation is only allowed if
all hops are protected by existing bypasses.
 Auto-create - FRR: If a hop is not protected, where possible, create new
node or link bypasses. Full FRR protection is not guaranteed because if a
bypass cannot be created for one or more hops, tunnel creation is still
permitted.
 Auto-create - EFRR: If a hop is not protected, where possible, create new
eFRR or link bypasses. Full FRR protection is not guaranteed because if a
bypass cannot be created for one or more hops, tunnel creation is still
permitted.
Not available if Manual Bypass Selection is selected.
User Usage State Enables you to set a user-configured usage state regardless of the system
calculated usage state, as follows:
 Idle: Sets the tunnel to Idle even if the actual state is Active. Idle tunnels are
not connected to traffic, and can therefore be deleted in the Tunnels pane;
see Deleting Tunnels (only if the system usage state is also idle.)
 Active: Sets the tunnel to Active even if the actual state is Idle. Active
tunnels are connected to traffic and therefore cannot be deleted.
Bypass Tunnel
Dual FRR Enable/Disable Dual FRR operation. Available only when Link Protection is
selected in the Basic Parameters pane, or when automatically creating multiple
bypass tunnels. See Dual FRR for Link and Node Protection.
Tunnel OAM and General Tunnel Alarms
Tunnel OAM (CV) Enable/Disable Tunnel OAM (Operations Administration and Maintenance).
Enables P2P tunnel operational state monitoring, ensuring that the tunnel has
correct connectivity and delivers the required availability and QoS.
A continuity control verification (CV) packet is sent over the tunnel, which the
tail expects to receive at periodic intervals. Otherwise the operational state of
the tunnel becomes Down. If the failure condition relates to the specific tunnel,
an alarm is raised. If the failure condition relates to some other failure which
affects multiple tunnels, for example a link failure, the alarm is masked.
E-LSP OAM CoS For E-LSP tunnel only. Lists the CoS values selected for the tunnels. You select
dropdown list the CoS in which tunnel OAM operates. Enabled if Tunnel OAM (CV) is Enabled,
and it is not a BE CoS (BW must not be zero).
Generate Tunnel Activates/deactivates generation of alarms on this tunnel in the same way as
Alarms Alarm Master Mask in trails. See Advanced Trail Parameters Pane.
Parent Topic

8.4.3.3 Protection Parameters Pane

This pane shows the tunnel FRR parameters. It is empty when the tunnel is created and filled with
information after the tunnel is completed or activated.
Figure 8-27: Create Tunnel - Protection Parameters pane
Table 8-4: Protection Parameters pane fields
Field Description
Protected Tunnel
Protection Actual Quality of protection actually applying to a protected tunnel. May differ from
Protection Desired, for example, if a bypass tunnel is not currently assigned to
the protected tunnel. For P2MP, denotes the weakest protection applying to any
associated subtunnel. Options are:
 Protection Full Node: Node protection on entire path, with link protection
applying on the last hop.
 Protected Full: Link protection on entire path, with node protection applying
on some hops.
 Protected Partial: Not all hops are protected.
 Unprotected: Tunnel currently not protected.
 Bypass: Tunnel is bypass.
Dual FRR (P2MP Whether the bypass tunnel is enabled to provide Dual FRR protection.
Tunnel)
Bypass Tunnel
Protected Port Name of port protected by bypass tunnel.
Protected Node Next hop node name (when the FRR Type is Link Protection) or next next hop
node name (when the FRR Type is Node Protection).
SRLG Diverse True indicates the bypass tunnel path has no SRLG in common with the protected
link/node; see SRLG Avoidance in Bypass Path Selection.
PHOP (Dual FRR) If Dual FRR protection applies, PE ID of node which is the penultimate (second to
last) hop of the protecting bypass tunnel.
Parent Topic

8.4.3.4 Status Parameters Pane

This pane shows operational, alarm, bandwidth, and protection state-related parameters. It is empty when
the tunnel is created and filled with information after the tunnel is completed or activated.
Figure 8-28: Create Tunnel - Status Parameters pane
Table 8-5: Status Parameters pane fields
Field Description
Tunnel State Synchronization state for tunnel:
 OK: Tunnel provisioned and consistent with LightSoft.
 Inconsistent: Tunnel provisioned but not consistent with LightSoft.
 Incomplete: Tunnel provisioning is partial or nonexistent, due to, for
example, NE disconnection from LightSoft. Tunnel Reconnect action may be
required.
Allocated BW (Mbps) Bandwidth allocated (reserved) for this tunnel related to its CoS. Relevant for:
 Bypass tunnels: Sum of BW of the protected tunnels.
 P2P Services Only tunnels: Sum of BW of services directed to this tunnel.
Note: Allocated BW, Unreserved BW, Expandable BW present BW as follows:
 L-LSP: BW value relevant to a single CoS.
 E-LSP: BW values displayed relative to relevant CoS instances, in ascending
CoS order.
Unreserved BW (Mbps) Unreserved bandwidth for the tunnel = BW minus Allocated BW. Relevant for:
 Bypass tunnels where the protection BW for this CoS is Best Effort.
 P2P Services Only tunnels.
Expandable BW (Mbps) Maximum BW that this tunnel can be increased to without violating CAC
constraints at any hop; see CAC for MPLS Tunnels - BW CAC, and Link Properties -
CAC Tab.
For E-LSP, CoS Expandable BW is the maximum possible BW for each possible CoS
provided all other CoS BWs are not expanded.
On Demand means you must click Show On Demand Parameters to

calculate this field.
Tunnel Usage Displays the tunnel usage over all E-LSP CoS instances:
 Bypass: Number of underlying protected tunnels.
 Protected or unprotected: Number of underlying VPNs.

Field Description
FRR Protection In Use Yes if traffic currently uses bypass tunnel. Value appears with respect to both the
protected and bypass tunnels.
On Demand means you must click Show On Demand Parameters to

calculate this field.
Parent Topic
8.4.3.5 General Parameters Pane

This pane shows the general tunnel parameters. It is filled with information after the tunnel is completed or
activated.
Figure 8-29: Create Tunnel - General Parameters pane
Table 8-6: General Parameters pane fields
Field Description
NMS Tunnel ID LightSoft tunnel identifier for this tunnel, a unique value in LightSoft, for example,
"36(38)", formatted as:
Unique ID Number (Managed System ID),
where:
 Unique ID Number – ID of the tunnel, sequentially assigned in the tunnel
creation process.
 Managed System ID – ID of the management system in which the tunnel was
created (EMS or LightSoft).
Actual No. of Hops Actual number of hops for this tunnel.
For P2MP, maximum amongst its subtunnels.
This can be used in the process of tunnel optimization; see the Optimization
Criterion description in Tunnel Management Constraint Preferences in the Getting

Field Description
Tunnel Metric
Cost of tunnel (sum of costs of all links through which tunnel traverses).
For P2MP, maximum among the subtunnels.
This can be used in the process of tunnel optimization; see the Optimization
Criterion description in Tunnel Management Constraint Preferences in the Getting
For details of its calculation and how it is used in the process of minimum tunnel
cost optimization, see Minimizing Tunnel Cost in the Getting Started &
Tunnel Length Length of tunnel (sum of the lengths of all links through which the tunnel
traverses).
For P2MP, max. among the subtunnels.
Created By User Tunnel creator.
Created With Application the tunnel was created with - GUI (LightSoft), XML (import from XML),
or TSC (acquisition from the EMS).
Creation Time Tunnel creation date and time.
Modified By User Tunnel modifier.
Modified With Application the tunnel was modified with - GUI (LightSoft), XML (import from
XML), or TSC (acquisition from the EMS).
Modification Time Tunnel modification date and time.
Parent Topic
8.4.4 Endpoints and Path

This tab lists the selected tunnel endpoints, details of each node along the tunnel path, and path user
selections comprising explicitly included and excluded path characteristics.
 Endpoints Pane : Tunnel endpoint selections.

 Path Pane : Details of each node along the entire tunnel path.
 Explicit Path Include Pane : Selected explicitly included path characteristics.
 Explicit Path Exclude Pane : Selected explicitly excluded path characteristics.
Parent Topic

8.4.4.1 Endpoints Pane

The Endpoints pane lists details of the tunnel endpoints. A P2P tunnel has two endpoints while a P2MP
tunnel can have up to 128 endpoints.
Figure 8-30: Endpoints pane
Table 8-7: Endpoints pane fields

Field Description
PE PE ID of the PE that contains the endpoint.
Role Endpoint's SNC role (Head, Transit, or Tail).
Port Details of Out Port in Head and In Port in Tail.
Protected Port Name of protected port of bypass tunnel.
Parent Topic
8.4.4.2 Path Pane

The Path pane lists details of each node along the tunnel path. It displays tunnel MPLS Switched Labels (In
Label, Out Label, Out ALT Label) in accordance with their input or output port.
This applies to P2MP tunnels if only one Tail endpoint is specified (otherwise no information is shown).
You can view bypass tunnel assignments per hop or you can remove bypass tunnels; see Actions on Bypass
Tunnels.
Figure 8-31: Path pane
Table 8-8: Path pane shortcut options

Option Description
Show Bypass Displays bypass tunnel paths for the selected hops (blue in map). Enabled for
protected tunnel segments with bypass assignments. See Actions on Bypass
Tunnels.
Hide Bypass Clears bypass tunnel color coding in the map.
Remove FRR Removes bypass tunnel assignments from the selected tunnel segment. Enabled
Protection for protected tunnel segments with bypass assignments.

Table 8-9: Path pane fields
Field Description
# Relative position of the node/link within the path (lower values are the hops that
the tunnel must traverse first).
PE PE ID of the PE representing the node.
Role Endpoint's SNC role (Head, Transit, or Tail).
In Port Tunnel entry port.
In Label Tunnel MPLS Switched In Label in accordance with the input port. Determined
automatically by LightSoft.
Out Port Tunnel termination port.
Out Label Tunnel MPLS Switched Out Label in accordance with the output port. Determined
automatically by LightSoft.
Protection Type Protection Desired values (see Basic Parameters Pane in the Supporting
Information Supplement), but on a per hop basis (taken from the EMS) as
follows:
 Unprotected tunnel: Unprotected
 Bypass tunnel: Bypass
 Protected tunnel: Protected if hop is protected, otherwise Unprotected
FRR Type FRR protection mode applying to this bypass tunnel (Node or Link protection);
see Basic Parameters Pane in the Supporting Information Supplement.
Dual FRR Whether Dual FRR applies; see parameter in Advanced Tunnels Parameters Pane
in the Supporting Information Supplement.
Bypass Tunnel ID NMS Tunnel ID of the associated bypass tunnel.
Bypass Tunnel Name Name of the associated bypass tunnel.
Bypass Out Port Associated bypass tunnel termination port.
Alternative Label Tunnel MPLS Switched Out Alt Label in accordance with the output port.
Relevant for working tunnels protected by bypass tunnels, and only to the PLR
(point of local repair) node. Determined automatically by LightSoft.
FRR In Use Whether the bypass tunnel at the port is currently carrying traffic as a result of
main tunnel failure.
Parent Topic

8.4.4.3 Explicit Path Include Pane

This pane lists the selected explicitly included path characteristics. Manually defined inclusions/exclusions
are reflected only in LightSoft. They are not saved to the EMS.
Figure 8-32: Inclusions pane
The order in which a row is displayed specifies its order in the path. The order can be changed by clicking
Move Up and Move Down. (In this pane, manual sorting by clicking column headers does not apply.)
Table 8-10: Inclusions pane fields
Field Description
# Relative position of the node/link within the path (lower values are the hops that the
tunnel must traverse first).
Type Node or link.
ID Node or link user label.
Parent Topic
8.4.4.4 Explicit Path Exclude Pane

This pane lists the path user selections comprising explicitly excluded path characteristics. Manually defined
inclusions/exclusions are reflected only in LightSoft. They are not saved to the EMS.
Figure 8-33: Exclusions pane
Table 8-11: Exclusion pane fields
Field Description
Type Node or link.
ID Node or link user label.
Parent Topic

8.4.5 Configuring OAM for Bidirectional Tunnels

The OAM tab is only available after Bidirectional has been selected for Directionality in the Tunnel
Parameters tab. You can configure BFD, an MPLS-TP OAM feature, and/or LDI for these tunnels.
 Bidirectional Forwarding Detection (BFD)
MPLS-TP tunnel OAM for bidirectional tunnels is based on Bidirectional Forwarding Detection (BFD), a
simple Hello protocol used to verify connectivity between systems. A pair of systems transmits BFD
packets periodically over each path between the two systems. If a system stops receiving BFD packets
for some preconfigured period of time, a component in that particular bidirectional path to the
neighboring system is assumed to have failed. Our equipment supports BFD for MPLS-TP in
bidirectional tunnels, enabling tunnel OAM that monitors endpoints and PWs running over the
tunnel.
 Link Down Indication (LDI)
The LDI message is generated in response to detecting a fatal failure in the server layer (MoE / MoT
port failure) on the LSP intermediate node. The server layer protection switch is activated when the
failure in the server layer occurs, but if the protection switch was unsuccessful in restoring the link
within the expected LDI Holdoff, an LDI messages must be sent periodically until the condition is
cleared.

Table 8-12: OAM tab
Field Description
General
Control Channel CoS Select the CoS channel to use (only channels that are
Reversion Mode Mode of Operation after system recovers from the failure
 Revertive: Returns to the main LSP.
 Non-revertive: Remains as is, and the Protected LSP becomes
the Main, and the fixed LSP becomes the protected.
WTR (Wait-To-Restore) The amount of time, in minutes, that the system waits before
switching. Used to prevent frequent switching.
Main LSP
BFD Enable/Disable BFD on the main LSP.
LDI Enable/Disable LDI on the main LSP
BFD Period (ms) The interval amount of time to transmit the BFD packets for the main
LSP.
Hold-Off Time on main LSP Amount of time to delay the linear protection operation on the main
LSP, and to let underlying protection take place. If the underlying
protection succeeds, the linear protection does not go into effect.
Protection LSP (Available only for Protected Tunnels)
BFD Enable/Disable BFD on the protected LSP
LDI Enable/Disable BFD on the protected LSP
BFD Period (ms) The interval amount of time to transmit the BFD packets for the
protected LSP.
Hold-Off Time on protection LSP Amount of time to delay the linear protection operation on the
protected LSP, and to let underlying protection take place. If the
underlying protection succeeds, the linear protection does not go
into effect.
Parent Topic
8.4.5.1 Editing OAM Parameters for Bidirectional Tunnels

You can edit OAM Parameters for Bidirectional Tunnels only. If unidirectional tunnels are also selected,
they appear in the list of tunnels, but changes are not applied to them. Only fields relevant to the tunnel(s)
selected are editable. All other fields appear gray.
If you select a single Bidirectional tunnel, the Edit OAM window displays the actual values of the tunnel,
and you can modify them accordingly.
If you select more than one Bidirectional tunnel, the values for individual tunnels are not displayed, and all
fields display 'N/A' in the Edit OAM window. You can then modify the parameters that you want to change.
The changes are applied to all bidirectional tunnels listed.
If the bidirectional tunnels includes at least one linear protected tunnel, LSP protection parameters are
enabled, however any changes made to the LSP parameters are applied to linear protected tunnels only.

LIMITATIONS: The BFD period cannot be modified when BDF is enabled. To modify the BDF
period,
1. Disable BDF, and click OK.
2. Edit the BDF period, and then enable BDF again.
To edit OAM Parameters:

1. In the Tunnels List, right-click the relevant bidirectional tunnel(s) and select Edit > Edit OAM. The Edit
OAM window opens, showing the selected tunnel(s).
2. Edit the relevant fields, as described in the table below, and click OK. A message is displayed, showing
how many tunnels were successfully modified. Any failures are also listed, with the reason for the
failure.

Table 8-13: Edit OAM fields
Field Description
General
Control Channel CoS Select the CoS channel required (only a channel that appears in all
CoS BW tables can be selected).
Reversion Mode Linear Protected tunnels only: Mode of Operation after system
recovers from the failure.
 Revertive: Returns to the main LSP.
 Non-revertive: Remains as is, and the Protected LSP becomes
the Main, and the fixed LSP becomes the protected.
Linear Protected tunnels only: The amount of time, in minutes, that
WTR (Wait-To-Restore)
the system waits before switching. Used to prevent frequent
switching.
Main LSP
BFD Enable/Disable BFD on the main LSP.
LDI Enable/Disable LDI on the main LSP
main LSP.
Hold-Off Time on main LSP Linear Protected tunnels only: Amount of time to delay the linear
protection operation on the main LSP, and to let underlying
protection take place. If the underlying protection succeeds, the
linear protection does not go into effect.
Protection LSP (Available only for Protected Tunnels)
BFD Enable/Disable BFD on the protected LSP. Note: Switching BFD to
disabled affects the actual tunnel protection. When disabled, the
tunnel is unprotected until BFD is re-enabled.
LDI Enable/Disable BFD on the protected LSP.
protected LSP.
Hold-Off Time (on protection LSP) Amount of time to delay the linear protection operation on the
protected LSP, and to let underlying protection take place. If the
underlying protection succeeds, the linear protection does not go
into effect.
Parent Topic

8.4.5.2 Viewing OAM Status and Performing Protection Switching

You can view the OAM status and perform protection switching on bidirectional MPLS Tunnels. The OAM
Status and Maintenance Operations window show a separate entry for the snc of the head end and the snc
of the tail end of each tunnel. You can also perform the following maintenance commands related to
protection switching:
 Forced switch: Switches traffic to Protection LSP, unless an equal or higher priority switch-over
command is in effect.
 Manual switch: Switches traffic to Protection LSP, unless a fault condition exists on the
Protection LSP or an equal or higher priority switch-over command is in effect.
 Protection Lockout of Protection: the Protection LSP is unavailable for traffic.
 Release (default): An action, initiated externally, that clears the active external command.
NOTE: Only one maintenance command can be performed on a tunnel at a time.

For bidirectional tunnels, Force Switch, and Lock Out maintenance commands should be
performed manually before starting NMS operation.
To view OAM Status and perform maintenance operations:

1. From the Tunnel List window, right-click the relevant tunnel and select Other and then OAM Status
and Maintenance Operations. The OAM Status and Maintenance Operations window opens.
The OAM Status and Maintenance Operations window displays details of each tunnel head and tail, as
detailed in the following table.
2. To perform a maintenance command, select the relevant tunnel and click either:
 Forced switch: Switches traffic to Protection LSP, unless an equal or higher priority
switch-over command is in effect.
 Manual switch: Switches traffic to Protection LSP, unless a fault condition exists on the
Protection LSP or an equal or higher priority switch-over command is in effect.

 Protection Lockout of Protection: the Protection LSP is unavailable for traffic.
 Release (default): An action, initiated externally, that clears the active external command.
3. Click Close.
Table 8-14: OAM Status and Maintenance Operations Fields
Parameter Description
ID of the tunnel.
NMS Tunnel ID
Tunnel Name Name of the tunnel.
PE Name Name of the PE.
PE Role Tunnel Head and Tail details (Bidirectional Tunnels only).
Tunnel Operational State BD tunnel operation state. Possible values include:
 Up: at least one LSP is operative.
 Down: all tunnel LSPs are failed.
 N/A (default): not applicable.
PSC State Protection Switch Coordination (PSC) protocol state per SNC. Relevant
for Head & Tail SNC. Possible values:
 N/A (Default) not applicable.
 Normal: Protection and working paths are active and fully
allocated. Data traffic is transported over the working path and no
trigger events are reported.
 Unavailable: Protection path is unavailable due to operator lockout
or detection of a failure condition on the protection path.
 ProtectingFailure: Failure condition reported on the working path,
and user traffic is being transported on the protection path.
 Protecting Administrative: Operator issued a command switching
user traffic to the protection path.
 WTR (Wait to Restore): Protection domain is recovering from an SF
condition on the working path that is controlled by the WTR timer.
 DNR (Do Not Revert): Protection domain has recovered from a
protecting state, but the operator has configured the protection
domain not to revert to Normal state upon recovery. PSC state
remains DNR until the operator issues a command to revert to
Normal, or a trigger occurs to change the state again.
Main BFD State Main LSP local BFD session state at the head & tail PE of a bidirectional
tunnel. Possible values include:
 AdminDown: BFD session is held down administratively.
 Down: BFD session is down.
 Up: BFD session is working.
 Unknown: BFD session state is unknown.
Main LDI Indicates whether an AIS Link Down indication is present for the Main
LSP in the Head & Tail PE.

Parameter Description
BFD Session Up Time The time that has elapsed since the BFD session last entered an Up
state. When the BFD session exists an Up state, the timer stops. When
the BDF session enters an Up state, the timer is reset.
Only applicable to Head & Tail protection on a bidirectional LSP.
Protection BFD State Protection LSP local BFD session state at the head & tail PE of a
bidirectional tunnel. Possible values include:
 AdminDown: BFD session is held down administratively.
 Down: BFD session is down.
 Up: BFD session is working.
 Unknown: BFD session state is unknown.
Protection LDI Indicates whether an AIS Link Down indication is present for the
Protection LSP in the Head & Tail PE.
Protection BFD Session Up Time The time that has elapsed since the BFD session last entered an Up
state. When the BFD session exists an Up state, the timer stops. When
the BDF session enters an Up state, the timer is reset.
Only applicable to Head & Tail protection on a bidirectional LSP.
Maintenance Command Maintenance command for a bidirectional 1:1 protected tunnel. The
following maintenance commands can be applied to MPLS Head & Tail
SNCs:
 Lockout of Protection: Protection LSP is unavailable for traffic.
 Forced switch: Switches traffic to the Protection LSP, unless
another switchover command of equal or higher priority is in
effect.
 Manual switch: switches traffic to the Protection LSP, unless a fault
condition exists on the Protection LSP, or a switchover command
of equal or higher priority is in effect.
 Manual Reversion: switches traffic to the Working LSP, unless a
fault condition exists on the Working LSP, or a switchover
command of an equal or higher priority is in effect.
 Release: an action that is initiated externally to clear the active
external command.
 N/A (default): Not applicable
Parent Topic

8.5 Hierarchical CoS (HR-CoS) Tunnels

E-LSP tunnels can be defined with Hierarchical CoS (HR-CoS), which enables limiting the bandwidth of E-LSP
tunnels in mobile backhaul networks. In HR-CoS tunnel traffic management, weights in the same CoS
priority level and a strict high priority CIR over low priority CIR are applied.
LightSoft uses the following equation to calculate the CIR (Aligned BW) for HR-CoS tunnels:
NOTE: Some nodes do not support HR-CoS. For these nodes, the allocated bandwidth is
calculated differently.
To create an HR-CoS tunnel, create an E-LSP tunnel as described in Creating a Tunnel. In the Basic
Parameters pane, select the BW Limit (Mb/s) option and enter the BW limit (see Basic Parameters Pane).

In the Tunnels Pane (in the Tunnel List Window), you can identify HR-CoS tunnels by displaying the BW
Limit and Aligned BW (Mb/s) columns (see Tunnels Pane Columns). HR-CoS tunnels appear with values in
these columns.
You can also convert existing E-LSP tunnels into HR-CoS tunnels. See Converting Tunnels into HR-CoS
Tunnels.
Parent Topic
8.6 Virtual RSVP Tunnel Type

When Virtual RSVP tunnels are included in the Tunnels List table, the parameters pane includes a third
Tunnel Type option, Virtual RSVP. This tunnel type cannot be reset by the user; the value is defined
automatically at the time that the Virtual RSVP tunnels are originally created through GCT to StubEMS or
STMS. These tunnels are used in VLAN Tree service. The tunnel endpoints are either VNEs created through
StubEMS or CESR platforms managed through STMS. See Configuring Virtual RSVP Tunnels.
Figure 8-34: Virtual RSVP tunnels included in Tunnels List
Parent Topic

8.7 Automatic Multi-Tunnel Creation

OPTIONAL FEATURE: LightSoft's tunnel automation toolset is a fully integrated add-on
capability, available on a cost basis. If not purchased, this feature and related menu
commands are unavailable.
An MPLS network can include up to 256 PEs. The full tunnel mesh connecting every two points can involve
a great numbers of tunnels. In addition, creating bypass tunnels for comprehensive protection to multiple
nodes and links can be a daunting task. LightSoft's optional automation functions greatly simplify the
processes.
LightSoft enters default values or the last used parameters, where applicable. See the pane descriptions for
mandatory parameters.
The following types of multi-tunnel creation are supported:
 Create Tunnel Mesh: Full mesh of working tunnels between the selected nodes. (When a node is
added to an existing mesh, only the additional tunnels are created. The new tunnels have the same
tunnel parameters as the existing mesh tunnels.)
 Create Multiple Bypass: Node or link-protecting bypass tunnels to protect the selected objects.
 Create Root and Leaf Tunnels: Multiple tunnels in a multi-rooted topology, providing the tunnel
infrastructure for P2MP services.
NOTE: The automation functions are recommended for use only by advanced users or with
the assistance of your local Customer Support representative.
In most cases, the toolbar buttons and menu options available during automatic tunnel creation are similar
to the options available during standard tunnel creation. Fields or options that are not relevant for the
selected type of tunnel are either not displayed or disabled. For more information, see:
 Creating Tunnels
 Create Tunnel Menu and Toolbar
 Basic Parameters Pane
 Advanced Tunnels Parameters Pane
 Selected Elements Pane
 Endpoints & Path Tab

To automatically create multi-tunnels:

1. (Optional) In the main window, select the objects containing the endpoints of the intended tunnels. A
Create window opens, displaying those objects and any associated MoT virtual links and MoE physical
links (rather than all the objects in the current view). When the PathFinder algorithm searches for
tunnels, it relates to the relevant topology, not only to the displayed elements.
2. In the main window Tunnels tab, in the Automation group, click either Create Tunnel Mesh or Create
Multiple Bypass or Create Root and Leaf. A window resembling the Create Tunnel window opens
with the relevant title.
3. Enter tunnel parameters that are common to all the required tunnels. Note that not all options listed
in this section are always available to the user; only options relevant for the selected tunnel type are
displayed or enabled. For example, in the preceding figure, tunnels configured with linear protection
must be bidirectional E-LSP tunnels, so these options are not enabled.
 Protection Desired, either Unprotected, Protected-FRR, Protected-Linear (1:1), or Bypass; see
Defining the Tunnel Parameters.
 FRR Type, either Node or Link.
 LSP Type, either E-LSP or L-LSP.
 Directionality, either Unidirectional or Bidirectional.
 CoS value(s); see CoS, Color, and BW Selections for a Tunnel.
For other parameters, you can accept default parameter values or you can select specific values.
Defaults are the last tunnel entry values. See the parameter descriptions in Tunnel Parameters.
To reset tunnel parameters to the default value, click Reset tunnel parameters to defaults .

4. When Bidirectional tunnels are selected, the following options are available:
 Configure BFD, LDI, and other OAM parameters. The OAM tab appears only after selecting
Bidirectional for Directionality. For further instructions, see OAM for Bidirectional Tunnels.
 Enable asymmetric setting radio button; see CoS, Color, and BW Selections for a Tunnel.
 Enable partial protection setting radio button; see CoS, Color, and BW Selections for a Tunnel.
5. For Full Mesh do the following:
a. In the Create window map, select PEs amongst which to create the full tunnel mesh. They are
listed in the Selected Elements pane.
 Select an object. It is listed in the Selected Elements pane.
OR
 Select multiple objects by holding down the SHIFT key, OR
Select all the objects in a rectangle area of the map by clicking and dragging (only objects
relevant to your current action are used).
Then right-click any object and select the applicable Select option (according to
parameters selected in the window panes). The selected objects are listed in the Selected
Elements Pane.
Use the main window Topology tab Search to locate a PE in the map.
To clear one selection:
 Click a selection in the map or right-click it and select Remove,
OR
 Right-click a selection in the Selected Elements pane and select Remove.
To clear all selections:
 Select Remove All.
OR
 Click Clear all endpoints and path .
NOTES:
 Nodes must reside within the same MPLS network.
 Secondary LEs that contain the endpoint ports should be selected, not their source
primary LEs.
)
b. To change the order of priority in which tunnels are built, select an object and click Up or Down.
OR

6. For Multiple Bypass: In the Create window map:

a. Select PEs or links for which to create Bypass tunnels, according to whether Link Protection or
Node Protection applies. The selections are listed in the Selected Elements pane.
The same selection procedures apply as in Step 4.
b. To change the order of priority in which tunnels are built, select an object and click Up or Down.
OR
7. For Root and Leaf Tunnels, select a path preference, roots, leaves, inclusions, and exclusions, as
required:
a. Path Preferences: Select the direction in which tunnels are created:
 Downstream: Creates the tunnels on the segments flowing out from the selected root to
leaves.
 Upstream: Creates the tunnels on the segments flowing in to the selected root from
leaves.
 Both: Creates the tunnels in both directions. When selected, choose:
 Same path: Return path must trace the same path in opposite direction.
 Different path: Return path should be another path.
 No Preference: PathFinder may select the return path by other optimization criteria.
b. Roots: Select the roots for which tunnels are created:
 Choose Roots in the toolbar.
 On the map, select up to 4 PEs that serve as roots. They are listed in the Roots pane.
 To change the order of priority in which tunnels are built with respect to roots, select a
root and click Up or Down.
c. Leaves: Select the leaves for which tunnels are created:
 Choose Leaves in the toolbar.
 Select any number of PEs in the map that serve as leaves. Tunnels are created from/to
each root and each leaf. The leaf PEs are listed in the Leaves pane.
d. To change the order of priority in which tunnels are built with respect to leaves, select a leaf
and click Up or Down.
e. Inclusions: Include segments and nodes that must be included in tunnels involving selected
roots. Inclusions cannot be selected while the Both direction is active; see the note in the
Direction description in Endpoints & Path Tab.
 Choose Inclusions in the toolbar.
 Select a root in the Roots pane (inclusions are per root).
 Select a node or link in the map which must be included in the tunnel path.
 If a link is selected, a Select Link window opens, listing the available segments and
directions.

 Select a specific link and associated direction icon (in the port cell) to designate the
applicable segment direction. Non-meaningful directions are disabled.
The selected nodes and links are listed in the Explicit Path Include pane.
 Repeat the process for
 The other segment direction if required.
 Any other segments or nodes, for the current or any other root.
f. Exclusions: Exclude segments and nodes involving selected roots that should not have tunnels
traversing them. Exclusions cannot be selected while the Both direction is active; see the note in
the Direction description in Endpoints & Path Tab.
 Click Exclusions in the toolbar.
 Make selections to exclude segments and nodes from the Automation process in the same
way as Inclusions, in the preceding step. The selected nodes and segments are listed in the
Explicit Path Exclude pane.
NOTE: Tunnels are not created if there are no feasible paths that satisfy specified inclusions
and exclusions.
8. Start automatic tunnel creation by clicking Start Tunnel Creation .

The process may take several minutes. A progress bar opens at the bottom of the window indicating
the number of tunnels processed at any point out of the total number defined by your selections.
The progress bar includes a Stop option which enables you to abort the processing if required.
The processing is aborted after the tunnel currently in process is built.
9. When the tunnel building process is completed, a Results pane opens showing the tunnels that were
processed (succeeded or failed).

Select tunnel lines in this list (by highlighting one or selecting multiple checkboxes or clicking Select
All) and click Show Tunnel. The Tunnel List window opens, displaying those tunnel(s). You can also
perform other operations on the listed tunnels; see Results Pane.
10. Close the Create window.
NOTE: There may be a residue of tunnels that are not created automatically due to CAC
compliance issues. Deal with these manually after the automation process is completed.
Parent Topic
8.7.1 Automation Windows

The Create Tunnel Mesh, Create Multiple Bypass, and Create Root and Leaf Tunnels windows (also
referred to as Automation windows) display information about the current automatic tunnel creation
setup.
The Create Tunnel Mesh window is shown below. The Create Multiple Bypass window has the same layout
but with different parameters enabled, as described in context.
Figure 8-35: Create Tunnel Mesh window

The Create Root and Leaf Tunnel window has a slightly different layout.
Figure 8-36: Create Root and Leaf Tunnels window
The Tunnel Automation feature includes some or all of the following configuration panes. Only feature
relevant for the selected tunnel type are displayed:
 Map View: Graphical representation of all or preselected objects and their associated MoT virtual links
and MoE physical links, with the relevant Ethernet LEs automatically split out; see Map View.
 Tunnel Parameters tab: Tunnel parameter entry panes for basic and advanced parameter sets; see
Basic Parameters Pane , Advanced Tunnels Parameters Pane , and Selected Elements Pane.
 OAM tab (bidirectional tunnels only): OAM configuration for bidirectional tunnels including BFD and
LDI. See Configuring OAM for Bidirectional Tunnels.
 Endpoints & Path tab (Root&Leaf tunnels only): List of selected tunnel endpoints, the tunnel
resources along its entire path, and explicit path user selections comprising excluded and included
nodes and links. See Endpoints and Path.
 Paint options (Root&Leaf tunnels only): The standard tunnel coloring options; see Create Tunnel
Menu and Toolbar.
 Select options (Root&Leaf tunnels only): For tunnel path definition purposes, enables selection in the
window map of nodes as Roots or Leaves, or links/nodes to be explicitly included (Inclusions) or
excluded (Exclusions) from the tunnel path.
 Results pane: Displays the tunnels that were processed (succeeded or failed) following a Create
Tunnel action; see Results Pane.
In most cases, the toolbar buttons and menu options available during automatic tunnel creation are similar
to the options available during standard tunnel creation. Fields or options that are not relevant for the
selected type of tunnel are either not displayed or disabled. The following table lists the toolbar buttons
that are relevant for automatic tunnel creation only. For a description of general tunnel creation toolbar
and menu options, see Create Tunnel Menu and Toolbar.

Table 8-15: Create Tunnel Mesh and Multiple Bypass window toolbar icons
Name Icon Description

Open
Create Tunnel Mesh Opens a Create Tunnel Mesh window in another view.
Create Multiple Bypass Opens a Create Multiple Bypass window in another view.
Create Root and Leaf Opens a Create Root and Leaf Tunnels window in another view.
Tunnels
Parent Topic
8.7 Automatic Multi-Tunnel Creation
8.7.1.1 Selected Elements Pane

This pane lists the PEs or links across which tunnels or bypass tunnels are built. Tunnels already existing
among the PEs are not shown in the list.
This pane applies to the Create Tunnel Mesh and Create Multi Bypass windows only. For the Create Root
and Leaf Tunnels window, the Endpoints and Path pane is used instead; see Endpoints & Path Tab.
Figure 8-37: Tunnel Mesh and Multi Bypass Tunnels Selected Elements pane
Tunnels are built for each CoS listed in the Basic parameters pane and for each node or link in the order
listed in the Selected Elements pane:
 Create Tunnel Mesh: For each CoS, LightSoft creates tunnels for the first-listed node bidirectionally
to/from all other nodes in the mesh. LightSoft then continues to the next-listed node.
 Create Multi Bypass: For each CoS, LightSoft creates:
 For listed links - Next hop bypass tunnels bidirectionally to protect the first-listed link; then
continues to the next-listed link, etc.
 For listed nodes - Next next hop bypass tunnels bidirectionally to protect the first-listed node
over each combination of links that traverses it. It then continues to the next-listed node, etc.
The process continues as permitted by BW limitations and CAC. Objects at the bottom of the list may
therefore not be handled successfully because of insufficient BW. Set the order of the objects according to
required priority. You can change the order by selecting an object and clicking Up or Down to promote or
demote them as needed.

Table 8-16: Automation window Selected Elements pane fields
Field Description
# Number indicating the priority of the nodes or links for which PathFinder is creating
tunnels or bypass tunnels. PathFinder handles the nodes or links in this order, as
permitted by BW limitations and CAC.
Link/Node Link or node.
ID Link or node user label.
Parent Topic
8.7.1.2 Endpoints & Path Tab

This tab lists the PEs or links across which root and leaf tunnels are built.
This tab applies to the Create Root and Leaf Tunnels window only. For the Create Tunnel Mesh and Create
Multi Bypass windows, the Selected Elements Pane is used instead.
For each CoS listed in the Basic parameters pane, tunnels are built from each root to each leaf in the order
listed in the Roots and Leaves panes. The paths observe specified inclusion and exclusion conditions per
root.
The process continues as permitted by BW limitations and CAC. Objects at the bottom of the list may
therefore not be handled successfully because of insufficient BW. Set the order of tunnel creation amongst
the specified roots and leaves according to required priority. You can change the order by selecting an
object and clicking Up or Down to promote or demote them as needed.
Figure 8-38: Root and Leaf Tunnels window Endpoints & Path tab

Table 8-17: Automation window Selected Elements pane fields
Field Description
Path Preferences pane
Direction Defines whether the tunnels should be created flowing into the root from leaves, or
out of a root to leaves, or both:
 Downstream - Creates the tunnels on the segment direction from roots to
leaves only.
 Upstream - Creates the tunnels on the segment direction from leaves to roots
only.
 Both - Creates tunnels in both segment directions.
Note: When Both is selected, inclusions or exclusions cannot be selected. If you
require both upstream and downstream tunnels to be created and also some
objects included/excluded to/from the tunnel building process, you can perform two
separate automation processes, first specifying one direction (Downstream or
Upstream) with required inclusions and exclusions, then specifying the other
direction.
Upstream vs. When Both is selected in Direction, select whether the return path should be the
Downstream Path same or different from the initial path.
 Same path - The return path must trace the same path in opposite direction.
 Different path - The return path should be another path, for example, for SRLG
minimization purposes; for details, see Shared Risk Link Groups (SRLGs).
 No Preference - PathFinder may select the return path by other optimization
criteria.
Roots pane
Roots list Lists the (up to 4) roots selected in the map for which tunnels will be created. (Click
Roots in the toolbar to start selecting roots.)
 Order of priority: Indicates the order in which root nodes will be dealt with by
the tunnel creation process.
 Link/Node: Node.
 ID: ID of the selected node.
Up and Down Used to change the order of priority in which the tunnels will be created on the
listed roots. Click Up or Down to promote/demote a selected root entry.
Leaves pane
Leaves list Lists the leaves selected in the map for a specific root for which tunnels will be
created. (Click Leaves in the toolbar and a root in the Roots pane to start selecting
leaves.)
 Order of priority: Indicates the order in which leaf nodes will be dealt with by
the tunnel creation process.
 Link/Node: Node.
Up and Down Used to change the order of priority in which the tunnels will be created on the
listed leaves. Click Up or Down to promote/demote a selected leaf entry.

Field Description
Explicit Path Include
Inclusions list Lists the links or nodes selected in the map that must be included in the tunnel path
for a specific root. Inclusions are selected per root. Click Inclusions in the toolbar
and a root in the Roots pane to start selecting inclusions. The link selection process
includes a segment direction arrow selection.
The pane's information columns include:
 Order of priority: Indicates the order in which nodes/links to be explicitly
included will be dealt with by the tunnel creation process.
 Link/Node: Link or Node.
Note: Inclusions cannot be selected while the Both direction is active; see Direction
field description.
Tip: Clicking on a root in the Roots pane displays its associated inclusions in the
Explicit Path Include pane and the map view. If multiple roots are selected,
inclusions are only listed if all of them are common to all the selected roots.
Otherwise the Explicit Path Include pane will be empty.
Explicit Path Exclude
Exclusions list Lists the links or nodes selected in the map that must not be included in the tunnel
path for a specific root. Exclusions are selected per root. Click Exclusions in the
toolbar and a root in the Roots pane to start selecting inclusions. The link selection
process includes a segment direction arrow selection.
The pane's information columns include:
 Order of priority: Indicates the order in which nodes/links to be explicitly
excluded will be dealt with by the tunnel creation process.
 Link/Node: Link or Node.
Note: Exclusions cannot be selected while the Both direction is active; see Direction
field description.
Tip: Clicking a root in the Roots pane displays its associated exclusions in the Explicit
Path Include pane and the map view. If multiple roots are selected, exclusions are
only listed if all of them are common to all the selected roots. Otherwise the Explicit
Path Exclude pane will be empty.
Parent Topic

8.7.1.3 Results Pane

The Results pane for the applicable Create window displays pathfinding results for the tunnels that were
processed. This pane opens at the end of the automatic Create Tunnel process, or it can be exposed by
pulling up the progress bar at the bottom of the window.
Figure 8-39: Automation Results pane
Table 8-18: Full Tunnel Mesh or Multiple Bypass Results toolbar icons
Icon Icon Name Description

Select All Selects all tunnels in the Results window.
Deselect All Deselects all tunnels in the Results window.
Show tunnel in another window Opens a Show Tunnel window in a different

view showing the specific tunnel in map view
and its parameters in the panes; see Show
Tunnel in Another View.
Show tunnel in Tunnel List window Opens a Tunnel List window showing the
selected tunnels; see Tunnel List Window.
Show Result Info for selected items Displays detailed results for the selected tunnel
line. See Performing Tunnel Operations.
Export tunnels to CSV Exports list data to a delimited format file like
CSV for import to Microsoft Excel or a relational
database application. See Exporting to CSV.
Print List Prints the contents of the Results pane, or
selected tunnels only.

Table 8-19: Full Tunnel Mesh or Multiple Bypass Results window contents
Column Notes
Selection checkbox. Menu options and the pane icons are enabled when at
least one tunnel is selected.
NMS Tunnel ID LightSoft tunnel identifier for this tunnel; see description in General
Parameters Pane.
Tunnel State Synchronization state for this tunnel (OK, Inconsistent, or Incomplete). See
Status Parameters Pane.
CoS Class of service; see Basic Parameters Pane.
Source PE PE at the Head of the tunnel.
Dest. PE Destination PE at the Tail of the tunnel.
LightSoft Result Result of the operation in LightSoft, for example Tunnel Created.
EMS Result Result of the operation in the EMS, for example, All XCs created in EMS.
Parent Topic

9 Performing Actions on Tunnels
This section describes the tunnel management interface for ongoing tunnel-related operations. A full range
of operations on existing tunnels can be performed using either the Tunnel List window or LightSoft main
window options.
9.1 Accessing the Tunnel List Window

The Tunnel List window (see Tunnel List Window) opens with different object combinations according to
preselections in the LightSoft main window:
 If no objects are preselected in the main window:
 Tunnel List window Map View shows all objects and associated MoT virtual links and MoE
physical links appear in the window map, including MPLS-relevant LEs, automatically split out
from their respective MCS MEs (consistent with your user permissions) and their associated
MoT virtual links and MoE physical links.
 Tunnels pane includes tunnels based on the default filter.
TIP: Opening the Tunnel List window may take less time if you choose "No Tunnels" as the
default filter. You can then select a different filter. For details, see Applying a Filter and Setting
it as Default.
 If objects are preselected in the main window:

 The Tunnel List window map opens with only those objects and their immediately associated
links/elements.
 The Tunnels pane shows only the associated tunnels. In this case, a "Temporary" filter applies
(the default filter is disregarded). If required, you can create a new filter based on the
temporary filter objects; see Creating a Filter with Preselected Objects.
User preference options also affect how tunnels appear in the Tunnel List window view; see Options Pane
in Tunnel Management Appearance Preferences in the Getting Started & Administration Guide).
A wide range of additional filter options are also available; see Filtering the Tunnels Pane.
A variety of utilities are available from the Tunnel List window. These are described in Tunnel List Window.
You can open multiple Tunnel List windows simultaneously, each displaying selected elements and view of
the network, and allowing different tunnel operations.

LightSoft® User Guide Performing Actions on Tunnels
To open the Tunnel List window:

1. (Optional) For ease of work and improved performance in larger networks, you can open the Tunnel
List window with links running between a limited number of PEs and corresponding limited tunnels in
the Tunnels pane. To do this:
 Ensure that the appropriate tunnel filter is set as the default. For information about available
predefined filters and how to set one as the default, see Filtering the Tunnels Pane.
OR
 Select any combination of specific virtual links (MoT trails), physical links, MEs, PEs, and EMSs
for which to display tunnels in the main window map or elements in the Inventory tree. (If more
than one view is open, the selections in the most recently opened view apply.) The Tunnel List
window map opens with only those elements and links, and the Tunnels pane displays only
associated tunnels. In this case, the default filter is overridden.
2. In the main window Tunnels tab, in the General group, click Tunnel List.
Similar windows are used for creating and synchronizing tunnels; see Provisioning MPLS Tunnels and
Synchronizing Tunnels.
Parent Topic
9.2 Tunnel List Utilities

You can perform the following tunnel procedures.
To view a tunnel route in the map view:

1. Select a tunnel in the Tunnels pane.
2. Click Show highlighted tunnel on map or right-click and select Show > Show Tunnel.
To show/hide the Tunnel Parameters/Endpoint/Path panes:
 Click Show/Hide Details .
To recalculate tunnel parameters:

 Some tunnel parameters (for example, Tunnel Length) show "On Demand" as their value when first
loaded. Click Show On Demand Parameters to calculate the current values.
Parent Topic

9.3 Tunnel List Window

The Tunnel List window enables viewing and filtering tunnel information. It features a graphical
representation of all or preselected MPLS objects in the ETH/MPLS topology layer, a filtered list of existing
tunnels, and detailed information about a selected tunnel. For information about opening the window, see
Accessing the Tunnel List Window.
Figure 9-1: Tunnel List window
You can view parameters, endpoints, and paths of tunnels belonging to multiple MPLS networks.
The window includes the following panes:
 Map View : Shows the elements and the MoT virtual links and MoE physical links of the selected
topology view.
 Tunnels Pane : Lists all or a filtered set of tunnels, and enables you to select specific tunnels for various
operations.
 Tunnel Parameters Tab : Displays detailed information about a selected tunnel, and enables you to
modify some information.
 Basic Parameters Pane : Configures basic tunnel parameters.
 Advanced Tunnels Parameters Pane : Configures more specific tunnel parameters.
 Protection Parameters Pane : Shows tunnel FRR parameters.
 Status Parameters Pane : Shows status-related parameters.
 General Parameters Pane : Shows general tunnel parameters.
 Endpoints and Path Tab : Displays the endpoints of a selected tunnel.
 Endpoints Pane : Lists details of a tunnel's endpoints.
 Path Pane : Lists details of each node along the tunnel path.
 Explicit Path Include Pane : Lists explicitly included path characteristics.
 Explicit Path Exclude Pane : Lists explicitly excluded path characteristics.

These panes are parallel to the same-name panes in the Create Tunnel process. Some parameters from that
process can be modified directly through the Tunnel Parameters tab Edit Attributes function; see
Tunnel Parameters Tab. Tunnel bandwidth, protection, and P2MP service endpoints can be modified; see
Editing Tunnels. For the parameter descriptions, see the applicable sections in Creating Tunnels.
Parent Topic
9.3.1 Tunnel List Menu and Toolbar

The following functions are available in the Tunnel List window menu and equivalent toolbar icons.
Some functions are available from a shortcut menu, displayed by right-clicking a row in the Tunnels pane;
see Tunnels Pane Shortcut Menu.
Table 9-1: Tunnel List menu and toolbar icons
Menu option Toolbar Description

icon
Paint menu
Path Highlights the tunnel path in the map.

Explicit Path Highlights specific link/port inclusions or exclusions in the map.
Path & Explicit Highlights both the tunnel path and specific link/port inclusions or
Path exclusions.
List menu
Select All Selects all tunnels in the Tunnels pane.

Deselect All Clears all tunnel selections in the Tunnels pane.
Load More Loads an additional increment of filter-defined tunnels, up to a
configurable limit. For information about configuring the Load more
tunnel limits, contact your local Customer Support representative.
Load All Loads all filter-defined tunnels in the network.
Refresh List Reloads the Tunnel List window and Tunnels pane, showing newly
created tunnels. All tunnels in the Tunnels pane become unselected.
Tunnels continue to be listed according to the active filter.
Export to XML Exports the tunnels selected in the Tunnels pane to an XML file for
network planning or backup purposes; see Exporting Tunnels.
Export to CSV Exports list data to a delimited format file like CSV for import to
Microsoft Excel or a relational database application. See Exporting to
CSV.
Print List Prints the contents of the Tunnels pane, or selected tunnels only.


icon
Tunnel menu
Edit
Add Subtunnel Adds a subtunnel to a P2MP tunnel; see Adding P2MP Tunnel Tail
Endpoints.
Remove Removes a subtunnel from a P2MP tunnel; see Removing P2MP Tunnel
Subtunnel Tail Endpoints.
Edit Bandwidth Modifies the bandwidth of selected tunnels regardless of their original
specific bandwidths, to a common value; see Editing Tunnel Bandwidth.
Protection  Remove FRR Protection: Removes bypass tunnel assignments from
the selected protected tunnels.
 Update FRR Protection: Assigns FRR bypass tunnels to the selected
protected tunnels.
 Update EFRR Protection: Assigns EFRR bypass tunnels to the
selected protected tunnels.
 Make Protected: Changes the Protection Desired of the selected
unprotected tunnels from Unprotected to Protected.
 Make EFRR Protected: Changes the Protection Desired of the
selected unprotected tunnels from Unprotected to EFRR Protected.
 Make Unprotected: Changes the Protection Desired of the selected
protected tunnels from Protected to Unprotected.
 Unassign: Unassigns the selected bypass tunnels from all their
protected tunnels.
For more information about Update FRR, see Updating FRR Protection.
For more information about other functions, see Editing Tunnel
Protection.
Delete
Delete Tunnels Deletes the tunnels whose checkboxes are selected in the Tunnels pane
from DB and from all databases (LightSoft and EMS). (If no tunnels are selected,
Network deletes the highlighted tunnel. If tunnels are selected, deletes only the
selected ones.) For more details, see Deleting Tunnels.
Delete Tunnels Deletes tunnels in the LightSoft database only, leaving it intact in the
from DB Only EMS database; for more details, including purposes of this option, see
Deleting Tunnels.
Show
Show Tunnels Shows selected tunnels and their associated objects by themselves in a
new Show Tunnel window; see Show Tunnel in Another View. This
differs from the function of the Show Tunnel icon in the Tunnels pane
toolbar, which highlights the currently selected tunnel's path in the
Tunnel List map view.
Show On Demand Some tunnel parameters (for example, Tunnel Length) show "On
Parameters Demand" as their value when a tunnel is first loaded or configured.
Clicking this icon initiates a calculation process which displays current
values for all such parameters. (The process may take some time.)


icon
Show Services Opens the Service List window showing the services defined on the
selected tunnel; see Viewing Associated Traffic Entities.
Show Trails Opens the Trail List window showing the trails that the selected tunnel
traverses; see Viewing Associated Traffic Entities.
Show Protected Opens a list of tunnels protected by a selected Bypass tunnel. This
Tunnels includes all the tunnels to which the selected Bypass tunnel was
assigned, not only those actively using the tunnel; see Viewing
Utilities menu
Performance Current PM: Enables you to view current link performance for
Monitoring 15-minute or 24-hour intervals.
Set Trail PMH Enabled: Enable PMH data collection for selected trail.
Set Trail PMH Disabled: Disable PMH data collection for selected trail.
See Monitoring Trail Performance in the Performance Monitoring Guide.
Other
Reconnect Reconnects incomplete tunnels selected in the Tunnels pane. This
Tunnel(s) operation may be required if Tunnel State is Incomplete, for example if a
PE was disconnected while a tunnel is established in the network; see
Reconnecting Tunnels.
Current Alarms Opens the Current Alarms window showing alarms that would affect the
selected tunnels; see Viewing Alarms for Selected Tunnels.
Synchronize Opens the Tunnel Segment Consistency (TSC) window for the tunnels
Tunnels selected in the Tunnels pane. Tunnel synchronization is the process of
reconciling the differences between tunnel definitions in the LightSoft
database and the EMS. For more details, see Synchronizing Tunnels.
Filter menu
Edit Filter Edits a filter. Enabled only if objects were preselected in the main
window before the Tunnel List window was opened, or a user-defined
filter is selected.
Set Current as Sets a filter as default.
Default
Additional toolbar options
Show Last Result Displays detailed results of the last operation. Enabled only when the
Info last-performed operation was not completely successful. For more
information, see Performing Tunnel Operations.
Hide/Show Alternately hides the left-side details panes, leaving only the Tunnels
Tunnel Details pane and the window map, or reinstates the details panes.
Filter selector Filters the Tunnels pane according to the selected tunnel filter. For more
information about tunnel filters, see Filtering the Tunnels Pane.


icon
Parent Topic
9.3.2 Map View

The map view provides a graphic representation of all or preselected objects and their associated MoT
virtual links and MoE physical links, with the relevant Ethernet LEs automatically split out. When a tunnel is
selected in the Tunnels pane, its path is highlighted in the map view.
in the same way as in the LightSoft main map view, as described in Managing Elements and Groups.
Parent Topic

9.3.3 Tunnels Pane

The Tunnels pane lists a filtered set of tunnel records.
When the pane first opens, it displays up to 100 filter-defined tunnels. You can click Load more tunnel
and Load all tunnels to load more tunnels (see the toolbar icon descriptions below).
In the Tunnel List window, click Reload whole tunnel list to reload the Tunnels pane.
Clicking a tunnel in the pane makes it the focus of the information provided by other panes. Highlighting a
tunnel, or marking the checkbox of one or more tunnels, selects those tunnels for various tunnel
operations.
Click Show highlighted tunnel to view a selected tunnel's path in the map; see the toolbar icon
descriptions in Tunnels Pane Toolbar.
The following tunnel statistics are shown in the status bar:
 n/n (for example, 6/6): Number of tunnels filtered in/total number of tunnels that can be displayed.
 n items selected: Total of selected tunnels (with marked checkboxes).
Parent Topic

9.3.3.1 Tunnels Pane Toolbar

Table 9-2: Tunnels pane toolbar

Load More Loads an additional increment of filter-defined tunnels; see
parameter in Tunnels Show menu in Tunnel List Menu and Toolbar.
Load All Loads all filter-defined tunnels in the network; see parameter in
Tunnels Show menu in Tunnel List Menu and Toolbar.
Show highlighted When selected (default when the window opens), and a tunnel is
tunnel highlighted in the Tunnels pane, the tunnel and its endpoints are
highlighted on the map. Information about the tunnel is shown in the
window panes. Deselect the icon to disable this feature. This differs
from Show Tunnel List window toolbar option and the Tunnels pane
right-click option (see Tunnel List Menu and Toolbar and Tunnels
Pane Shortcut Menu), which shows selected tunnels and their
associated objects by themselves in a new Show Tunnel window; see
Show Tunnel in Another View.
Show On Demand Some tunnel parameters (for example, Tunnel Length) show "On
Parameters Demand" as their value when a tunnel is first loaded or configured.
Clicking this icon initiates a calculation process which displays current
values for all such parameters. (The process may take some time.)
Quick Filter Opens Quick Filter fields at the top of the pane, enabling you to
quickly filter the tunnels by Tunnel ID, name and/or customer; see
Creating a Quick Tunnel Filter.
Parent Topic
9.3.3 Tunnels Pane
9.3.3.2 Tunnels Pane Shortcut Menu

Some functions are available from a shortcut menu, displayed by right-clicking a row in the list.
These are the same options as in the Tunnel List window Tunnel menu, listed under Edit, Delete, Show,
Utilities, and Other submenus; see Tunnel List Menu and Toolbar.
Parent Topic
9.3.3 Tunnels Pane

9.3.3.3 Tunnels Pane Columns

You can choose which columns to show in the Tunnels pane. Standard column sorting and ordering
operations can also be performed in the pane; see Getting Started Guide.
Table 9-3: Tunnels pane columns
Column Description
Selection checkbox. Marking the checkbox of one or more tunnels selects
those tunnels for various trail operations (as described in context).
The currently highlighted tunnel (whether or not the checkbox is selected) is
the focus of the information shown in the Tunnel List window panes.
NMS Tunnel ID LightSoft tunnel identifier for this tunnel; see description in General
Parameters Pane.
Tunnel Name Name of the tunnel; see Basic Parameters Pane.
Customer Customer associated with this tunnel; see Basic Parameters Pane.
LSP Type Tunnel mode, whether E-LSP or L-LSP is supported for this tunnel; see Basic
Parameters Pane.
CoS Class of service applicable to the tunnel; see Basic Parameters Pane.
For E-LSP, all applicable CoS values with their related colors.
BW (Mbps) Bandwidth of this tunnel; see Basic Parameters Pane.
Protection Desired Protection desired for this tunnel (Unprotected, Protected, or Bypass); see
Basic Parameters Pane.
Protection Actual Actual protection applying to a protected tunnel. For more details, see
Protection Parameters Pane.
Dual FRR Value: Enabled/Disabled, or not applicable:
 For a bypass tunnel: Whether or not the bypass tunnel is set to provide
Dual FRR protection, based on the Dual FRR selection in the Advanced
Parameters pane.
OR
 For a P2MP tunnel: Whether or not a dual FRR-enabled bypass tunnel is
assigned to the tunnel.
For details about Dual FRR, see Dual FRR for Link and Node Protection.
Tunnel State Synchronization state for this tunnel (OK, Inconsistent, or Incomplete). For
more details, see Status Parameters Pane.
User Usage State  Idle – tunnel can be deleted from Tunnel List
 Active – tunnel cannot be deleted from Tunnel List
Tunnel Type Type of tunnel (P2P, P2MP, or Virtual RSVP). For information about these
tunnel types, see P2P and P2MP Tunnel Types and Virtual RSVP Tunnels.
Source PE PE at the head of the tunnel.

Column Description
Dest. PE Destination PE at the tail of the tunnel.
Tunnel Usage Bypass tunnel: Number of underlying protected tunnels.
Protected or unprotected tunnel: Number of underlying VPNs.
Tunnel OAM (CV) Enabled/disabled state of Tunnel OAM. For more details, see Advanced
Tunnels Parameters Pane.
E-LSP OAM CoS For E-LSP tunnel, enables selecting the CoS in which tunnel OAM will operate;
see Advanced Tunnels Parameters Pane.
Single Service Only Whether this tunnel is restricted to a single VPN. For more details, see
Advanced Tunnels Parameters Pane.
P2P Service Only Whether this tunnel is restricted to P2P VPNs. For more details, see Advanced
Tunnels Parameters Pane.
Actual No. of Hops Actual number of hops for this tunnel. For more details, see General
Parameters Pane.
Guaranteed FRR Desired Whether FRR is guaranteed along the whole path of the protected tunnel. For
more details, see Advanced Tunnels Parameters Pane.
Allocated BW (Mbps) Bandwidth allocated (reserved) for this tunnel. For more details, see Status
Parameters Pane.
Unreserved BW (Mbps) Unreserved bandwidth for the tunnel = BW minus Allocated BW. For more
details, see Status Parameters Pane.
FRR Type FRR protection mode applying to this bypass tunnel (Node, Link, or EFRR
protection). For more details, see description in Basic Parameters Pane.
Protected Port Name of the port protected by a bypass tunnel.

Protected Node Next-hop node name (when the FRR Type is Node Protection).
PHOP If Dual FRR protection applies, PE ID of node which is the penultimate (second
to last) hop of the protecting bypass tunnel.
Comments Free text about the tunnel. For more details, see description in Basic
Parameters Pane.
Created By User Tunnel creator.
Created With Application the tunnel was created with - GUI (the LightSoft GUI), XML (import
from XML), or TSC (acquisition from the EMS).
Creation Time Tunnel creation date and time.

Modified By User Tunnel modifier.
Modified With Application the tunnel was modified with - GUI (the LightSoft GUI), XML
(import from XML), or TSC (acquisition from the EMS).
Modification Time Tunnel modification date and time.

Column Description
SRLG Diverse True indicates that the bypass tunnel path has no SRLG in common with the
protected link/node. For more details, see Protection Parameters Pane.
BW Limit The bandwidth limit, which is only defined for HR-CoS tunnels. See Hierarchical
CoS (HR-CoS) Tunnels.
Aligned BW (Mb/s) The Aligned BW (or CIR), which is automatically defined for HR-CoS Tunnels.
See Hierarchical CoS (HR-CoS) Tunnels.
Parent Topic
9.3.3 Tunnels Pane
9.3.4 Tunnel Parameters Tab

The Tunnel Parameters tab lists the main tunnel attributes defined in the Create Tunnel process.
Figure 9-2: Tunnel List - Tunnel Parameters tab
The All Parameters view (default) enables you to edit certain non-path affecting parameters (see the
enabled fields in the figures in the next sections). Click Edit Attributes (top right, enabled when a
tunnel is selected) to set the editable fields to Edit mode (white). The icon changes to Save Attributes ,
enabling you to save changes.

NOTE: Editing is restricted to non-path-affecting parameters. You can also:

 Add or remove tail endpoints of P2MP tunnels using the Edit Tunnel window; see Adding
or Removing P2MP Tunnel Tail Endpoints.
 Change tunnel bandwidth; see Editing Tunnel Bandwidth.
The User Selection view provides quick access to the most important attributes and enables you to set
tunnel preferences.
Click Configure Attributes List (top-right) to display the User Preferences window, where you can
configure the attributes included in this list and set other tunnel preferences. For more information, see
Tunnel Management Appearance Preferences in the Getting Started & Administration Guide.
The Tunnel Parameters tab information is provided in the following panes:
 Basic Parameters Pane
 Advanced Parameters Pane
 Protection Parameters Pane
 Status Parameters Pane
 General Parameters Pane
Parent Topic

The Basic Parameters pane enables you to edit/view the most basic tunnel attributes. For parameter
descriptions, see the Create Tunnel Basic Parameters Pane.
Figure 9-3: Tunnel creation - basic parameters
Parent Topic

9.3.4.2 Advanced Parameters Pane

The Advanced Parameters pane allows you to view more specific working tunnel attributes and to
enable/disable OAM and alarm functions for a tunnel. For parameter descriptions, see the Create Tunnel
Advanced Tunnels Parameters Pane.
Figure 9-4: Tunnel Parameters tab - Advanced Parameters pane
Parent Topic
9.3.4.3 Protection Parameters Pane

This pane shows the tunnel FRR parameters. For parameter descriptions, see the Create Tunnel Protection
Parameters Pane.
Figure 9-5: Tunnel Parameters tab - Protection Parameters pane
Parent Topic

9.3.4.4 Status Parameters Pane

This pane shows operational, alarm, bandwidth and protection state-related parameters. For parameter
descriptions, see the Create Tunnel Status Parameters Pane.
Figure 9-6: Tunnel Parameters tab - Status Parameters pane
Parent Topic
9.3.4.5 General Parameters Pane

This pane shows the general tunnel parameters. For parameter descriptions, see the Create Tunnel General
Parameters Pane.
Figure 9-7: Tunnel Parameters tab - General Parameters pane
Parent Topic

9.3.5 Endpoints and Path Tab

The Endpoints and Path tab provides information about the tunnel route in four panes. The parameters
can only be viewed here.
The Endpoints and Path tab information is provided in the following panes:
 Endpoints Pane
 Path Pane
 Explicit Path Include Pane
 Explicit Path Exclude Pane
Parent Topic
9.3.5.1 Endpoints Pane

This pane lists details of the tunnel endpoints. For parameter descriptions, see Endpoints Pane.
Figure 9-8: Endpoints pane
TIP: P2MP tunnels - selecting a tail endpoint in the Endpoints pane highlights the path
represented by the associated subtunnel in the map view. As well, any inclusions/exclusions
that the path involves are highlighted in the Explicit Path Include and Exclude panes. (Not
applicable to a Head endpoint selection.)
Parent Topic
9.3.5.2 Path Pane

This pane lists details of each node along the tunnel path. For parameter descriptions, see Path Pane.
You can view bypass tunnel assignments per hop, or remove bypass tunnel assignments; see Actions on
Bypass Tunnels.
Figure 9-9: Path pane
Parent Topic

9.3.5.3 Explicit Path Include Pane

This pane lists the path user selections comprising explicitly included path characteristics. For parameter
descriptions, see Explicit Path Include Pane.
Figure 9-10: Inclusions pane
Parent Topic
9.3.5.4 Explicit Path Exclude Pane

This pane lists the path user selections comprising explicitly excluded path characteristics. For parameter
descriptions, see Explicit Path Exclude Pane.
Figure 9-11: Exclusions pane
Parent Topic
9.4 Viewing Tunnel Information

Selecting a tunnel in the Tunnels pane makes it the focus of the detailed information provided in other
panes. In addition, associated tunnels and other traffic entities can be identified and associated alarms can
be displayed.
Parent Topic

9.4.1 Viewing Tunnel Information

The Tunnel List window displays several information panes. The Tunnels Pane , displays a filtered set of
tunnel records.
When you click to select a tunnel in the Tunnels pane list, the tunnel becomes the focus of the information
provided by other panes.
When one or more tunnels are selected in the Tunnels pane, associated objects and links are highlighted in
the Tunnel List window map.
To view information about a tunnel:

1. In the Tunnel List window, ensure that a tunnel filter is selected, filtering the tunnels you want listed
in the Tunnels pane. For information about tunnel filters, see Filtering the Tunnels Pane.
2. Click to select a tunnel in the Tunnels pane. By default, the Show icon on the toolbar on the right
is selected and:
 The other information panes immediately show detailed information about this tunnel.
 The tunnel's associated elements and links are highlighted in the Tunnel List window map.
NOTE: When you select tunnels in the Tunnels pane and the Show one tunnel only option is
selected in the Preferences dialog box, the Tunnel List window map shows only the associated
elements and links, hiding all the others. For more information, see Tunnel Management
You can select tunnels in the Tunnels pane in two ways:

 Click and highlight the tunnel (as described in the previous procedure). Using this method, you can
select only one tunnel at a time.
 Select (or deselect) the checkboxes of multiple tunnels. This method is used for operations such as
delete, export, reconnect, show current alarms, TCI, print. This procedure is described in more detail in
Performing Tunnel Operations.
In this section, "selecting a tunnel" means selecting its checkbox.
Parent Topic

9.4.2 Showing Tunnels Associated with a Link

You can show tunnels of a specified type associated with an MoT virtual link or MoE physical link, as
follows:
 All tunnels, regardless of protection status
 Protected tunnels (whether or not a bypass tunnel is defined)
 Bypass tunnels
To view tunnels associated with a link:

1. In the main window, select the ETH/MPLS view.
2. Select an MoT virtual link or MoE physical link.
3. Right-click and select Show Tunnels.
4. Select the required option in the submenu:
 All Tunnels
 Protected Tunnels
 Bypass Tunnels
The Tunnel List window opens, showing the relevant tunnels in the Trails pane and the relevant
associated objects in the map view.
Parent Topic
9.4.3 Viewing Associated Traffic Entities

You can view which services, trails, or protected tunnels are associated with the specific tunnel you are
working on.
 Show Tunnel in Another View
 Show Associated Trails, Services, or Protected Tunnels
Parent Topic

9.4.3.1 Show Tunnel in Another View

A selected tunnel can be opened in a separate Show Tunnel view, similar to the Create Trail window but
with read-only parameters.
Figure 9-12: Show Tunnel window
This differs from the functioning of the Show Tunnel icon in the Tunnels pane toolbar, which highlights the
currently selected tunnel's path in the Tunnel List map view; see Tunnels Pane Toolbar.
To view a tunnel associated with a link:

1. In the Tunnel List window, select a tunnel in the Tunnels pane.
2. Click Show Tunnels in another window .

OR
Right-click a tunnel and select Show Tunnel. The Show Tunnel window opens.
Parent Topic

9.4.3.2 Show Associated Trails, Services, or Protected Tunnels

You can view the following tunnel-related entities in their connected list windows:
 Underlying services for a selected non-bypass tunnel.
 MoT Trails associated with a tunnel.
 Protected tunnels associated with a bypass tunnel.
You can also view the tunnels associated with selected services; see Viewing Service Information - Viewing
To view traffic entities associated with a tunnel:

1. In the Tunnel List window, select the checkboxes of the tunnels (or select a single tunnel) for which
you want to view associated traffic entities.
2. Select the following icon or right-click option:
 Show services associated with this tunnel(s) icon, or right-click and select Show Services.
The Service List window opens showing the associated services.
 Show trails associated with this tunnel(s) icon, or right-click and select Show Trails. The
Trail List window opens showing the associated trails.
 Show Protected Tunnels icon, or right-click and select Show Protected Tunnels.
A separate Tunnel List window opens showing the protected tunnels associated with the selected
bypass tunnels.
Parent Topic
9.4.4 Viewing Alarms for Selected Tunnels

You can view all the alarms that affect selected tunnels. These alarms are displayed in the Current Alarms
window; see Viewing Alarms for Selected Traffic Entities.
You can also view the tunnels affected by a selected alarm; see Viewing Traffic Entities Affected by an
Alarm.
Parent Topic

9.5 Performing Tunnel Operations

This section describes how to perform tunnel-related operations and view the results.
To perform a tunnel operation:

1. Select the tunnels by selecting their checkboxes in the Tunnels pane.
2. Select a Tunnel List window toolbar option, or right-click a tunnel in the Tunnels pane and select a
shortcut menu option.
3. Continue the operation as described in the corresponding procedure in this section. At the conclusion
of the operation:
 If the operation succeeded, an appropriate message opens.
 If any part of the operation did not succeed, a results window opens, giving information about
the failed operations. If multiple tunnels are involved, the window includes results for each
tunnel.
Each time an operation is performed that is not completely successful, LightSoft enables
Operational Results Info in the Tunnel List window toolbar. After you close the message
window (here a Tunnel successfully completed window), you can revisit the results by clicking
this icon.
The icon remains enabled until another operation is performed. If the second operation is completely
successful, the icon is disabled. If it is partially successful, it displays the detailed results for that operation.
Parent Topic

9.6 Actions on Bypass Tunnels

The following actions can be performed through the Path pane after a tunnel is completed, or on an
existing tunnel in the Tunnel List window:
 View/hide bypass tunnel assignment per hop.
 Remove bypass tunnel assignments.
NOTES:
 Unassigning a bypass tunnel from a subtunnel, also unassigns it from all subtunnels that
share the bypass tunnel.
 Protection Desired is not affected by removal of bypass tunnel assignments or failure to
assign bypass tunnels. (This is different from Trails, where a protected trail means the
main path is already protected by a protection path. For tunnels, you create the protected
tunnel (protection desired), but it is not actually protected until a bypass tunnel is
assigned.)
To view/hide bypass tunnel assignment per hop:

1. Highlight one or more rows in the Path pane that represent tunnel segment hops.
2. Right-click. The shortcut menu opens with the relevant options enabled.
3. Select Show Bypass.
Bypass tunnel paths for the selected hops are displayed in the map in blue (this color overrides the
pink and violet of the tunnel path in overlapping links/nodes).
4. To clear bypass tunnel color coding, right-click the relevant rows and select Hide Bypass.
To remove bypass tunnel assignments:

1. Highlight one or more rows in the Path pane, representing tunnel segment hops with assigned bypass
tunnels.
2. Right-click. The shortcut menu opens with the relevant options enabled.
3. Select Remove FRR Protection.
The Bypass tunnel information is removed from the corresponding row in the Path pane. This option is
relevant when Protection Desired is Protected AND Bypass tunnel was assigned to that hop.
Parent Topic

9.7 Filtering the Tunnels Pane

You can filter the Tunnels pane (determine the tunnel records that are displayed) according to any
combination of tunnel attributes and objects activated from either predefined or created filters.
The following tunnel statistics are shown in the status bar:

 n/n (for example, 100/100): Number of tunnels filtered in/total number of tunnels that can be
displayed.
 n items selected: Total number of selected tunnels (with marked checkboxes).
LightSoft supports the following predefined tunnel filters:
 All Tunnels: All tunnels are displayed (no filter is applied).
 No Tunnels: No tunnels are filtered in. (When this is the default filter, the Tunnel List window initially
opens quickly without any tunnels. Another filter should then be applied; see Applying a Filter and
Setting it as Default.)
 Unprotected (Desired): Tunnels where the Protection Desired is Unprotected; see the parameter
description in Basic Parameters Pane.
 Protected: Tunnels where Protection Desired is Protected.
 Bypass: Tunnels where Protection Desired is Bypass.
 Unprotected (Actual): Protected tunnels where Protection Actual is Unprotected; see parameter
description in Protection Parameters Pane.
 Full Node Protected: Tunnels where FRR Type Actual is Full Node; see the parameter description in
Protection Parameters Pane.
 Fully Protected: Tunnels where FRR Type Actual is Full Node Link.
 Partially Protected: Tunnels where FRR Type Actual is Partial.
 Bypass w/Node Protection: Bypass tunnels where FRR Type is Node Protection.
 Bypass w/Link Protection: Bypass tunnels where FRR Type is Link Protection.
 Bypass w/EFRR Protection: Bypass tunnels used for EFRR protection.
 Partially Protected by EFRR Bypass: Tunnels that are partially protected by EFRR.
 Full Node Protected by EFRR Bypass: Tunnels where EFRR protection is Full Node.
 Fully Protected by EFRR Bypass: Tunnels that are fully protected by EFRR.
 Bypass w/Dual FRR: Bypass tunnels where Dual FRR protection applies.
 High CoS: Tunnels with high priority CoS.
 Hr-CoS Inconsistent Tunnels: E-LSP tunnels that have BWLim !=NA at their Head PE equipment, and
can be converted into HR-CoS tunnels via the MakeHr-CoS operation.

Filter the Tunnel List Window to only display tunnels not defined as HR-CoS tunnels by selecting the
HR-Inconsistent Tunnels
Filter options from the Tunnel List vs. main window

Filter options can be activated from either the LightSoft main window or the Tunnel List window.
In the LightSoft main window:

You can use the Tunnels tab (General group) Tunnel Filters option to:
 Create or edit a new filter according to any combination of tunnel attributes or objects; see Creating
and Editing Advanced Filters.
 Edit, rename, or delete a filter that you created, or set it as the default (which automatically activates
it when the Tunnel List window opens); see Rename, Delete, and Set Default Filter Actions.
The Tunnels pane can automatically be opened with tunnels corresponding to preselected objects in the
LightSoft main window; see Accessing the Tunnel List Window.
In the Tunnel List window:

You can:
 Click Quick Filter to quickly filter by Tunnel ID, Name, and/or Customer; see Creating a Quick
Tunnel Filter.
 Use the Filter selector dropdown list to activate any filter. You can also click
Set Filter as Default to set the current filter as the default (automatically activated when the
Tunnel List window opens); see Applying a Filter and Setting it as Default.
(The icon is disabled if the currently applied filter is already the default.)

 Show traffic entities associated with the selected tunnel(s):
 Show Tunnels icon: Opens a selected tunnel in a Show Tunnel view; see Show Tunnel in
Another View.
 Show Services Associated with this Tunnel icon: Filters tunnels associated with specific
services; see Show Associated Trails, Services, or Protected Tunnels.
 Show Trails Associated with this Tunnel icon: Filters tunnels associated with specific trails;
see Show Associated Trails, Services, or Protected Tunnels.
 Show Protected Tunnels icon: Filters tunnels protected by a selected bypass tunnel; see
Show Associated Trails, Services, or Protected Tunnels.
Parent Topic

9.7.1 Creating a Quick Tunnel Filter

The Quick Filter function enables you to quickly filter the tunnels either currently in the Tunnels pane or
throughout the database, by NMS Tunnel ID, Tunnel Name, and/or Customer. This method does not involve
a filter template and is defined per use.
To quickly filter tunnels by NMS Tunnel ID, Tunnel Name, and/or Customer:
1. Open the Tunnel List window, as described in Accessing the Tunnel List Window.
2. In the Tunnels pane, click Quick Filter . A quick filter field bar opens at the top of the pane.
3. Enter a text string to the relevant fields to filter in tunnels with field values that include this text.
 NMS Tunnel ID; see parameter in General Parameters Pane.
 Tunnel Name; see parameter in Basic Parameters Pane.
 Customer; see parameter in General Parameters Pane.
You can enter partial strings to identify all tunnels with this text anywhere in the fields. For example,
enter xy to find all tunnels with xy anywhere in the field value. (Wildcard character is not used.)
 The table immediately adjusts to show tunnels previously in the table that satisfy the filter
criteria.
OR
 To filter the entire database (instead of the current tunnel contents), enter a string to each

First perform a Force Filter search of the entire database.
Then apply multiple incremental filters to the current table contents, adjusting the filter
criteria on-the-fly to change the composition of tunnels displayed.
Click Info to display an Info Tip describing the use of this filter type.
Click Clear Filter to clear the current quick filter selections. (You can also backspace to empty a
filter field.)

4. Click Close Filter to close the quick filter field bar.

After the field bar is closed:
 If Force Filter (database search) had been used, the list reverts to its contents before the filter
was applied.
 Otherwise, if a table search was performed, the latest filtered contents are retained in the list.
(in the same way as when objects are preselected before opening the Tunnel List window)
which you can use as a base for other filter actions; see Creating a Filter with Preselected
Objects.
Parent Topic
9.7.2 Working with Advanced Tunnel Filters

Advanced filters enable you to view a subset of the tunnels in the Tunnel List window according to any
combination of:
 Tunnel attributes (like specific rates)
 Selected objects (all tunnels traversing specific objects)
create.
Saving a filter after performing a create or edit operation automatically applies the filter settings to the
open Tunnel List window. Any other filter can be applied as needed at any time.
Parent Topic
9.7.2.1 Applying a Filter and Setting it as Default

Any filter (predefined or user-defined) can be applied, immediately changing the tunnels listed in the
Tunnels pane. In addition, the currently applied filter can be set as the default, defining the tunnels that
automatically appear when the Tunnel List window opens in a new session.
TIP: Opening the Tunnel List window may be time consuming if many tunnels are filtered in. If
you choose "No Tunnels" as the default filter, initially the window opens very quickly without
any tunnels in the Tunnels pane.
You can then apply a different filter.

To apply a filter and (optionally) set it as default:
1. In the Tunnel List window, select a filter in the Filter dropdown list .
The filter is immediately applied, reflected in tunnels listed in the Tunnels pane.
2. Optional. You can set the current filter as the default by clicking Set filter as default . The Tunnel
List window now automatically opens with this filter in any new session.
Parent Topic

Advanced filters are used to search the database for tunnels that satisfy the filter criteria. The following
describes how to create or edit a filter that includes advanced criteria combinations.
preselected in a map window are not relevant. For information about how to create a filter
with the objects preselected in the LightSoft main window map, see Creating a Filter with
Preselected Objects.

1. In the main window Tunnels tab, in the General group, click Tunnel Filters. The Tunnel Filters dialog
box opens. (You can view a summary of parameters and topology elements for an existing filter by
selecting the filter in the Filters pane.)


OR
Select a user-created (non-predefined) filter that you want to modify in the Filters pane and click Edit
(enabled when a user-created filter is selected). The Create Filter or Edit Filter dialog box opens.
Click Show Tree to open the Topology Tree pane. The icon changes to Hide Tree , for hiding
3. In the Filter Name field, type a name for the new filter (for example, MyFilter).
OR
If you are editing, this field is disabled. You can save the changes for the modified filter as a different
name, if needed.
a. Select a parameter's checkbox in the Filter By area.
 Text entry field (see the note about the text field entry below)

 Options fields
additional values. The multiple selections are displayed in the Value area
.
d. Repeat previous steps for as many parameters as needed. (You can remove a selected value by
selecting it again.)

NOTE: ABOUT TEXT FIELD ENTRY

Text filters are case sensitive.
If filtering by any text entry field, use the wildcard character * to filter in all tunnels where the
field value includes a specified string, for example:
 xy* to filter in all tunnels with the field value starting with xy
 *xy* to filter in all tunnels with xy anywhere in the field value
 *xy to filter in all tunnels with the field value ending with xy (this pattern is not
recommended).
OR
If any resource objects are selected in the Topology Tree area (see next step), enter xy to find
all tunnels with xy anywhere in the field value. (Wildcard character is not used.)

0)
5. If you want to filter by selected resource objects with associated tunnels, move objects from the
Topology Tree area to the Topology tab, as follows:
 Select the topology layer for the filter: ETH/MPLS (default). The Physical layer can also be
selected, enabling you to select physical nodes. Double-click the root of the tree to refresh
its elements.
 Select the objects for which you want to filter tunnels (drill down in the tree). To select
multiple objects, press SHIFT and click them one by one. )
b. In the Topology pane, click Add to move selected objects from the Topology Tree area to
the Topology tab (click Remove to remove objects not required for the filter).
OR
7. Click Close to close the Tunnel Filters dialog box.
Parent Topic


You can also edit a user-defined filter via the Tunnel List window.
To edit a filter via the Tunnel List window:

1. Open the Tunnel List window as described in Accessing the Tunnel List Window.
Parent Topic

You can create a new tunnel filter with objects selected in the LightSoft main window map. This avoids
having to select the elements again when creating the filter. These objects are automatically reflected in
the Tunnel List window map and in a "Temporary" filter which you can build on.

1. In the LightSoft main window map, select any objects that you want to include in a new tunnel filter.
In the main window Tunnels tab, in the General group, click Tunnel List. The Tunnel List window
opens.
2. Click Edit Filter (enabled only if objects were preselected in the main window before the Tunnel
List window was opened). The Edit Filter dialog box opens with the preselected objects already
selected in the Topology pane. (The filter name is "Temporary" until you click Save As to save under a
different name.)
Parent Topic

9.7.2.5 Rename, Delete, and Set Default Filter Actions

This section describes how to rename, delete, or set a filter as default (automatically applied when the
Tunnel List window opens).
To rename or delete a filter, or set a filter as default:

1. In the main window Tunnels tab, in the General group, click Tunnel Filters. The Tunnel Filters dialog
box opens.
2. Select a filter and select one of the following options:

action.
Filter and Setting it as Default.
(New and Edit are used to create and edit filters; for details, see Creating and Editing Advanced
Filters.)
3. Click Close to close the Tunnel Filters dialog box.
Parent Topic

9.8 Reconnecting Tunnels

You may sometimes need to reconnect a tunnel. This is typically required if a problem arises while you are
creating one. For example, if a PE included in a tunnel is disconnected at the time it is created, the resulting
tunnel is left with the Tunnel State being Incomplete. In this case, reconnecting the tunnel sends the
missing tunnel segments to the network.
To reconnect a tunnel:
1. Open the Tunnel List window, ensuring that the required main map window objects are preselected
and the desired filter is set as the default, as described in Accessing the Tunnel List Window.
2. Select the checkboxes of the tunnel/s you want to reconnect by highlighting a tunnel or selecting one
or more tunnels by checking their checkboxes.
NOTE: Tunnel State should be Incomplete or Failed in order for the operation to be
meaningful.
3. Click Tunnel Reconnect . A confirmation dialog box opens, showing the tunnels that will be
reconnected.
4. Click Reconnect Tunnels to continue. A completion message appears, describing the operation result
and listing nonfatal errors. For more information, see Performing Tunnel Operations.
Parent Topic

9.9 Updating FRR/EFRR Protection

The Update FRR Protection option assigns bypass tunnels to the selected protected tunnels. The sequence
in which you create tunnels and FRR protecting bypass tunnels is important. You should first create FRR
bypass tunnels and then create the tunnels to be protected. The following options exist for updating
protection on existing tunnels:
 Using existing Bypasses: LightSoft selects the bypass tunnels that provide the highest available
protection using existing bypasses only.
 Use existing Bypasses and create FRR Bypasses for unprotected hops (full FRR protection not
guaranteed): If a hop is not protected, create new node or link bypasses, where possible. Full FRR
protection is not guaranteed because if a bypass cannot be created for one or more hop, tunnel
creation is still permitted.
 Use existing Bypasses and create EFRR Bypasses for unprotected hops (full EFRR protection not
guaranteed): If a hop is not protected, create new EFRR or link bypasses, where possible. Full EFRR
protection is not guaranteed because if a bypass cannot be created for one or more hop, tunnel
creation is still permitted.
You can also export selected tunnels to an XML file, defining that the import of this file at a later time will
automatically trigger bypass tunnel assignment on these tunnels; see Exporting Tunnels.
If a protected tunnel is created before an FRR bypass tunnel is available for it, or if a bypass tunnel is
removed (whether manually or as a result of an automated process) the protected tunnel's Protection
Actual status may become Unprotected. In this case, you should update the protection of those tunnels as
described below.
NOTE: To prevent loops, ERP Dual-Homing H-VPLS service protection should not be
configured to use protected tunnels.
To update FRR tunnel protection:

1. Ensure that bypass tunnels of the intended type exist along the path to be protected.
2. In the Tunnel List window, select the checkboxes of all protected tunnels whose protection needs to
be updated.
3. Right-click and select Edit > Protection > Update FRR Protection.

The Update FRR Protection window opens displaying the selected tunnels.
Figure 9-13: Update FRR protection window
4. In the Protection Mode field, select either:

 Use existing Bypasses
 Use existing Bypasses and create Node/Link Bypasses for unprotected hops (full FRR
protection not guaranteed)
 Use existing Bypasses and create EFRR Bypasses for unprotected hops (full FRR protection not
guaranteed)
5. Click OK. FRR protection is updated, and bypass tunnels are created, if applicable.
Parent Topic
9.10 Editing Tunnel Protection

You can edit the protection of existing tunnels without having to recreate the tunnels. For example, you can
assign Bypass tunnels to one or more selected tunnels.
To modify tunnel protection:

2. Highlight a tunnel or select the checkboxes of multiple tunnels on which you want to perform the
same operation.
3. Right-click a tunnel, select Edit > Protection > and select a protection option. Note that the protection
options displayed depend on the protection type selected (FRR or EFRR).
 Remove FRR Protection: Removes bypass tunnel assignments from the selected protected
tunnels. (In this case, Desired protection remains protected, but Actual protection will be
unprotected.) This is permitted only if a bypass tunnel is not currently carrying traffic (FRR In
Use is No); see the FRR In Use parameter in Path Pane.

 Make Protected or Make EFRR Protected: Changes the Protection Desired of the selected
unprotected tunnels from Unprotected to Protected or EFRR Protected. In the Make Protected
window, select a protection mode:
 Use existing bypasses: Search for existing and matching bypass tunnels and assigns them
to the selected tunnel(s).
 Use existing Bypasses and create FRR Bypasses for unprotected hops (full FRR protection
not guaranteed): Search for existing and matching bypass tunnels. If no bypass exists
between hops, create FRR bypass where possible.
 Use existing Bypasses and create EFRR Bypasses for unprotected hops (full EFRR
protection not guaranteed): Search for existing and matching bypass tunnels. If no bypass
exists between hops, create EFRR bypass where possible.
 Update FRR Protection or Update EFRR Protection: Reassigns FRR or EFRR bypass tunnels to
one or more protected tunnels selected from the Tunnel list. In the Updated FRR window,
select a protection mode:
 Use existing Bypasses and create FRR Bypasses for unprotected hops (full FRR protection
not guaranteed): Search for existing and matching bypass tunnels. If no bypass exists
between hops, create FRR bypass where possible.
 Use existing Bypasses and create EFRR Bypasses for unprotected hops (full EFRR
protection not guaranteed): Search for existing and matching bypass tunnels. If no bypass
exists between hops, create eFRR bypass where possible.
 Make Unprotected: Changes the Protection Desired of the selected protected tunnels from
Protected to Unprotected.
 Unassign: Unassigns the selected Bypass tunnels from all their protected tunnels. (Desired
protection of those tunnels remains protected, but Actual protection will be unprotected.)
For information about the Update FRR option, see Updating FRR Protection.
Only the options consistent with the tunnel selections are enabled. If the selected tunnels include
multiple types, no options are enabled.
Parent Topic

9.11 Editing Tunnels

This section describes how to edit certain aspects of a tunnel, or to delete selected tunnels:
 Adding or Removing P2MP Tunnel Tail Endpoints
 Editing Tunnel Bandwidth
 Adding, Editing, or Removing Tunnel CoSs
 Converting Tunnels into HR-CoS Tunnels
 Deleting Tunnels
NOTE: Operations to add or remove a P2MP tunnel endpoint or delete a tunnel may fail due
to one of the following circumstances:
 LightSoft network values are different from the values in the EMS/network. Tunnel
consistency operations or modifications in the EMS may be required.
2. Admit the tunnel from the network using Synchronization.
LightSoft is unable to set up the tunnel in the network as defined. This problem typically arises
during tunnel creation if an NE included in a tunnel is disconnected or a craft terminal is
connected, causing the resulting tunnel to be incomplete.
To resolve this problem: After the NE is uploaded or the craft is disconnected, reconnect the
tunnel to send the missing tunnel segments connects to the network.
Parent Topic
9.11.1 Adding or Removing P2MP Tunnel Tail Endpoints

This section describes how to add or remove subtunnels to/from P2MP tunnels.
Details of the Add or Remove P2MP Subtunnel action can be exported to an XML file for backup purposes
or to automatically assign bypass tunnels to protected tunnels.
Changes to other tunnel parameters can be performed via the Tunnel List window Tunnel Parameters tab
Edit Attributes function. For details, see Tunnel Parameters Tab.
 Adding P2MP Tunnel Tail Endpoints
 Removing P2MP Tunnel Tail Endpoints
Parent Topic

9.11.1.1 Adding P2MP Tunnel Tail Endpoints
NOTE: Before beginning, ensure that the Show PEs and Links Only Where Tunnel Traverses
and Show endpoint on map options are not selected in the Preferences dialog box. If they
are, no additional endpoints will appear in the Tunnel List window map. For more
information, see Tunnel Management Appearance Preferences in the Getting Started &
To add P2MP tunnel tail endpoints:

2. In the Tunnels pane, select a P2MP tunnel:
 Select the tunnel and click Add Subtunnel .

OR
 Right-click the tunnel and select Edit > Add Subtunnel. The Add Subtunnel window opens. The
tunnel path is shown in the map, and the window panes are updated with the tunnel
information.
TIP: The Paint selectors enable you to identify and select the endpoints or explicit path tunnel
elements (segments or nodes).
3. Select one or more additional tail endpoint LEs. Their details are reflected in the Endpoints pane list.
Add Tail endpoints with or without Explicit Path Include/Exclude as described in Creating a Tunnel.

4. (Optional) Click Complete tunnel . LightSoft searches for a path using your selections. When a
path is found, the details are displayed for you to review. You can go back and modify the path if
required.
warnings or nonfatal errors; see Performing Tunnel Operations. If the Complete step encounters a
problem, see Diagnosing a Create Tunnel Failure.
5. Click Activate tunnel . LightSoft activates the changes on the network.

warnings or nonfatal errors; see Performing Tunnel Operations. If the Activate step encounters a
NOTE: If Complete Tunnel was not performed before or if it was followed by any potentially
performed/repeated before the tunnel is activated on the network.
6. You can export the edited tunnel to an XML file for backup purposes or to automatically assign bypass
tunnels to protected tunnels, as follows:
a. Click Export . The Export Tunnels dialog box opens.

b. Continue the procedure as described in Exporting Tunnels , from Step 3.
For information how to eventually implement the edited tunnel in the network, see Importing
Tunnels.
Parent Topic
9.11.1.2 Removing P2MP Tunnel Tail Endpoints

Follow these steps to remove P2MP tunnel tail endpoints.
To remove P2MP tunnel tail endpoints:

2. In the Tunnels pane, select a P2MP tunnel:
 Select the tunnel and click Remove Subtunnel .

OR
 Right-click the tunnel and select Edit > Remove Subtunnel. The Remove Subtunnel window
opens. The tunnel path is shown in the map, and the window panes are updated with the tunnel
information.

TIP: The Paint selectors enable you to identify and select the endpoints or explicit path tunnel
elements (segments or nodes).
3. Select one or more tail endpoint LEs to remove. Their details are removed from the Endpoints pane
list.
4. (Optional) Click Complete tunnel . LightSoft examines the remaining path after the endpoints
are removed for bypass tunnel validity and to ensure that any applicable FRR guarantees are satisfied.
New bypass tunnel assignments may be applied. The details are displayed for you to review.
warnings or nonfatal errors; see Performing Tunnel Operations. If the Complete step encounters a
5. Click Activate tunnel . LightSoft activates the changes on the network.

warnings or nonfatal errors; see Performing Tunnel Operations. If the Activate step encounters a
NOTE: If Complete Tunnel was not performed before or if it was followed by any potentially
performed/repeated before the tunnel is activated on the network.
6. You can export the edited tunnel to an XML file for backup purposes or to automatically assign bypass
tunnels to protected tunnels, as follows:
a. Click Export . The Export Tunnels dialog box opens.

For information how to eventually implement the edited tunnel in the network, see Importing
Tunnels.
Parent Topic

9.11.2 Editing Tunnel Bandwidth

You can edit the bandwidth of a CoS associated with existing L-LSP or E-LSP tunnels, regardless of their
original specific bandwidths, to a common value without having to recreate the tunnels.
The Edit process does not allow tunnel bandwidth to be changed to zero. For the other allowed values see
BW parameter in Basic Parameters Pane.
NOTE: If bandwidth is edited on multiple tunnels with multiple CoS values, the editing of CoS
values is performed by LightSoft on a best effort basis and for some tunnels not all CoS values
may be edited successfully. In some cases a CoS value may simply not exist for a tunnel. In
other cases CoS values may not be updated for a technical reason. Refer to the relevant failure
message for more information.
To modify tunnel bandwidth:

2. Highlight a tunnel or select the checkboxes of multiple tunnels, right-click, and select Edit > Edit
Bandwidth.
The Edit Bandwidth dialog-box opens.
3. Click Select CoS to open a dropdown list of the CoS instances defined for the tunnel and select one to
edit. The selected CoS and its current bandwidth value appear in the Selected CoS area.

4. Click the BW (Mb/s) dropdown list and select a new bandwidth value for the CoS.
5. For an E-LSP tunnel, repeat steps 3 and 4 to add more CoS values and associated BW, as needed.
6. For an HR-CoS tunnel, you can also edit the BW limit as needed by changing the value in the Edit BW
Limit (Mb/s) field.
7. Click OK to apply the change. You can cancel the current change with Cancel.
8. A successful completion message opens. Click OK to close the window.
Parent Topic
9.11.3 Adding, Editing, or Removing Tunnel CoSs

You can add, edit, or remove the CoSs of an E-LSP tunnel using the Edit CoS dialog box.

Adding a CoS to a tunnel:

1. In the Tunnel List Window , select an E-LSP tunnel, right-click and select Edit > Edit CoS.
The Edit CoS dialog box opens.
2. Click Add/Edit CoS and select the CoS from the dropdown list. The CoS is added to the CoS list (left
pane).
NOTE: A default color is associated with any selected CoS. Optionally use the Color dropdown
list to select a different color for this CoS/Color combination (Green, Yellow, or
Green&Yellow).
Adding a CoS to a protected tunnel adds the new CoS to the protecting bypass as well.
LightSoft validates whether adding the CoS to the bypass is possible. If it's not, the entire Add
CoS operation will be rejected (include adding the CoS to the working tunnel).
3. Select the bandwidth for the CoS from the BW (Mb/s) dropdown list, and click OK.
Editing a CoS:
2. Click Add/Edit CoS and select the CoS from the dropdown list.
3. In the CoS list (left pane), change the color and/or bandwidth of the CoS as required, and click OK.
NOTE: When you edit a CoS, LightSoft automatically updates the CoS in the bypasses defined
for the tunnel. To view the updated bypasses, right-click on the selected tunnel and select
Show > Show Bypass Tunnels.

Removing a CoS from a tunnel:

2. Click Remove CoS and select the CoS from the dropdown list. The CoS is added to the list of CoSs to
remove (right pane).
3. Click OK.
NOTE: A bypass CoS can’t be removed if it protects a working tunnel CoS. When editing the
bandwidth of a protected tunnel, the protecting bypass tunnel bandwidth is not decreased
accordingly (it remains unchanged).
Parent Topic
9.11.4 Converting Tunnels into HR-CoS Tunnels
To convert an E-LSP tunnel into an HR-CoS tunnel:

1. Filter the Tunnels pane to only display E-LSP tunnels not defined as HR-CoS tunnels by selecting the
HR-Inconsistent Tunnels filter (see Filtering the Tunnels Pane).
2. Select a tunnel (or several tunnels), right-click and select Edit > Make HR-CoS.
The Make HR-CoS dialog box opens.

3. Do one of the following:

 To apply the BW Limit value defined in the NMS, click OK.
 To apply a new BW Limit value, select the Edit BW Limit (Mb/s) option, enter the value, and
click OK.
The tunnel is converted into an HR-CoS tunnel according to the Head parameters.
Parent Topic
9.11.5 Deleting Tunnels

This section describes how to delete tunnels. You can delete several tunnels at the same time.
You can delete tunnels for either immediate or future effect in the network. When the deletion is for future
application, its details are exported to an XML file and put into effect by importing the file into LightSoft at
a later time; see Exporting Tunnels.
All tunnels are deleted the same way, whether they were created in LightSoft or created in the EMS and
later uploaded to LightSoft using tunnel synchronization.
Tunnels are generally deleted from all databases (both the LightSoft database and the EMS network
database). You can optionally delete a tunnel from only the LightSoft database, leaving it intact in the EMS
database. This may be useful, for example, to perform repair or upgrade of the LightSoft database without
affecting traffic. In addition, this option has the effect of forcing a tunnel segment inconsistency and
causing the tunnel to appear in the TSC window; see Synchronizing Tunnels.
Deleting a P2MP tunnel causes deletion of all its subtunnels.
When a tunnel is deleted, all tunnel segments defined for each PE in the tunnel are also automatically
deleted. If this does not occur (for example, if one of the PEs is disconnected at the time the tunnel is
deleted), the tunnel remains in the Tunnel List window in an Incomplete or Failed state. The tunnel is
removed from the list when all tunnel segments are deleted from the network.
NOTES:
 You cannot delete a tunnel as long as services still traverse it. Services must be deleted
before their tunnels.
 You cannot delete bypass tunnels assigned to protect working tunnels.

To delete a tunnel:
2. In the Tunnels pane, select a tunnel by highlighting it or select one or more tunnels by checking their
checkboxes.
a. If you want to delete the tunnels from all databases, click Delete or right-click any selected
line in the Tunnels pane and select Delete > Delete Tunnels from DB and Network. A
confirmation window opens showing the tunnels that will be deleted.
Click Delete Tunnels from DB and Network to complete the action.

OR
b. If you want to delete the tunnels from only the LightSoft database (leaving them intact in the EMS
database), right-click any selected line in the Tunnels pane and select Delete > Delete Tunnels
from DB Only. A confirmation window opens.
Click Delete Tunnels from DB Only to complete the action.
NOTES:
 If Bypass tunnels are assigned to protected tunnels, they are unassigned and deleted.
 Bypass tunnels that are actively protecting traffic are not deleted.
A completion message appears, describing the operation result. For more information, see
Performing Tunnel Operations.
OR 0)

4. If you want the tunnel deletion to be implemented in the network at a later time, save the action in
an XML file, as follows:
a. Click Export .
OR
Right-click one of the selected tunnels and select Utilities > Export Tunnels. The Export Tunnels
dialog box opens. )

For information about how to eventually implement the deletion in the network, see Importing
Tunnels.
Parent Topic
9.12 Batch Tunnel Operations

This section describes how to perform Create, Update FRR, and Delete tunnel operations in a batch by
exporting and importing tunnel definitions to/from an XML file.
 The Export operation enables you to save the data of selected tunnels in an XML file for either
network planning or backup purposes.
 The Import operation translates the data stored in the XML file and sends this information to LightSoft
according to the requested operation for each tunnel in the file.
Records in the XML file specify the action commands and parameters. Both import and export records
coexist in the same XML file. For information about the XML syntax, see Import/Export Traffic Syntax.
LightSoft automatically generates a log file documenting the import or export process. You can find this log
file in the directory ~nms/NMSTunnels. The log file name is the same as the XML file, with the extension
.log.
keywords, and how to parse the file. If required, the names of the tags in the DTD file can be changed (for
additional information, contact your local Customer Support representative).
You can also export/import service XML files via UNIX, which may include prescheduling using the UNIX
crontab command; see the generic trail, tunnel and service export/import procedure in
Exporting/Importing Traffic Entities via UNIX.
Parent Topic

9.12.1 Exporting Tunnels

This section describes how to export tunnel definitions to an XML file for either network contingency
planning and design purposes or backups in case of system failure.
Exported tunnels are automatically implemented in the network by the Import function according to the
settings that were used to export them to XML.
Tunnel definitions either from the Tunnel List window or in XML file format can be converted to CSV for
viewing in a relational database program. For details, see Exporting Tunnels to CSV.

 For planned addition/removal of P2MP tunnel endpoints, see Adding or Removing P2MP Tunnel Tail
Endpoints. For this purpose the tunnels are exported to XML using the Export Tunnels window's
Export for Edit mode.
 For planned deletion of existing tunnels; see Deleting Tunnels. For this purpose the tunnels are
exported to XML using the Export Tunnels window's Export for Delete mode.
 Update FRR Protection: For protected tunnels, the XML file that is produced by the Export process can
later be imported to LightSoft, triggering bypass tunnel assignment.
XML until needed. When the new network design is ready to be implemented, the planned tunnels may be
imported to LightSoft as part of the active network.

You can export tunnels so that they can be restored if inadvertently deleted or corrupted:
 Tunnels that were deleted from the network can be restored by importing. For this purpose the
original tunnels must be selected in the Tunnel List or Add/Remove Subtunnel window, and the
export must be performed using the Export Tunnels window's Export for Create mode.
Existing tunnels that become corrupted can be restored by importing. For this purpose the original tunnels
must be selected in the Tunnel List or Add/Remove Subtunnel windows, and the export must be
performed using the Export Tunnels window's Export for Edit mode.
Parent Topic

9.12.1.1 Export Tunnels Procedure

Tunnels can be exported to XML using the Export Tunnels window. This example shows the window
accessed from the Tunnel List window. It includes a list of tunnels selected for the export.
You can export tunnels to an XML file for a variety of purposes:

 For backup or future planning, to be imported later to LightSoft as needed.
 To automatically delete selected tunnels at a future time.
 To automatically assign bypass tunnels to selected protected tunnels at a future time.
NOTE: XML records are exported in the order that they are displayed in the Tunnel List
window, and are eventually imported serially, in the same order.
To export tunnels to XML:

1. If you are creating an XML file for:
 Backup purposes or automatic bypass tunnel assignment: From the Tunnel List window, select
one or more tunnels; see Performing Tunnel Operations.
You can also perform this action from the Create Tunnel or Add Subtunnel or Remove
Subtunnel window on the current tunnel that has just been activated; see Creating a Tunnel, or
Adding P2MP Tunnel Tail Endpoints , or Removing P2MP Tunnel Tail Endpoints.
OR
 Deleting tunnels: From the Tunnel List window, select one or more tunnels for deletion (but do
not click Delete); see Deleting Tunnels.
2. Click Export .
OR
(If you are in the Tunnel List window) In the Tunnels pane, right-click a tunnel and select Utilities >
Export Tunnels from the shortcut menu. The Export Tunnels dialog box opens.
3. Select an existing file name from the Files pane or enter a name in the File Name field.

*, ?, !, |, \, /, ', ", {, },<, >, ;, <comma>, ^, (, ), $, ~, #, @, <space>, +, =, &
4. If the file already exists, two fields are enabled:

 Select Overwrite file to overwrite the existing file
OR
 Select Append to file to add the tunnels to the existing file (preserving its previous contents)
5. Select the Batch Operation to be applied on all the tunnels to be exported:
 Backup purposes: Select Create.
 Automatic bypass tunnel assignment: Select Update FRR.
 Delete purposes: Select Delete.
6. Click Export. The tunnel definitions are saved as an XML file.
Clicking Abort at any time causes the operation to stop after the current tunnel is processed. An
Exporting Failed message opens. An export file will be produced containing definitions of the tunnels
that completed processing up to that point.
Parent Topic
9.12.1.2 Exporting Tunnels to CSV

You can export Tunnel List window data to a delimited-format CSV file for subsequent import to Microsoft
Excel or a relational database application. LightSoft also enables you to export tunnels in XML files to CSV
using a command line application.
To export tunnels to CSV:

 See the generic procedure in Exporting to CSV.

Parent Topic

9.12.2 Importing Tunnels

This section describes tunnel definition import from XML using LightSoft menu options. (You can also
import trail XML files via UNIX; see Exporting/Importing Traffic Entities via UNIX.)
NOTES:
 Before importing tunnels, ensure that all the required endpoints and resources are free
and available. If any are occupied, the Complete action, which is performed automatically
by the import, will fail.
details, see the note in Exporting Tunnels.
To import tunnel definitions from XML files via LightSoft:

1. In the main window Tunnels tab, in the Utilities group, click Import Tunnels. The Import Tunnels
dialog box opens.


 Only check that the file format is valid: Checks the XML file structure validity for tunnel import.
 Only check that the tunnels in the file can be completed successfully: Checks file syntax and
verifies that tunnel creation is feasible in accordance with network rules, availability of
resources, and so on. This action is similar to Complete in the Create Tunnel procedure.
 Create, Update FRR, or Delete the tunnels in the file: Checks syntax, finds a path, and either
creates, updates FRR protection, or deletes the specified tunnels in the network. The choice of
action is determined individually for each tunnel listed in the file. For example, users may
append a tunnel creation request to a file containing a list of tunnels for deletion. Tunnel mode
is set at the time of export.
Note that tunnel creation here is similar to Activate in the Create Tunnel procedure. Tunnel
editing is similar to Activate in the Edit Tunnel procedure. Tunnel deletion is similar to the same
actions when accessed via the Tunnel List window.
4. Click Import. Each tunnel object in the XML file is executed (sequentially) according to the selection
option and corresponding tunnels are reflected in the Tunnel List window.
 If Create/Edit/Delete was selected, the file is imported and the tunnels in it are created, edited,
or deleted from the database and network, as relevant.
 For Check file format or Check tunnel integrity, checks the XML file structure validity or verifies
that tunnel creation is feasible, as relevant.
The Status pane shows the total number of tunnels processed and the number that processed successfully
or failed.
Clicking Abort at any time causes the operation to stop after the current tunnel is processed. An Importing
Failed message opens. The tunnels that completed processing up to that point will be imported.
Parent Topic

10 Synchronizing Tunnels
This section describes the tunnel synchronization process which reconciles differences between tunnel
definitions in LightSoft and tunnel definitions in an EMS.
In general, new tunnel inconsistencies should be dealt with as they occur and their causes investigated. The
number of outstanding inconsistencies in the system at any time should be kept to a minimum.
Inconsistencies between the LightSoft database and EMSs can develop over time for a number of reasons,
such as:
 Tunnels were created in LightSoft while the EMS was down.
 Tunnel segments were defined or changed at the EMS or craft terminal level.
Tunnel synchronization functionality is available in accordance with user permissions. It is not available for
CNM users; see VPNs and CNMs.
10.1 Viewing Tunnel Segment Consistency Status

Inconsistency information can be accessed using the following LightSoft main window indication and
option:
 The Tunnel Segment Consistency (TSC) counter in the main window shows the total
number of inconsistent tunnel segments. The color of the counter indicates the worst condition of the
inconsistencies in the count. For information about color correspondences, see Severity Breakdown
Pane.
 To open the Tunnel Segment Consistency (TSC) window, where you can view detailed information
about inconsistencies, in the main window Tunnels tab, in the General group, click Tunnel
Consistency.
The Tunnel Synchronization feature is composed of the following windows:
 Tunnel Segment Consistency (TSC) window: Begins the trail synchronization process, providing
warning flags colored according to the type of detected inconsistencies, and counters that add up the
number of inconsistencies on each layer. See Tunnel Segment Consistency (TSC) Window.
 Tunnel Synchronization window: Performs various synchronization actions, both directly and via
several floating windows. See Tunnel Synchronization Window.
You can perform synchronization in the TSC window in an automated fashion, either by imposing tunnels
defined in LightSoft on the EMSs, or by admitting (acquiring) tunnels from the EMSs to LightSoft.
Alternatively, you can display inconsistencies in the TSC window but perform synchronization manually in
the Tunnel Synchronization window, where you can select individual tunnels and decide whether to
impose, admit, or delete them. After completing and activating your changes, you can refresh the
information displayed in the TSC window to confirm that the inconsistencies have been resolved, thereby
indicating that the synchronization process was successful.
The synchronization process is used to admit tunnels that do not conform to normal trail patterns (flex
trails) to LightSoft's Tunnel Management subsystem.

LightSoft® User Guide Synchronizing Tunnels
NOTE: The TSC window opens with only tunnel segments that involve inconsistencies, unlike
the TCI window for trails that can display consistent trails as well. You can force a tunnel
segment to be inconsistent in order to view it in the TSC window. An easy way to do this is to
delete the tunnel in the LightSoft database using the Delete Tunnels from DB Only option,
leaving it intact in the EMS database. See Deleting Tunnels.
Parent Topic
10.2 Performing Tunnel Synchronization

Tunnel synchronization can be performed for tunnel inconsistencies associated with selected multilinks or
objects, links in a multilink, or specific tunnels.
Only one LightSoft client can perform tunnel synchronization at any given time.
To perform tunnel synchronization:

1. Open the Tunnel Segment Consistency (TSC) window, showing tunnel inconsistencies associated
with:
OR
Do not select anything in order to display all tunnel inconsistencies.
 In the main window Tunnels tab, in the General group, click Tunnel Consistency.
OR )

dialog box.
 Right-click the Link Name cell of any link and select Tunnel Consistency. The TSC window
opens.
OR
c. Specific tunnels:
 In the Tunnel List window Tunnels pane:
Select the tunnels (checkboxes) you want to synchronize.
OR
Click and highlight the single tunnel you want to synchronize.
 In the Tunnel List window toolbar, click .

OR
Right-click either the highlighted tunnel or one of the selected (check marked) tunnels,
and select Tunnel Operations > Tunnel Consistency.

The TSC window opens; see Tunnel Segment Consistency (TSC) Window.
If you selected specific links or PEs in the map, the right pane of the window displays a list of
inconsistent tunnel segments related to all the inconsistent tunnels connected with the preselections.
Otherwise, all the inconsistencies in the network are displayed. Select the tunnel segments you want
to synchronize by checking their checkboxes.
You need to select only one inconsistent tunnel segment per tunnel in order to synchronize the whole
tunnel.
You can select all checkboxes by clicking Select All or clear all by clicking Clear All .
2. Click Start .
NOTE: Click Stop to discontinue processing after the current tunnel is checked. Results
are provided only for tunnels processed up to that point and enable you to make decisions
about inconsistent tunnels in that group.
Click Abort to discontinue the entire operation. No results are provided.
When the process is completed, the Tunnel Synchronization window opens; see Tunnel Segment
Consistency (TSC) Window.
It shows the inconsistent or incomplete tunnels associated with the segment selections of the
previous window, in two floating windows:
 Inconsistent/Incomplete Tunnels – DataBase window: Shows the tunnels that appear in the
LightSoft database.
 Inconsistent/Incomplete Tunnels – Network window: Shows the tunnels that appear in the
EMS.
A third floating window (Synchronization Results window) display results of the process.
3. In the Inconsistent/Incomplete Tunnels – DataBase and Network windows, select tunnels that you
want to synchronize:
NOTES:
 Window elements and relevant icons are enabled when the associated window header
(Database or Network) is selected.
 When a trail exists in both the Database and Network, only one operation in one window
can be assigned to the tunnel per synchronization cycle.
0)
4. In the Database window (listing tunnels in the LightSoft database):

a. Select checkboxes of tunnels that you want to synchronize. )
b. For each selected tunnel, highlight the tunnel and select the synchronization operation toolbar
icon you want:
 Reconnect: Reconnects the tunnel.
 Impose to Network: Imposes the tunnel from the LightSoft database into the EMS.

 Delete from DB: Deletes the tunnel from the LightSoft database.
AND/OR
In the Network window (listing tunnels in the EMS):
c. Select checkboxes of tunnels that you want to synchronize.
d. Set the order in which the tunnels are processed - promote or demote a tunnel by highlighting it
and clicking and . The tunnels at the top of the window list are
processed first. This is significant when applying CAC on Classified tunnels, when the first
admitted tunnels are the first to be reserved BW resources.
e. For each selected tunnel, highlight the tunnel and select the synchronization operation toolbar
icon you want:
 Admit to DB: Admit the tunnel from the EMS to the LightSoft database.
 Delete from Network: Delete the tunnel from the EMS database.
As you select an action for a highlighted tunnel, the Selected Operation column shows the
operation name. For recommended actions, see Tunnel Consistency Use Cases.
 You can select all checkboxes of the window that is the current focus by clicking Select All
or clear all by clicking Clear All .
 You can select a tunnel in the Inconsistent Tunnels - Database or Network window and click
Show on Map to open a Show Tunnel window, where the tunnel is highlighted in the
window map and the tunnel parameter values are indicated. For more information, see the icon
description in Tunnel Synchronization Window Toolbar.
5. Click Start . The tunnels are synchronized according to the selected options.
Select Stop to discontinue processing after the current tunnel is checked; results are provided
only for tunnels processed up to that point.
After the operation completes for each tunnel, the relevant row is removed from the relevant
Inconsistent/Incomplete Tunnels windows and a row is added to the Synchronization Results
window, displaying information in the Operation Result column.
6. Close the Tunnel Synchronization window by clicking Close .
7. Return to the TSC window and click Refresh . The window is updated with the new information.
Parent Topic

10.3 Tunnel Segment Consistency (TSC) Window

The tunnel synchronization process (see Performing Tunnel Synchronization) begins in the TSC window,
which displays information about tunnel segment inconsistencies.
The window displays the total number of inconsistent segments and a breakdown of the number of
inconsistent segments per severity.
Figure 10-1: Tunnel Segment Consistency (TSC) window
Table 10-1: TSC window toolbar

Start Starts tunnel synchronization on the selected tunnels.
Stop Stops tunnel synchronization. The operation continues on the

tunnels processed up to that point, providing results for these and
enabling decisions to be taken concerning inconsistent tunnels in
that group.
Abort Aborts tunnel synchronization. The entire operation stops at once
and no results are provided.
Select all tunnels Selects (checkmarks) all the tunnels in the currently selected
window.
Clear all tunnels Clears all the tunnels in the currently selected window.
Close Closes the TSC window.
Parent Topic

10.3.1 Severity Breakdown Pane

This pane displays the total number of SNC inconsistencies and a breakdown of inconsistencies per severity
level.
The following are the default color correspondences per severity. The colors can be customized according
to your needs; see Tunnel Management Consistency Preferences in the Getting Started & Administration
Guide.
For a description of the inconsistency types and corresponding possible remedial actions, see Tunnel
Consistency Use Cases in the LightSoft User Guide.
Table 10-2: Indications of warning flags
Color Possible indications

Red Critical - Non-editable parameters. Synchronization might be traffic affecting.
Red Major - Editable parameters. Synchronization might be traffic affecting.
Tan Minor - Editable parameters. Synchronization is not traffic affecting.

Yellow Warning - Names-related. Synchronization is not traffic affecting.
Gray Incomplete - Segment missing in network.
Parent Topic
10.3.2 Selected Objects Pane

The Selected Objects pane of the TSC window lists the tunnel segments involving inconsistencies in the
system (or based on preselected objects). The segments you select will be considered by the
synchronization process.
Figure 10-2: Selected Objects pane
The columns displayed can be varied as required (see Getting Started Guide).

Table 10-3: Selected Objects pane of TSC window
Column Description
# Ordinal number of the tunnel in the list.
Tunnel selection checkbox, used to select tunnels for synchronization.
NMS Tunnel ID LightSoft tunnel identifier for this tunnel; see description in Create Tunnel
Window - General Parameters Pane.
Tunnel Name Name of the tunnel.
Customer Customer associated with the tunnel.
Incon. Severity Severity of the inconsistency, as described in Severity Breakdown Pane.
Protection Type Protection Desired associated with the tunnel; see parameter in Create Tunnel
Window - Basic Parameters Pane.
PE Name PE ID of a PE endpoint associated with the tunnel; see PE in Create Tunnel
Window - Endpoints Pane.
CoS CoS associated with the tunnel; see parameter in Create Tunnel Window - Basic
Parameters Pane.
EMS Tunnel ID Number allocated by the EMS, uniquely identifying the SNC within the EMS.
Detected At Time when the inconsistency was detected.
Parent Topic

10.4 Tunnel Synchronization Window

This window opens after you click Start in the TSC window to start the Synchronization procedure
(see Performing Tunnel Synchronization).
Figure 10-3: Tunnel Synchronization window
The Tunnel Synchronization window includes floating windows used in the synchronization procedure. It
shows the inconsistent or incomplete tunnels associated with segment selections in the TSC window:
 Database window: Shows inconsistent/incomplete tunnels present in the LightSoft database for which
one or more segments were selected in the TSC window.
 Network window: Shows inconsistent/incomplete tunnels present in the EMS database for which one
or more segments were selected in the TSC window.
 Synchronization Results window: Synchronization results, whether successful or failed.
When a tunnel is represented in both the database and the network, when you select the tunnel line in one
window, the same tunnel is highlighted in the other window.
NOTE:
 Window elements and relevant icons are enabled when the associated window header
(Database or Network) is selected.
 When a trail exists in both the Database and Network, only one operation in one window
can be assigned to the tunnel per synchronization cycle.
Parent Topic

10.4.1 Tunnel Synchronization Window Toolbar

Table 10-4: Tunnel Synchronization window toolbar

Activate Activates synchronization on the tunnels with the Selected
Operation column not empty. When clicked, the following
confirmation prompt opens: "This operation may be
traffic-affecting. Are you sure you want to continue?"
Stop Stops the synchronization process.
Reconnect Reconnects a tunnel (relevant for tunnels listed in the

Database window).
Impose to Network Imposes a tunnel from the LightSoft database into the EMS
(relevant for tunnels listed in the Database window).
Delete from DB Deletes the tunnel from the LightSoft database (relevant for
tunnels listed in the Database window).
Admit to DB Admits the tunnel from the EMS to the LightSoft database
(relevant for tunnels listed in the Network window).
Delete from Network Deletes the tunnel from the EMS (relevant for tunnels listed in
the Network window).
Select all tunnels Selects (checkmarks) all the tunnels in the currently selected
window.
Clear all tunnels Clears all the tunnels in the currently selected window.
Show highlighted tunnel on Opens a new Show Tunnel window view, where the tunnel
map that you selected in the Database or Network window is
highlighted in the window map, and the tunnel parameter
values are indicated. For the Fragment or Unclassified
inconsistency types, the tunnel or subtunnel path may not be
displayed, or displayed only partially. For a description of the
inconsistency types, see Tunnel Consistency Use Cases.
Close Closes the Tunnel Synchronization window.
Parent Topic

10.4.2 Tunnel Synchronization Floating Window Columns

Table 10-5: Tunnel Synchronization floating window columns
Column Description
Tunnel selection checkbox for selecting tunnels for some operations (described in
context). Other tunnel operations apply only to highlighted tunnels. A highlighted
tunnel is the focus for information shown in the Tunnel List window panes.
(DB and Network windows)
Selected Operation Operation selected by user: Impose, Admit, Reconnect, Delete.
(DB and Network windows)
Operation Applied Impose, Admit, Reconnect, Delete from Network, Delete from DB (Results
window)
Operation Result Succeeded or Failed.
(Results window)
Tunnel State Synchronization state: OK, Inconsistent, or Incomplete.
(DB and Results windows)
Inconsistency Type Inconsistency condition: Classified, Classified+, ClassifiedNet, Unclassified, or
Fragment. See Tunnel Consistency Use Cases. (Network and Results windows)
NMS Tunnel ID Tunnel identifier. (All windows)
Tunnel Name User-defined label for the tunnel. (All windows)
Customer Customer associated with the tunnel. (All windows)
CoS CoS (one or more) associated with the tunnel. (DB and Results windows)
BW Tunnel bandwidth per CoS. (DB and Results windows)
Description Provides reason why operation failed.
(Results window)
Parent Topic

10.5 Tunnel Consistency Use Cases

This section describes the main characteristics of each tunnel inconsistency type for inconsistent or
incomplete tunnels, and the corresponding possible actions to resolve the problem. For example:
 A tunnel is considered Classified+ if it is in the LightSoft database and classified in the EMS database,
and the highest inconsistency level of any component SNC is Warning or Minor (for a description of
the possible indications, see Severity Breakdown Pane).
 For tunnels with inconsistency type Classified+, possible actions to resolve the inconsistency are to
impose the tunnel to the EMS, admit the tunnel to LightSoft, or delete it from the network.
Table 10-6: Tunnel Inconsistency types and possible remedial actions
Tunnel inconsistency In DB? Classified in SNC inconsistency Unrecognized Possible Remedial Actions
type EMS? level segments?
Inconsistent tunnels
Classified+ Y Y Warning or Minor N/A Impose, Admit, or

Delete from Net
Classified Y Y Major or Critical N/A Impose, Admit, or
Delete from Net
Unclassified Y N Major or Critical N/A Impose, or
Delete from Net
ClassifiedNet N Y Critical Y Admit, or
Delete from Net
Fragment N N Critical Y Delete from Net
Incomplete tunnels
Unclassified or Y N Incomplete N/A Reconnect; see

N/A Reconnecting Tunnels
Additional comments
 LightSoft uniquely identifies a tunnel by its NMS Tunnel ID; see Create Tunnel Window - General
Parameters Pane. Connectivity can identify a tunnel only if NMS Tunnel ID = Null, in which case
LightSoft assigns an NMS Tunnel ID during admission.
 New services can only be mapped to tunnels with Tunnel State = OK.
 CAC and SRLGs: MPLS SNCs created/edited in network are taken into account in CAC calculations only
if admitted by LightSoft.
NOTE: A bypass tunnel can be admitted whether or not it is SRLG Diverse (SRLG Diverse
means its path has no SRLG in common with the protected link/node); see SRLG Diverse
parameter in Create Tunnel Window - Protection Parameters Pane.

 Protected Tunnel:
 LightSoft may admit a protected tunnel without some or all of its assigned Bypass tunnels. In
this case, the Tunnel State of the Protected tunnel is inconsistent.
 LightSoft does not impose or admit a Bypass tunnel assignment for a Protected tunnel, unless
the Bypass tunnel:
 Is in NMS DB and has Tunnel State = OK.
NOTE: It is therefore recommended to first Impose/Admit the Bypass tunnels.
 Meets node or link protection conditions.
Inconsistency types
When a tunnel state is Inconsistent, the tunnel is characterized by one of the following Inconsistency Types,
according to the nonconformance with the Classification rules:
 Classified: Classified trail that fails admission due to CAC violation.
 Classified+: Classified trail whose synchronization is non-traffic-affecting, for example, a Tunnel Name
mismatch.
 ClassifiedNet: Classified in EMS but not in LightSoft (Network Only Classified).
 Unclassified: Not meeting a combination of the above, or some other classification criteria.
 Fragment: Group of one or more segments with identical unallocated NmsTunnelId or Null, which do
not form a Classified tunnel.
Parent Topic

11 Provisioning Ethernet Services
Ethernet services are provisioned directly from LightSoft using the Create Ethernet Service window.
The basic steps required to create a generic Ethernet service are described in Creating a Service. Further
procedures are required for other service provisioning tasks.
Note that telecommunication networks are based on a hierarchical set of technology layers, ranging from
the lower physical layers to the higher application layers. Higher level Ethernet services are provisioned
over an underlying infrastructure of physical ports and tunnels.
When provisioning Ethernet services, LightSoft assumes that the network elements required to handle the
service, including physical ports, links, trails, and tunnels, have been created and configured before the
service is provisioned. The exact infrastructure requirements depend on the type of service. For example,
Layer 1 services are provisioned directly over EoS trails. MPLS services are provisioned over MoT trails and
MPLS tunnels. For instructions on how to provision the necessary infrastructure, see Provisioning SDH and
EoS/MoT Trails and Provisioning MPLS Tunnels in the LightSoft User Guide.
You may optionally choose to have LightSoft automatically create missing tunnels when provisioning a new
customer service type. We recommend that you view and edit tunnels created automatically via the
Tunnels List window, to ensure that the tunnel parameters fulfill all operator requirements. For more
information, see Service Management Preferences in the Getting Started & Administration Guide.
Customer service types include MP2MP, Rooted MP, P2P, P2MP (E-Tree), VLAN Tree, Freeform, and CES;
see Creating a Service.
NOTE:
 You can customize how services are created in LightSoft and which fields are visible in
various parameter windows; see Service Creation Management Preferences in the Getting
 If Ethernet services and endpoints are provisioned through the respective EMS, LightSoft
acquires the associated information from the EMS.
 Service data can be exported to an XML file for backup purposes.
OPTIONAL FEATURE: Ethernet services and RSTP map functionality are only available subject
to the ETH/MPLS layer being enabled. This is a fully integrated add-on capability, available on
a cost basis. If not purchased, the functionality and related menu options are unavailable.
OPTIONAL FEATURE: Automatic tunnel creation when provisioning a new customer service
type is a fully integrated add-on capability, available on a cost basis. If not purchased, the
functionality and related menu options are unavailable.

LightSoft® User Guide Provisioning Ethernet Services
11.1 Understanding Data Network Services

LightSoft supports Ethernet services on the following types of networks:
 Provider Bridge (PB) networks, using bridge LEs connected with Ethernet internal network to network
interface (I-NNI) links; see Provider Bridge Networks in the LightSoft User Guide.
In PB networks, the operator selects the service endpoints and configures the general service
characteristics and endpoint attributes. LightSoft then selects the S-VLAN ID and determines how to
implement the service on the PB network using S-VLAN registration, as explained in Automatic
S-VLAN Registration.
 MPLS networks; see Global MPLS Layer in the LightSoft User Guide.
In MPLS networks, the operator selects and configures the service endpoints. LightSoft then
automatically determines the tunnels and the inner tunnel labels to be used for that service. In many
cases the operator may choose whether to have LightSoft complete all service provisioning
automatically or to manually assign configuration parameters or select tunnels. This is described in
greater detail later in this section.
 Networks that have not yet been upgraded to the current LightSoft implementation may be working
with older network types; see earlier versions of the LightSoft User Guide.
NOTE: EVC and ESI service views

While specific L2 Ethernet service views are implementation/technology-independent, they
involve different implementation details depending on the LightSoft-managed network type. A
service is generally called Ethernet Virtual Connection (EVC) when discussed without its
implementation details, or Ethernet Service Instance (ESI) when discussed with all the relevant
implementation details. In this manual "Ethernet services" refer to the latter. All details of the
service following configuration of the EVC parameters are automatically completed.
Ethernet services are implemented over a physical layer of VCG trails with VC-12, VC-3, and VC-4
granularity. Each interface is configured separately, for maximum flexibility. For example, in an MPLS
network, a customer’s Ethernet traffic is transported over MPLS tunnels that can be shared or dedicated
per customer.
Parent Topic

11.1.1 Ethernet Service Types

Ethernet services are provided in the following configurations.
L1 P2P Service
Point-to-point service between a pair of L1 Ethernet ports over an SDH trail (also known as Ethernet Private
LAN service (EPL)). Creating a trail between the L1 Ethernet ports automatically creates the L1 Ethernet
service.
L2 PB and MPLS Services

 MP2MP (also known as Ethernet Virtual Private LAN service (EVPLAN)): Multipoint-to-multipoint
service in which frames from each service endpoint can be delivered to any other endpoint or can be
multicast to a set of endpoints. This type of service is the default (and recommended) choice for PB
networks. It is implemented by VPLS on an MPLS network.
Links used in MP2MP services cannot be selected manually. The service is always completed
automatically by LightSoft. You can only decide if the registration should be performed on the entire
PB network where RSTP is enabled (by selecting Automatic S-VLAN Registration) or not performed at
all.
Even if the network currently requires only P2P service, MP2MP service is recommended for PB
networks. MP2MP works efficiently for P2P service as well as preparing the network for future
expansion.
 P2P (L2, also known as Ethernet Virtual Private Line service (EVPL)): This type of service associates
exactly two UNIs. A UNI cannot be added to a P2P service to convert it to a MP2MP service. This
service is implemented by VPWS on an MPLS network.
Note that services with only two endpoints on a PB network do not have to be defined as P2P
services. They can also be defined as MP2MP services, in which case additional endpoints can be
added as needed. For this reason, the default and recommended service choice for PB networks is
MP2MP.
PB P2P services, in which you elect one direct EoS trail or ETY link between two endpoints, are
recommended only for specific use cases; see Configuring PB P2P Services between MCS Cards in the
 P2MP (root and leaf): Each service endpoint is configured as either a root or a leaf, but not as both.
Frames are delivered from root to leaves and from leaves to root. No frames are delivered directly
between two leaves. A P2MP service must have at least one root, with up to four roots supported. By
default, the first endpoint selected is the root and subsequent endpoints are all leaves.
P2MP service is implemented by configuring tunnels in each direction (or bidirectionally) between the
root and each leaf. Only supported for MPLS networks.
 E-Tree: A type of P2MP service, in which the standard of no direct communication between leaves is
more strictly enforced.
 Rooted Multipoint (Rooted MP): A type of P2MP service, typically used for multicast services such as
IPTV or E-Learning, configured between a root and multiple leaves. Each service endpoint is configured
as either a root or a leaf, but not as both. Frames are delivered from roots to leaves and from leaves
back to roots. No frames are delivered directly between two leaves. A rooted MP service must have at
least one root, with up to two roots supported. By default, the first endpoint selected is the root and
subsequent endpoints are all leaves.

This service is implemented in an MPLS network over P2MP tunnels that have already been
configured between the root and all leaves.
 Freeform: MP2MP service enabling manual network configuration not subject to standard validations.
 CES: Circuit Emulation Services (CES) emulate SDH services over packet-switched (MPLS/Ethernet)
networks. LightSoft provides three types of CES services: PB P2P, PB MP2MP, and MPLS P2P.
 H-VPLS: H-VPLS service defines a hierarchy of VPLS domains and allows MPLS-level connectivity
between them, providing VPLS network scalability, hierarchical partitioning, and interoperability.
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.
 Multisegment PW: Multisegment PW service enables a hierarchical network structure for P2P
networks, similar to H-VPLS capabilities. Multisegment PW functionality improves scalability, facilitates
multi-operator deployments, and facilitates use of different control plane techniques in different
domains. These are valuable capabilities in network configurations that must typically be able to
integrate static PW segments in the access domains and signaled PW segments in the IP/MPLS core.
 VLAN Tree: A type of P2MP service, used with Virtual RSVP tunnels and VNEs to integrate dynamic
signaled MPLS services on IP/MPLS networks in the LightSoft management sphere. The Virtual RSVP
tunnels are used to aggregate multiple VLANs into a single service.
 In-Band Management (read-only): Ethernet in-band management control service using in-band
Management Communication Channels (MCC). This service is created in the EMS, and cannot be
edited or changed in LightSoft.
LightSoft assumes that the network elements, including physical links, trails, and tunnels required to handle
the service, have been created and configured before the service is provisioned. You may optionally choose
to have LightSoft automatically create missing tunnels when provisioning a new service; see Service
Parent Topic

11.1.2 Understanding Ethernet Service Endpoints and Their

Interfaces
LightSoft supports L2 Ethernet service endpoints on the following physical interfaces. (For a description of
all data port types supported by LightSoft at the logical level, see Supported ETH/MPLS Port Types.)
ETY UNI
Comprising direct ETY UNIs.
Ethernet Remote UNI

On EoS trail creation between an Ethernet EoS UNI bridge or MPLS-PE interface and an L1 Ethernet port
(possibly on a UME), the L1 Ethernet port becomes an ETY UNI remote interface to the Ethernet network,
which can be selected as a service endpoint.
PB I-NNI
To create services over PB networks, LightSoft requires that all ports within the service path be defined as
I-NNI ports. LightSoft V6 supports top-down service provisioning over both EoS trails and ETY links
configured with I-NNI ports.
The service endpoint ports are either UNI (for connections to customer equipment ports) or E-NNI (for
connections to a different network via external network ports). Services that run over E-NNI or UNI ports
are provisioned 'bottom-up' at the EMS level.
ETY E-NNI
An ETY E-NNI interface can be selected as the service endpoint when a prospective Ethernet service spans
multiple provider networks. Frames on this interface are double-tagged with the S-VLAN ID indicating the
frame's Ethernet service.
A network polices this service endpoint on ingress for each CoS. CoS support in adjacent networks is likely
to be different, so operators agree on a CoS mapping for frames (for the MCS, mapping is by port).
E-NNI support differs between MPLS and PB networks, as follows:
 MPLS layer: Since the MPLS network does not carry S-VLAN IDs, multiple E-NNI endpoints to a specific
service are handled and S-VLAN IDs on different endpoints are independent. In effect, the network
performs S-VLAN ID switching between E-NNI pairs.
 PB network (implemented by EIS or MCS): S-VLAN ID at the E-NNI must be the S-VLAN ID
characterizing the service and is retained in all frames for this purpose. There is no S-VLAN ID
switching. This reduces the flexibility of the E-NNI interface. This port type is supported by the EISMB
bridge but not by the EIS.
Remote UNI (over EoS)

When an EoS trail connects an EoS UNI port to an L1 Ethernet port, the L1 port acts as a UNI to the
network. LightSoft supports configuration of service endpoints on such (remote) ports.
Remote E-NNI (over EoS)

On EoS trail creation between an EoS E-NNI logical port and an L1 Ethernet port (possibly on a UME), the L1
Ethernet port serves as an ETY UNI physical interface to the Ethernet network and can be selected as a
service endpoint.

The following figure illustrates a simple example of these port types.

Figure 11-1: MEF port types
Parent Topic
11.1.2.1 PB P2P Connectivity and MPLS PWs

The Metro Ethernet Forum (MEF) has defined a standard for E-Line P2P connectivity used to create
Ethernet private line services such as EPL and EVPL.
For example, E-Line services may be implemented through an MPLS-based VPWS that provides P2P
connectivity over MPLS PWs. A PW is a virtual E2E service connection between two endpoints. Many PWs
can share a single MPLS tunnel, as illustrated in the following figure.
Figure 11-2: Pseudowire representation
This efficient approach allows all the services to benefit from MPLS E2E H-QoS and carrier class capabilities.
Different PWs are distinguished by their unique VC frame labels. P2P service utilizes a single PW with a
single VC label. MP2MP service utilizes many PWs between the different endpoints, identified by their
different VC labels.
Parent Topic
11.1.2 Understanding Ethernet Service Endpoints and Their Interfaces

11.1.3 Distinguishing between Services

A customer may have several services where specific ones can be accessed by different internal
departments (such as Development, Marketing, etc.) or collaborating partners (such as system or
component manufacturers). Thus endpoints for multiple services can exist on the same UNI or E-NNI
interfaces. A secure and efficient mechanism is needed to distinguish between frames belonging to each
service. Hence:
 C-VLAN (C = Customer) tags on a frame enable discrimination between services on a UNI. (The absence
of tags is an untagged frame.) In service endpoint configuration, LightSoft supports the definition of a
list of C-VLAN IDs at an endpoint to be associated with a service.
 S-VLAN (S = Service) tags on a frame enable discrimination between different customers/services on
an E-NNI interface. This is the same S-VLAN Tag/ID used to discriminate between services in a PB
network; see Create Ethernet Service Window VLANs Pane in the Supporting Information Supplement.
Parent Topic
11.1.4 Understanding H-VPLS Service

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 11-3: VPLS network configuration

With H-VPLS, the network is split into hierarchical VPLS domains. Leaf nodes are connected only to their
roots, and full mesh is only created between root nodes within each domain. Traffic may be routed
between tunnels of different VPLS domains. Since it removes the burden of unnecessary connections, this
efficient approach improves MP2MP service scaling and allows less powerful devices such as access
switches to be used as leaf nodes.
Figure 11-4: 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.
ADR platforms support static H-VPLS over MoT and MoE interfaces, based on IETF standard RFC 4762. ADR
platforms also support an enhanced H-VPLS feature enabling definitions of multiple SHGs with traffic
switching between these groups.

The ADR H-VPLS implementation supports both two-tier H-VPLS (root and leaf) and multidomain H-VPLS.
The following figure illustrates an example of a network where the gateway supports multiple H-VPLS
domains. Within each domain, member nodes are connected in a full mesh VPLS. Each domain is connected
to other NEs using H-VPLS. Multiple domains are connected through each gateway NE.
Figure 11-5: Multiple H-VPLS domains
H-VPLS also enables dual homing for multiple access/metro rings connected to a core ring, see ERP DH
H-VPLS Service Examples.
Parent Topic
11.1.4.1 H-VPLS Implementation

In typical MPLS networks, all service endpoints must be connected by direct tunnels. This is based on the
essential "Split Horizon" principle that incoming packets arriving on one tunnel must never be forwarded
outward on a different tunnel. This rule is essential to create loop-free tunnel paths in a complex mesh
network.
H-VPLS makes a large hierarchical network scalable by reducing the number of MPLS tunnels and PWs
required for a service to operate compared to traditional full mesh networks. This approach also reduces
the number of multicast and flooding transmissions.
Deploying H-VPLS service requires organizing the VSI PWs into Split Horizon Groups (SHGs). For example,
the following figure portrays a VSI with ten PWs, labeled A through J, organized into four SHGs:
 PWs A, B, and C are all members of SHG 3.
 PWs D and E are all members of SHG 2.
 PWs F, G, and H are all members of SHG 1.
 PWs I and J are both members of SHG 0 (also known as Null).

Traffic transmission between SHGs is according to the following guidelines:

 For all SHG domains except for SHG 0, traffic is not transferred back and forth between PWs within
the same SHG domain. For example, traffic from PW A is not transmitted onward onto PWs B or C.
Traffic can be transmitted onto any of the other PWs in any other SHG domain.
 Traffic from the SHG 0 domain PWs may be transmitted on all other PWs, including other PWs within
SHG 0. For example, traffic from PW J is transmitted onward onto all the other PWs, A through I. SHG 0
is also known as the Null domain in other systems.
Figure 11-6: SHG configuration in VSI
To prevent vulnerability to SPoF, dual homing protection is provided for H-VPLS networks by creating ERP
DH H-VPLS services, as described in Dual-Homed Device Protection in H-VPLS Networks.
Parent Topic
11.1.4.2 H-VPLS Configuration Guidelines

After configuring an H-VPLS service, the user clicks Calculate and LightSoft analyzes the domain structure
with the participating nodes and links. For P2MP services, LightSoft calculates the appropriate root and leaf
nodes for each domain. LightSoft fills in the Tunnels table with a list of tunnels necessary to provision this
service, based on the domain requirements.
If the service has been configured correctly, LightSoft validates it and the service may be completed and
activated. If there are configuration errors, LightSoft displays a window with the results in warning and
error messages.
This section describes the basic validation checks used for H-VPLS configurations.

 Connectivity Validation: A P2MP or MP2MP service using H-VPLS domains must have full domain
connectivity. There cannot be any islands of disconnected domains. The following figure illustrates a
network configured with two isolated domains, R1 and R2.
Figure 11-7: Disconnected domains
 Endpoint Validation:
 All service endpoints must reside within one of the H-VPLS domains. In the preceding figure,
nodes C and B are defined as endpoints, yet they are not located within any domain.
 If two or more PEs belong to the same two (or more) domains, loops could be created and
LightSoft validation fails.
 Domain Loop Validation: Only a single route must exist between each pair of domains, meaning that
no loops exist between domains.
 Exception: When an ERP DH H-VPLS service is defined, the validation exempts SHG 0 domains with
two members, each one in a different domain, in which one of the nodes serves as RPL owner. This is
illustrated in the following figure. Note how domains R1, R2, R4, and R3 seem to form a loop since
there is overlap in the nodes within each domain, apparently enabling traffic to flow in a loop around
nodes in the four domains. However, since this configuration includes an ERP service (defined
between nodes E and F or between nodes C and D), the ERP service effectively blocks one of the
domain links and prevents looping.
Figure 11-8: H-VPLS domains

 LightSoft verifies that all H-VPLS gateways (these are the PEs with multiple SHGs assigned) are capable
of supporting the current configuration of H-VPLS service with the specified tunnel mode. LightSoft
also verifies that the service does not require use of more SHGs than the maximum number supported
by the equipment. If the underlying equipment is not appropriate for this configuration, the service is
not validated.
Parent Topic
11.1.4.3 H-VPLS Topology Examples

H-VPLS service can be a powerful tool to enhance network efficiency and functionality. This section
provides a few examples of how H-VPLS can be used in a variety of contexts.
Parent Topic
11.1.4.3.1 P2MP Service on Single Homing Topology

The following are the logical stages involved in creating a P2MP service using H-VPLS in a single homing
topology. These stages correspond to the more detailed step descriptions in Creating Multidomain Services.
The following figure shows the basic configuration.
Figure 11-9: P2MP service on single homing topology
As illustrated in the preceding figure:

 Endpoints are located at ports on nodes A, G, J, K, and M.
 A is the root.
 D and E serve as H-VPLS gateways.
 G, J, K, and M are the leaves.
 The necessary tunnels are portrayed by green lines.
 SHG values are indicated next to each participating port.

To create a P2MP service in a single homing topology:

1. Choose P2MP service and enable H-VPLS in the basic parameters pane.
2. Select service endpoints:
 Choose ports on A, G, J, K, and M.
 Designate G, J, K, and M as leaf ports.
3. Create three new domains, each one including a subset of the selected nodes directly connected by
tunnels:
 Select A, D, and E, and add them to a new domain.
 Select D, G, and J, and add them to a new domain.
 Select E, K, and M, and add them to a new domain.
4. (Optional) Click Calculate Tunnels List to calculate the service tunnel requirements and SHGs
appropriate for the new domain structure.
5. (Optional) Click Select Tunnels to populate the Tunnel Assignments table and manually select
tunnels for this service.
6. Click Activate service to complete and activate the service.

LightSoft automatically adds the entries necessary for the root to communicate with the leaves to the
Tunnel Assignment table. Note the following SHG implementation points:
 Ports D and E serve as H-VPLS gateways, with two different SHG values assigned to two ports within
the same node.
 SHG 1 is used for the ports facing towards the core domain.
 SHG 2 is used for the ports facing towards the access domains.
 The other participating PE ports are all assigned SHG 1.
CAUTION: The figure in this section illustrates a limitation in the system validation capabilities
you must keep in mind when planning an H-VPLS configuration. If node D is also defined as a
leaf endpoint, the system would not be able to prevent D's endpoint port from
communicating with leaves G and J.
Parent Topic

11.1.4.3.2 P2MP Service on Dual Homing Topology

This following are the logical stages in creating a P2MP service using H-VPLS in a dual homing topology.
These stages correspond to the more detailed step descriptions provided in Creating Multidomain Services.
Figure 11-10: P2MP service on dual homing topology
As illustrated in the preceding figure:

 Endpoints are located at ports on nodes A, F, and G.
 A is the root.
 B and C serve as H-VPLS gateways.
 D and E serve as H-VPLS gateways that are also connected through an ERP service.
NOTE: ERP DH H-VPLS service must be defined for the ERP-participating nodes before
configuring the H-VPLS service; ERP DH H-VPLS Service Examples.
 F and G are the leaves.

To create a P2MP service in a dual homing topology:

1. Choose P2MP service and enable H-VPLS in the basic parameters pane.
 Choose ports on A, F, and G.
 Designate F and G as leaf ports.

3. Create four new domains, each one including a subset of the selected nodes directly connected by
tunnels:
 Select A, B, and C, and add them to a new domain.
 Select B and D, and add them to a new domain.
 Select C and E, and add them to a new domain.
 Select D, E, F, and G, and add them to a new domain.

LightSoft automatically adds to the Tunnel Assignment table the entries necessary for the root to
communicate with the leaves. Note the following SHG implementation points:
 Ports B, C, D, and E serve as H-VPLS gateways, with two different SHG values assigned to two ports
within the same node:
Ports D and E also have an additional ERP service connection between them.
Parent Topic

11.1.4.3.3 MP2MP Service on Single Homing Topology

The logical stages involved in creating a MP2MP service using H-VPLS in a single homing topology
correspond to the more detailed descriptions in Creating Multidomain Services.
Figure 11-11: MP2MP service on single homing topology
As illustrated:
 Endpoints are located at ports on nodes A, G, J, K, and M.
 D and E serve as H-VPLS gateways.
To create a MP2MP service in a single homing topology:

1. Choose MP2MP service and enable H-VPLS in the basic parameters pane.
 Choose ports on A, G, J, K, and M.
3. Create three new domains, each one including a subset of the selected nodes directly connected by
tunnels:
 Select A, D, and E, and add them to a new domain.
 Select D, G, and J, and add them to a new domain.
 Select E, K, and M, and add them to a new domain.


LightSoft automatically adds to the Tunnel Assignment table the entries necessary to form a full mesh
configuration within each domain. Note the following SHG implementation points:
the same node:
Parent Topic
11.1.4.3.4 SHG 0 Domains

An H-VPLS domain can be configured as an SHG 0 or Null domain when it consists of only two nodes, where
one H-VPLS gateway connects the network to a single CE equipment node. SHG 0 domains allow packets to
pass freely to and from all participating H-VPLS domains.
Note that an SHG 0 designation should only be used in configurations where the CE equipment is located in
nodes that are clearly isolated and therefore configured as natural spokes. The following figure illustrates
this point by portraying a network with two elements that seem to resemble spokes of a wheel.
Figure 11-12: SHG 0 (Null) domains
However, in this example, only domain R6 should be configured as a spoke configuration, as it connects a
single CE equipment node P to node H in R1.
Domain R2 should not be configured as a spoke since node O is part of a ring. It is quite possible that at
some future time domain R2 might be extended to include the other nodes in the ring (such as node N).
Configuring domain R2 as a spoke would eliminate the possibility of later adding additional nodes to the
domain, and is therefore not a correct action.
Parent Topic

11.1.4.3.5 MP2MP Service on Dual Homing Topology

The logical stages involved in creating a MP2MP service using H-VPLS in a dual homing topology correspond
to the more detailed step descriptions provided in Creating Multidomain Services.
The configuration described in this section includes SHG 0 (Null) domains. An H-VPLS domain that includes
only two PEs and is used for MP2MP service is by default assigned an SHG 0 value. This is especially
relevant when one of the node pairs is part of an ERP service.
Figure 11-13: MP2MP service on dual homing topology
As illustrated:
 Endpoints are located at ports on nodes A, F, and G.
 B and C serve as H-VPLS gateways.
 D and E serve as H-VPLS gateways that are also connected through an ERP service.
NOTES:
 In this example, nodes D and E are configured as H-VPLS gateways that are also connected
through an ERP service. The system designer could have selected nodes B and C as the ERP
service participants; either one of the pairs (D/E or B/C) would in theory serve equally well
for the ERP service. Specific node choices depend on local configuration considerations
such as equipment capabilities.
 ERP DH H-VPLS service must be defined for the ERP-participating nodes before configuring
the H-VPLS service; ERP DH H-VPLS Service Examples.


To create a MP2MP service in a dual homing topology:

1. Choose MP2MP service and enable H-VPLS in the basic parameters pane.
 Choose ports on A, F, and G.
3. Create four new domains, each one including a subset of the selected nodes directly connected by
tunnels:
 Select A, B, and C, and add them to a new domain.
 Select B and D, and add them to a new domain configured as an SHG 0 domain.
 Select C and E, and add them to a new domain configured as an SHG 0 domain.
 Select D, E, F, and G, and add them to a new domain.

LightSoft automatically adds to the Tunnel Assignment table the entries necessary to form a full mesh
configuration within each domain. Note the following SHG implementation points:
 Ports B and C serve as H-VPLS gateways, with two different SHG values assigned to two ports within
the same node:
the same node:
Ports D and E also have an additional ERP service connection between them.
Parent Topic

11.1.4.3.6 Planning Domains

H-VPLS domains must be planned carefully before defining the service in LightSoft. Understand the basic
network structure before assigning nodes to domains, correctly taking into account Dual Homing
requirements. This section illustrates a typical network planning example.
In top-down service provisioning, define an H-VPLS service by:
 Selecting service endpoints.
 Dividing the endpoints and gateway nodes into H-VPLS domains. H-VPLS domains are simply
collections of VSIs that satisfy the following rules:
 VSIs contained in the same domain may only communicate with each other through direct
tunnels.
 All tunnels in a given VSI going to other members of the same domain are configured with the
same SHG. That SHG value cannot be 0 (null).
Based on these guidelines, we see that no packets pass between tunnels that belong to the same domain;
packets always pass between adjacent tunnels belonging to different domains.
We are now ready to apply these guidelines to a simple network topology, illustrated in the following
figure.
Figure 11-14: H-VPLS top-down provisioning example
The service in the preceding figure has nine endpoints, indicated by the gray color nodes G, J, H, C, B, P, M,
O, and N.

The goal now is to divide the service into multiple H-VPLS domains such that nodes belong to the same
domain only if a tunnel mesh exists between all those nodes. The following figure illustrates a set of
domains that meet our guidelines and requirements.
Figure 11-15: H-VPLS domains
Divide the service in our example into seven H-VPLS domains:

 R1 (nodes G, J, H).
 R4 (nodes C, D, B, K, L).
 R2 and R3 are Null domains that create dual homing links between R1 and R1 and therefore require
use of an ERP DH H-VPLS service.
 R5 is defined as an additional single-homed ring connected to R4.
 R6 and R7 are two ‘edge’ connections with only two nodes each, so they are each configured as SHG 0
domains.
With this domain division you also define how the service must be completed:
 Full tunnel mesh connectivity is required for the domain rings in R1, R4, and R5.
 Direct tunnels must be used for the SHG 0 nodes in R2, R3, R6, and R7.
 H-VPLS switching is required in nodes common to two or more domains (E, F, C, D, K, and L).
Parent Topic

11.1.5 Understanding PW Redundancy

PW redundancy (PW-R) enables networks to provide protection on the PW level in addition to the other
existing layers of protection. PW-R is based on configuring pairs of PWs, where one is configured as the
primary (active) and the other as secondary (secondary). Both PWs originate in a pivot node, with both PW
exits from the pivot node in the same SHG.
The pivot node normally transmits traffic out the active PW. If there is a failure on the active PW, the node
'pivots' and transmits traffic out the standby PW. (The nodes that are linked to a pivot PE node are referred
to as gateways. Two gateways that connect to the same pivot node and serve as destinations for two
redundant PWs are referred to as a redundancy pair.)
Figure 11-16: Generalized PE Dual-Homing Topology
PW-R is supported on MCS and selected ADR data cards for MoT, MoE, MoF, and IC-MoE ports over
bidirectional E-LSP tunnels. A Bidirectional Forwarding Detection (BFD) protocol monitors the status of the
tunnels and PEs.
Our equipment offers multiple layers of protection options. Protection option selection and configurations
can be tailored to specific network preferences. For example, PWs run over MPLS tunnels. If the tunnel is
protected, for example through FRR or LP protection, then the PW-R hold-off timer should be configured to
a high enough value to allow time to handle protection at the tunnel level. If tunnel traffic is either restored
or diverted to the protection tunnel within the time limit set by the hold-off timer, then no PW redundancy
switchover will be needed. Alternatively, if the underlying tunnel is not protected, then a failure of the
transport layer tunnel will be handled by the PW at the service layer. In this case, the hold-off timer setting
would be much smaller.
To provision PW redundancy in LightSoft, define a PW redundancy domain (PWR domain) that includes one
or more pivot PEs and two PEs that will serve as gateways. LightSoft automatically configures the
redundancy pairs of PWs into sets of primary and secondary PWs. You may optionally choose to manually
configure the primary and secondary PWs.

The following figure illustrates a simple network example. Two pivot PEs, located in the same PWR domain,
are connected through the same gateway PEs to a VPLS domain.
Figure 11-17: Sharing Gateways between Domains
Parent Topic
11.1.6 Understanding VLAN Tree Service

VLAN tree services are a type of P2MP root and leaf service typically used to efficiently backhaul mobile
traffic from NodeBs (leaves) into two RNCs (roots). For example, mobile traffic can be backhauled from BTS
antennas via BG9300 static access rings, and then transmitted to SR9705 signaled metro rings.
Each BG9300 leaf manages groups of access devices. Each access device is assigned a separate VLAN and is
configured with its own VSI and policer settings. BG9300 platforms can handle up to 25 local VSIs (up to 5
VSIs per E-NNI port). The BG9300 leaf bundles these groups of VLANs into a single VPN ID. Within LightSoft,
a leaf's aggregate VPN ID represents the group of devices managed by that leaf. From LightSoft's
perspective, each BG9300 and SR9700 platform represents a single aggregate VSI. LightSoft supports up to
32 VLAN groups.
These types of networks are usually organized into groups of static and dynamic regions, often with static
MPLS-TP access rings connected to a dynamic IP/MPLS core ring. Multiple small static access domains are
configured to enable efficient traffic load-sharing between the leaves. Signaling gateways (Sig-GW) are used
to transfer data between static and dynamic regions of the network.

The following figure shows how a VLAN tree service would be applied in a typical cellular service network
with multiple rings. Sig-GWs are located at the nodes connecting the static MPLS-TP access rings with the
dynamic IP/MPLS core rings.
Figure 11-18: VLAN tree topology example
The following figure illustrates a simple VLAN tree network topology that includes a static access region and
a dynamic core region. The network is organized into three domains:
 Domain 1: Dynamic IP/MPLS core ring including four SR9700 platforms (A, B, C, and D). Nodes A and B
are the root endpoints.
 Domain 2: Static MPLS-TP domain including two BG9300 leaf platforms (E and F) and one SR9700
platform (C) serving as a signaling gateway.

 Domain 3: Static MPLS-TP domain including two BG9300 leaf platforms (G and H) and one SR9700
platform (D) serving as a signaling gateway.
Figure 11-19: VLAN tree domain example
The next two figures help clarify how logical network domains are configured and viewed in LightSoft. The
first figure illustrates three network domains listed on a LightSoft Domains tab. The second figure shows
the network map corresponding to this domain structure.
Figure 11-20: VLAN Tree - Network tab - Domains defined

In the following network map, the network MEs are divided into three domains: one core domain (blue)
composed of four SR9700 platforms and two leaf domains composed of two BG9300 and one SR9700 each
(yellow and pink). Two SR9700 MEs are members of multiple domains and serve as SIG-GWs (black).
Figure 11-21: VLAN tree service map with domains indicated
Parent Topic
11.1.7 Understanding CES

Circuit Emulation Services emulate classic TDM P2P SDH service over MPLS or Ethernet packet-switched
networks. CES service endpoints are the standard low-order ports (E1/T1/VC-12 in STM-1 or n x 64K
timeslots). LightSoft supports two CES service modes:
 Structured Agnostic TDM over Packet (SAToP) service encapsulates the entire E1/T1 payload without
any frame alignment. This means that once a port is assigned as a CES service endpoint in SAToP
mode, the entire port is reserved for this service. LightSoft supports SAToP service for individual E1 or
VC-12 over SDH with 2.048 Mbps TDM rate.
 Circuit Emulation Service over Packet Switched Network (CESoPSN) service offers a finer granularity by
enabling E1/T1 frame alignment. Users can select specific 64K time slots within a selected port and
leave other timeslots available for other uses. LightSoft supports CESoPSN service for individual E1 or
VC-12 over SDH, for basic mode, basic frame, multiframe, or 64K timeslot fractionated E1.
Note that once the CES service mode has been chosen when the service is first provisioned, it cannot later
be edited.

A typical CESoPSN application is in mobile backhaul networks which aggregate traffic of many Nodes
towards the RNC.
Figure 11-22: CESoPSN service in mobile backhaul application
CES ports are initially defined at the EMS level. CES services are then configured in LightSoft by selecting
service endpoints. CES service endpoints may be either endpoint ports that have been configured for CES
service at the EMS level, or E-NNI ports leading to external or third-party networks.
LightSoft's CES implementation offers many advantages, including:
 Simplified provisioning of new CES services through:
 Automatic discovery of services already configured at the EMS level.
 Import and export of CES services using XML files.
 Scalability, with support for thousands of CES services.
Parent Topic
11.1.8 Understanding PB Protection Choices

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. Often the choices are not clear cut. Network operators must choose the options
that are most appropriate for their network configuration. Operators 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.
RSTP is a logical choice for PB network protection and restoration. RSTP is a classic choice which is simple to
implement, reliable, and works with both simple ring and complex mesh topologies. However, RSTP cannot
provide reliable < 50 msec protection; recovery times may significantly exceed 50 msec.
LightSoft provides BPDU tunneling dual homing service to close protected connections between MPLS
networks and PB networks using RSTP; see Understanding BPDU Tunneling Dual Homing. BPDU tunneling
DH is the original version of dual homing supported by previous versions of LightSoft. BPDU tunneling DH is
a good choice for closing an RSTP instance over multiple homed PB networks, where the network topology
consists of one or more isolated RSTP rings where each internetwork connection includes only two gateway
endpoints.

LightSoft provides RSTP multiple homing to close protected connections between PB and MPLS networks
that require greater flexibility, including multiple connection points and faster recovery times; see
Understanding RSTP Multiple Homing.
ERP was developed in response to the need for faster PB ring recovery times. ERP protection is significantly
faster than RSTP, clearly meeting a sub-50 msec recovery time standard. When working with a ring PB
topology, ERP protection is often the best choice. However, ERP cannot be used in a mesh configuration.
LightSoft provides ERP PB Ring service to protect one or more ERP rings in a PB network. The ERP rings may
optionally also be connected to MPLS networks; see ERP PB Ring Service Examples.
LightSoft provides an additional ERP dual homing service for networks utilizing H-VPLS configurations; see
ERP DH H-VPLS Service Examples.
NOTE: The choice of protection service (RSTP service, BPDU tunneling DH, ERP) depends on
customer configuration requirements. RSTP service is the default choice for most. However, if
a network is running multiple RSTP services that are dual homed to the same equipment, and
it is important to keep these instances on totally separate RSTP trees, BPDU tunneling would
be the preferred choice.
Parent Topic
11.1.9 Understanding BPDU Tunneling Dual Homing

BPDU tunneling DH utilizes pairs of MPLS network PE ports to provide protection in two contexts:
 Creating 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.
 Creating 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.
 When connecting an MPLS network to a customer access network, the PE ports connected to
the CE ports are ETY UNI ports.
 When connecting an MPLS network to an unmanaged network entity, the PE ports connected
to the CE ports are E-NNI ports.
 When connecting an MPLS network to a managed PB network, the PE ports connected to the
PB ports are I-NNI ports (EoS or ETY). Note that internetwork DH configuration with I-NNI ports
is an exception to the rule that services should not be defined between I-NNI ports where the
I-NNI ports serve as the service endpoints.

 A dual homed P2P service configured as a PW 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 11-23: DH for access network or internetwork connections
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.
Parent Topic
11.1.10 Understanding 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.
RSTP service enables MCS cards residing on an MPLS network to actively participate in the RSTP protocol
and spanning tree by running an RSTP state machine on the cards themselves and not only passively
transparently transferring other-nodes generated BPDUs (as in BPDU tunneling dual homing service).
Multiple nodes can participate in the same RSTP service, with each node configured for up to a maximum
of 32 connections (tunnels) to other nodes in the service.

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 11-24: Two methods for closing an RSTP ring
When creating an RSTP service, RSTP must be enabled on the ports of the bridge PEs at the EMS level. In
the preceding figure, this include the PE ports A, B, C, D, E, and F. Note that E and F are MoE or MoT ports.
A CoS must also be selected for the tunnel between E and F.
Parent Topic
11.1.11 Understanding Ethernet Ring Protection

Ethernet Ring Protection (ERP) is a series of mechanisms 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.
These mechanisms are defined in standard ITU G.8032. ERP defines a central node which blocks one of the
ports to ensure that no Ethernet traffic loop is generated. The link that is blocked by the node is called Ring
Protection Link (RPL). ERP uses control messages to coordinate switching the RPL link on and off.

The following figures illustrate a simple ERP example. The RPL defined in the first figure effectively prevents
a loop condition by virtually blocking the link between node 1 and node 6, as illustrated in the logical
topology section.
Figure 11-25: RPL basic example
Any failure along the ring triggers a Signal Fail message. This message is transmitted in both directions from
the nodes adjacent to the failed link, after these nodes have blocked the port facing the failed link. On
obtaining this message, the RPL owner unblocks the RPL port, enabling the connection between node 1 and
node 6 and thereby compensating for the broken link between node 4 and node 5. The ring continues to
operate, as illustrated in the logical topology section on the left side of the following figure.
Figure 11-26: RPL implementation example

Once the failed link between node 4 and node 5 is restored, the nodes adjacent to the restored link send
messages notifying the RPL owner that the RPL port should again be blocked. Messages are also sent to all
other nodes in the ring (other than the RPL owner) telling them to unblock all the blocked ports. The ring's
logical topology now returns to the original structure, as illustrated in the logical topology section on the
right side of the preceding figure.
This protocol 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.
Parent Topic
11.1.12 Understanding BSC Policer Profiles

A Broadcast Storm is a condition where a large number of broadcast frames are propagated across the
(provider) network, thereby causing network overload. Most bridges support Broadcast Storm Control
(BSC), where incoming frames not handled as unicast are metered by the assigned BSC policer profile for
the service. When the number of broadcast frames exceeds a threshold, the frames are discarded.
When BSC is configured for the service, LightSoft configures its traffic parameters and thresholds at all
bridges at which the service is defined and which support BSC. (If a bridge does not support BSC, the BSC
parameter is ignored.)
When BSC is not enabled for a service (default), LightSoft disables BSC at all bridges for this service.
BSC parameters for acquired services (not configured by LightSoft) may take different values at different
bridges. Actual BSC Policer Profiles and Thresholds may differ from the default by EMS configuration. In this
case, LightSoft regards the service as non-conformant.
When editing an existing service with non-conformant parameters, the configured value is configured for
all NEs. The service then becomes conformant on this parameter.
BSC TCA is then a per-PE TCA on the Ethernet service. LightSoft indicates whether the BSC TCA is raised on
any Bridge supporting the service. When the entry threshold is exceeded, a BSC TCA (alarm) is generated on
the service and this lasts until the exit threshold is reached.
For information how to create or edit policer profiles, see Managing Policer Profiles. Policer profiles are also
used to police bandwidth at each CoS instance of a service endpoint; see Policers Pane in the Supporting
Parent Topic

11.1.13 Understanding CFM

Connectivity Fault Management (CFM) is the Operations, Administration, Management (OAM) mechanism
for Ethernet services. CFM defines proactive and diagnostic fault localization procedures for P2P and
multipoint services that span one or more links end-to-end within an Ethernet network. CFM enables
detection, verification, localization, and notification of different defect conditions and enables service
providers to manage each customer service instance on an individual basis.
CFM enables:
 CFM Maintenance Operations: The LightSoft user can initiate the following maintenance operations
on service endpoints; see CFM Maintenance Operations in the LightSoft User Guide:
 Loopback
 Link Trace
 Continuity Check
 CFM Alarm Management: Various types of CFM alarms can be received at the service level when
Alarms functionality is enabled for an MA; see CFM for Alarm Management in the LightSoft User
Guide.
 CFM-PM (Y.1731) Mechanisms: The Y.1731 standard defines Ethernet PM mechanisms for measuring
Ethernet service performance. LightSoft supports CFM-PM (Y.1731) measurements for P2P, P2MP,
VLAN Tree, and MP2MP services, performed between pairs of MEPs belonging to the same MA.
You must add MAs to a service to set up CFM. Each MA comprises a set of the following maintenance
entities:
 Maintenance Association Endpoints (MEPs) on the edge ports of a service for which an MA is defined.
A MEP generates and receives OAM frames and tracks any responses.
 Maintenance Entity Group Intermediate Points (MIPs) at intermediate points along the end-to-end
path where Ethernet frames are bridged to a set of transport links.
MEPs and MIPs are sometimes referred to collectively as MPs.
When an MA is created for a service in LightSoft, MEPs and MIPs are automatically established for the MA
by LightSoft in coordination with the EMS, taking into account service endpoints and network topology.
NOTE: The Ethernet service provisioning security level is required to:

 Edit, acquire, delete, and export/import MAs
 Configure CFM MPs using GCT
 Perform CFM maintenance operations
Users permitted to view service alarms can also view CFM alarms.
Parent Topic

11.1.13.1 Implementing CFM via LightSoft or EMS

Background to Service Creation
An Ethernet service includes an FDFr (VSI or Ethernet XC) on each NE along the service path. For example,
FDFrs 1 to N must be created and matched individually to elements 1 to N, respectively.
When a service is created via LightSoft, these FDFrs are created automatically. If a service is created via the
EMS, the EMS user must manually create FDFrs at each NE.
Background to CFM Implementation
CFM is implemented by adding an MA (sometimes called a service MA) to the service. An MA includes a set
of "FDFr MAs" (sometimes called local MAs) that must be matched to the service's FDFrs at each NE (for
example, FDFr MAs 1 to N matched to FDFrs 1 to N at each relevant NE). The FDFr MA serves as a container
for a MEP/MIP, which must also be associated.
TERMINOLOGY NOTE: The term "MA" in LightSoft windows refers to a service MA and should
not be confused with the component FDFr MAs per NE.
Creating a Service MA via LightSoft

LightSoft enables one top-down automatically-created MA per service. The created FDFr MA is matched to
the FDFr endpoint at each relevant NE. The MEP/MIP is automatically selected for each FDFr MA in
coordination with the EMS. See Managing CFM MAs.
Creating a Service MA via the EMS
Service MAs are configured manually via the EMS. The created FDFr MA is matched to the FDFr at each
relevant NE by a manual process. See the EMS User Guide for your equipment.
NOTE: LightSoft top-down MA creation uses a default Maintenance Domain (MD) label and
level (Operator Level 1), for which only one MA can be created for a service. Additional MAs
may be created via the EMS with other MD Labels and Levels; see Multiple MAs for a Service.
The LightSoft-created MA can be identified by its Operator MD label, while EMS-created MAs
use other MD labels. (The Operator label can also be used in the EMS since a different string is
used to describe it - Op in EMS vs. Operator in LightSoft.)
NOTE: The FDFr MAs intended for a service must all be specified with the same MA Label,
CoS, MD Level, and MD Label.
Actions on LightSoft- vs. EMS-created Service MAs

The following actions can be performed in LightSoft on any MA created in either LightSoft or the EMS:
 Loopback, Link Trace, and Continuity Check maintenance operations; see CFM Maintenance
Operations.
 Changing attributes; see Editing One or More MAs for One or More Services.
 Deleting MAs; see Removing MAs.
The EMS-created service MA configuration (MEPs/MIPs) cannot be changed in LightSoft.
Parent Topic

11.1.13.2 CFM Support

CFM is supported as follows:
 P2P, P2MP (which can be E-Tree enabled), MP2MP (which can be H-VPLS enabled), and Freeform user
services. For more information about P2MP support, see P2MP CFM Support with E-Tree.
 In all networks (MPLS, PB).
 RSTP and ERP DH H-VPLS infrastructure services. See Implementing CFM for ERP DH H-VPLS and
Understanding RSTP Multiple Homing.
NOTES:
 In H-VPLS-enabled MP2MP services involving CFM, MIP functionality is provided at the
junctures of Split Horizon Groups (SHG); see CFM Support for H-VPLS.
 LightSoft blocks CFM on ERP PB Ring services.
If not all service endpoints support CFM:

 If only one endpoint of a service has CFM support and creation of a single MEP (and no MIP) is implied,
then no service MA is created.
 If only some endpoints of a service have CFM support, MEPs are created at the supporting endpoints,
thus providing partial monitoring of the service.
Parent Topic
11.1.13.2.1 P2MP CFM Support with E-Tree

Configuring CFM on a P2MP service enables CCM operation as well as LLCF on that service. In addition, you
can enable E-Tree to allow roots to communicate with other roots. The P2MP service must have the
following characteristics:
 MD Level = 1, MA assigned only on MPLS network (see CFM MD Level).
 Leaf remote MEP list includes the root MEPs (up to four roots).
 Root remote MEP list includes one of the following options (depending on E-Tree option being
enabled):
 E-Tree enabled: The remote MEP IDs and the full list of root MEPs IDs.
 E-Tree disabled: The remote leaf MEP IDs.
 When several root and leaves exist in the same PE, LS sets a single local MEP to represent all and
assigns the MEP list assuming the above CFM connectivity rules between the remote roots and leaves
and the local root and leaf.
 The CFM application is not aware of the SHG assignment. It is the user's responsibility to edit the MEP
list if the P2MP connectivity is not idle.
MAs assigned on P2MP service ports on a PB network are assigned to an MP2MP service for technical
purposes.

The CCM period selected must be supported by both endpoints. As part of the CFM assignment validations,
LightSoft verifies that all service endpoints support the configured CCM period. If not, they stop at the
service Complete state.
Parent Topic
11.1.13.2.2 VLAN Tree CFM Support

LightSoft supports a VLAN tree service, a P2MP VPLS service for backhauling mobile traffic from nodes B to
two RNCs.
The CFM configuration for VLAN tree service includes:
 MEP assignment for the BG9300 ENNI port in nodes B (which are the service leaves)
 MEP assignment for the 9700 nodes which have their ENNI ports connected to the RNC (which are the
service root ports)
For each service endpoint, an MEP is configured.
When configuring CFM top down from LightSoft:
 MA configuration is only MD Level 1.
 MEPs are configured as a single MEP per PE.
CFM in the 9700 Platform
The CFM in the 9700 is configured by STMS and not displayed in the NMS. Instead, EMS-BGF configures the
remote 9700 root MEPs in the BG leaf nodes as remote unmanaged MEPs.
NOTE: Since the VLAN tree service is a P2MP service which prohibits direct traffic between
leaves, each leaf's remote MEP list only includes remote root MEPs, RNC1, and RNC2.
CFM alarms based in SR9700 equipment are reported to the NMS and appear in the Alarms List window.
CFM in the 9300 Platform
RNC MEPs in the 9300 MEP lists are seen by LightSoft as unmanaged remote MEPs.
Parent Topic

11.1.13.3 Multiple MAs for a Service

The LightSoft top-down MA creation process enables you to create only one MA per service with MD
Operator Level 1 and one user-selected CoS. However, multiple MAs may be created for a service via the
EMS.
Multiple MAs enable CFM to perform Loopback, Link Trace, and Continuity Check for different
combinations of MD level and CoS. See CFM CoS Specification and CFM MD Level , respectively.
When multiple MAs are needed for a service:
 You can create the first MA top down via LightSoft with a selected CoS, as described in Managing CFM
MAs.
 You can then create subsequent MAs with any other combinations of CoS and MD level values via the
EMS. See the EMS User Guide for your equipment.
LightSoft automatically uploads MEPs of EMS-created service MAs. MIPs of EMS-created service MAs
(typically where I-NNI meets I-NNI at PEs in a PB network) are also uploaded automatically for equipment
(MCS) where MIPs are treated as service attributes.
NOTE: Certain equipment maintains MIPs at the port rather than the service level. In these
cases, EMS-created MIPs do not appear as Target choices in the LightSoft Select Target
window. However, you can still perform Loopback and Link Trace with such a MIP as Target by
entering its MAC address in the MIP pane; see Selecting Source/Target for Loopback or Link
Trace.
Parent Topic
11.1.13.4 CFM MD Level
CFM relies on a functional model consisting of hierarchical MDs. An MD is an administrative domain for the
purpose of managing and administering a network and is defined by provisioning specific switch/router
ports within it.
An MD is assigned one of eight possible MD levels by the administrator. This is useful for defining the
hierarchical relationship of domains to accommodate different network deployment scenarios. An MA that
belongs to a specific MD level has a default level assignment amongst customer, provider, and operator
roles:
 Customer role levels: 7, 6, and 5.
 Provider role levels: 4 and 3.
 Operator role levels: 2, 1, and 0.
LightSoft top-down service MA creation currently supports only the most common Operator Level 1 MD as
default. Service MAs can also be created via the EMS with any CFM level. Thus MAs with the required MD
levels can be defined partially via LightSoft or via the EMS. For details on creating multiple service MAs, see
Multiple MAs for a Service.
Parent Topic

11.1.13.5 CFM CoS Specification

Service connectivity is checked at the resolution of frames, and frame behavior may differ according to CoS
(when the network is busy, high CoS frames are never dropped; lower CoS frames may be). It therefore can
be useful to check service connectivity per CoS.
Certain equipment flexibly supports defining multiple service MAs for a service. This enables CFM
Loopback, Link Trace, and Continuity Check at the different relevant CoS values. See Multiple MAs for a
Service.
NOTE: Consider the following issues when creating an MA per CoS:

 Processor resource limitations and budget constraints.
 In a mixed equipment network, only one CoS per MD level can be continued to
non-supporting equipment.
Parent Topic
11.1.13.6 Remote Service Endpoints
CFM can be set up on a service that has an endpoint on a remote unmanaged MEP (UME). In this case,
LightSoft creates the corresponding MEP on the port connected to the UME (called remote service
endpoint). When a service MA is selected in the MA List pane, the corresponding MEP pane's Managed
column indicates if an MEP is managed or unmanaged.
NOTE: CFM can be configured only when equipment at both service endpoints support CFM.
In this case, CFM parameter selection is disabled.
Maintenance Operations Involving Remote Service Endpoints

When performing Loopback or Link Trace involving a remote service endpoint, you must specify a Source
MEP and a Target MP as follows:
 Source MEP: Always an MEP in LightSoft.
 Target MP: Manually enter the MAC address associated with the UME. This must be done each time a
maintenance operation is requested. LightSoft does not retain the MAC address from session to
session.
NOTE: Each FDFr MA contains a Remote MEP ID List of all the MEPs in the same service MA.
This enables each MEP to know its remote MEP neighbors for purposes of sending/receiving
CFM messages.
When CFM is set up on a service that involves a remote service endpoint, you must
additionally ensure that the unmanaged MEP ID was manually inserted to the Remote MEP ID
List via the EMS in order for the MEP to be recognized as an unmanaged MEP.
See also Resynching MAs.
The result of the maintenance operation notes if the managed and unmanaged ports are connected.
Parent Topic

11.1.13.7 CFM for Alarm Management

When Continuity Check OAM messages (CCMs) are enabled on an MA, CFM enables you to receive the
following types of alarms on the service:
 MA Mismatch: CFM frame received with invalid MA ID or is on port that is not registered in service.
 MEP Mismatch: CCM frame received with invalid MEP ID (MA ID is valid).
 Period Mismatch: CCM frame received with invalid CCM period (MA ID and MEP ID are valid).
 Discontinuity: Failure to receive a valid CCM frame from one of the MA's remote PEs during more than
three times the time period represented by the CCM Period.
CFM alarm management is enabled if any MA associated with the service has the Alarms checkbox
enabled; see the Alarms parameter description in Adding MAs to One or More Existing Services.
The CFM alarms are registered in the Current Alarms and Event Log windows in the same way as other
object alarms. The CFM alarms displayed in the Event Log window can be filtered as needed via the Event
Log Configuration window; see Configuring Event Logging, Archiving, and Historical Viewing.
Alarms are generated only on MAs or also on MPs, according to specific equipment support. See the
relevant equipment manual for more information.
You can view:
 Services affected by a selected alarm:
Right-click an MA/MP alarm in the Event Log window and select Show Affected Services. (Show
Affected Trails and Show Affected Tunnels are also available.) A Service List window opens with a list
of services affected by the CFM alarm. See Viewing Alarms for Selected Traffic Entities.
 Alarms currently affecting a selected service:
Right-click a service in the Service List window and select Show Current Alarms. A Current Alarms
window opens with a list of all alarms affecting the service, including MA and MP alarms. See Viewing
Traffic Entities Affected by an Alarm.
Parent Topic

11.1.13.8 Link Loss Carrier Forwarding (LLCF)

LLCF detects a port failure (Loss of Signal or Link Down) in a PB or MPLS network and reflects the
information to the service’s associated far-end port. The far-end port then asserts this information towards
the Attachment Circuit (AC) side, the user side of a port, closing that port to traffic. The port status is thus
transferred end to end. Third party equipment is made aware of the failure and can reroute traffic to an
alternative path. The following diagram shows a P2MP LLCF service example.
Figure 11-27: LLCF in hub and spoke configuration
For implementation details, see Implementing LLCF.

LLCF is supported as follows:
 P2P, P2MP, and MP2MP user services (MP2MP bottom-up only).
 LLCF must be operated only in MPLS networks (although LightSoft does not block it on PB networks).
 UNI, E-NNI (Eth only).
For LLCF to operate on an Ethernet service:
 Service ports must be LLCF capable.
 Service must have a CFM MA created on it with CCM enabled.
Parent Topic

11.1.14 Understanding CFM-PM (Y.1731)

The Y.1731 standard defines Ethernet PM mechanisms for measuring Ethernet service performance.
LightSoft supports CFM-PM (Y.1731) measurements for P2P, P2MP, VLAN Tree, and MP2MP services,
performed between pairs of MEPs belonging to the same MA. Each pair includes a Sender MEP that
generates messages, and a Responder MEP that replies to them. On MP service MEGs, CFM-PM can be
applied to any subset of the pairs of MEPs.
LightSoft's CFM-PM mechanism covers the following SLA parameters:
 Frame Delay (FD): The round trip time that a frame spends on the way to the remote endpoint and
back. FD time includes travel time only; the time that the packet is delayed within the remote MEP is
excluded.
 Frame Delay Variation (FDV): The difference (delta) between the current FD value and the previous
FD value. This measurement also excludes the time that the packet is delayed within the remote MEP.
 Frame Loss (FL): The number of frames lost during transmission from the local MEP to the remote
MEP, or during the return transmission.
 Availability: The amount of time (in seconds) that service was available between a pair of MEPs
belonging to the same MA.
To measure SLA parameters, synthetic frames are periodically generated by a local MEP towards a remote
MEP along the same path as the service frames. The remote MEP replies with synthetic frames of its own,
which are then used by the local MEP for calculating performance.
CFM-PM quality standards can be tailored to the type of service through user-defined profiles. Settings for
transmission period, frame size, and minimum performance threshold can be configured by the user.
Parent Topic
11.2 Creating a Service

This section describes the steps in creating an Ethernet service and lists the minimal essential fields that
must be completed.
Ethernet services are created using the Create Ethernet Service window. In most cases you can accept the
default field values provided by LightSoft. Detailed descriptions of all parameter field options are described
in detail in Create Ethernet Service Window in the Supporting Information Supplement, organized by
window tab and pane.

NOTES:
 For some of the more advanced types of services or service features, additional
configuration steps are required; follow the links to specific instructions.
If you are directed to a different section, you do not have to return to the previous topic.
All necessary information to complete provisioning the new service is in the new topic.
 Not all parameters or field options are relevant in every instance. Irrelevant parameters in
the GUI are grayed out.
 For a general set of guidelines and recommendations when creating a service, see Service
Creation Guidelines and Recommendations.
To create an Ethernet service:

1. In the main window Topology Layer dropdown list, select the ETH/MPLS layer.
2. (Optional) In the main window map region, select the LEs containing the endpoints of the intended
service.
If you select LEs in advance, they, rather than all the objects in the current view, will be displayed
when you open the Create Ethernet Service window.
3. In the main window Services tab, in the General group, click Create ETH Service. The Create Ethernet
Service window opens.
4. (Optional) If you want to create the new service based on saved global template details:
a. Click Load Global Template . The Load Global Template dialog box opens.
b. Select an existing global template, and click OK. The parameters and path details from the
template are applied to the current service. You can change selected parameter values as
needed according to the following steps.
See Creating and Working with Global Service Templates.
5. In the Service Details tab, in the Basic Parameters pane:
a. Identify the new service:
 In the Label field, enter a name for the new service. Choose a name that identifies the
new service in some meaningful way.
 In the Customer field, enter a string that identifies the customer linked to this new service.
Choose a meaningful string.
b. From the Service Group dropdown list, select Customer or Infrastructure:
 Customer service types range from basic to complex. The steps described in this section
are sufficient to create a simple service. If you are provisioning advanced services that
require additional operator input, links are provided to the additional steps.
--MP2MP (default)
--Rooted MP
--P2P
--P2MP (E-Tree)
--VLAN Tree
--Freeform
--CES (MPLS P2P, PB P2P, PB MP2MP)

 Infrastructure service types offer a choice of service protection mechanisms:

--ERP DH H-VPLS
--ERP PB Ring
--RSTP
c. (Optional) For P2MP services that adhere strictly to a standard of no communication between
leaves, check the E-Tree Enabled checkbox. (Default)
d. (Optional) For hierarchically structured services:
 For H-VPLS services, check the H-VPLS Enabled checkbox.
 For hierarchically structured P2P and CES P2P services, check the MS-PW Enabled
checkbox.
 For PW redundancy protection for P2MP, MP2MP, and E-Tree services, check the H-VPLS
Enabled checkbox.
For a detailed description of hierarchical service creation, see Creating Multidomain Services.
e. (Optional) To automatically enable the service after successful activation, check the
Administrative Service Enable checkbox. (Default. Note that the service can be manually
enabled or disabled after activation using the same checkbox in the Service List window.)
f. (Optional) To allow a tunnel to be assigned without verifying the endpoint EIR compatibility (‘all
green tunnel’), check the Allow Assigning CIR-only tunnels to 2-Rate Policer checkbox.
6. In the Service Details tab, in the Advanced Parameters pane:
a. Select the appropriate BSC Policer profile (Understanding BSC Policer Profiles). Note that this
feature is not relevant for P2P and VLAN Tree services.
 In the Service Details tab Advanced Services Parameters pane, click BSC Policer Profile
Selector . The Select Policer window opens.
 Select an existing policer profile, and click Apply. The selection is reflected in the BSC
Policer Profile field. Note that a BSC policer must be a Two Rate Policer type.
b. (Optional) To specify the maximum number of MAC addresses that can be learned per VSI
supporting this service, enter a value in the vFIB Quota field. (Default 100. Not relevant for P2P
and VLAN Tree services.)
c. (Optional) Select the LSP Tunnel Mode option for this service's tunnels, either E-LSP (default) or
L-LSP.
d. (Optional) Select the VC Label Scheme behavior for this service, either Regular (default) or Single
Label.

e. (Optional) To ensure that this service uses only protected tunnels, check or uncheck (default) the
Protected Tunnel Only checkbox.
f. (Optional) To enable BPDU tunneling dual homed service protection for P2P services, check or
uncheck the BPDU Tunneling Dual Homing checkbox and choose the service type:
 Access Link
 Internetwork Link
g. To use this service as an Ethernet control service, select the Used for Control checkbox.
7. Select and configure the service endpoints in the Endpoints tab fields:
a. In the Create Ethernet Service window map view, select an LE or group. To select multiple
nodes, click each node while holding down the SHIFT key or hold down the left mouse button
and drag to select a group of nodes included within a virtual region.
b. Right-click and choose Select Endpoint. A filtered version of the port tree is displayed, including
slots of the relevant ports.
c. Expand the tree and select a port for the endpoint. LightSoft automatically displays only
compatible endpoints, graying out the others.
d. When creating a P2MP, Rooted MP, E-Tree, or VLAN Tree service, specify whether the endpoint
selected is to serve as a root or a leaf. By default, the first endpoint selected in a group is the
root, and subsequent selections are leaves. P2MP services can be configured with max. four
roots and an unlimited number of leaves. Roots can only be configured on PE nodes, while
leaves can be configured on PE or PB nodes. When the P2MP service is E-Tree-enabled, the
same LE can be used for both root and leaf endpoints.
e. Click Select to complete the selection. The port details are listed in the Endpoints tab Endpoint
List pane.
f. To remove an endpoint from the Endpoint List, right-click that endpoint and select Remove. To
clear all endpoints in the list, right-click an endpoint and select Remove All.
g. Repeat the preceding steps for each required endpoint.

A service can only be completed after two or more endpoints are defined. A port only becomes a
configured service endpoint after activation.
8. Assign C-VLAN values for all UNI ports in the list of endpoints. Select each UNI port entry in turn and
configure the C-VLAN values (1:4094) using one of the following methods:
 Select the All/Other checkbox. Packets associated with any C-VLAN IDs not used by other
services at this port will be available. For example, if the C-VLAN IDs 1 and 2 are used by other
services at this port, packets with C-VLAN IDs 3 through 4094 can be used. Note that selecting
All/Other for the C-VLAN ID disables the DSCP option. The reverse is also true; configuring DSCP
disables the All/Other option.
OR
 Enter specific C-VLAN IDs, entered as comma-separated individual C-VLANs and/or ranges of
C-VLAN. For example, the string '1,2,3,5-10' indicates the nine C-VLAN IDs 1 to 3 and 5 to 10.
Packets associated with these C-VLAN IDs will be allowed for the service.
C-VLAN IDs that are available for use at this port are listed in the C-VLAN List window. To open
this window, click Show Free C-VLANs List .
Note: C-VLAN values must be between 1 and 4094 and not duplicated in any other services at
the selected endpoint. If you type an illegal C-VLAN value into the field, the number is written in
red and the Complete and Activate buttons are disabled until the C-VLAN value is corrected. A
red question mark overlaid on the Complete button flags the C-VLAN error and provides a
tooltip explaining the error condition, as illustrated in the following figure.
OR
 For specific types of equipment and services, multiple C-VLAN IDs can be entered in the form of
a C-VLAN group by clicking Add a C-VLAN Group .

Specify the C-VLAN IDs and checkbox selections applicable to the packets that should be policed
based on the additional C-VLAN group. Note that any specific C-VLAN value can appear only
once across all groups in the table. Similarly, the All/Other checkbox can be selected only once
in the table, in only one line, and no other values/checkboxes can be set on that line.
To remove one or more C-VLAN groups, select the C-VLAN group(s) and click Remove Selected
C-VLAN Groups .
NOTE: The Multiple C-VLAN Group capability is provided as a convenience for certain
equipment. The same purpose can also be achieved by defining a separate service for each
required policing regime.
 (Optional) Select (or deselect) the Untagged and/or Priority Tagged checkboxes to allow (or
block) untagged and/or priority tagged packets for the service, in addition to packets with the
appropriate C-VLAN IDs.

Note: Depending on the capabilities of the underlying equipment, the Untagged and Priority
Tagged checkboxes may either be configured independently or configured as a set, with both
set to On as soon as one is selected and both set to Off as soon as one is cleared. When working
with VLAN groups, the Untagged and Priority Tagged checkboxes can be selected only once in
the table, in only one line.
For more information, see C-VLAN Port Settings.
9. Assign S-VLAN values for all NNI ports in the list of endpoints. Select each NNI port entry in turn and
enter the appropriate VLAN ID values.
S-VLAN IDs that are available for use at this port are listed in the VLAN List window. To open this
window, click Show Free VLANs List .
Note: S-VLAN values must be between 1 and 4094 and not duplicated in any other services at the
selected endpoint. Illegal S-VLAN selections are not allowed and trigger an error when LightSoft
validates the service at completion.
10. (Optional) Configure policer profiles, described in detail in Managing Policer Profiles.
11. (Optional) Additional optional configuration settings are available through the panes in the Endpoints
tab. Highlight the endpoint in the Endpoints tab and complete the steps described in the following
sections, as relevant:
 Applying C-VLAN Translation to a Selected Endpoint
 Configuring Priority-CoS Mapping
 Configuring DSCP-CoS Mapping
Detailed descriptions of all parameter field options are provided in the relevant window pane and tab
descriptions under Endpoints Tab in the Supporting Information Supplement.
TIP: If endpoints have the same or similar attributes and settings, after they are selected and
you have fully configured one endpoint, you can copy and paste some/all attributes and
settings to other endpoints. In the Endpoint List pane, do the following:
 Right-click a configured endpoint line, and select Copy Details.
 Select one or more endpoint lines into which to copy the attributes and settings.
 Right-click, select Paste Details, and then All Details or a specific configuration aspect. See
the Paste Details description in Endpoint Shortcut Options in the Supporting Information
Supplement.
OPTIONAL FEATURE: The Copy Details shortcut is a fully integrated add-on capability,
unavailable.
12. Configure network-related service parameters in the Networks tab fields. In this step you are
configuring the tunnels that will connect the selected endpoints.
The Networks tab displays either a PB or an MPLS network pane, with an H-VPLS domains tree when
relevant (depending on the service type). Detailed descriptions of all parameter field options are
provided in the relevant window pane and tab descriptions under Networks Tab in the Supporting
In most cases you can accept the default field values. Your input is only needed:

 (Optional) In MPLS networks when selecting tunnels manually for a service.

 (Optional) In PB networks for manual S-VLAN registration for a PB MP2MP service or when
selecting a direct link and configuring PB P2P services between MCS cards.
If you decide to select links manually, if the required link is within a multilink, you can choose
the appropriate link from amongst those in the multilink. If you do not choose a specific link,
LightSoft automatically chooses the segment to add to the list at completion time.
13. Configure the maintenance associations (MAs) needed to implement CFM functionality in the CFM
tab fields .
CFM provisioning tasks include configuring and managing MAs and implementing LLCF, as described
in Managing CFM MAs. Detailed descriptions of all parameter field options are provided in the
relevant window pane and tab descriptions under CFM Tab in the Supporting Information
Supplement.
a. In the Create Service window MA List pane, click Add MA. The Add MA dialog box opens.
b. (Optional) Enter an MA label.

c. (Optional) Select the appropriate values in the dropdown lists for fields that are enabled.
d. LightSoft automatically selects CFM parameters appropriate for the service being provisioned.
In most cases you can leave the default values. To enable CFM continuity checks, enable CCM
and Alarms.
e. Click OK. The dialog box closes and the MA is reflected in the MA List pane. Once the new
service is activated, the MA is saved.
14. (Optional) Click Complete service . LightSoft makes a selection from amongst the candidate
tunnels based on your service configuration settings. The selection details are displayed for you to
review. You can go back and modify the service parameters if needed.

NOTE: You may optionally choose to have LightSoft automatically create missing tunnels
when provisioning a new service; see Service Management Preferences in the Getting Started
& Administration Guide.
warnings or nonfatal errors. If the Complete step fails, perform the verifications listed in Diagnosing a
Create Service Failure.
15. (Optional) You can store a temporary local template of the configuration details for the service you
just created. Use it to create other similar services, using the same endpoints, without having to
redefine the service properties.
a. Click Store Local Template . The service details are stored in temporary memory of the
user session for use during the current session only. Do not close the Create Service window
before creating the additional services, as this erases the local template.
b. Continue with the remaining steps in this section to activate the current service and then create
additional services, using the local template, as described in the final step.
c. To save the current configuration settings as a service template in the database for later use (in
this or another session) when creating new services with similar parameters and path details,
click Save Global Template . To load details of a saved service template to the Create
Ethernet Service window in the process of creating a similar service, click Load Global Template
.
16. To implement the new service, click Activate service .

warnings or nonfatal errors. If the Activate step fails, perform the verifications listed in Diagnosing a
NOTE: If Complete Service was not performed before, or if it was followed by an action that
would change the links used by the service (such as a change of endpoint), service completion
will automatically be performed/repeated as part of the activation process.
17. (Optional) You can export one or more services to an XML file for backup purposes.
 Click Export . The Export Services dialog box opens. Continue the procedure as described in
Exporting Services , from Step 3.
18. (Optional) To create additional services based on the local template created after the current service
was completed:
a. Select Clear and Reset to clear the service contents (this step is required if Show
Activated Services is set to ON).
b. Click Restore Local Template .

c. Select the same endpoints again.

d. Perform Steps 4 through 14 to implement (or export) the additional service. The service
parameter and endpoint selections will already be set to the previous service's settings. Enter
different setting values, if any.
e. If another similar service is required, repeat this step.
Parent Topic
11.2.1 Service Creation Guidelines and Recommendations

Follow these basic guidelines when configuring a data service. If you do not, your network or service
configuration may not be operational and LightSoft will be unable to validate and activate the service. This
section is not a complete list of all possible errors; it is simply a starting set of guidelines. Specific network
or service configuration details may vary. Check the warning and failure messages that appear for more
information.
General Guidelines
 Consistency is the basic rule. Parameters such as label schemes, tunnel modes, VC labels, services, and
media types, must be defined and used consistently and match the underlying equipment
requirements and capabilities.
 When creating a service, the only network resources for your use are the resource domains for which
your user group has access; see Managing User Groups.
 Services can only work within the physical limits of the underlying equipment. Configure a service only
on equipment that is capable of supporting it. Do not try to exceed built-in limits, such as limits in
VClabel value, number of SHGs, etc.
 Plan your network data service configurations carefully to provide the best possible support for the
customer services to be defined on them. Keep in mind that later changes may be complicated. Editing
or deleting data services that are in active use by customer application services may negatively affect
traffic, or may simply not be allowed.
Link Types
Ethernet services can traverse the following types of links:
 EoS virtual link (EoS trail)
 ETY physical link
 ETY virtual link (LP trail)
Ethernet services can also be clients of optical automatic virtual links.
You can provision Ethernet traffic (MPLS tunnels and Ethernet services) over WDM topology using
LightSoft. Ethernet/MPLS data networks can include path segments in which direct physical connections are
impractical because of distance or need for aggregation. In such cases, optical WDM segments are included
in the data network.
Data services run between two Ethernet or MPLS ports with the endpoints residing in the relevant data
layer. To provision Ethernet Traffic over WDM topology, a LP trail must be provisioned between the
endpoints. The LP trail is displayed as a virtual link in the Ethernet/MPLS layer. This ensures a consistent
logical Ethernet/MPLS link, whether or not the link includes underlying optical segments, and enables easy
navigation between the Ethernet/MPLS network layer and the underlying WDM network.

VC Labels
 When working with a single-label VC label scheme, LightSoft automatically assigns VC labels. The user
does not have this option.
 When working with a regular VC label scheme, LightSoft by default automatically assigns VC labels.
The user may optionally choose to assign VC labels manually. Be sure to choose a valid VC label value
or LightSoft will not validate the service (check the list of free VC labels to be sure you choose an
available VC label).
 The VC label scheme and label values must be appropriate for the equipment participating in the
service. For example, single-label equipment cannot work with a regular VC label scheme. See the
relevant EMS User Guide for more information.
 Services acquired from the EMS level that do not meet LightSoft's validation standards are labeled
nonconformant and must be corrected. For example:
 Each PW's incoming and outgoing labels must match. If not, the VC label column displays
'Invalid'.
 All VC labels transmitted to nodes configured for single label VC schemes must be the same.
 For each VSI, the VC label scheme and tunnel mode must match.
E-Tree/P2MP Service Configuration

 LightSoft supports up to four roots or four redundancy pairs in a P2MP or E-Tree service.
 Users can select a mixture of endpoints on LEs both with and without E-Tree capability. Depending on
the endpoint capabilities, the E-Tree service can be full, partial, or not relevant.
 The same LE can include a mixture of roots and leaves. Note that this may be risky if the configuration
includes a second remote root, since a leak between leaves becomes possible. It is the responsibility of
the operator to validate the service topology and ensure that the configuration is functionally correct.
 As a general recommendation, first define roots and then add leaves as part of the same Create
Service or Edit Service operation. Adding roots after the service has already been created is not
recommended since the existing SHG assignments may interfere with full connectivity between each
root with every leaf.
LAG Configuration
 Creating services in a LAG configuration entails certain prerequisites. For example, the ports used must
be preconfigured as LAG ports at the EMS level; see LAG Support.
Parent Topic
11.2 Creating a Service

11.3 Creating Multidomain Services

H-VPLS, multisegment PW, and VLAN Tree services are all categorized as multidomain services and this
section deals with their configuration. E-Trees are VLAN Trees that meet stricter behavior criteria. PW
Redundancy (PWR) is an optional feature available for H-VPLS services. Points of information in this section
that only apply to a specific service type are so noted. See Creating a Service.
H-VPLS Service Considerations and Prerequisites

Two approaches can be used when creating H-VPLS and PWR services:
 In top-down service creation, you first enable the service and then divide the MPLS PEs into domains.
LightSoft can automatically assign the tunnels needed to implement the service or you can do so
manually, as described in the introduction to MPLS Network Pane in the Supporting Information
Supplement.
 When configuring PWR services, all PEs participating in the PWR domain (pivot and gateways) must
support PW redundancy.
 In bottom-up service creation, services are acquired from the network and admitted to LightSoft.
LightSoft analyzes the service structure and creates the required domains automatically. LightSoft
classifies a service as H-VPLS if separate domains can be inferred from its tunnel requirements.
Similarly, LightSoft identifies if the service is configured for PW redundancy based on the service
structure and tunnel configuration.
If LightSoft is not able to identify an H-VPLS-appropriate domain structure and there is no other
predefined configuration that matches this service configuration, the service is classified as Freeform
(the most appropriate (and only) alternative).
Note: H-VPLS services can also be edited after the service has been activated. When editing or
changing the service, the tunnels and attributes must be defined as usual.
Ensure that the required tunnels have all been created. Note that LightSoft validates the proposed service
topology and configuration only at the end of the service configuration process, at the point of completion.
If the proposed service fails the validation checks, the service activation request will be denied.
Multisegment PW Service Considerations and Prerequisites

 Multisegment PW service must be configured over E-LSP tunnels utilizing a regular VC label scheme,
and the underlying hardware must support multisegment PW capabilities.
 If the user enables multisegment PW functionality for an existing service, LightSoft unassigns the
existing direct tunnels. Alternatively, if the user disables multisegment PW functionality for an existing
service, LightSoft unassigns the existing domains and domain-by-domain tunnels that were originally
configured to support multisegment PW.
VLAN Tree Service Considerations and Prerequisites

Before defining VLAN Tree service, verify the following configuration points:
 Endpoints for VLAN Tree services can only be located on MPLS cards in BG9300 or SR9700 platforms.
VLAN Tree service must be enabled for the endpoints.
 Each service endpoint is configured as root or leaf, depending on the equipment type:
 BG9300 platforms are always configured as leaves.
 SR9700 platforms can be either leaves or roots.

By default, the first SR9700 endpoint selected is the root and subsequent endpoints selected are
leaves. VLAN Tree service must have at least one root, with up to four roots supported.
 VNEs and third party equipment can be included in the service.
 Create the MoE links required between participating MEs.
 Create the necessary infrastructure of E-LSP tunnels in each domain, configuring an appropriate
arrangement of root and leaf tunnels.
 Create the necessary virtual RSVP tunnels between VNE and CESR nodes. VLAN Tree service nodes are
connected with one virtual RSVP tunnel between each pair of nodes.
 Synchronize the new tunnels in LightSoft through the TSC, as described in Synchronizing Tunnels.
 Identify the natural static and dynamic regions in the topology layer of the network, as described in
Planning Domains. When creating a new VLAN Tree service, these regions are configured as separate
domains within the VLAN Tree service, similar to standard H-VPLS service.
To create a multidomain service:

2. To configure H-VPLS service:
 In the Basic Parameters pane:
 From the Service Group dropdown list, select Customer.
 From the Type dropdown list, select MP2MP, P2MP (E-Tree), Freeform, or VLAN Tree.
 Select the H-VPLS Enabled checkbox.
(If the H-VPLS Enabled checkbox is disabled, verify that the Tunnel Mode and VC Label
Scheme fields in the Advanced Parameters pane are set appropriately. Then return to this
step - the H-VPLS checkbox in the Basic Parameters pane should now be enabled.)
 In the Advanced Parameters pane:
 For the VC Label Scheme parameter, select Regular.
3. To configure MS PW service:
 From the Type dropdown list, select P2P or CES MPLS P2P.
 Select the MS-PW Enabled checkbox.
4. To configure PW Redundancy service:
 From the Type dropdown list, select MP2MP, P2MP (E-Tree), or VLAN Tree.
 Select the H-VPLS Enabled checkbox.

5. To configure VLAN Tree service:

 From the Type dropdown list, select VLAN Tree.
 In the Advanced Parameters pane:
 Select (default) or clear the Protected Tunnels Only checkbox.
Note re VLAN Tree: Protected tunnels are strongly recommended for VLAN Tree service.
6. Select endpoints for the service.
Note: Endpoints for VLAN Tree services can only be located on MPLS cards inside BG9300 or SR9700
platforms. VLAN Tree service must be enabled for the endpoints. On BG9300 platforms, endpoints
must be configured as E-NNI ports, and on SR9700 platforms as UNI ports.
a. In the Create Ethernet Service window map view, select the appropriate nodes.
b. Right-click and choose Select Endpoint. A filtered version of the port tree is displayed, which
includes slots of the relevant ports.
c. Expand the tree and select ports for the service endpoints. LightSoft automatically indicates the
compatible endpoints available.
d. Click Select to complete the selection. The port details are listed in the Endpoints tab Endpoint
List pane.
e. Note: Each port selected for VLAN Tree services must be assigned a role as either root or leaf
(default). In a typical network configuration, BG9300 platforms are usually leaves and SR9700
platforms roots. One VLAN ID value is assigned per VLAN group. Multiple VLAN groups are
supported for VLAN Tree service if the endpoint's LE equipment is capable of supporting
multi-VLAN trees, such as in BG9300 platforms. One VLAN ID is used in SR9700 platforms. See
VLANs Pane for VLAN Tree Services in the Supporting Information Supplement.
f. Configure policer profiles as appropriate (see Managing Policer Profiles) or use the default
settings.
g. Repeat the preceding steps for each required endpoint.
NOTE: If any of the service endpoints are in a PB network, the PB ring must be connected via
gateway nodes to the MPLS network. All gateway nodes for a PB network must be included
in the same domain.
7. Define domains with their constituent nodes. Note that domains are listed in a Domains area above
the Tunnel Requirements table in the Networks pane. This table is empty until domains are defined
in the service.

a. Select the required nodes in the map by holding down the left mouse button and dragging to
enclose the required nodes in a virtual selection region.
b. Click New Domain in the Domains area of the MPLS Network pane. The New Domain
dialog box opens.
c. Enter the domain name, select the domain type from the drop down list (VPLS (default), PW
Redundancy, or ERP DH), and click OK. The new domain appears in the Domains area list.
The icon and text next to each domain in the list identify the domain type:
 indicates PW Redundancy domains

 indicates VPLS domains
 indicates ERP DH domains

d. Repeat this step for each required domain.

8. Add a node to an existing domain:
a. Right-click the node in the map, and select Add LEs to Domain.
b. In the Add LE to Domain dialog box, select the appropriate domain name in the dropdown list,
and click OK.
c. Repeat this step until all the domains contain their required nodes.
NOTES:
 A node that serves as a gateway node should be added to both adjacent domains. For
example, nodes 22.01-I1-101 and 22.01-I3-103in the preceding figure are included in both
domains, PW1 and VPLS1.
 Each domain is assigned a different color. Nodes within a domain are outlined with that
domain's color (yellow and blue in the preceding figure). Gateway nodes that are included
within multiple domains are outlined in black.
 Next to each domain name is listed the domain type (VPLS, ERP DH, or PW Redundancy).
 Clicking a domain name or any node in the domain tree causes the associated objects in
the window map to be highlighted.
 Double-clicking a node expands or collapses its subtree. When the branch is collapsed, the
number of elements included in the branch is listed in the table
.

9. To change a domain type, right-click the domain in the domains tree, and in the shortcut menu, select
the new domain type.
10. To remove a domain and all its nodes from the domains tree, right-click the domain in the domains
tree, and in the shortcut menu, select Remove.
11. (Optional) Manually calculate the tunnel requirements to implement this domain configuration.
Tunnel requirements are based on the domains that have been defined. To optionally complete this
step manually click Calculate Tunnels List to calculate the service tunnels and SHGs
appropriate for the new domain structure. LightSoft automatically analyzes the new service
configuration to identify which tunnels are necessary and adds them to the Tunnel Assignments
table. (LightSoft completes this step automatically as part of the Complete and Activate stages if it is
not done manually.)

Note that the Calculate Tunnels List step may fail if there is a problem validating the service
configuration, for example, if the domains are not properly defined. If the calculation fails, an error
message is displayed. For example, when provisioning a multidomain service that should include PW
redundancy, LightSoft provides a warning message if the underlying physical infrastructure selected
includes LEs with no PW redundancy capability, as illustrated in the following figure.
The user is also warned about other potentially problematic or risky configurations, where relevant.
For example, configuring an ERP DH service in a PW redundancy gateway may lead to traffic loss.
This means that the Calculate Tunnels List step, while optional, can provide a useful early indicator of
potential problems in the new service configuration.
TIP: Manual tunnel list calculation by clicking Calculate Tunnels List is optional.
Nevertheless, it is sometimes useful to complete this step in order to examine LightSoft's
choices and have the option of revising specific tunnel selections before completing the
service configuration.
The remaining manual intervention steps in the domain definition process are optional. From
this point on, at any time you can choose to have LightSoft automatically calculate the tunnel
requirements table, complete, and activate the service.
12. (Optional PWR features) When configuring PW redundancy services for P2MP, E-Tree, and MP2MP
services, LightSoft automatically configures the redundancy pairs and assigns primary and secondary
tunnel roles. By default, active traffic is transmitted over primary tunnels. A fault condition over the
primary tunnel automatically triggers a switch of active traffic to the secondary tunnel. Members of
the same Redundancy Pair are easily identified through the LightSoft GUI because each pair is
displayed with distinct colors. For example, the following figure illustrates an Ethernet service
configured with two domains. The corresponding tunnels are listed in the Tunnel Requirements table
below the Domains pane. Two selected tunnels are highlighted in the table and in the map view.

 To check if a PW tunnel is being used for active traffic or is on standby:

 Right click on the selected tunnels and choose Show PW status (LightSoft or EMS) from
the shortcut menu,

Or
 Select one or more tunnels in the Tunnel Requirements table and click in the
Network tab toolbar,
A PW Status table opens, listing the selected PWs and their current status (Active or Standby).
 To switch the primary and secondary tunnels:

1) Open the Networks tab.
2) In the Tunnel Requirements table, choose the tunnel whose role you want to switch.
3) Click the Redundancy Role dropdown box and select Primary or Secondary. The
corresponding tunnel role switches automatically.

13. (Optional) Manually selecting tunnels.

In the Tunnel Assignments area, you may optionally choose to manually select one or more tunnels;
see Selecting Tunnels Manually for a Service.
a. To populate the Tunnel Assignments table, click Select Tunnels . LightSoft fills in tunnel
options that are appropriate for the requirements of the domains that have been defined.
b. Manually assign the tunnels you want to each row, choosing the appropriate bandwidth and
CoS values.
Repeat this any number of times, until the entire domain structure is defined to your satisfaction.
14. (Optional) Click Complete service .

LightSoft automatically analyzes the new service configuration to identify necessary tunnels (choosing
from amongst the candidate tunnels using your parameters), and adds them to the Tunnel
Assignments table. The new service configuration details are displayed for you to review. You can
modify the service parameters if needed.
warnings or nonfatal errors. If the Complete step fails, perform the verifications in Diagnosing a
15. Click Activate to complete and activate the service.

After completing internal verification checks, LightSoft implements the service. If something has not
been configured correctly, an error message indicates the problem and suggests appropriate
corrective measures.
NOTES:
 When checking the new service before activation. LightSoft validates that there is
contiguous connectivity between the two endpoints in each direction.
 In multisegment PW services, LightSoft configures CAC for each static segment, similar to
CAC configuration for any P2P service. CAC is not configured for the dynamic segments of
the service. The user is reminded of this with a warning message at activation.
 In H-VPLS P2MP service, LightSoft does not validate that there is no direct communication
between leaves or between roots. The network designer must take this into account and
verify the topology as needed. This is due to a data plane limitation. An example clarifying
this point appears in P2MP Service on Single Homing Topology.
 If Complete Service was not performed before, or if it was followed by an action that
would change the links used by the service (such as a change of endpoint), it will
automatically be performed/repeated as part of the Activate process.
Parent Topic

11.4 Creating Freeform Services

The Freeform service type enables you to flexibly define a service without being subject to the standard
LightSoft validations, such as tunnel or connectivity requirements. This service type is intended as a 'last
resort' for advanced service scenarios that do not match any of the standard service configurations.
Freeform service can be a powerful tool, as it allows LightSoft to manage non-orthodox services while still
classifying them as Conformant. However, it can also be risky, since the standard LightSoft validation and
safeguard mechanisms are not applied.
With Freeform service, tunnel selection is manual. All tunnel requirements must be explicitly defined. In
addition, a full mesh tunnel structure is not assumed. The user manually defines only the tunnels needed
for that service by specifying the pairs of nodes that should communicate with each other via direct
tunnels.
Freeform service can be configured with or without H-VPLS enabled:
 The basic mode is without H-VPLS enabled, enabling the user to manually define a specific set of
connections between endpoints. This allows configuration of partial mesh topologies where full
connectivity is not required, avoiding the extra overhead of unnecessary connections.
 The advanced mode is with H-VPLS, enabling the user to manually define:
a. Tunnel connections between PEs that are not endpoints.
b. Multiple SHG values that enable a wider set of packet transfer options within a root node.
CAUTION: The greater power and flexibility of Freeform service carries with it a risk of the
user unintentionally creating loops within the network configuration.
NOTE: This topic focuses on the specific steps and parameter values required to configure a
Freeform service. For general service creation and available service options, see Creating a
Service.
To define a Freeform service between multiple PEs:

2. In the Basic Parameters pane:
 In the Service Group dropdown list, select Customer.
 In the Type dropdown list, select Freeform.
 Select or clear the H-VPLS Enabled checkbox.
3. In the Advanced Services Parameters pane:
 Select the VC Label Scheme option.
With H-VPLS enabled, the VC Label Scheme must be Regular.

4. Select endpoints for the service.

b. Right-click, and choose Select Endpoint. A filtered version of the port tree is displayed, including
d. To complete the selection, click Select. The port details are listed in the Endpoints tab Endpoint
List pane.
e. Configure policer profiles as appropriate (see Managing Policer Profiles) or use the default
settings.
f. Repeat the preceding steps for each required endpoint.
5. Define tunnels to provide bidirectional connections between nodes. In the MPLS Network pane of the
Networks tab, the Tunnel Assignments table displays only tunnels that have already been assigned.
This table is initially empty; you must define all Freeform service tunnels manually.
a. In the window map view, select pairs of nodes that should be connected by a direct tunnel.
b. Right-click the nodes, and choose Select Tunnels. The Assign Tunnels dialog box opens.
c. Assign at least two tunnels between each node pair to provide a bidirectional connection.
d. Repeat for each pair of nodes participating in the service.
NOTES:
 With Freeform service, LightSoft does not automatically configure the connections
between nodes.
 Connectivity is configured by the user per node pair.
 The selected nodes do not have to be endpoints.
 If any of the service endpoints are in a PB network, the Freeform service configuration
must include tunnels to the PB network gateway nodes.
6. When the H-VPLS Enabled checkbox in the Basic Parameters pane is checked, you can manually
assign different SHG values according to the connectivity requirements of the specific service.
When the H-VPLS Enabled checkbox is not checked, all tunnels listed in the Tunnel Assignments table
have an SHG value of 1, as illustrated in the following figure.


LightSoft displays the new service configuration details for you to review. You can modify service
parameters if needed.

LightSoft implements the service after completing internal verification checks. If something has not
changed the links used by the service (such as an endpoint change), it will automatically be
performed/repeated as part of the Activate process.
Parent Topic
11.5 Configuring BPDU Tunneling Dual Homing

Services
When configuring dual homing services, note the following guidelines and prerequisites:
 One CoS can be configured.
 Frame selection is automatically set to BPDU. Other values are not relevant.
 RSTP must be used in the participating PB network.
 Protected tunnels are highly recommended.
 On selecting a service endpoint for which a dual-homed peer has been configured, by default LightSoft
adds the dual-homing peer as an additional service endpoint.

 Policer profiles and C-VLAN list are copied by default to the dual-homing peer.
 The dual-homing peer UNI ID is displayed for each UNI.
 After initial configuration, LightSoft allows modification of the policer profile and the C-VLAN list
without requiring equality between the values.
 For UNIs connecting to a UME, selection of the UME is equivalent to selection of the LE.
 For LAG ports, the service can only be defined on the master port, not on slave ports.
 Port-based UNIs on which a service is already defined and bridge EoS UNIs connected (by EoS) to
remote access points are not sensitive for selection.
 Ethernet service endpoints can be defined on Ethernet UNIs. A single service can be defined on a
port-based UNI.
Parent Topic
11.5.1 Creating Access Link Dual Homing

Prerequisites
Before defining access link DH service, verify the following configuration points:
 The PB client network must be working with RSTP.
 The MPLS network should have already defined a complete network of functional tunnels, including
the PEs to be protected by dual homing.
 Two EoS trails or ETY links must be defined between the MPLS PEs and the client network CEs.
 Services are only protected if service endpoints are defined on both the DH ports. Both DH peer ports
usually share identical attributes values (VLANs, CoS mapping, policers) since they are handling the
same customer frames. After you have configured the first endpoint, LightSoft conveniently fills in
attribute values for the second endpoint.
NOTE: This topic focuses on the specific steps and parameter values required to configure
access link DH. For general service creation and available service options, see Creating a
Service.
Defining Access Link DH
To define a P2P service between the two access link dual homed PEs:
 In the Type dropdown list, select P2P.

 Select the BPDU Tunneling Dual Homing checkbox.

 Select the Access Link Service option.
 Select or clear the Protected Tunnels Only checkbox.
NOTE: Protected tunnels are strongly recommended for dual homed service.
4. Select endpoints for the service:

c. Expand the tree and select a port for the DH endpoint. LightSoft automatically indicates the
d. To complete the selection, click Select. The port details are listed in the Endpoints tab Endpoint
List pane.
e. Configure policer profiles as appropriate (see Managing Policer Profiles) or use the default
settings. The standard service creation requirements apply. For example, the service CoS must
match the tunnel CoS.



NOTES:
 If Complete Service was not performed before, or if it was followed by an action that
changed the links used by the service (such as a change of endpoint), it will automatically
be performed/repeated as part of the Activate process.
 Once your DH service has been defined, you will be defining customer (application)
services that utilize the DH service. If you define a customer application utilizing an
endpoint that is part of a BPDU DH configuration, LightSoft automatically adds the
necessary protective PE endpoints to your configuration. These additional peer
endpoints, with the appropriate parameters and policer profiles, are automatically added
to the Endpoints List pane. When you complete the service configuration, LightSoft
automatically configures the customer service with dual homing on the peer dual-homed
ports.
Note that you are not required to accept the suggested second port for the service. (You
can remove it in the Endpoints List pane.) However, DH protection will not apply unless
the service endpoint is defined on both PE ports on the links connecting the CE and PE.
Parent Topic
11.5 Configuring BPDU Tunneling Dual Homing Services
11.5.2 Creating Internetwork Dual Homing

Prerequisites
Before defining internetwork DH service, verify the following configuration points:
 The PB client network must be working with RSTP.
NOTE: This topic focuses on the specific steps and parameter values required to configure
internetwork dual homing. For a general description of link, trail, and service creation, see
Creating Topology Links , Creating a Trail , and Creating a Service.
Defining Internetwork DH Service

Defining an internetwork DH service requires the following stages:
1. Linking the MPLS and PB networks by creating EoS trails or ETY links connecting the two networks.
Note that LAG can be used to increase the capacity of the MPLS/PB network links for the EoS trails or
ETY links; see LAG Support.
2. Configuring the ports on the two endpoints.
3. Creating a P2P BPDU tunnel dual homing service between the two dual homed PEs.
Stage 1a: To create two EoS trails connecting the MPLS and PB networks:
1. In the main window Trails tab, in the General group, click Create Trail. The Create Trail window
opens.
2. In the Basic Trail Parameters pane :

 In the Rate dropdown list, select EoS-VC-4-X.

 Select the appropriate VCAT size and protection scheme.
3. In the EoS/MoT Configuration pane , clear the RSTP Enabled checkbox.
Note that by default RSTP is enabled in LightSoft. However, this is incompatible with dual homing.
4. In the map pane, select a pair of PB/PE nodes as endpoints of one EoS trail. Click the two trail
endpoints and create an EoS trail between the PB/PE node pair.
5. Repeat with the second PB/PE node pair to create the second EoS trail.
6. Click Activate to complete and activate the trails.
7. (Optional) The two 'arms' of the DH configuration (illustrated in Understanding BPDU Tunneling Dual
Homing) can each serve as an EoS trail LAG. If you are working with LAG, note the following:
a. You must first configure the LAG at the EMS level.
b. The LAG EoS trails must then be connected at the LightSoft level.
c. When LAG is used in a DH context, the LAG master ports must be connected before the LAG
slave ports.
Stage 1b: To create two ETY links connecting the MPLS and PB networks:
1. In the topology map pane, hold down the left mouse button and drag to select the two link
endpoints: one a PB and the other a PE.
2. In the main window Topology tab, in the Create Group, click Topology Link to create a link between
the two selected endpoints.
3. Select two ETY I-NNI ports, and click Apply to create the link.
4. (Optional) The two 'arms' of the dual homing configuration (see Understanding BPDU Tunneling Dual
Homing) can each serve as an ETY link LAG. If you are working with LAG, note the following:
a. You must first configure the LAG at the EMS level.
b. The LAG ETY links must then be connected at the LightSoft level.
c. When LAG is used in a dual homing context, the LAG master ports must be connected before
the LAG slave ports.

Stage 2: To configure the ports on the two endpoints appropriately:

1. On the PB side of the link, the selected port must be configured with RSTP at the EMS level:
a. Double-click the PB endpoint icon to open the EMS directly through LightSoft’s GCT. )
b. In the EMS, go to the RSTP Configuration window for the bridge.

c. Enable RSTP on the participating port.
For detailed instructions, see the relevant EMS User Guide.
2. On the MPLS side of the link, create a tunnel between the two PEs:
 In the main window Tunnels tab, in the General group, click Create Tunnel. A tunnel is created
between the two PEs.
 Verify that all necessary MPLS tunnels are connected to the two PEs that serve as gateways to
the PB network. Tunnels may be of any appropriate type, including E-LSP or L-LSP, going over
MoT or MoE, with the required CoS.
CAUTION: Use only protected tunnels for DH service (Basic Parameters Pane (page 8-37)).
If you work with unprotected tunnels, only a weaker level of protection can be implemented.
If traffic must be diverted to the DH protection path, no additional path will be available in the
event of a subsequent failure.
NOTE: The MPLS and PB networks are now connected in a simple DH configuration.
 If you are not working with LAG, the networks are connected via two EoS trails or ETY
links.
 If you are working with LAG, the networks are connected via two EoS LAG trails or ETY LAG
links, with each LAG trail/link incorporating multiple trails/links.
Stage 3: To create a P2P BPDU tunnel DH service between the two dual
homed PEs:
 Select the BPDU Tunneling Dual Homing checkbox.
 Select the Internetwork Link Service option.
NOTE: Protected tunnels are strongly recommended for dual homed service.

3. Select endpoints for the service. Choose an I-NNI port (EoS or ETY) as the first endpoint and the
second endpoint from among the I-NNI ports of the same Ethernet network:
d. Configure policer profiles as appropriate (see Managing Policer Profiles) or use the default
settings. The standard service creation requirements apply. For example, the service CoS must
match the tunnel CoS.
e. Repeat the preceding steps for each required endpoint.


All services created by LightSoft between PB and MPLS networks are DH protected. Services created by
EMS are DH protected provided that S-VLAN registration is performed on the dual-homed links.
Parent Topic
11.5 Configuring BPDU Tunneling Dual Homing Services
11.6 Creating RSTP Multiple Homing Services

Prerequisites
At least one MPLS network and one PB network must be defined and connected through an RSTP service.
When defining the RSTP service, pairs of MPLS PE nodes are designated as gateways between the MPLS and
PB networks. Tunnels are defined between these gateway nodes.
NOTES:
 Even though gateway nodes serve as the ends of tunnels, they are not technically
considered ‘endpoints’ and the Endpoints tab is disabled.
 This topic focuses on the specific steps and parameter values required to configure RSTP
services. For general service creation and available options, see Creating a Service.

WARNING: Deleting an RSTP service whose endpoints are supporting customer services may
cause traffic loops for those services. While LightSoft does allow the action, caution is
recommended.
Defining RSTP Services
To define an RSTP service:

 In the Service Group dropdown list, select Infrastructure.
 In the Type dropdown list, select RSTP.
 For the Tunnel Mode parameter, select the appropriate mode.
 For the VC Label Scheme parameter, select the appropriate label scheme.
NOTE: Protected tunnels are strongly recommended for RSTP service.
4. In the Create Ethernet Service window map view, select two MPLS PEs to serve as the PB network
gateway. Only appropriate nodes are available for selection. LightSoft does not allow you to select the
following:
 PEs that do not support RSTP service.
 PEs for which the max. number of supported RSTP services would be exceeded with this
selection.
5. Assign tunnels for both directions of the service:
a. Right-click one of the PEs and choose. Select Tunnels. The Assign Tunnels dialog box opens. The
list of available tunnels includes all tunnels between the two PEs in both directions with all CoS
available. Note that two rows (one in each direction) are displayed for each E-LSP tunnel.
Sixteen rows (eight in each direction) are displayed for each L-LSP tunnel. Select at least two
tunnels, one in each direction.
b. Assign the appropriate tunnels as usual; see Selecting Tunnels Manually for a Service.

6. Repeat the preceding two steps for every additional pair of gateway nodes. Up to 32 gateway nodes
may be selected.
NOTE: All gateway nodes must be linked with bidirectional connections. Full mesh
connectivity is not required, but there must be no isolated nodes.

8. Click Activate to complete and activate the service. When the service is activated, new VSIs are
created, connected via the newly defined tunnels.
If unprotected tunnels were selected, a warning appears. Click Yes if you want to proceed anyway.
(Protected tunnels are highly recommended for an RSTP service.)
changed the links used by the service (such as a change of endpoint), it will automatically be
9. RSTP service definition requires configuring ports with RSTP at the EMS level. For each MPLS PE
participating in the new RSTP service:
a. Double click the node icon to open the EMS directly through LightSoft’s GCT.
b. In the EMS, go to the RSTP Configuration window for the bridge.
c. Enable RSTP on each I-NNI port connected to the PB network.
d. Select the appropriate CoS for the RSTP VSI interface.

e. Apply your changes and enable RSTP for this interface.

See the relevant EMS User Guide.
Parent Topic
11.7 Configuring ERP Protection

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, the RPL Owner, is responsible for blocking and unblocking the RPL in case
of failure (and subsequent recovery) in the network.
 ERP endpoints must utilize comparable equipment.
 Deleting an ERP service whose endpoints are supporting customer services may cause traffic loops for
those services. While LightSoft does allow the action, caution is recommended.
 Services acquired from the EMS level that do not meet LightSoft's validation standards are labeled
nonconformant and must be corrected. The most common problems are inconsistency in the
underlying equipment or the ERP mode, or incorrectly defined RPL/ring ports. For example:
 The ERP mode is not consistent for all VSIs participating in the same service (same VPN ID).
 The ERP DH H-VPLS service includes two different VSIs with inconsistent equipment capabilities.
 The ERP DH H-VPLS service includes two different VSIs and both VSIs are defined as RPL or ring
ports (instead of one RPL and one ring).
 The ERP PB ring service includes VSIs of the same service with too many or too few RPL ports
(the service must have exactly one RPL port defined).
 An illegal number of MoT ports/tunnels are configured. The service allows only 0 or 2 MoT
ports/tunnels.
LightSoft's ERP service supports two ERP operating modes:
 Creating ERP DH H-VPLS Services in MPLS DH topologies
 Creating ERP PB Ring Services in PB or mixed PB-MPLS topologies
Parent Topic
11.7.1 Creating ERP PB Ring Services

ERP PB service is created for PB rings consisting of EoS or ETY I-NNI links. For information about PB
protection choices, see the 1Net End to End Management Suite General Description.
NOTE: This topic focuses on the specific steps and parameters required to configure ERP PB
ring services. For general service creation and all available options, see Creating a Service.

To create an ERP PB ring service:

a. In the Service Group dropdown list, select Infrastructure.
b. In the Type dropdown list, select ERP PB Ring.
a. For the Tunnel Mode parameter, select the appropriate mode.
b. For the VC Label Scheme parameter, select the appropriate mode.
c. Select or clear the Protected Tunnels Only checkbox.
NOTE: Protected tunnels are only relevant for ERP PB ring service if the PB ring is closed via an
MPLS tunnel. When relevant, protected tunnels are recommended.
4. In the Networks tab, open the Provider Bridge Network pane to select links for this service. Only
appropriate links are available for selection. LightSoft does not allow you to select as ERP PB nodes:
 PEs that do not support ERP PB service.
 PEs for which the max. number of supported ERP services would be exceeded with this
selection.
5. Choose I-NNI links that all belong to the same PB network.
6. (Optional) Assign an RPL or ring role to each endpoint.
In an ERP configuration, one port must be RPL and the other ring. The port designated as the RPL is
listed in the PB pane.
By default, LightSoft assigns the first endpoint selected as the RPL port and the other as the ring port.
If you change the role of one endpoint, LightSoft automatically changes the others to the opposite
value.
To manually designate an RPL port:
a. Left-click the link and open the Select Link and RPL port for ERP PB Ring service window.
b. Specify the RPL port by clicking the port at the end of the link in the table.

7. (Optional) Configure S-VLAN for the ERP PB ring service.

In the PB pane, you can optionally configure S-VLAN for the ERP PB Ring service. Otherwise, LightSoft
completes the S-VLAN, automatically selecting the next S-VLAN value available.
8. When the selected links constitute an open ring ending in two MPLS PEs, tunnel selection is enabled.
To configure two tunnels between these two PEs (one tunnel in each direction):
a. Select both PEs by dragging the mouse in the topology map.
b. Right-click and choose Select. The Assign Tunnels dialog box opens. The list of available tunnels
includes all tunnels between the two PEs in both directions with all CoS available.
c. Assign tunnels and CoS to both directions of the service; see Selecting Tunnels Manually for a
Service.


(Protected tunnels are highly recommended for an ERP PB service.)
LightSoft implements the service after completing internal verification checks, including verifying a
correct ring topology. If something has not been configured correctly, an error message indicates the
problem and suggests appropriate corrective measures.
Parent Topic
11.7.1.1 ERP PB Ring Service Examples

ERP PB ring service is normally used to prevent loops in PB network access rings. The PB rings may be
configured either as standalone rings or connected in some way to an MPLS network. In a typical
configuration:
 The PB network links may be EoS or ETY, depending on the underlying equipment hardware.
 The PB ring may optionally be dual homed to an MPLS network.

The following figure illustrates a simple ERP configuration utilizing a single PE node in the MPLS network
side.
Figure 11-28: ERP PB ring example with one PE node
Three access rings are linked to an adjacent MPLS network, each configured with a separate ERP PB ring
service. Each ERP service includes its own RPL link with a corresponding RPL owner. The three ERP service
rings are completely independent of each other. A single PE in the adjacent MPLS network is used to close
all three services.
The following figure illustrates a slightly more complex configuration utilizing two PE nodes in the MPLS
network.
Figure 11-29: ERP PB ring example with two PE nodes

The three ERP rings resemble the configuration in the first figure, the difference being that the ERP rings
are closed in the MPLS network using two PEs, with a protected MPLS tunnel running between them.
Finally, the following figure illustrates 'mixed' network configurations that utilize a mixture of RSTP and ERP
access ring protection. These network configurations are very similar to those illustrated by the first two
figures in this section, the difference being that the third PB ring in each configuration is defined as an RSTP
ring rather than an ERP ring. All three rings are closed by the same MPLS PEs.
Figure 11-30: PB rings configured with mixture of RSTP and ERP PB ring services
Parent Topic
11.7.1 Creating ERP PB Ring Services
11.7.2 Creating ERP DH H-VPLS Services
NOTE: This topic focuses on the specific steps and parameters required to configure ERP DH
H-VPLS services. For general service creation and all available options, see Creating a Service.
To define an ERP DH H-VPLS service:

 In the Service Group dropdown list, select Infrastructure.
 In the Type dropdown list, select ERP DH H-VPLS.


 In the Tunnel Mode dropdown list, select the appropriate mode.
 In the VC Label Scheme dropdown list, select the appropriate label scheme.
NOTE: Protected tunnels are strongly recommended for ERP DH H-VPLS service.
4. In the Create Ethernet Service window map view, choose two MoE or MoT endpoints residing on the
same or different PEs. Endpoints on the same PE must be of the same type (both MoT or both MoE).
Only appropriate nodes are available for selection. LightSoft does not allow you to select the
following as ERP DH endpoints:
 PEs that do not support ERP DH H-VPLS service.
 PEs for which the maximum number of supported ERP services would be exceeded with this
selection.
5. (Optional) Assign an RPL or ring role to each endpoint. In an ERP configuration, one port must be an
RPL port and the other a ring port. The port designated as the RPL is listed in the PB pane.
By default, LightSoft assigns the first endpoint selected as the RPL port and the other as the ring port.
If you change the role of one endpoint, LightSoft automatically changes the others to the opposite
value.
To manually designate an RPL port:
a. Right-click the endpoint and open the Select Endpoint window.
b. Select the endpoint Role, either RPL port or Ring port.
6. (Optional) Tunnel selection may now be completed manually if appropriate. Follow these guidelines:
 When the selected endpoints reside on the same PE, tunnel selection is disabled.
 When the selected endpoints reside on different LEs, LightSoft automatically fills in the missing
tunnels on Complete.
 You can optionally choose to configure two direct tunnels (one in each direction) between
endpoints residing on different PEs.
a. Right-click one of the PEs and choose Select Tunnels. The Assign Tunnels dialog box opens. The
list of available tunnels includes all tunnels between the two PEs in both directions with all CoS
available.
b. Assign tunnels and CoS to both directions of the service; see Selecting Tunnels Manually for a
Service.
NOTE: ERP DH-VPLS service on MCS cards must be configured with CoS 7.


IMPORTANT: ERP DH H-VPLS service must be combined with CFM. CFM must be configured
between the two ERP DH nodes to monitor connectivity between them. Define CFM
capabilities at the same time as the ERP DH H-VPLS service. They can also be configured at a
later time.
To implement CFM on an ERP DH H-VPLS service, assign CFM on the P2P tunnel infrastructure
service running between the two ERP nodes. CFM service must be configured using the EMS.
For faster notification, the recommended CCM period is 100 msec (optional).
See Understanding CFM.
Parent Topic
11.7.2.1 ERP DH H-VPLS Service Examples

ERP dual homing service for H-VPLS networks is usually implemented in one of the following configurations:
 Single ERP DH node in the access or metro ring linked to two nodes in the core ring. Two ERP ports are
defined on the same node, with one active and the second kept as standby for protection. The
gateway links are arranged in a V-shape topology illustrated in the following figure.
Figure 11-31: ERP DH H VPLS with V shape topology

 Two ERP DH nodes in the access or metro ring, each linked to a node in the core ring. Two ERP ports
are defined, one on each gateway node, with one active and one as standby for protection. The
gateway links are arranged in a parallel-lines topology illustrated in the following figure.
Figure 11-32: ERP DH H VPLS with parallel lines topology
This configuration can be implemented on both MoE and MoT ports. Depending on the network
equipment and configuration, the protection bypass tunnel can be routed through the core network
or kept within the access/metro network.
Parent Topic
11.7.2.2 Migrating from Single Homing to Dual Homing Configuration
To migrate from single homing to dual homing configuration:

1. Add a new link between the two networks.
In the original single homing configuration, there is one link between the two networks. Begin by
adding a second link. This will become the second half of the DH service.
2. Create a new ERP DH H-VPLS service using the new link created in the preceding step. In this new
service:
 Administrative state should be enabled. (Default)
 Designate the new link as the RPL link.
3. Edit the underlying services using the original link to now go through the newly connected gateway
node.
NOTE: Migrating from single homing to dual homing may be traffic affecting for the
underlying services.
Parent Topic

11.7.3 Enabling ERP Service Editing

By default, when a new ERP service is defined, Administrative Status is enabled. This is usually convenient
for typical network operator tasks.
However, once ERP services have been defined and activated, they cannot be edited (for example, changing
links or ports within the service) as long as Administrative Status is enabled. To edit an existing ERP service
you must first disable Administrative status.
To disable Administrative status for an ERP service:

1. In the main window Services tab, in the General group, click Create ETH Service.
2. In the Services pane, right-click the required service, and select Service Operations and then Set
Administrative Service.
3. In the Set Administrative Service dialog box, choose Disable Administrative State.
The ERP service can now be edited.
Parent Topic
11.8 Creating CES Services

Prerequisites and Guidelines
 The initial steps when creating all types of CES services are similar. Slight differences between CES
MPLS and CES PB services are noted.
 All CES service endpoints must be either ports configured as CES ports at the EMS level, or E-NNI ports
leading to remote CES service endpoints at external or third party networks.
 For CES MPLS P2P service, choose two endpoints located on two different LEs.
 For CES PB services (P2P and MP2MP), choose two or more endpoints located on two or more
different LEs. The number of endpoints must be evenly distributed between LEs.
 CES service endpoints are usually configured in pairs except when configuring a CES service with E-NNI
ports:

 Pairs of CES endpoints are referred to as CES Mates. Multiple CES Mate pairs can be configured
for each CES PB (P2P or MP2MP) service. For CES MPLS P2P services, CES Mates are paired
automatically by the NMS when the endpoints are selected. For CES PB P2P/MP2MP services,
CES endpoints are paired manually as CES mates.
 When working with a combination of CES and E-NNI ports, the E-NNI ports are configured
individually. CES ports are either configured as pairs of CES Mate ports, or individually, if the CES
port serves as a partner to a remote CES Mate located beyond an E-NNI port. When a CES port is
configured individually, the CES attribute tabs display only one set of attribute fields rather than
a pair. Note that multiple CES ports can be configured as partners to multiple remote CES Mates
located beyond a single E-NNI port.
Defining CES Services
To define a CES service:

 In the Type dropdown list, select the appropriate service type:
 CES PB P2P
 CES PB MP2MP
 CES MPLS P2P
 For CES PB services only: Select or clear the H-VPLS Enabled checkbox.
 For the Tunnel Mode parameter, enter the appropriate mode when relevant.
 For CES PB services only:
 For the vFIB Quota parameter, enter the appropriate value.
 For the BSC Policer Profile parameter, set the appropriate value.
NOTE: For CES PB P2P services configured on qualifying equipment, LightSoft assigns a transit
PB P2P VSI for which user-configured RSTP, ERP, vFIB Quota, and BSC Policer values are not
relevant.
User-configured vFIB Quota and BSC Policer values are relevant for transit PEs in PB MP2MP
VSIs or for transit PEs which do not support this PB P2P functionality.
 Select or clear (default) the Administrative Service Enable checkbox. (CES service endpoint
parameters will only be editable in the future if this box is left unchecked.)
 Select or clear (default) the Dedicated Tunnels Only checkbox.
 Select (default) or clear the Protected Tunnels Only checkbox.

NOTE: Protected tunnels are strongly recommended for CES services.
4. Select endpoints for the service:

b. Right-click and choose Select Endpoint. A filtered version of the port tree opens. LightSoft
enables selection only of compatible ports with available timeslots, including CES ports that
were already configured at the EMS level for CES service, or appropriate E-NNI ports.
c. Expand the tree and select a port. The selection window format depends on the network
configuration:
 STM-1/VC-12 configuration:
Select an STM-1 port to open the corresponding VC-12 matrix, with the available CTPs
indicated.
 E1 configuration:
Select a slot to open a tree of E1 ports with VC-12 CTPs enabled and available.
Unavailable ports or times slots are blocked and cannot be selected. When working in CESoPSN
mode, a port is marked as available for selection as long as the matrix includes any available 64K
timeslots. When working in SAToP mode, a port is no longer available for selection once any of
the VC-12 CTPs have been assigned to a service endpoint.
d. Click an endpoint port or timeslot. Clicking Select toggles between selecting/deselecting the
endpoint. When configuring a CES PB MP2MP service, you may select several CES endpoints
from the same slot in the same PE.
e. Click Select to complete the selection. The port details are listed in the Endpoints tab Endpoint
List pane.


5. Configure service endpoints - CES ports only:
a. In the Create Ethernet Service window, open the Endpoints tab. The Endpoint List pane
displays the endpoints selected in the preceding step.
b. The endpoints must be configured as CES Mates, with certain parameter values corresponding
between the two endpoints.
c. For CES MPLS services: LightSoft configures endpoint pairs automatically.
d. For CES PB services: The user explicitly configures pairs of CES Mates:
 Select two endpoint rows in the Endpoints List table.
 Right-click and select Pair as CES Mates. Note that only ports with the same mapping type
can be paired as CES Mates.
Once two endpoints have been designated CES Mates, each one lists the other endpoint as its
CES Mate in the Endpoints List table.
e. Select one endpoint in the Endpoints List to highlight the rows of both mates in the Endpoints
List table. A CES Parameters pane just below the list displays the parameter values for both
endpoints. This pane includes three tabs: General, Timing, and L2.
f. In the General tab, complete the fields with the appropriate values for both endpoint ports.

 The Mapping Type field options are CESoPSN or SAToP, depending on endpoint type.
Note that this value cannot be edited at the NMS level once the service has been
activated.
 Select or clear the Enable RTP Header checkbox.
 Select the appropriate CoS values. Note that CoS values can be different at the two
endpoints.
 Select the appropriate Framing Mode. LightSoft limits the options to values appropriate
for the selected port and mapping type.
 For CESoPSN mapping type services: Select timeslots for each endpoint in the selection
matrix (the same number at both endpoints). If you try to complete the service with an
unbalanced number of timeslots selected, an error message appears.
LightSoft indicates the timeslots available for selection.

g. In the Timing tab, complete the fields with the appropriate values for both endpoint ports.
Note: Once you have selected the mapping type and channels in the General tab and entered
the TDM payload time in the Timing tab, the TDM payload size value updates automatically.

h. For CES PB services only: In the L2 tab complete the fields with the appropriate values for both
endpoint ports.
 ECID (In and Out): These values can be configured automatically or manually. If manually,
note:
-- The In ECID must be unique for each PE.
-- For both endpoints, the local In ECID value must match the remote peer Out ECID value,
and the local Out ECID value must match the remote peer In ECID value.
 DA MAC: When both endpoints are managed by LightSoft, LightSoft automatically
configures the local MAC address to match the remote peer MAC address.
If the remote service endpoint is located beyond an E-NNI port representing a third party UME,
or if the service is located in two PB networks separated by transit E-NNI ports, the destination
MAC address and Out ECID on the local endpoint must be configured manually to match the
MAC address and ECID on the UME.

6. Configure service endpoints with E-NNI ports as well as CES ports. E-NNI ports are used, for
example, to configure CES services linking to an external third-party network. When working with a
combination of CES and E-NNI ports, the E-NNI ports are configured individually, as follows:
a. Select the E-NNI port as part of the standard endpoint selection step. The port type in the
Endpoints List table is E-NNI.
b. Manually assign an S-VLAN registration for the E-NNI port.
c. While most CES endpoints are configured in pairs as CES Mates, a CES endpoint which works
with a remote mate located beyond an E-NNI endpoint is configured individually. Since LightSoft
doesn't manage the remote mate, LightSoft cannot automatically fill in the L2 fields. You must
do so for each endpoint. Verify that the Out ECID and MAC address values you enter for the CES
endpoint and the corresponding remote CES endpoint are valid.
d. Select the All Priorities checkbox in the Priority-CoS Mapping pane, and select a CoS that
matches the CES service CoS, as described in Configuring Priority-CoS Mapping.
e. Complete the other standard PB attribute setting as appropriate for the port. For example, if
you are configuring a CES PB MP2MP service, decide if you are handling RSTP configuration
manually or automatically through LightSoft. See Creating a Service.
TIP: Right-click an endpoint with comparable attribute settings, and choose Copy Details.
Then select a new endpoint and paste those attribute values into the endpoint fields. Change
the In ECID to be unique and adjust other values as needed.
OPTIONAL FEATURE: The Copy Details shortcut is a fully integrated add-on capability,
unavailable.
7. For CES MPLS services: (Optional) Manually select tunnels; see Selecting Tunnels Manually for a
Service.
a. Click Select Tunnels to populate the Tunnel Assignments table. LightSoft fills in tunnel
options appropriate for the domains that have been defined.
b. Manually assign the tunnels to each row, choosing the appropriate bandwidth and CoS values.
c. Repeat this step any number of times until the entire domain structure is defined.

LightSoft automatically fills in anything else required to complete the service, such as protection
tunnels. The new service configuration details are displayed for you to review. You can modify
parameters if needed. You can also choose to configure some aspects of the service manually, as with
any service creation.

Parent Topic
11.8.1 Editing CES Services

CES services can be edited and updated like any other by right-clicking the service and selecting Edit; see
Editing Services. Typical changes include adding or removing service endpoints and editing tunnels. CES
service attributes that can be edited include:
 Enable RTP Header
 CoS
 Clock Recovery Mode
 TDM Payload Time
 Delay Variation
 Time Slot selections
 In and Out ECID addresses
 Adding or removing service endpoints
Parent Topic
11.8 Creating CES Services
11.9 Creating Services for CESR 9600/9700 NEs

When creating services for CESR 9600/9700 NEs, create service definitions in STMS before creating the
service in the NMS (see STMS User Manual).
Start by performing the following actions in STMS:
 Create a service in the NMS with service definitions
 Modify default QoS values for services
Parent Topic

11.9.1 Creating a Service in NMS with Service Definitions
NOTE: Editing of UNI mapping in NMS services that use service definitions overwrites the
existing STMS service definitions.
To define service definitions:

1. In the STMS main window, click Edit and then Server Preferences.
2. Select the LightSoft TcProfiles tab.
3. To add a new TcProfile, click Add. The Edit TmTable window opens.
4. Select the CoS mapping and relevant policer profiles to match the exact CoS mapping and policer
profiles you want to create in the NMS.
5. In the Service Definition field, select the options you want to use. If the CoS mapping and policer
profile match that of the NMS, the service is created with the definition defined in this field.
6. Click Finish, and then click Apply.
NOTE: If one or more services do not match those defined in the LightSoft TcProfiles tab, the
service is created without service definitions. To prevent this, select the Reject service
creation unless mapping exists checkbox.
Parent Topic

11.9.2 Modifying Default QoS Values for Services

Table 11-1: Default QoS values
Profile/Block Parameter Default value Applies to

Drop Profile Green Min Threshold (%) 40 All CoS
Drop Profile Yellow Min Threshold (%) 10 All CoS
Queue Blocks Scheduling Class ef+ CoS 7
Scheduling Class ef CoS 6
Scheduling Class af CoS 0-5
PIR Maximum port rate CoS 0-5
CIR 10Mb/s All CoS
To modify the default QoS value:

1. In the QoS Explorer tab, right-click Templates and select Create LightSoft Default Templates. Drop
and Queue profiles are created under the relevant folders in the STMS Network Explorer tree.
2. Select the relevant Drop profile or Queue block, and in the Properties tab, change the field values as
required.

NOTE: The LightSoftDfaultNniQueueBlock and LightSoftDfault10GQueueBlock templates are

relevant for topology links only.
Parent Topic
11.10 Creating and Working with Global Service

Templates
Global service templates can be used to streamline the service creation process. New services with similar
parameters and path details can be set up using a template stored in the database. Once created, the
template details can be applied to the Create Service window and only specific parameters changed as
needed for a new service.
This supplements the local service templates functionality, which saves service information in flash memory
to use for creating services based on a new service defined in the current session only.
Local service templates contain all service information, while global templates omit service structure
information (for example, domain structure or peer requirements and tunnel selections).
To create a global service template:

1. Perform the new service creation procedure (see Creating a Service) up to the point of Completing
the service.
2. Click Save Global Template . The Store Global Template dialog box opens.
3. Enter a name for the template.

4. Click OK. The template is saved.

To create a new service based on a global template:

1. Open the Create Ethernet Service window (see Creating a Service).
2. Click Load Global Template . The Load Global Template dialog box opens.
3. Select an existing global template in the list, and click OK. The parameters and path details from the
template are applied to the current service.
4. Change details as needed and Complete and Activate the service as described in the generic service
creation procedure (see Creating a Service).
Parent Topic
11.11 Working with Advanced EMS-based Endpoint

Configurations
Certain advanced features such as multiple CoS ingress policers can only be configured and modified at the
EMS level. These endpoint settings are then uploaded to LightSoft. The service is flagged in LightSoft as
inconsistent, with the reason Different EMS Specific Configuration. Actions on the service are limited until
the service state is changed back to OK by:
 Admitting to LightSoft; see Admitting Services to DB.
OR
 Canceling the EMS configuration by imposing the known LightSoft-specific expected structure back to
the EMS; see Imposing Services on the Network.

If the advanced EMS configuration is admitted to LightSoft, the Endpoints List pane displays a message
indicating that the selected endpoint has advanced configurations in the EMS and whether or not the
endpoint can be modified in LightSoft. Only endpoint settings that can be configured within LightSoft can
later be modified within LightSoft. EMS-based configuration settings are displayed as read only. The
endpoint can be removed, but not modified in LightSoft.
NOTE: A service with advanced configuration endpoints that was admitted and subsequently
becomes inconsistent, must be re-admitted to LightSoft. At this stage the endpoint
configuration cannot be imposed back on to the EMS.
For certain equipment, click Open to directly access (via GCT) the relevant EMS window where the
non-LightSoft-supported configuration can be changed as needed. For example, when the context is:
 Ingress policers: The Ingress Policers tab opens in the EMS.
 C-VLAN translation: The C-VLAN Translation tab opens in the EMS.
NOTE: The following Export to XML limitations apply for advanced endpoint configurations:
 Export to XML from LightSoft: A warning about loss of configuration is displayed, but the
export continues.
 Edit via XML: The action is rejected and an error message is displayed/log file.
For information about exporting to XML, see Batch Service Operations.
Parent Topic

11.12 C-VLAN Port Settings

An Ethernet port on which a service is defined can be partitioned to define which packets going through the
port belong to that service. Packets can be categorized based on:
 Specific C-VLAN values and/or Priority status (untagged or priority tagged)
 Any C-VLAN values not assigned to other services at that port (All/Other)
A line in the VLANs pane C-VLANs selection area represents a group of one or more C-VLAN IDs and/or
other tag settings which packets must satisfy in order to be included in the service at the current port.
Figure 11-33: C-VLANs selection area in VLANs pane
Certain equipment support up to eight C-VLAN IDs groups, with different tag settings applying to C-VLANs
specified in each group. This is useful if distinct policing is required per VLAN IDs. For more information
about the VLAN Group policer, see Policers Pane in the Supporting Information Supplement.
Rules govern how the C-VLAN values and tag settings may be combined within a group and across separate
groups. Settings cannot be selected for endpoints with PVID assigned; see Endpoints with PVID in the
Supporting Information Supplement.
Parent Topic
11.12.1 Configuring C-VLAN Values for a Port
NOTE: If you have reached this topic while in the middle of creating a new service, return to
Creating a Service once the C-VLAN configuration is completed to finish creating the new
service.
To implement C-VLAN values for a port:

Specify the first (or only) line in the table as follows:
 If no C-VLAN ID entry or other checkbox is selected, select the All/Other checkbox. Packets associated
with C-VLAN IDs not used by other services at this port will be allowed to the service. For example, if
the C-VLAN IDs 1 and 2 are used by other services at this port, packets with C-VLAN IDs 3 through 4095
will be allowed to the current service.

NOTE: Selecting All/Other for the C-VLAN ID disables the DSCP option.
OR
 Enter C-VLAN IDs entries and/or select checkboxes as follows:
 Specific VLAN IDs, entered as comma separated individual C-VLANs and/or ranges of C-VLAN.
For example, the string '1,2,3,5-10' indicates the nine C-VLAN IDs 1 to 3 and 5 to 10. Packets
associated with these C-VLAN IDs will be allowed to the service.
NOTE: The entered C-VLAN ID values must be non-overlapping and not used by any other
group (see below) or service at the current port.
 If entries overlap (duplicated in the same or different lines) or are out or range (beyond
4095), the illegal entries appear in red. They must be corrected before the service is
allowed to complete.
 If entries are used by other services at the current endpoint, the service fails activation.
The C-VLAN IDs that are available for use at this port for this and other services are listed in
the VLAN List window. Open this window by clicking Show Free VLANs List .
And/Or
 Untagged and/or Priority Tagged checkbox selections. These are additional values associated
with packets, unrelated to C-VLAN ID designations, if any. Untagged and/or priority tagged
packets will be allowed to the service (as well as packets with specific indicated C-VLAN IDs).
NOTE: The Untagged and Priority Tagged checkboxes may be individually selectable or bound
to each other (both On when one is selected, both Off when one is cleared), according to
specific equipment capabilities.
To implement multiple C-VLAN groups for a port:
1. Click Add New VLAN Group (enabled for certain equipment). An additional line appears in the
C-VLANs selection area.
2. Specify the C-VLAN IDs and checkbox selections applicable to the packets that should be policed
based on the additional C-VLAN group. The same rules apply as for the first C-VLAN group line
definition, plus the following:
 All/Other checkbox can be selected only once in the table, in only one line and no other
values/checkboxes can be set on that line (other lines are not restricted). Note that selecting
All/Other for the C-VLAN ID disables the DSCP option.
 Untagged and/or Priority Tagged checkboxes can be selected only once in the table, in only one
line.

 Any specific C-VLAN value can appear only once for a service at a port, in the same way as in the
single group procedure. Thus any specific C-VLAN value can appear only once across all groups
in the table.
NOTE: The multiple C-VLAN group capability is provided as a convenience for certain
equipment. The same purpose can also be achieved by defining a separate service for each
required policing regime.
Parent Topic
11.12.2 Applying C-VLAN Translation to a Selected Endpoint

Egress C-VLAN translation, supported by certain equipment, enables translating the C-VLAN at the Egress
direction. For example, two customer sites may historically have different VLAN designations for the same
departments. The marketing department may use the C-VLAN 10 in one site and 5 in the other. VLAN
translation enables the packets to be correctly translated in the Egress direction to be C-VLAN 5 in order to
be correctly received by its destination.
VLAN translation is implemented in the Egress C-VLAN Translation area of the VLANs pane.
The translation parameters are available when only one C-VLAN group is defined and only one C-VLAN
value is indicated (with or without checkbox selections).
You can choose translate frames received from the network, as follows:
 Tagged frames to be untagged, priority tagged, or the indicated C-VLAN value.
 Priority tagged frames to be untagged, or the indicated C-VLAN value.
NOTE: Certain equipment where LightSoft Egress C-VLAN ID translation is not supported may
support some other Egress translation mechanism. If a non-LightSoft capability is used for this
purpose, the endpoint configuration is regarded as Advanced and all Endpoints tab aspects for
this port are disabled for editing - the endpoint configuration must be edited only via the EMS;
see Working with Advanced EMS-based Endpoint Configurations.
To apply VLAN translation to the current endpoint:

1. In the From Tagged to dropdown list, select the translation mode for tagged frames received from
the network:
 No Change (default), meaning no translation is performed.
 Untagged (enabled if Untagged checkbox is selected).
 Priority Tagged (enabled if the Priority Tagged checkbox is selected).

 The currently assigned single C-VLAN ID in the table.
AND/OR
2. In the From Priority Tagged to dropdown list, select the translation mode for priority tagged frames
received from the network:
 No Change (default), meaning no translation is performed.
 Untagged (enabled if Untagged checkbox is selected).
 The currently assigned single C-VLAN ID in the table.
Table 11-2: C-VLAN ID translation options
Column/Field Description
From Tagged to When no checkboxes are selected, choices are:
 No Change
 The C-VLAN ID defined on this port
When Untagged/Priority Tagged is selected, choices are:
 No Change
 Untagged
 Priority Tagged
 The C-VLAN ID defined on this port
From Priority Tagged to When no checkboxes are selected, choices are:
 No Change
 The VLAN ID defined on this port
When Untagged/Priority Tagged is selected, choices are:
 No Change
 Untagged
 The VLAN ID defined on this port.
Parent Topic
11.13 S-VLAN Registration

S-VLAN registration is required for MP2MP PB services. By default, S-VLAN registration is completed
automatically by LightSoft. It can also be done manually, if preferred.
Parent Topic

11.13.1 Automatic S-VLAN Registration

Services on a PB network must be S-VLAN registered on some or all of the EoS and ETY links. LightSoft
typically registers the S-VLAN on all network links when an individual service is created (see Automatic
S-VLAN Registration checkbox in Provider Bridge Networks pane in the Supporting Information
Supplement) or edited (see Editing Services). When an individual service is registered in this way, the PB
network ports are configured with registration information, enabling all the virtual links for the service.
S-VLAN registration is performed on NNI ports. Port configuration is completed in the EMS.
Links and connected nodes are normally color coded according to the most severe alarm affecting any of
their associated components, both link and node indicating the same color; see the Performance
Management Guide. A service not S-VLAN registered is shown in the map view in gray. (Only S-VLAN
registered services have the same color as their associated nodes; see Create Ethernet Service Window
Map View in the Supporting Information Supplement.
You can view the S-VLAN registered links in the system using the Show S-VLAN Registered Links option; see
Create Service Menu and Toolbar in the Supporting Information Supplement.
NOTE: S-VLAN registration can be performed at the trail or link level when an EoS trail or ETY
link is created or edited. This avoids having to register the S-VLAN manually at each of many
services individually so that they will be accommodated by the trail's ports. This adds the
S-VLAN registration to the virtual link, downloading it automatically to each existing service in
the network; see S-VLAN Registration from a Link or Trail.
Parent Topic
11.13.2 Manual S-VLAN Registration for a PB MP2MP

Service
Most customer PB networks involve loop or mesh topologies with RSTP Enabled. In this case, only
automatic S-VLAN registration should be performed.
P2P or loopless (tree) topologies are also sometimes used, since by nature they do not require RSTP. (EoS
trail protection may be used on the upper layer.) In this case, manual S-VLAN registration can be
performed. By default, manual S-VLAN registration is enabled only for links where RSTP is Disabled.
In one exceptional use case, manual S-VLAN registration is performed for selected links where RSTP is
Enabled. This applies very rarely. Consult with your local Customer Support representative before
undertaking this course.
For manual S-VLAN registration, the selected links are S-VLAN-registered to the two ports on which each
link terminates.
If you are in the middle of creating a new service, return to Creating a Service once the S-VLAN registration
is completed.

To manually S-VLAN register a multipoint service only on selected links:

1. Clear the Automatic S-VLAN Registration Enabled checkbox in the Networks tab Provider Bridge
Network pane.
2. Ensure that the Selectable I-NNI Links for Manual S-VLAN Registration user preference parameter is
set to RSTP Disabled Only (default); see Service Management Preferences in the Getting Started &
3. Select the EoS/ETY links in the Map view which provide connectivity between the selected service
endpoints. If it is part of a multilink, a selection window opens from which you can select the required
link. The selected link is highlighted in the map.
After the service is activated, it will be S-VLAN registered only on the selected links.
Parent Topic
11.14 CoS Mapping for Ethernet Services

The frames of a service are assigned a CoS and the service provider commits to provide a certain level of
performance for each CoS. It has two aspects:
 Priority for forwarding frames that exist at the switch, with some frames having priority over other
frames.
 Priority for dropping frames when non-dedicated bandwidth is overbooked; see Configuring Service
Overbooking.
Higher CoS values afford dependable bandwidth to more sensitive services, such as VoIP or IPTV. (High
priority is less essential for HSI service support.)
An Ethernet service classifies ingress frames to CoS categories of the network carrying the traffic. The CoS
categories may be from CoS0 (lowest) to CoS7 (highest) or represented by free-text display names
configured for the network, such as Gold or Platinum in place of CoS7. Ingress policing is performed
separately for each CoS. The C-VLAN Priority attribute is used to classify incoming frames by CoS; see
Priority - CoS Mapping Pane in the Supporting Information Supplement. The classification is per service and
may take into account the Ethernet (C-VLAN) priority of the frames.
Many services assign all traffic to a single CoS; other services assign traffic to multiple CoS values:
 Most prevalently, a port belongs to a single customer with the same CoS (e.g., Silver) applying to all
the frames (priorities are irrelevant).
 Alternatively, customer frames may be assigned to different CoS values (for example, HSI and VoIP)
according to the required priority.
Frames carried over an MPLS network use a tunnel having the required CoS. CoS instances for services on
this network are supported via the tunnel CoS.
Frames carried over a PB network implement CoS by assignment of S-VLAN Priority (Priority0 to Priority7).
Parent Topic

11.14.1 Configuring Priority-CoS Mapping

Priority-CoS mapping can be configured on an endpoint concurrently with configuring DSCP-CoS mapping ,
except for CESR products.
To configure Priority-CoS mapping:

1. Select an endpoint in the Endpoints pane. Its CoS mappings are shown in the Priority-CoS Mapping
pane.
2. In the Priority-CoS Mapping pane, assign a CoS value to each relevant S-VLAN priority of the
endpoint. (For an E-NNI endpoint, do this in the Ingress left side of the pane). All priorities are initially
mapped to CoS 0. (This step applies to both UNI and E-NNI endpoints.)
Select the All Priorities checkbox to apply the same CoS value to all priorities at once
.
3. Click Restore Default Mappings to reinstate the default mappings, if necessary.
NOTE: The selected CoS must be compatible with the assigned tunnel CoS. Otherwise the
service completion fails. See Create Tunnel Window Basic Parameters Pane in the Supporting
4. For an E-NNI endpoint (on an MPLS-PE or PB switch) in the Egress, specify an S-VLAN priority for each
CoS.
5. Repeat the previous steps for every endpoint of the service.
Parent Topic
11.14.2 Configuring DSCP-CoS Mapping

The DSCP-CoS Mapping pane is enabled by selecting Enable DSCP-CoS Mapping - Enable.
DSCP-CoS mapping can be configured on an endpoint concurrently with configuring Priority-CoS mapping ,
except for CESR products.
From V7.1 and up, you can configure up to 64 DSCP values (21 standard and 43 non-standard).
Limitations:
 For CESR products, DSCP-CoS mapping cannot be configured on an endpoint concurrently with
Priority-CoS mapping.
 For MCS cards, only standard DSCP values are supported.
 DSCP mapping is not supported on some equipment types, including EIS and ESW cards.

To configure DSCP-CoS mapping:

1. Select an endpoint in the Endpoints pane. Its CoS mappings are shown in the Priority-CoS Mapping
pane. Ensure that Enable DSCP-CoS Mapping - Enable is selected.
2. In the Enable DSCP to CoS Mapping field, click Enable.
3. To assign standard DSCP values only:
a. In the Mapping Option field, click By value. A list of mapping options for each standard DSCP is
displayed.
b. In the dropdown lists, assign a CoS value to each relevant DSCP of the endpoint. All priorities are
initially mapped to CoS0.
OR
To apply the same CoS value to all priorities at once, select the Map All DSCP As checkbox, and select
the relevant CoS from the dropdown list .
4. To assign standard and non-standard DSCP values:
a. In the Mapping Option field, click By name.
b. For each CoS, enter the DSCP value(s) or range of values you want to include. If invalid or entered
twice, the value is highlighted in red.
c. In the Discard field, enter a DSCP you want to map to discard (not applicable for CESR).
d. To map all DSCP values that have not been specified in any other CoS, in the All Others field,
select a CoS in the dropdown list. All values that have not been mapped to another CoS are added
to the specified CoS.
5. Click Restore DSCP-CoS Default Mappings to reinstate the default mappings.
NOTE: The selected CoS must be compatible with the assigned tunnel CoS. If not, service
completion fails; see Create Tunnel Window Basic Parameters Pane in the Supporting
6. Repeat the previous steps for every endpoint of the service.
Parent Topic

11.15 Selecting Tunnels Manually for a Service

The MPLS Network pane can be used to manually select tunnels for some or all tunnel requirements of a
service. Tunnels are automatically selected for tunnel requirements for which no manual selections are
made.
This procedure is performed during service creation, before it is completed; see Creating a Service.
To select tunnels for the service:
1. In the MPLS Network pane, click Select Tunnels (or double-click within the Tunnel Assignments
area). The Assign Tunnels window opens. The Tunnel Assignment List pane shows the tunnel
requirement lines from the MPLS Network pane.
2. In the Tunnel Assignment List pane, select a tunnel requirement line. All the possible available
tunnels are shown in the Available Tunnels pane.
3. In the Available Tunnels pane, select the tunnel you want associated with the tunnel requirement
line.
4. Click Assign ^. In the Tunnel Assignment List pane, the tunnel requirement line is bolded, signifying
that a manual selection was implemented. Details of the tunnel you selected are shown in its tunnel
columns.

You can select a different tunnel for the endpoint pair by clicking Unassign (to clear the first
selection), selecting another tunnel, and clicking Assign.
The fields in this window are described in MPLS Network Pane in the Supporting Information
Supplement.
5. Repeat from Step 2 for each tunnel you want to assign manually to another endpoint pair.
Parent Topic
11.16 Managing Policer Profiles

Each CoS of a service endpoint can be associated with a rate-enforcing policer, which determines which
frames of an incoming frames sequence should be transmitted and which dropped (or possibly marked).
For certain equipment, policers may also control outgoing traffic.
Policer profiles encapsulate all relevant bandwidth parameters at an Ethernet service endpoint. For
information about parameters that can be configured when assigning policer profiles to CoS instances, see
Policers Pane in the Supporting Information Supplement.
Policers are defined as single rate or two rate, according to specific equipment requirements:
 Single rate (characterized by two traffic parameters):
 CIR (Committed Information Rate); see also Configuring Service Overbooking.
 CBS (Committed Burst Size)
 Two rate (characterized by four traffic parameters):
 CIR
 CBS
 EIR (Excess Information Rate)
 EBS (Excess Burst Size)
The policer profile also includes the standard MEF policer Color Mode and Coupling Flag parameters, as
supported by specific equipment. Policer granularity values may be continuous or discrete according to
specific equipment.
Individual profiles must include a unique combination of the parameter values. For details of the Policer
Profiles window parameter options, see Policers Pane in the Supporting Information Supplement.
Policer profile management includes the following tasks:
 Viewing the Policer Profiles List.
 Creating a Policer Profile ; including parameter options.
 Editing a Policer Profile.
 Deleting a Policer Profile.
 Acquisition of Policer Profiles.
 Assigning Policer Profiles to CoS Values of an Endpoint.

MP2MP and Rooted MP services can be configured with a rate-enforcing policer profile for BSC purposes;
see Understanding BSC Policer Profiles. VLAN Tree services offer the option of defining a different policer
profile for each C-VLAN ID.
Parent Topic
11.16.1 Viewing the Policer Profiles List

The Policer Profiles List window is used to create, edit, or delete policer profiles. Up to 1000 profiles can be
defined. LightSoft supports a default set of entries which includes the grid of BW parameters defining the
MCS policer profiles.
To open the Policer Profiles List window:

 In the main window Services tab, in the Utilities group, click Policer Profiles List. The Policer Profiles
List window opens.
Parent Topic

11.16.2 Creating a Policer Profile

A new policer profile is created in the Create Policer Profile dialog box.
NOTE: Each policer profile name must be unique. No two profiles can have precisely the same
values for all attributes.
To create a policer profile:
1. Click Create Policer Profile . The Create Policer Profile window opens.
2. Enter values in the fields.

3. Click Save (enabled when all required fields contain values). The new profile is reflected in the Policer
Profiles List window.
Table 11-3: Policer Profiles List window columns
Field Description
Profile Name Name of policer profile (unique in the list).
Rate Type Single rate (EIR and EBS are zero) or two rate if EIR and EBS have positive
values.
CIR (kb/s) Overall Ingress BW for this service over all destinations which the provider
has guaranteed to carry without dropping or marking as low priority. Values
may be 0, or 66 to 10G bits/sec.
The Broadcast Storm Control (BSC) policer must be configured with CIR > 0
for MP2MP services. CIR = 66k may be sufficient. In many cases, MP2MP
Ethernet services include Broadcast packets (in particular ARP). If CIR is set
to 0, this broadcast traffic may be blocked and result in the service not
working.
CBS (KB) Max. bursts of data that the provider agrees to transfer without dropping or
marking (associated with the CIR value). Values from 0 to 524 bits/sec. (For
technical reasons, the value should not be set to 0 or 1.)

Field Description
EIR (Kb/s) Additional Ingress bandwidth which the provider agrees to carry after
marking the frames as lower priority. Such frames are carried end-to-end
when congestion conditions in the network permit. Values may be 0, or 66
to 10G bits/sec. Not applicable for EIS cards. Displayed as N/A for Single
Rate.
EBS (KB) Max. burst size associated with EIR. Values from 0 to 524 bits/sec. Not
applicable for EIS cards. Displayed as N/A for Single Rate.
Color Mode Whether mode at the UNI or E-NNI port is color aware or color blind:
 Color Blind (default): The service frame color (if any) is ignored when
determining whether a frame is conformant or non-conformant to a
bandwidth profile.
 Color Aware: The service frame color is considered when determining
whether a frame is conformant or non-conformant to a bandwidth
profile.
Two colors are recognized - green for conformant (committed rate), and
yellow for non-conformant (excess rate).
Enabled only when two rate policer applies and if supported by equipment.
Coupling Flag Indicates mode of operation of the rate enforcement algorithm:
 Uncoupled (default)
 Coupled
When Color Mode is Color Blind, Coupling Flag is disabled and Uncoupled.
Enabled only when two rate policer applies and if supported by equipment.
NOTE: Minimums, maximums, and applicability limitations apply for specific hardware which
is not validated by LightSoft. See the relevant hardware User Guide for more information.
Parent Topic

11.16.3 Editing a Policer Profile

Only the name of an existing policer profile can be edited in LightSoft. This does not update the endpoint.
The bandwidth associated with an endpoint is edited by selecting another profile. This results in
transmission of the appropriate data to the EMS.
To edit a policer profile name:
1. Select a policer profile in the Policer Profiles List window and click Edit Selected Profile . The Edit
Profile window opens.
2. Change the profile name as needed.

3. Click Save. The new name is reflected in the Policer Profiles List window.
Parent Topic
11.16.4 Deleting a Policer Profile

LightSoft can delete a policer profile only if it is not used by any endpoint.
To delete a policer profile:

1. Select one or more policer profiles in the Policer Profiles List window (hold the CTRL key for multiple
selections).
2. Click Delete Selected Profile . A confirmation window opens.

3. Click Yes to confirm. The profile(s) are removed in the Policer Profiles List window.

NOTE: Different bridges (MCS, EIS, ESW) handle profiles differently. LightSoft does not control
these differences. If an invalid profile is configured, the EMS rejects the endpoint. Some
reasons may be:
 Bridge or PE does not support two rate profile.
 Profile attributes out of range for the bridge or PE.
 Maximum number of profiles already configured at the bridge or PE.
Parent Topic
11.16.5 Acquisition of Policer Profiles

The EMS maintains a name for each policer profile. On configuration of an endpoint from the EMS, the
LightSoft policer profile name is used.
When an endpoint is acquired from the EMS, the EMS includes the Policer Profile Name in its upload (as
well as other parameters):
 If the uploaded attribute set appears in the Policer Profile list, the profile is not added. Reference is
made to the existing LightSoft name.
 If the uploaded attribute set does not appear in the Policer Profile list:
 If the name exists, the profile is added with a new name (EMS name and suffix).
 If the name does not exist, the profile is added with the EMS name.
In this way, profiles generally have a single name throughout the system. However, different EMSs may
have their own local names for some profiles different from the LightSoft names.
Parent Topic
11.16.6 Assigning Policer Profiles to CoS Values of an

Endpoint
Each CoS of a service endpoint (and C-VLAN group, if applicable) can be associated with a rate-enforcing
Ingress policer that determines which frames of an incoming frames sequence should be transmitted and
which dropped (or marked in the case of a two-rate policer).
To assign policer profiles to CoS values of an endpoint:

1. Select a service endpoint in the Endpoints pane and C-VLAN group line (if applicable) for which CoS
assignments by Priority or DSCP were already made. The Policers pane shows the CoS values that are
enabled for policer profile assignment. The policing status at each CoS instance is initially Blocked.

If a C-VLAN group is also selected, the tab header includes "for Group" details. The policer settings
per CoS are specific to the C-VLAN group.
2. In the Policers pane, click Select Policer Profile . The Select Policers window opens. The upper
part of the pane lists the mapped CoS instances available for policer profile assignments. (Create
Policer Profile is used to create a new policer; see Creating a Policer Profile.)
3. Assign a policer profile to each CoS of the current endpoint:

a. Select a CoS in the upper pane.
b. Select a profile in the lower pane.
c. Click Apply. In the upper pane, the policer is reflected in the Policer column for that CoS.

d. Repeat the previous steps for each CoS requiring a policer assignment.
OR
If you selected All Priorities in the Priority - CoS Mapping pane, only CoS7 appears in the upper pane.
Assigning a policer profile to that line applies the policer to all CoS instances.
4. Click OK to save the assignments and close the window. The assignments are reflected in the Policers
pane.
The default value for a Policer Profile is the last configured profile for this CoS.
5. Set the profile status as needed, for example, to Policing.
The status of the BW profile selection on an existing endpoint can be edited.
Parent Topic
11.17 Configuring Service Overbooking

To configure overbooking for a service:
1. Define policer profiles with parameters that would achieve transmission performance in accordance
with applicable customer SLAs; see Managing Policer Profiles.
2. Define services with the required CoS values in accordance with SLAs; see Configuring Priority-CoS
Mapping.
3. Assign the policer profile that would achieve the contemplated level of service to CoS values
applicable to that service; see Assigning Policer Profiles to CoS Values of an Endpoint.
NOTE: In MPLS networks, a booking factor assignable to each CoS sets a ceiling on the CIR
that can be defined for a policer profile; see Overbooking and CIR.
Note that effective overbooking configuration can be a skillful art. The recommendation in
most cases is to remain with the default configuration settings.
Parent Topic

11.17.1 Understanding MPLS CAC and Service Overbooking

CAC for Ethernet services ensures that a tunnel has sufficient bandwidth to add more services while still
providing the expected QoS. Service CAC supplements MoT trail or MoE link CAC mechanisms to facilitate
effective QoS delivery by MPLS networks.
Services are configured at each UNI with a policer profile. The policer CIR specifies the overall ingress
bandwidth per CoS over all destinations. The bandwidth between endpoint pairs is not configured.
Service CAC is supported by LightSoft for P2P services configured over dedicated tunnels (P2P Service Only
checkbox selected), based on the service policer's CIR. The CIR specifies the bandwidth required by a P2P
service to the other service endpoint. LightSoft checks that the sum of service CIRs assigned to a P2P
Service Only tunnel does not exceed the tunnel bandwidth before authorizing the following actions:
 Adding a service to an existing tunnel.
 Increasing the CIR for an existing Ethernet service.
 Reducing the bandwidth of an existing tunnel.
Overbooking (also known as oversubscription) takes advantage of statistical multiplexing whereby the sum
of defined service bandwidth can exceed a link's bandwidth capacity. For example, a 10 Mbps link can be
allocated to 20 customers, each with a CIR of 1 Mbps. This is accomplished by assigning less-than-maximal
CoS values to services, in accordance with applicable SLAs. This is useful, for example, for internet traffic
where customers do not all demand their bandwidth simultaneously. See Overbooking and CIR.
Parent Topic
11.17 Configuring Service Overbooking
11.18 Configuring PB P2P Services between MCS

Cards
Services between MCS cards in PB networks should normally be configured as MP2MP (rather than P2P,
even if only two endpoints are involved), and with RSTP protection enabled. However, P2P services can be
created top down between MCS cards in a PB network to accommodate two use cases:
 Direct P2P service between pairs of MCS cards with RSTP disabled; see Use Case 1: Direct P2P Service
between MCS Cards.
 P2P service with RSTP enabled; see Use Case 2: PB P2P Service with RSTP Enabled.
P2P services implemented by P2P VSIs on PB networks are advantageous since they avoid the need for
MAC learning and for performing S-VLAN registration throughout the network. They cannot be protected in
the Ethernet layer using RSTP. If there is an alternative path between the endpoints, RSTP may disable the
selected path thus disabling service connectivity.
An operator may choose to configure such a service on links with RSTP disabled. This does have
disadvantages. Some clients may have the service endpoints connected through the operator network and
through some other mechanism (the so-called “backdoor”). If RSTP is not enabled on the operator network,
a loop may be formed which impacts not only the client services but also the services of other clients.

In most cases, the operator must choose either implementing P2P service on a PB network or protecting
against the backdoor loop phenomenon. In some cases (for example, star networks or areas of a network
with a star topology), it is possible to implement P2P services with RSTP enabled on the link and to retain
assurance that backdoor loops cannot form.
NOTES:
 These procedures are designed only for the indicated use cases and should be
implemented by experienced users.
 These procedures primarily concern services between MCS cards, and also apply to
services between BG cards.
The following restrictions apply to P2P top-down service creation in PB networks:

 Service created between MCS cards only. (EIS card cannot be used for P2P services as it does not
support P2P VSIs.)
 The two service endpoints must be:
 Within the same PB network. Endpoint selection from two PB networks or MPLS and PB
networks is disallowed.
 Directly connected by a single EoS trail or ETY link (no PBs in between). Remote endpoints
(UMEs) can be connected if the other conditions are satisfied.
 In addition to the mandatory endpoint selections, a direct EoS trail or ETY link between the endpoints
(no other PB in between) can optionally be selected.
 The RSTP Enabled/Disabled state configured in the Create Trail window EoS/MoT Configuration pane
for the trail selected for the service (see EoS/MoT Configuration Pane) must match the User
Preferences – Services window Selectable I-NNI Links for Manual S-VLAN Registration option (see
Service Management Preferences in the Getting Started & Administration Guide). These selections
must both be either RSTP enabled or RSTP disabled, as follows:
 Use case 1: RSTP Disabled; see Use Case 1: Direct P2P Service Between MCS Cards. (A non-RSTP
protection mechanism may apply instead.)
 Use case 2: RSTP Enabled; see Use Case 2: PB P2P service with RSTP Enabled.
Parent Topic

11.18.1 Use Case 1: Direct P2P Service between MCS Cards

EMS-configured legacy PB networks sometimes use P2P services between pairs of EIS cards without RSTP
protection. If needed, MCS cards may be configured in the same way as EIS cards. (EIS cards and their
associated P2P-type VSIs do not perform MAC learning.)
To configure a direct P2P service between MCS cards:

1. Ensure that RSTP is disabled in both these cases:
 User Preferences – Services window Selectable I-NNI Links for Manual S-VLAN Registration
value is set to RSTP Disabled; see Service Management Preferences in the Getting Started &
 EoS trail that the service will traverse has its Create Trail window EoS/MoT Configuration pane
RSTP Enabled checkbox unselected; see EoS/MoT Configuration Pane.
2. In the Service Creation process, select the P2P service type and select PB endpoints. The Provider
Bridge Network tab shows the PB network.
3. Optionally select a direct EoS trail or ETY link between the PBs which the P2P service should traverse.
The selected link appears in the S-VLAN Registered I-NNI Links pane and is colored white in the Map
view. If no link is selected, LightSoft determines an appropriate direct link and displays it in the
S-VLAN Registered I-NNI Links pane after completion.
Parent Topic
11.18 Configuring PB P2P Services between MCS Cards
11.18.2 Use Case 2: PB P2P Service with RSTP Enabled

P2P services are generally not supported with RSTP On. Since RSTP may cut any link at any time to prevent
a loop, the service may subsequently run on a broken path. MP2MP services should be used in general for
any service on a PB network (even one with only two endpoints).
However, certain applications may potentially cause a loop if RSTP is not running. In that case RSTP can be
enabled for a P2P service. Even if RSTP cuts the direct link between the PBs, traffic will continue over the
switches.
NOTE: The following configuration applies from EMS V8.1, where RSTP will be supported on
ETY ports on P2P VSIs. It is meant only for the described use case and must be used with
caution.

To enable RSTP for a P2P service:

 Ensure that RSTP is Enabled in both these cases:
 User Preferences – Services window Selectable I-NNI Links for Manual S-VLAN Registration
value is set to RSTP Enabled Only; see Service Management Preferences in the Getting Started
 EoS trail that the service will traverse has its Create Trail window EoS/MoT Configuration pane
RSTP Enabled checkbox selected; see EoS/MoT Configuration Pane.
Parent Topic
11.18 Configuring PB P2P Services between MCS Cards
11.19 Managing CFM MAs

MAs can be configured as part of creating a new service or edited at any point as part of service
management.
When configuring MEs for a new service

 You can add only one LightSoft-created MA to the new service being created. After the MA is added,
you can edit its attributes or you can remove it and add another MA, as needed, using the CFM tab
MA pane options.
 When the service is activated, LightSoft automatically creates the necessary MEPs and MIPs within the
MA that you added. LightSoft updates the MEP and MIP pane lists and downloads the updated FDFr
MAs to the relevant FDFrs in the EMS; see Implementing CFM via LightSoft or EMS.
 Once the service has been activated, you can edit and reconfigure service MAs via the Service List
window.
 Additional MAs, in addition to the LightSoft-created MA, may be added to an existing service via the
EMS; see Multiple MAs for a Service.
 When managing MEs for existing services:
 MA management procedures are the same whether the MA was created through LightSoft or
the EMS.
 After editing the MA of an existing service, a remote operation is required: either one of the
CFM toolbar options, or Activate to activate the service as a whole; see the description of
remote operations in CFM Tab in the Supporting Information Supplement.
 When service endpoints are added or deleted, LightSoft automatically modifies the
LightSoft-created MA as needed.
 MEPs and MIPs for an MA created through the EMS cannot be changed in LightSoft.
TIP: To avoid transient CFM alarms, CCM should be disabled on MAs when performing Add,
Edit, Remove, or Resync MA operations; for details, see Handling Transient Alarms.
Parent Topic

11.19.1 Adding MAs to a Service

Adding an MA configures CFM functionality on specific service endpoints.
You can add an MA to:
 The current service by clicking Add MA in the CFM tab.
 One or more services via the Service List pane CFM > Edit MA shortcut option.
Add MA is enabled for the current service if no LightSoft-created MA already exists for that service. Other
MAs created by the EMS may be present. You can also create additional MAs via the EMS; see Multiple MAs
for a Service.
You can configure CFM functionality on remote unmanaged MEPs; see Remote Service Endpoints.
Creating an MA generally involves selecting a CoS value and using the default values for the remaining
parameters:
 The MD Label and MD level parameters have default values Operator Level1.
 The MA Label is optional. LightSoft automatically adds a prefix to the user-assigned label that includes
the VPN ID and the CoS, so the MA label is unique. The association between service MA and service is
identified by the VPN ID.
An MA consists of MEPs (at the service endpoints) and MIPs (at intermediate points), which are defined
automatically by LightSoft per MA; see MEP and MIP Panes in the Supporting Information Supplement.
NOTE: Certain equipment limit the number of supported MEPs/MIPs to protect the host from
excessive load. Attempts to configure more MPs may be rejected with the message Maximum
CCM Budget will be Exceeded. You can disable CCM on some MAs to free resources for use
elsewhere.
Table 11-4: Add MA dialog box parameters
Field Description
List of selected services
When Add MA is initiated through the Service List window, a list of selected services to which new MAs
will be added is displayed.
MA parameters
MD Label Maintenance domain name. The one LightSoft-created MA is
automatically associated with the Operator 1 MD Label. See MA List
Pane in the Supporting Information Supplement.
MD Level Maintenance domain level. The one LightSoft-created MA is
automatically associated with the Operator 1 MD Level. See MA List
Pane in the Supporting Information Supplement.

Field Description
CoS CoS value 0 to 7 applicable to the MA. Default is the associated service
CoS. Can be changed as needed. See MA List Pane in the Supporting
Note: If the selected CoS is not consistent with the service CoS, the
MA is created with an Incomplete MA state.
MA Label MA identifier. (Optional) You can enter up to 14 characters. LightSoft
automatically assigns the VPN ID and applicable CoS as suffix, making
the MA Label unique over the MD.
CCM Period (ms) Time interval between CCM transmissions on endpoints of the MA.
Examples are 1000 msec (1 sec) (default), 10000 msec (10 sec), 60000
msec (1 min), 600000 msec (10 min).
Supported periods may vary according to the equipment type. The
CCM period selected must be supported by both endpoints. See the
relevant equipment manual for more information.
CCM Period is used in conditions associated with CFM Alarm
generation; see CFM for Alarm Management.
Enable CCM checkbox Enables CCM functionality on the MA (default Cleared); see Continuity
Check.
Note: Enable CCM on a P2MP service is not recommended as false
continuity check alarms may result.
Alarms checkbox Enables/disables CFM alarms on the service associated with this MA
(default Cleared); see CFM for Alarm Management.
LLCF Enables or disables LLCF functionality for the MA; see LLCF (Link Loss
Carrier Forwarding).
Parent Topic
11.19.1.1 Adding an MA to a New Service
To add an MA to a new service:

1. In the Create Service window MA List pane, click Add MA. The Add MA dialog box opens.

2. Enter an MA label.
3. (Optional) Select the appropriate values in the dropdown lists for fields that are enabled. LightSoft
automatically selects CFM parameters appropriate for the service being provisioned. In most cases
you can leave the default values.
4. To enable CFM continuity checks, enable CCM and Alarms.
5. Click OK. The dialog box closes and the MA is reflected in the MA List pane. Once the new service is
activated, the MA is saved.
Parent Topic
11.19.1.2 Adding MAs to One or More Existing Services
To add an MA to an existing service:

1. In the Service List window Services pane, select a service.
2. In the MA List pane, click Add MA. The Add MA dialog box opens.
3. Enter values in the required fields.

4. Click OK. The dialog box closes and the MA is reflected in the MA List pane.
5. In the CFM tab toolbar, click Activate New MA to activate the new MA on the service. A
standard Results window opens at the end of the process.
6. Click OK. Additional processing occurs, at the end of which the MA details are displayed in the MA List
pane.
To add an MA to one or more services:

1. In the Service List window Services pane, select one or more services and right-click.
2. In the shortcut menu select CFM and then Add MA.
The Add MA dialog box opens. The services for which a new MA will be added are shown at the top of
the window.

3. Enter values in the enabled fields as needed.

4. Click OK. The dialog box closes and a standard Results window opens at the end of the process. Click
OK in this window.
When the related services are selected in the Services pane, the new MAs appear in the MA List pane.
Parent Topic
11.19.2 Editing Service MAs

You can edit the CCM Period, Alarms, and Enable CCM attributes of existing MAs (whether LightSoft- or
EMS-created). These attributes can be edited in:
 An MA of the current service by clicking Edit MA in the MA List pane.
 All MAs of one or more services via the Services pane CFM > Edit MA shortcut option. If a user
selection involves multiple MAs, attributes of all the MAs are changed at once.
MA list attributes are defined in Adding MAs to a Service.
Parent Topic

11.19.2.1 Editing the Current MA of a New Service
To edit the current MA of a new service:

1. In the Create Service window CFM tab MA List pane, select the MA and click Edit MA. The Edit MA
Attributes dialog box opens.
2. Modify the CCM Period, Alarms, and/or Enable CCM attributes as needed.
3. Click OK. The changes to the MA are reflected in the MA List pane.
Parent Topic
11.19.2.2 Editing One or More MAs for One or More Services
To edit a single MA:

1. In the Service List window CFM tab MA List pane, select an MA and click Edit MA. The Edit MA
Attributes dialog box opens.
2. Modify the CCM Period, Alarms, and/or Enable CCM attributes as needed.
3. Click OK. A standard Results window opens at the end of the process.
4. Click OK. The changes to the MA are reflected in the MA List pane.

To edit all the MAs of one or more services:

1. In the Service List window Service List pane, select one or more services, right-click, and select CFM
and then Edit MA. The Edit MA dialog box opens. The services for which all MAs will be modified are
shown in the top of the window.
2. Modify the CCM Period, Enable CCM, and/or Alarms attributes as needed.
3. Click OK. A standard Results window opens at the end of the process.
4. Click OK. When the related services are selected in the Services pane, the modified MAs appear in the
MA List pane.
Parent Topic
11.19.3 Removing MAs

Existing MAs, whether LightSoft- or EMS-created, can be removed from a service. Removing MAs is not
traffic affecting since the service is not essentially changed.
To remove the current MA of a new service:

 In the CFM tab MA List pane, select the MA and click Remove MA. The MA is removed from the
current service.
To remove existing MAs from a service:

1. In the Service List window, select a service in the Services pane.
2. Right-click and select Edit Service. The Edit Services window for that service opens.
3. In the CFM tab, select the MA and click Remove MA. The MA is removed from the service.
4. Click Activate to save the changes to the database.
5. Close the Edit Service window.
The Service List window CFM tab reflects the change.
Parent Topic

11.19.4 Validating MAs

The Validate action recalculates the conformance status (MA State) of:
 A single MA of a service
 All MAs associated with one or more services
The result appears in the MA State field. The most severe detected MA State of all MAs associated with the
current service determines the CFM State of the service. A table explaining the possible MA validation
states is provided at the end of this section.
To validate a service MA:

1. In the Create Service window or Service List window for the current service, in the MA List pane,
select an MA.
2. Click Validate MA . A confirmation window opens showing the selected MA.

3. Click Yes. The MA is validated and a Validate Operation Succeeded message appears. The MA State is
shown.
4. Click OK to close the window.
To validate all MAs associated with one or more services:

1. In the Service List window Service List pane, select one or more services, right-click and select CFM
and then Validate. A confirmation window opens showing the services for which MAs will be
validated.
2. Click OK. The MAs are validated and a Validate Operation Succeeded message appears, listing the
number of MAs in each MA State in all the validated MAs.

Table 11-5: MA states
MA State Description
States resulting from Validation
OK The MA is conformant and its FDFr MAs comply with all the following conditions:
 MEP List for all MAs is identical for P2P and MP2MP services.
 MEP ID for each MEP is a member of the MEP List.
 CCM is enabled or disabled for all MEPs in an MA.
 CCM Period (if defined) is the same for all MEPs in an MA.
 Levels in an MA are equal.
 CoS is the same for all MCS MPs in an MA.
Unmanaged MEPs may be present. The managed MEPs are a subset of the MEPs in
the MEP list.
Not Conformant When one of the FDFrs has a different value of CCM Period, Enable CCM, Alarms,
and/or MEPID List, the MA is considered non-conformant. For example:
 A service MA is created with CCM Period set to 1000, but for some reason one
of the FDFr MAs was created with another value. The Non Conformance
Reason field indicates non-conformance due to CCM Period.
 MEPID List is not the same list in all MAs. The Non Conformance Reason field
indicates nonconformance because of MEP ID.
In the event of non-conformance, the Ethernet service is marked as
non-conformant with the following degrees of severity:
 Inconsistent MEP List
 Inconsistent Values of Enable CCM
 Inconsistent Values of CCM Period
N/A Denotes the service is not CFM enabled and CFM validation is not relevant.
States resulting from other causes (not affected by Validate)
Not Validated (State is unknown as validation was not performed.)
When the service MA is changed or created through EMS actions, for performance
reasons the MA state is not automatically calculated on each FDFr MA created in
the EMS. In this case the MA State automatically becomes Not Validated. You can
calculate the MA state through Validate if needed.
Not Complete (Highest severity state)
When top-down MA creation is attempted and an NE is disconnected, the process
of setting up FDFr MAs in the EMS is disrupted. The top-down MA creation request
is rejected by the EMS, leaving the MA incomplete. Not Complete denotes a failure
at the EMS level. (If you subsequently perform any change to the MA, the MA State
becomes Not Validated.)
Parent Topic

11.19.5 Resynching MAs

After a service with changes to MAs is admitted to LightSoft from the EMS, the MA State of an MA may
become Non Conformant - for technical reasons the MA and FDFr MA attributes may not exactly match.
For details about the conformance conditions, see Validating MAs.
You can make the MAs conformant by performing Resynch MA. You can perform this on:
 A single MA of a service
 All MAs associated with one or more services
Resynch MA can be performed on any non-conformant service MAs, whether LightSoft- or EMS-created.
The Resynch MA action synchronizes the CCM period, Alarms, and Enable CCM. For a LightSoft-created
MA, it also synchronizes the remote MEPID lists (see Remote MEPID List below). All FDFr MAs should then
have the same service MA values and the MA will be conformant. The MA State is recalculated (see
Validating MAs) and the revised status appears in the MA State field.
Remote MEPID List and EMS-created MAs

For EMS-created MAs, one synchronization aspect is not dealt with and the MA may remain
non-conformant even after Resynch MA is performed.
Each MEP of an MA contains a Remote MEPID list that contains the MEPID of each of its neighbor MEPs. (If
the MA has four FDFr MAs with IDs 1 to 4, each FDFr MA's Remote MEPID list should show the four IDs.)
When an MA is LightSoft-created, the Remote MEPID list is automatically created at each FDFr MA, and
thereafter updated in normal upload or Resynch MA actions.
For EMS-created MAs, the Resynch MA action regarding remote MEPID lists does not operate if the
following conditions are not met:
 When creating all the FDFr MAs, you must assign the same Remote MEPID list to each one, listing the
MEPIDs of all its neighbor FDFr MAs.
 When removing an FDFr MA via the EMS, you must manually also remove its MEP ID from all Remote
MEPID lists.
Edit Service and Service Reconnect

The Edit Service and Service Reconnect functions automatically support CFM in the following ways.
 When a service is edited, LightSoft synchronizes its CFM aspects. If endpoints are changed, MEPs and
MIPs are created or removed in existing MAs. The Edit process synchronizes FDFrs an FDFr MAs.
 When a service is reconnected for a LightSoft-created MA, LightSoft checks if a new FDFr MA should
be associated and does this if required.
However, Reconnect does not deal with FDFr MAs that are deleted or edited. Use Resynch MA to
synchronize the MA.

NOTES:
 For Edit MA Attributes and Service Reconnect, the Remote MEPID list is synchronized
only for the LightSoft-created service MA. For EMS-created MAs, synchronize the list
manually via the EMS.
 To avoid transient alarms, CCM should be disabled on MAs while Resynch MA is being
performed; see Handling Transient Alarms.
To resynch an MA of a service:
1. In the Service List window MA List pane for the current service, select an MA.
2. Click Resynch MA . A confirmation window opens showing the selected MA.

3. At the conclusion of processing, a standard Results window opens. Click OK in this window.
Additional processing continues. When completed, the MA State in the MA List pane is updated.
To resynch all MAs associated with one or more services:

1. In the Service List window Service List pane, select one or more services, right-click and select CFM
and then Resynch. A confirmation window opens showing the services for which MAs will be
synchronized.
2. Click OK to start processing. When completed, a Succeeded message opens.
Parent Topic
11.19.6 Implementing LLCF

LLCF can be assigned by LightSoft on P2P and P2MP services. LLCF for MP2MP service can be set from the
EMS. LightSoft will display it but does not apply any validations.
LightSoft assures that LLCF operates within an MPLS network. On P2MP services spanning MPLS and PB
networks, LightSoft configures the CFM as for MP2MP service, so as a result, LLCF operation will be
incorrect and should not be applied.
See LLCF (Link Loss Carrier Forwarding).

To assign LLCF on a service:

1. Configure the Port LLCF Role on the service ports in the Properties for Port window; see Port
Properties - ETH/MPLS Tab.
 For a P2MP service, set the root ports as LLCF Source and the leaf ports to LLCF Sink.
 For P2P service with unidirectional LLCF, set one service port as a LLCF Source port and the
other service port as LLCF Sink.
 For P2P with bidirectional LLCF, set both service ports to LLCF Source & Sink.
2. Select the service whose ports have been configured with LLCF Roles from the service list, and select
the CFM tab to open the Edit MA window (which contains the service MA and MEP List panes).
3. In the MA List pane, select one MA to open the MA MEP list. Note that only a service MA that
contains all service endpoint MEPs (usually the MA with MD Level = 1) should be selected, in order to
achieve the required CFM connectivity for a full LLCF operation.
For each MEP ID and port in the MEP List, the MEP table displays the associated LLCF Port Role
(Source or Sink).
4. To enable/disable the LLCF operation in an MA, in the MA List pane LLCF Operation dropdown list,
select Enable or Disable for that MA line.
MA LLCF Enabled is disabled for non P2P/P2MP services.
5. If the P2MP service resides over MPLS and PB networks, a full Remote MEP List is assigned at all PEs,
and LLCF is forced to Disabled.
a. Assigning a full remote MEP List on a PB creates the situation where every continuity loss
between any MEP associated with LLCF Sink will cause LLCF to shut down the Sink port, even
though LLCF is meant to shut down the port only if continuity is lost with the root.
b. Because of this LLCF malfunction in the PB network, LightSoft validation shuts down the LLCF
Enable for this service.
c. The user may enable LLCF for this service from EMS.
Parent Topic

11.19.7 Handling Transient Alarms

Transient alarms may occur if any CFM traffic-affecting operation (see below) is performed while CCM is
enabled on an MA (Enable CCM checkbox is selected). If you wish to avoid such transient alarms, you can
perform the following actions on the MAs involved in this sequence:
To handle transient alarms:

1. Clear the Enable CCM checkbox.
2. Perform the required CFM traffic-affecting operation (see the list below).
3. Reselect the Enable CCM checkbox.
If the MA is being processed via the EMS instead of top down via LightSoft, all these actions must be
performed per FDFr MA via the EMS.
Perform this action to avoid transient alarms during the following CFM traffic-affecting operations:
 Creating an MA or editing MA attributes within an existing service; see Managing CFM MAs.
 Removing MAs.
 Resynching MAs.
 Reconnecting Services.
 Editing an existing service's endpoints (since LightSoft automatically adjusts CFM aspects if needed);
see Editing Services.
Parent Topic
11.20 Configuring CFM-PM (Y.1731)

The Y.1731 standard defines Ethernet PM mechanisms for measuring Ethernet service performance.
LightSoft supports CFM-PM (Y.1731) measurements for P2P, P2MP, VLAN Tree, and MP2MP services,
performed between pairs of MEPs belonging to the same MA. Each pair includes a Sender MEP that
generates messages, and a Responder MEP that replies to them. For more information, see Understanding
CFM-PM (Y.1731).
To start CFM PM operations:

1. Right-click a service in the Service List window Services pane and select CFM and then CFM PM. The
CFM Performance Management window opens.
The title bar of the Performance Management window identifies the service being monitored.
The top of the Performance Management window provides a Services Summary pane that
summarizes the parameters of the selected service.

2. DM sessions for the selected service are configured through the DM Sessions window panes; see
Creating New DM Sessions and Editing and Deleting DM Sessions.
3. SLM sessions for the selected service are configured through the SLM Session window panes; see
Creating New SLM Sessions and Editing and Deleting SLM Sessions.
4. Click Get CFM-PM Counters in the window toolbar to open a table with the current CFM-PM
session counter values; see Displaying a List of Current CFM-PM Counters.
NOTES:
 Only one DM session can be configured per MA.
 Only one SLM session can be configured per MA.
 You are allowed to configure one DM session as well as one SLM session for the same
sender/responder pair.
TIP: This section provides step-by-step instructions for configuring and editing DM and SLM
sessions. Screenshot are provided to illustrate the relevant windows and fields. For a complete
list of the DM and SLM session properties and their ranges, (when relevant), see Service
Performance Management Window (Y.1731). For more information about MAs, their member
MEPs, and their configuration properties, see Managing CFM MAs.
Parent Topic
11.20.1 Creating New DM Sessions
To configure new DM sessions:

1. Right-click a service in the Service List window Services pane; select CFM and then CFM PM. The CFM
Performance Management window opens, identifying the service being monitored in the window
title bar.
2. Select the DM Session pane to open a list of the DM sessions that have been configured, as illustrated
in the following figure. If no DM sessions exist, the table is empty.

3. To configure new DM sessions, click Add at the bottom of the DM Sessions pane. The Set DM Session
pane opens, with a blank MEP table ready to fill with new MEPs for the new session.
4. Click Select Sender to select a sender MEP for this session. The Select Sender window opens.

The Select Sender window lists selected MEPs according to the MA to which they belong. For more
information, see MA List Pane and MEP and MIP Panes in the Supporting Information Supplement.
5. Select Sender MEPs from a drop-down list of MEPs in the Select Sender window and click OK.
6. Click Select Responder to select a responder MEP for this session. The Select Responder window
opens.
7. Select Responder MEPs from a drop-down list of MEPs in the Select Responder window and click OK.
Note that Responders may include third party MEPs, in which case you must enter the Responder
node's MEP ID and MAC address in the 3rd Party MEP pane at the bottom of the Select Responder
window.

8. As MEPs are selected, they are added to the list of DM Session MEPs in the lower half of the Set DM
Session pane.
NOTE: Once you have selected a MEP as a sender, LightSoft only enables MEPs that belong to
the same MA to be chosen as a responder. Potentially appropriate MEPs are listed as a pool of
potential responders. To reset the sender/responder settings, click Clear and reselect as
needed.
9. If the MEP selections would not produce valid session, appropriate warning messages are displayed
and the user must select different MEPs. For example:
 If the second MEP selected is the same as the first MEP selected, a warning message is displayed
and the user must choose a different MEP.
 If the two MEPs chosen to be a pair of MEPs are the same as the two MEPs selected for a
different session, a warning message is displayed and the user must choose a different MEP
pair.
10. (Optional) Choose one of the convenient auto-select options available, telling LightSoft to
automatically select the appropriate senders and responders. Options include:
 Auto Select Leaves: P2MP and VLAN Tree services offer auto-completion after the user selects a
root MEP. LightSoft automatically finds all leaf and combination root/leaf MEPs that belong to
the same MA and creates a DM session for each sender/responder pair.
 Auto Select Roots: P2MP and VLAN Tree services offer auto-completion after the user selects a
leaf MEP. LightSoft automatically finds all root and combination root/leaf MEPs that belong to
the same MA and creates a DM session for each sender/responder pair.
 Auto Select Unselected MEPs: For P2P and MP2MP services, once the user selects a sender or
responder MEP, LightSoft automatically finds all other unselected MEPs that belong to the same
MA as the sender MEP and creates a DM session for each sender/responder pair.

11. To create new sessions with pairs of MEPs in the table, click Apply in the Session Operations area at
the bottom of the Set DM Session pane. Note that the Apply button is only enabled if you have
selected an even number of MEPs that can be configured as sessions with sender/responder pairs.
As LightSoft creates the new DM sessions, the MEP entries in the DM Session MEPs table are cleared
and the corresponding sessions are added to the DM Sessions table. Sessions are by default
configured and saved in an Enabled state.
12. To enable (or disable) a session, select the session from the list in the DM Session pane and click
Enable (or Disable) in the Session Operations area at the bottom of the Set DM Session pane.
13. If the session being created could not be completely implemented at both the sender and responder
ends, the session is assigned a status of Partial. When that session is selected, the corresponding
MEPs for that session are listed in the DM Session MEPs window pane. The MEP that could not be
implemented successfully is assigned a status of Undefined. To create a valid session, the user must
delete this session and create a new one.
When implementing these services, LightSoft automatically downloads the relevant configuration
information to the EMS level. Current CFM-PM data is uploaded from the EMS and displayed to the user
through the CFM-PM counters table; see Displaying a List of Current CFM-PM Counters.
Parent Topic
11.20.2 Editing and Deleting DM Sessions
To edit property settings for a current DM session:

title bar.
2. Select the DM Session pane to open a list of the DM sessions that have been configured.
3. Select the session you wish to edit from the list of DM sessions in the table, and click Edit at the
bottom of the DM Sessions pane.
The sender and responder MEPs for the selected session are listed in the DM Session MEPs table in
the Set DM Session pane. Their current property values are displayed in the window fields.

4. Edit MEP property values as needed. The following properties can be edited:
 Period
 Frame size
Note that sessions can only be edited when they are in a Disabled state. For more information about
specific fields, see Service Performance Management Window (Y.1731).
5. Click Apply in the Session Operations area to save and implement your changes.
6. Click Enable or Disable in the Session Operations area to enable or disable the DM session, as
needed.
To delete a DM session:
title bar.
2. Select the DM Session pane to open a list of the DM sessions that have been configured.
3. Select the session you wish to delete from the list of DM sessions in the table, and click Delete at the
bottom of the DM Sessions pane.
4. Confirm that you wish the session deleted. LightSoft deletes the sessions and removes it from the DM
Sessions table.
5. If the session cannot be deleted, LightSoft disables the session instead. Confirm this action through
the message window.
Parent Topic

11.20.3 Creating New SLM Sessions
To configure new SLM sessions:

title bar.
2. Select the SLM Session pane to open a list of the SLM sessions that have been configured. If no SLM
sessions exist, the table is empty. This is illustrated in the following figure.
3. To configure new SLM sessions, click Add at the bottom of the SLM Sessions pane. The Set SLM
Session pane opens, with a blank MEP table ready to fill with new MEPs for the new session.
4. Click Select Sender to select a sender MEP for this session. The Select Sender window opens.

The Select Sender window lists selected MEPs according to the MA to which they belong. For more
information, see MA List Pane and MEP and MIP Panes in the Supporting Information Supplement.
5. Select Sender MEPs from a drop-down list of MEPs in the Select Sender window and click OK.
6. Click Select Responder to select a responder MEP for this session. The Select Responder window
opens.
7. Select Responder MEPs from a drop-down list of MEPs in the Select Responder window and click OK.
Note that Responders may include third party MEPs, in which case you must enter the Responder
node's MEP ID and MAC address in the 3rd Party MEP pane at the bottom of the Select Responder
window.

8. As MEPs are selected, they are added to the list of SLM Session MEPs in the lower half of the Set SLM
Session pane.
NOTE: Once you have selected a MEP as a sender, LightSoft only enables MEPs that belong to
the same MA to be chosen as a responder. Potentially appropriate MEPs are listed as a pool of
potential responders. To reset the sender/responder settings, click Clear and reselect as
needed.
9. If the MEP selections would not produce valid session, appropriate warning messages are displayed
and the user must select different MEPs. For example:
 If the second MEP selected is the same as the first MEP selected, a warning message is displayed
and the user must choose a different MEP.
 If the two MEPs chosen to be a pair of MEPs are the same as the two MEPs selected for a
different session, a warning message is displayed and the user must choose a different MEP
pair.
10. To create new sessions with pairs of MEPs in the table, click Apply in the Session Operations area at
the bottom of the Set SLM Session pane. Note that the Apply button is only enabled if you have
selected an even number of MEPs that can be configured as sessions with sender/responder pairs.
11. As LightSoft creates the new SLM sessions, the MEP entries in the SLM Session MEPs table are
cleared and the corresponding sessions are added to the SLM Sessions table. Sessions are by default
configured and saved in an Enabled state.
12. To enable (or disable) a session, select the session from the list in the SLM Session pane and click
Enable (or Disable) in the Session Operations area at the bottom of the Set SLM Session pane.
13. If the session being created could not be completely implemented at both the sender and responder
ends, the session is assigned a status of Partial. When that session is selected, the corresponding
MEPs for that session are listed in the DM Session MEPs window pane. The MEP that could not be
implemented successfully is assigned a status of Undefined. This is illustrated in the following figure.
To create a valid session, the user must delete this session and create a new one.

When implementing these services, LightSoft automatically downloads the relevant configuration
information to the EMS level. Current CFM-PM data is uploaded from the EMS and displayed to the user
through the CFM-PM counters table; see Displaying a List of Current CFM-PM Counters.
Parent Topic
11.20.4 Editing and Deleting SLM Sessions
To edit property settings for a current SLM session:

title bar.
2. Select the SLM Session pane to open a list of the SLM sessions that have been configured.
3. Select the session you wish to edit from the list of SLM sessions in the table, and click Edit at the
bottom of the SLM Sessions pane.
The sender and responder MEPs for the selected session are listed in the SLM Session MEPs table in
the Set SLM Session pane. Their current property values are displayed in the window fields.

4. Edit MEP property values as needed. The following properties can be edited:
 Period
 Frame size
 FLR window (unavailable if the sender is an MCS card)
Note that sessions can only be edited when they are in a Disabled state. For more information about
specific fields, see Service Performance Management Window (Y.1731).
5. Click Apply in the Session Operations area to save and implement your changes.
6. Click Enable or Disable in the Session Operations area to enable or disable the SLM session, as
needed.
To delete an SLM session:

title bar.
2. Select the SLM Session pane to open a list of the SLM sessions that have been configured.
3. Select the session you wish to delete from the list of SLM sessions in the table, and click Delete at the
bottom of the SLM Sessions pane.
4. Confirm that you wish the session deleted. LightSoft deletes the sessions and removes it from the
SLM Sessions table.
5. If the session cannot be deleted, LightSoft disables the session instead. Confirm this action through
the message window.
Parent Topic

11.20.5 Displaying a List of Current CFM-PM Counters
To display a list of current CFM-PM counters:

title bar.
2. In the window toolbar, click Get CFM-PM Counters to display a list of the current CFM-PM
counters.
3. Table data is organized by sender/responder MEP pair. Each row lists a pair of sender and responder
MEPs, identified by MEP IDs and owner LEs. The rest of the table columns display all the CFM-PM
counters that are currently relevant for that MEP pair. This means that, for example, if a MEP pair is
only being used in a DM session, only DM session counters are listed for that MEP pair. If a MEP pair is
used in both a DM and an SLM session, all the relevant counters for both types of sessions are listed
for that MEP pair.
By default, the most commonly referenced counters are listed in the table columns. To change the
selection or order of counters listed in the table, click Table Edit (far right side of the table column
headings) and arrange the table columns as you prefer.
4. If the PM data retrieval was only partially successful, a summary message appears in the information
bar at the bottom of the window. Click Details for more information.
For an explanation of each of the Performance Monitoring toolbar buttons, see Viewing Current Trail
Performance Data in the Performance Monitoring Guide.
Parent Topic

11.20.6 Service Performance Management Window (Y.1731)

CFM-PM (Y.1731) performance management operations are configured through the Performance
Management window. The selected service name appears at the top of the window. The window icons are
described in the following table.
Table 11-6: Performance Management window

Refresh Refresh the MEP and session table entries.
Get CFM-PM Counters Opens a table with the current CFM-PM session counter values;
see Displaying a List of Current CFM-PM Counters.
Service Summary pane

This pane summarizes the parameters of the service selected for the operation.
Figure 11-34: Service Summary pane
DM Sessions pane
This pane lists the DM sessions that have been configured for the selected service. The property values
configured for each session are listed in a table in this pane. Buttons at the bottom of the pane are used to
add, edit, or delete selected DM sessions.
Figure 11-35: DM Sessions pane

Set DM Session pane

Configure a DM session through this pane. Used to define a new DM session or to reconfigure an existing
DM session. Window fields are explained in a table at the end of this topic.
Figure 11-36: Set DM Session pane
SLM Sessions pane

This pane lists the SLM sessions that have been configured for the selected service. The property values
configured for each session are listed in a table in this pane. Buttons at the bottom of the pane are used to
add, edit, or delete selected SLM sessions.
Figure 11-37: SLM Sessions pane

Set SLM Session pane

Configure an SLM session through this pane. Used to define a new SLM session or to reconfigure an existing
SLM session. Window fields are explained in a table at the end of this topic.
Figure 11-38: Select SLM Session parameters
NOTE: The following table includes session properties for both DM and SLM sessions. Most of
the properties apply to both types of sessions. Properties that are relevant for only one type
of session are so noted.
Table 11-7: Set DM/SLM Session pane fields
Field Description
DM/SLM Session Parameters
DM/SLM Period Sets the time between every test packet transmission (in ms).
DM/SLM Frame Size Frame size of the test session packets, ranging from 64 to 9600 in
increments of 4 (in Bytes).
SLM FLR Window Frame Loss Ratio value for this test session, ranging from 10 to 1000 in
increments of 1, sets the window size in which calculations will be
performed (in packets).
Add Button, click to add a new session.
Edit Button, click to edit the property values of the selected session.
Delete Button, click to delete the selected session.
DM/SLM Session MEPs
Role Identifies the MEP's role (sender or receiver).

Field Description
Sender MEP ID ID of the sender MEP.
Responder MEP ID/MAC address ID or MAC address (as relevant) of the responder MEP.
LE Name LE associated with the MEP.
Status Current status of the session. Options are:
 Enabled, indicates both MEPs are enabled.
(Default initial value)
 Disabled, indicates both MEPs are disabled.
 Partial, indicates one MEP is enabled and one MEP is disabled.
(DM/SLM) Period Sets the time between every test packet transmission (in ms).
(DM/SLM) Frame Size Frame size of the packets used in this MEP's test session, ranging from
64 to 9600 in increments of 4.
SLM FLR Window Frame Loss Ratio value for this test session, ranging from 10 to 1000 in
increments of 1, sets the window size in which calculations will be
performed (in packets).
Parent MA MA with which this MEP is associated.
Select Sender Button, click to specify the selected MEP is the sender for this session.
Select Responder Button, click to specify the selected MEP is the responder for this
session.
Clear Button, click to clear the selected sender/responder assignments.
DM Session only
Auto Select Roots Checkbox, asking LightSoft to automatically find all root MEPs that
belong to the same MA as the currently selected MEPs and create a DM
session for each root/leaf pair.
Auto Select Leaves Checkbox, asking LightSoft to automatically find all leaf MEPs that
belong to the same MA as the currently selected MEP and create a DM
session for each root/leaf pair.
Checkbox, asking LightSoft to automatically find all unselected MEPs
Auto Select All Unselected MEPs
that belong to the same MA as the currently selected MEP and create a
DM session for each MEP pair.
Session Operators
Apply Button, click to create DM/SLM sessions from the MEPs currently listed
in the DM/SLM Session MEPs table.
Enable Button, click to enable the selected DM/SLM sessions.
Disable Button, click to enable the selected DM/SLM sessions.
Parent Topic

11.21 Troubleshooting Service Provisioning

This section describes the actions usually performed by LightSoft to complete and activate a new service,
followed by a list of validation messages and tips on diagnosing and resolving a failure in service creation.
For more information, see the lists of reasons for service inconsistency and service nonconformance in the
Parent Topic
11.21.1 Actions Performed by Complete and Activate

Complete
The Complete operation does the following (parameters set manually or calculated by LightSoft during
configuration are not changed):
 Derives the MPLS and PB networks on which the service is implemented.
 Selects an appropriate tunnel.
 Selects S-VLAN ID for each PB network.
 Performs automatic S-VLAN ID registration on all links of Ethernet networks where the service is
defined.
The Networks and the tunnels selected for a Service are displayed in the Networks pane. At this point the
service has not yet been saved to the database or downloaded to the EMS.
Activate
The Activate operation configures the EMSs for the services as follows:
Service creation (MPLS network):
 Selects a VC label.
 Creates a VSI at each PE for the service in the network.
 Creates a UNI or E-NNI service endpoint, where required.
 Attaches the service to the selected tunnels.
Service creation (PB network):
 Selects a VC label.
 Creates a VSI for each LE in the network for each MTNM-defined service.
 Transmits flow points of the VSI as attributes of the VSI creation transaction.
 Creates policers on the Bridge point where Ethernet Remote UNIs are connected.
Other:
Adds/deletes/modifies a service endpoint by updating the VSI for the LE at which the endpoint is defined.
For each bridge and MPLS-PE on which the service is defined, on service enable/disable, sets the service's
Administrative State to Enable/Disabled.

At this point the service is saved to the database and downloaded to the EMS. EMS implementation
depends on the module type.
Parent Topic
11.21.2 Connectivity Validation Messages and Actions

Table 11-8: Troubleshooting messages
Message Explanation/Recommendation
Error messages provided following failed calculate/complete/activate request:
Maximum number of RSTP Defining this RSTP service between the selected nodes would cause
instances reached the nodes to exceed the maximum number of services supported
per node. Open the relevant service in the Service List window and
delete an unnecessary RSTP instance.
One or more tunnels missing When completing and validating a proposed service, LightSoft failed
to find all the tunnels required. You must select or create the
necessary tunnels before the service can be completed and
activated.
Note that this message may reflect node connections that are
completely missing, or that are only connected in one direction. All
nodes participating in the service must have bidirectional
connectivity to at least one other service node. Create additional
tunnels between the nodes as needed.
One or more tunnels configured Participating tunnels must be configured consistently. This includes:
inconsistently  Tunnel mode and CoS settings must match those of the service
endpoints.
 Services configured to use dedicated and/or protected tunnels
only must be assigned tunnels that are configured the same
way.
Selected domains are not fully This message is a specific instance of the more general 'missing
interconnected tunnels' message described previously. When completing and
validating a proposed H-VPLS service, LightSoft found that not all
domains are interconnected. Additional tunnels must be configured
to complete the service.
Selected domains form loop service When completing and validating a proposed H-VPLS service,
structure LightSoft found loop topologies in the configuration. No loops may
exist between domains.
Reminder messages provided after successful activate request:
EMS reminder message At activation, a reminder message appears that you must configure
RSTP on the relevant ports at the EMS level before the RSTP service
can be functional at the LightSoft level.
Connectivity check messages provided upon user complete/activate request:

Message Explanation/Recommendation
Automatic S-VLAN registration is in Recommendation: Either use manual registration or protect the
use but PB network GWs are not GWs using dedicated infrastructure service.
protected. Service may not be
operational. Do you want to
proceed?
Manual S-VLAN registration in use This warning message appears if one or more gateways are missing
but PB network GWs are protected. from the manual selection set.
Service may not be operational. Do Recommendation: Either use automatic registration or remove the
you want to proceed? infrastructure service protecting the GWs in case it does not protect
other PB networks.
GWs ports RSTP state is inconsistent Recommendation: Make sure RSTP state is consistent in all GWs (all
are enabled or disabled).
Multiple infrastructure services Recommendation: Delete redundant infrastructure services.
exists on the GWs
RSTP service exists on the GWs but Recommendation: Enable the RSTP state on the GWs’ ports.
the ports RSTP state is disabled
GWs ports RSTP state is enabled but Recommendation: Activate RSTP state on the GWs.
RSTP service is missing
ERP service exists but it does not Recommendation: Either remove the unprotected GWs ports or
protect all GWs ports make sure all GWs ports are protected by some infrastructure
service.
BPDU Tunneling service exists but it Recommendation: Either remove the unprotected GWs ports or
does not protect all GWs ports make sure all GWs ports are protected by some infrastructure
service.
GWs ports RSTP state is enabled but Recommendation: Replace the existing infrastructure service with
the infrastructure service is not RSTP service.
RSTP
Service state marked RSTP service acquired from the EMS with only one LE is considered
nonconformant nonconformant in LightSoft and cannot be activated.
Warning messages provided upon service/tunnel creation or editing actions:
Deleting this ERP service may cause If ERP PEs are being used by other user services, LightSoft does not
loops and is not allowed. allow the user to delete that ERP service. A warning appears
explaining that this may cause loops in the user services.
Deleting this RSTP service may If RSTP PEs are being used by other user services, LightSoft does not
cause loops and is not allowed. allow the user to delete that RSTP service. A warning appears
explaining that this may cause loops in the user services.
Editing the tunnels of this service Editing RSTP service and changing tunnels and PEs may affect traffic.
might cause traffic hit. Are you Confirmation is required before proceeding with this action.
sure?
Parent Topic

11.21.3 Diagnosing a Create Service Failure

Note that LightSoft assumes that the network elements, including physical links, trails, and tunnels required
to handle the service, have been created and configured before the service is provisioned. You may
optionally choose to have LightSoft automatically create missing tunnels when provisioning a new service;
see Service Management Preferences in the Getting Started & Administration Guide.
If the Create Service operation fails, perform the following verification steps.
If the action failed at the Completion stage:

2. Check if all the endpoints are correct, if tunnels exist between all endpoints with available bandwidth,
and if the selected tunnels are appropriate.
4. If completion fails due to one or more required tunnels being unavailable, verify that the
configurations of tunnels selected by LightSoft for the service are compatible with the intended
service's attributes; see Networks Tab - MPLS Network Pane in the Supporting Information
Supplement.
5. Check the parameters selected in the Create Service window.
If the service failed at the Activation stage (Completion succeeded):

2. Check if all VSIs/FDFrs were created at the EMS level.
3. Verify that all the relevant networks are uploaded in EMS and LightSoft.
Parent Topic

12 Performing Actions on Ethernet Services
The Ethernet Service List window enables you to manage data services in the network. You can display one
or a list of services and modify attributes, including advanced sorting and filtering.
This section also describes the ERP/RSTP Map window, which shows the current traffic state of RSTP or ERP
services.
Ethernet services are provisioned and modified via the respective EMS. You can admit these services to
LightSoft, making them available for viewing and changes in the Service List window (as LightSoft-created
services). You retain full control over services with problematic service states; see Service Acquisition and
ESI.
Acquired services or EMS-initiated service modifications may sometimes fail LightSoft network-wide
validations and deemed to be Non-Conformant (similar in concept to flex trails). Convert the service to
conformant by appropriate editing; see Service Non Conformance Reasons in the Supporting Information
Supplement.
12.1 Accessing the Ethernet Service List Window

As per preselections in the LightSoft main window, the Ethernet Service List window opens with different
object combinations:
 No preselected objects:
 The map view shows all objects in the network (consistent with your user permissions).
 The Services pane includes Ethernet services based on the default filter; see Services Pane in
the Supporting Information Supplement.
TIP: Choose No Services as the default filter to take less time to open the Ethernet Service
List window. You can then select a different filter. See Applying a Filter and Setting It as
Default.
 Preselected objects:
 The map view shows only preselected objects and their immediately associated links/elements.
 The Services pane shows only the associated tunnels. A "temporary" filter applies (default filter
is disregarded). If required, you can create a new filter based on the temporary filter objects;
see Creating a Filter with Preselected Objects.
A wide range of filter options is available; see Filtering Ethernet Services.
You can open multiple Ethernet Service List windows simultaneously, each displaying selected layer and
elements independently of other layers, having its own topology layer and view of the network, and
allowing different service operations.

LightSoft® User Guide Performing Actions on Ethernet Services
To open the Ethernet Service List window with only selected NEs:
1. Select the NEs in the most recently opened Topology View map.
2. In the main window Services tab, in the General group, click ETH Service List. No specific Topology
Layer selection is required. The Ethernet Service List window opens.
To open the Ethernet Service List window with services of a single PE:
1. In the ETH/MPLS layer, in the View map, select a PE.
2. Right-click and select Show Services. The Ethernet Service List window opens, showing only services
associated with the selected PE.
Parent Topic
12.2 Viewing Service Information

Selecting a service in the Services pane makes it the focus of the information in other panes. Associated
services and other traffic entities can be identified and associated alarms displayed.
Parent Topic
12.2.1 Viewing Information Detail

The Ethernet Service List window opens with several information panes, one of which, the Services pane in
the Supporting Information Supplement, lists a filtered set of service records.
When you select a service in the Services pane list, the service becomes the focus of the information in the
other panes, and associated objects and links are highlighted in the Service List window map.
To view information about a service:

1. In the Service List window, ensure that a service filter is selected to filter the services you want listed
in the Services pane; see Filtering Ethernet Services.
2. Select a service in the Services pane. By default, Show on the right of the toolbar is selected and:
 The other information panes immediately show detailed information about the selected service.
 The service's associated elements and links are highlighted in the Service List window map.
You can select services in the Services pane in two ways:
 Click to select one service at a time.
 Select (or unselect) the checkboxes of any number of services. This method is used for operations such
as delete, export, reconnect, show current alarms, print, etc. See Performing Service Operations.
Parent Topic


In the relevant list windows, you can view tunnels and trails associated with selected services. You can also
view the underlying services for a selected non-bypass tunnel; see Viewing Tunnel Information - Show
Associated Trails, Services, or Protected Tunnels.
To view traffic entities associated with a service:

1. In the Service List window, select the service(s) for which you want to view associated traffic entities.
2. Choose one of the following:
 To show associated tunnels: Click Show tunnel(s) , or right-click and select Show and then
Show Tunnels. The Tunnel List window opens, showing the associated tunnels.
 To show associated MoT trails: Click Show MoT trails associated with this service(s) , or
right-click and select Show and then Show MoT Trails. The Trail List window opens, showing the
associated MoT trails.
 To show associated EoS trails: Right-click and select Show and then Show EoS Trails. The Trail
List window opens, showing the associated EoS trails.
Parent Topic
12.2.3 Viewing Alarms for Selected Services

All the alarms affecting selected services are displayed in the Current Alarms window; see Viewing Alarms
for Selected Traffic Entities.
You can also view the services affected by a selected alarm; see Viewing Traffic Entities Affected by an
Alarm.
Parent Topic
12.2.4 Viewing Services Associated with a Policer Profile

A selected policer profile can be configured as a service endpoint or be the BSC Policer for the service.
To view services associated with a policer profile:

1. Select a policer profile in the Policer Profile List window; see Viewing the Policer Profiles List.
2. Select Policer Profiles and then Show Services, or click Show Services . The list of services is
displayed.
Parent Topic

12.3 Viewing RSTP/ERP Information

The RSTP/ERP Map window shows the current traffic state of RSTP or ERP services: active/non-active links
(RSTP) or links forwarding/blocking traffic (ERP). Click RSTP or ERP in the dropdown list to display
information for the protocol.
NOTES:
 Customize the default colors used to display links and LEs in the RSTP and ERP maps; see
RSTP/ERP Map Preferences in the Getting Started & Administration Guide.
 The ERP Map window supports one ERP instance per port. Some EMSs support multiple
instances of ERP per port, meaning each instance can protect a range of VLANs.
 The MPLS region of the map is not colored.
Limitation:
Open the RSTP/ERP Map window with a limited number of objects. When the map is opened for a large
number of objects (PEs, PTPs), one of the following warnings appears:
 Opening the window may take a while (optionally start over with fewer objects).
 Too many objects are selected (start over with fewer objects).
The threshold number of objects producing each warning type is configurable. For details, contact your
local Customer Support representative
When the RSTP/ERP map is opened, LightSoft displays the most updated State values from the EMS. These
values are static and are not updated automatically when attributes change in the EMS. Click Refresh to
load the latest information from the EMS.
To view RSTP or ERP information:

1. Select the Ethernet topology view in the LightSoft main window Topology Layer dropdown list.
2. If you want to open the RSTP/ERP Map window with only selected LEs and the links running between
them, select the LEs in the LightSoft main window view map.
Do not attempt to load a large topology containing several RSTP domains and ERP rings all at once
into the RSTP/ERP map. Instead, select part of the topology, for example, a PB network and several
PEs.
3. In the main window Tools tab, in the Maps group, click RSTP/ERP Map. The RSTP or ERP for Ethernet
window (whichever window was last used in the previous session) opens, showing an updated view of
the RSTP or ERP schemes that are in use.
You can switch to the other protocol (RSTP or ERP) by selecting the required option in the RSTP/ERP
dropdown list.
Note: When the map is opened for a large number of objects (PEs, PTPs), according to the number of
objects allowed, a warning appears:
 Opening the window may take a while. To continue, click Continue, or click Cancel to start over
with a smaller object selection.
 Too many objects are selected. Click OK and start over with a smaller selection.

4. While viewing, the message "RSTP map has changed" may appear at the bottom of the window,
signifying that the underlying spanning tree has changed due to changes in relative costs of links or
link availability. Click View and then Refresh to refresh the display. The Last Update time stamp in the
bottom right-hand corner of the window shows the date/time of the last refresh.
Table 12-1: RSTP/ERP Map window options
Menu/Toolbar option Description

RSTP/ERP Switches between RSTP and ERP. The window titles changes
dropdown list accordingly.
Map
Preferences Enables you to change the colors associated with RSTP
information; see RSTP/ERP Map Preferences in the Getting
Close Closes the RSTP Map window.
View
Refresh Refreshes the RSTP Map window to show the latest RSTP color
coding on trails. The Last Update time stamp in the bottom
right corner of the window shows the date/time of the last
refresh. The RSTP Map window automatically refreshes when
it opens.
Legend Shows/hides the status bar legend and Last Update time
stamp.
Parent Topic

12.3.1 RSTP Map Window

LightSoft's RSTP map shows the parts of the tree between the endpoints of an Ethernet service used by
traffic and enables you to understand current traffic flow. This section describes how to view the active
RSTP tree in the RSTP for Ethernet window.
Figure 12-1: RSTP map view
The RSTP map comprises the following color-coded components (default colors are indicated):
 RSTP-relevant LEs (yellow): One Ethernet switch is defined by the protocol as the root bridge of a tree.
 RSTP-relevant links (arrows show directionality):
 Light blue (or same as main trail) - active RSTP links, which allow the flow of Layer 2 Ethernet
traffic.
 Purple (or same as protection trail) - RSTP-enabled links with inactive standby status; may
switch to active RSTP links if required by the RSTP algorithm.
 Gray - RSTP-disabled links (for a port or bridge) or links not running through EIS cards.
The default colors are configurable via the RSTP Map Preferences dialog box; see RSTP/ERP Map
If multilinks contain links of both states (active and non-active), the map shows the active state color (light
blue). The Expand Link window shows each link with its relevant color.
If the RSTP involves an RSTP infrastructure service, the MoT/MoE links used by the service are colored like
I-NNI links (i.e., active/non-active state).
PEs with no RSTP connections (no active/non-active links) are colored gray (as links that don’t participate in
RSTP).
LAG links are represented in the map as single links.

RSTP topologies are not always implemented with RSTP infrastructure services:
 If only one PE is connected to the PB network (with multiple connections), it is sufficient to select the
service's RSTP attribute, thereby enabling RSTP on every participating port on the connection. An RSTP
infrastructure service is not needed.
 If multiple PEs are connected to the PB network, an RSTP infrastructure service is needed between the
two PEs to enable moving the protocol between them.
NOTES:
 The RSTP for Ethernet window only operates with LEs that have been created as Ethernet
switches by selecting the Split by an Ethernet Switch checkbox in the Create LE dialog
box.
 The RSTP map shows only the RSTP state of single links. See the relevant EMS for links in a
multilink (including LAGs).
 The RSTP Map window does not support MSTP. The RSTP protocol protects all VSIs of a
port, while MSTP allows protecting selective ranges of VLANs. Typically, an
MSTP-supporting EMS creates MSTP on the whole range and is treated by LightSoft as
RSTP protection.
Parent Topic
12.3.2 ERP Map Window

LightSoft's ERP map shows the relevant objects of an ERP protected topology.
Figure 12-2: RSTP/ERP Map window - ERP

The objects have the following default color coding:

 RPL owner port: Relevant LE is colored yellow (same as RSTP Root LE).
 RPL forwarding link: Link has RPL icon and is colored light blue. (RPL link is link where one endpoint is
an RPL port.)
 ERP blocked links: Colored purple.
Nonparticipating links are colored gray.
The color coding scheme can be modified as needed; see RSTP/ERP Map Preferences in the Getting Started
If multilinks contain links of both states (forwarding and blocked), the map shows the active state color
(light blue). The Expand Link window shows each link with its relevant ERP state color.
LAG links are represented in the map as a single link.
NOTE: The ERP Map window does not support multiple ERP instances per port. An ERP
instance that contains only part of the range (from an EMS that supports this) is not reflected
in the ERP map. In this case, the port must contain a single ERP instance that contains the
whole range.
Parent Topic
12.4 Performing Service Operations

To perform a service operation:
1. Select the service by selecting its checkbox in the Services pane.
2. Select a Service List window toolbar option or right-click a service in the Services pane and select a
shortcut menu option.

3. Continue the operation as described in the relevant procedure. At the conclusion of the operation:
 If successful, an operation succeeded message opens.
 If any part of the operation was not successful, a Results window opens, showing information
about the failed operations.
Whenever an operation is not completely successfully, Operational Results Info in the Service List
window toolbar is enabled. After you close the message window, you can revisit the results by clicking this
icon.
The icon remains enabled until another operation is performed. If the second operation is completely
successful, the icon is disabled. If it is partially successful, it displays the detailed results for that operation.
Parent Topic

12.5 Implementing MAC Address Learning Query

The Ethernet Service MAC Address Learning Query dialog box lists the PBs and MPLS-PEs at which a
user-configured MAC address has been learned.
This query applies for MP services only (MP2MP, RootedMP, and P2MP). P2P services are implemented as
VPWS for which there is no MAC learning.
Figure 12-3: Ethernet Service MAC Address Learning Query dialog box
For each selected service and MAC address, the following is listed:
 ME identification
 LE identification
 Port at which the MAC address was learned (if it is in the vFIB); otherwise blank
 Remote PE from which the address was learned (for MPLS-PE only); otherwise blank
 Flag indicating if service is in vFIB
To implement a MAC address learning query:

 Right-click a service in the Services pane and select Service Utilities and then MAC Address Learning
Query. The Ethernet Service MAC Address Learning Query dialog box opens.
Parent Topic

12.6 Implementing vFIB Utilization Query

The Ethernet Service vFIB Utilization dialog box lists the vFIB usage at each PB and MPLS-PE at which the
service is implemented.
This query applies for MP services only (MP2MP, RootedMP, and P2MP). P2P services are implemented as
VPWS for which there is no MAC learning.
Figure 12-4: Ethernet Service vFIB Utilization Query dialog box
For each LE supporting the selected service, the following is listed:

 ME identification
 LE identification
 Current vFIB occupancy (number of MAC Address entries at this LE)
 Applicable vFIB quota: max. number of MAC addresses that can be learned per VSI supporting this
service, derived from the default vFIB Quota parameter or vFIB Quota assigned to the service at the
EMS
 Utilization percentage, indicating the current vFIB/applicable vFIB Quota
To implement a vFIB utilization query:

1. Right-click a service in the Services pane and select Service Utilities and then vFIB Utilization Query.
The Ethernet Service vFIB Utilization dialog box opens.
Parent Topic

12.7 Toggling Between Network and DB Service

Views
The Services pane toolbar includes a Show DB/Network toggle icon to show the selected service as it exists
in the LightSoft DB or the network.
Icon Function Description

Show DB service Selected service as it exists in the LightSoft DB (expected service
structure).
Show network service Selected service as it exists in the network (actual service structure).
Enabled when service state is Inconsistent, Incomplete, or Not
Admitted.
When the selected service is in Not Admitted state, the Map view automatically changes to Network mode
and the toggle option is disabled (Not Admitted services have no DB structure).
When a service in any other state is highlighted, the window automatically switches to DB mode and the
icon and menu are enabled.
Parent Topic
12.8 Filtering Ethernet Services

You can filter the Services pane according to any combination of service attributes and objects activated
from either predefined or created filters.
Figure 12-5: Services pane
The Total services statistic in the status bar shows the number of services filtered vs. the total number of
services. (The status bar also shows the total number of services with checkboxes selected.)

The following predefined service filters are supported by LightSoft.
Table 12-2: Predefined service filters
Filter Description
Customer Services All services except dual homing (factory default filter; can be changed by
user as required).
All Services All services (no filtering).
All Managed Services All services except those in Not Admitted state (default when Service List
window is opened with no other filter).
No Services No services. (When this is the default, the Service List window initially
opens quickly without any services. Another filter should then be applied;
see Applying a Filter and Setting It as Default.)
Dual-Homing Services Dual homing services only.
Inconsistent Services Services in Inconsistent, Incomplete, and Not Admitted states.
Table 12-3: Service filtering by service state
Filter OK Non Conformant Inconsistent Incomplete Not Admitted
All managed services

All services
Customer services
Infrastructure services
Inconsistent services
NOTES:
 All automatic filters omit Not Admitted services (for example, when opening the service
list by selected resources, alarms, or tunnels).
 When objects are selected in the map or tree (resource filtering) and filtering is by specific
states, only the applicable services passing through the selected PEs are shown.
Filter options can be activated from both the LightSoft main window and Service List window.
In the LightSoft main window

Use the Services tab (General group) Service Filters option to:
 Create or edit a new filter according to any combination of service attributes or objects; see Creating
and Editing Advanced Filters.
 Edit, rename, or delete a filter that you created, or set a filter as the default (which automatically
activates it when the Service List window opens); see Renaming, Deleting, and Setting Default Filter
Actions.

The Services pane can automatically be opened with services corresponding to preselected objects in the
LightSoft main window; see Accessing the Ethernet Service List Window.
In the Service List window

You can:
 Click Quick Filter to quickly filter by Service ID, Name, and/or Customer; see Creating a Quick
Service Filter.
 Use the Filter selector dropdown list to activate any filter. You can also click
Set Filter as Default to set the current filter as the default (automatically activated when the
Service List window opens); see Applying a Filter and Setting It as Default.
The icon is disabled if the currently applied filter is already the default.

 Click Show Tunnels or Show MoT Trails to show the tunnels or MoT trails associated with
selected services; see Viewing Associated Traffic Entities.
Parent Topic
12.8.1 Creating a Quick Service Filter

The Quick Filter function enables you to quickly filter the services in the Services pane or throughout the
database, by Service ID, Name, and/or Customer. This method does not involve a filter template and is
defined per use.
To quickly filter services by label, service ID, and/or customer:

1. Open the Service List window, as described in Accessing the Ethernet Service List Window.
2. In the Services pane, click Quick Filter . A quick filter field bar opens at the top of the pane.
3. For parameters besides Type, enter a string included in the parameter(s) for which you want to filter
services.

4. Enter a text string to the relevant fields to filter in services with field values that include this text; see
field descriptions in Services Pane Columns in the Supporting Information Supplement.
(For Type, select P2P, MP2MP, Rooted MP, P2MP, or L1 in the dropdown list.)
You can enter partial strings, (e.g., xy), to identify services with this text anywhere in the fields.
Wildcard characters are not used.
 The table immediately adjusts to show services that satisfy the filter criteria.
OR
 To filter the entire database (instead of the current service contents), enter a string to each

First perform a Force Filter search of the entire database. Then apply multiple incremental
filters to the current table contents, adjusting the filter criteria on-the-fly to change the
composition of services displayed.
5. Click Info to display an Info Tip describing the use of this filter type.
6. Click Clear Filter to clear the current quick filter selections. (You can also backspace to empty a
filter field.)
7. Click Close Filter to close the quick filter field bar. If Force Filter (database search) had been
used, the list reverts to its contents before the filter was applied. Otherwise, if a table search was
performed, the latest filtered contents are retained in the list.
(in the same way as when objects are preselected before opening the Service List window),
which you can use as a base for other filter actions; see Creating a Filter with Preselected
Objects.
Parent Topic

12.8.2 Working with Advanced Service Filters

Advanced filters enable you to view a subset of the services in the Service List window according to any
combination of:
 Service attributes (like specific rates)
 Selected objects (all services traversing specific objects)
create.
Saving a filter after performing a create or edit operation automatically applies the filter settings to the
open Service List window. Any other filter can be applied as needed at any time.
 Applying a Filter and Setting It as Default
 Creating and Editing Advanced Filters
 Another Way to Edit a Filter
 Creating a Filter with Preselected Objects
 Renaming, Deleting, and Setting Default Filter Actions
 Selectable Service Filter Attributes
 Other Service Filters
Parent Topic
12.8.2.1 Applying a Filter and Setting It as Default

Any filter (predefined or user-defined) can be applied, immediately changing the services listed in the
Services pane. In addition, the currently applied filter can be set as the default, defining the services that
the Service List window automatically opens with in a new session.
TIP: Opening the Service List window may be time consuming if many services are filtered in.
If you choose No Services as the default filter, the window initially opens without any services
in the Services pane.
You can then apply a different filter.

To apply a filter, and (optionally) set it as default:
1. In the Service List window, select a filter in the Filter dropdown list .
The filter is immediately applied, reflected in services listed in the Services pane.
2. (Optional) Set the current filter as the default by clicking Set filter as default .
Parent Topic

Advanced filters are used to search the database for services that satisfy the filter criteria.
preselected in a map window are not relevant. For information how to create a filter with
object preselections in the LightSoft main window map, see Creating a Filter with Preselected
Objects.

1. In the main window Services tab, in the General group, click ETH Service Filters. The Service Filters
dialog box opens. (You can view a summary of parameters and topology elements for an existing filter
by selecting the filter in the Filters pane.)

OR
Select a user-created (non-predefined) filter that you want to modify in the Filters pane, and click
Edit. The Create Filter or Edit Filter dialog box opens.

3. Click Show Tree to open the Topology Tree pane. The button changes to Hide Tree for hiding
4. In the Filter Name field, type a name for the new filter. If you are editing, this field is disabled. You
can save as a different name for the modified filter, if needed, when saving the changes.
a. In the Filter By area, select a parameter's checkbox.
 Text entry field (See the note about the text field entry below.)

 Field options
additional values. The multiple selections are displayed in the Value area
.
d. Repeat the above for as many parameters as needed. (You can remove a selected value by
selecting it again.)

NOTE: About Text Field Entry

Text filters are case sensitive. If filtering by Label and Customer text entry fields, use the
wildcard character * to filter in all trails where the field value includes a specified string, for
example:
 xy* to filter in all trails with the field value starting with xy
 *xy* to filter in all trails with xy anywhere in the field value
 *xy to filter in all trails with the field value ending with xy (this pattern is not
recommended).
OR
If filtering by any other text fields, or if any resource objects are selected in the Topology Tree
area (see next step), enter xy to find all trails with xy anywhere in the field value. (Wildcard
character is not supported.)

0)
6. If you want to filter by selected resource objects to which services are associated, move objects from
the Topology Tree area to the Topology tab, as follows:
 Select the topology layer for the filter: ETH/MPLS (default). The Physical layer can also be
selected, enabling you to select physical nodes. Double-click the root of the tree to refresh
its elements.
 Select the objects for which you want to filter services (drill down in the tree). To select
multiple objects, press SHIFT and click. )
b. In the Topology pane, click Add to move selected objects from the Topology Tree area to
the Topology tab (click Remove to remove objects not required for the filter).
OR
Parent Topic


You can also edit a user-defined filter via the Service List window.
To edit a filter via the Service List window:

1. Open the Service List window.
Parent Topic

You can create a new service filter with objects selected in the LightSoft main window map. This avoids
having to select the elements again when creating the filter. These objects are automatically reflected in
the Service List window map and in a "Temporary" filter which you can build on.

1. In the LightSoft main window map, select any objects that you want to include in a new service filter.
2. In the main window Services tab, in the General group, click ETH Service List.
The Service List window opens with the selected objects and with the Temporary filter preselected in
the Filter selector dropdown list.

3. Click Edit Filter (enabled only if objects were preselected). The Edit Filter dialog box opens with
the preselected objects already selected in the Topology pane. (The filter name is "Temporary" until
Save As is used to save under another name.)
Parent Topic
12.8.2.5 Renaming, Deleting, and Setting Default Filter Actions
To rename/delete a filter, or set a filter as default:

1. In the main window Services tab, in the General group, click ETH Service Filters. The Service Filters
dialog box opens.

2. Select a filter and click one of the following options:

action.
Filter and Setting It as Default.
Click New and Edit to create and edit filters; for details, see Creating and Editing Advanced Filters.
Parent Topic
12.8.2.6 Selectable Service Filter Attributes

If no selections are made, all services are included.
Table 12-4: Configurable selection criteria for overall service attributes
Ethernet Svc Attribute Selection Criterion Configuration

Actual Traffic State Disabled, Enabled, or Partial
Administrative Service Enable Yes or No.
BPDU Tunneling Dual Homing Not Dual Homing, Access Link, or Internetwork Link.
BSC Policer Profile String with wildcard characters.
CFM State Choice of N/A, Non conformant, Not validated, OK, Incomplete.
Created By User Name of LightSoft operator. String with wildcard characters.
Created With GUI, XML, or Acquisition, selected in the list.
Creation Time Date/time range selected using From and To selector fields.
Customer Label string including wild cards denoted by *.
Dedicated Tunnels Only Yes or No.
EthVPN ID Date/time range selected using From and To selector fields.
Label Service label string including wild card denoted by *.
Modification Time Date/time range selected using From and To selector fields.
Modified By User Name of LightSoft operator. String with wildcard characters.
Modified With GUI, XML, or Acquisition, selected in the list.
Non Conformance Reason Choice of available reasons.
Policer Profile Name of policer profile. String with wildcard characters.
Note: Service appears in the filtered list if the policer appears at any
endpoint or is the BSC policer profile for the service.
Protected Tunnels Only Yes or No.
Service Group Customer or Infrastructure.
Service State Inconsistent, Incomplete, or Non-conformant.

Tunnel Mode E-LSP or L-LSP.

Type Service type. P2P, MP2MP, RootedMP, P2MP, and/or L1 selected in
the list. Multiple values can be selected.
VC Label Scheme Single Label or Regular.
vFIB Quota Ranges of vFIB quota separated by commas.
You can also select a list of ports, LEs, or groups in the Ethernet layer Inventory tree, which adds them as an
additional selection criterion.
Entity Selection Criterion Comment

Port List of Ports Services with any endpoint in the list are included.
LEs List of LEs Services with any endpoint on the LE are included.
Groups List of Groups Services with any endpoint in the list are included.
Parent Topic
12.8.2.7 Other Service Filters

You can also generate Service lists from other entities in LightSoft:
 Tunnels: Services for which a tunnel is one of the primary tunnels for the service on the MPLS
Network; see Show Associated Trails, Services, or Protected Tunnels.
 Policer Profiles: Display the list of services for which a selected policer profile is configured as one of
the service endpoints or is the BSC Policer for the service; see Viewing Services Associated with a
Policer Profile.
Parent Topic
12.9 Reconnecting Services

You may sometimes need to reconnect a service. This is typically required if a problem arises during service
creation, for example, if an NE is disconnected. The resulting service is left in an Incomplete state.
Reconnecting the service downloads missing VSIs and endpoints to the EMS according to the service
structure expected by LightSoft. The service state becomes OK. This action is not traffic affecting.
A topology change to an existing service in the EMS can result in a partial service structure and a need for
additional VSIs in the EMS. Just reinstating expected VSIs will not create the additional VSIs implied by the
new topology. A re-complete operation is required. The Reconnect Service dialog box includes a Perform
Recompletion option, which, in addition to reinstating LightSoft-created VSIs to the EMS, automatically
re-completes the selected services. This option is potentially traffic affecting since all aspects of the service
are recompleted.
See also the reconnection use cases at the end of this section.

NOTE: In previous LightSoft versions, Recompletion was performed automatically with

Reconnect. It is optional in the current version, avoiding traffic disruption if it is not needed.
To reconnect a service:
1. Open the Service List window; see Accessing the Ethernet Service List Window.
2. Select the checkboxes of the services you want to reconnect.
3. Click Reconnect (enabled when non-L1 incomplete services are selected). A confirmation
window opens, showing the services to be reconnected.
4. Select the Perform Recompletion checkbox if needed.

5. Click OK to continue.
A completion message appears, listing the operation result and nonfatal errors; see Performing
Service Operations.
Reconnection use cases

1. Suppose that:
 An MPLS network has a gateway to a PB network at B.
 A service A-E with VSIs at the PEs A, B, and D connected with tunnel A-B, and EoS/ETY B-D.
 In the following figure, VSIs exist on nodes A, B, D, and E.
If the VSI at A or D is deleted in the EMS, the service state becomes Incomplete. Reconnect is
sufficient to reinstate the expected structure in LightSoft (3 VSIs) to the EMS. The service is recreated
and its service state is restored to OK. No further action is needed. Traffic is not affected.

2. Additionally, suppose that:

 A PB is added at E.
 A service B-E is connected via a new gateway C.
 A DH configuration is created between B-C.
The creation of the C-E link makes C a gateway. There is now a need to create an additional VSI in C.
This is done by selecting Perform Recompletion in the Reconnect Service process. Traffic may be
affected.
Parent Topic
12.10 Editing and Deleting Services

This section describes how to edit or delete selected services. The actions can be implemented in the
network either immediately or postponed to a later time. When the actions are for future use, their details
are exported to an XML file and are put into effect by importing the file into LightSoft.
NOTE: Edit or Delete operations may fail if LightSoft is unable to set up the service in the
network as defined. This problem typically arises during service creation if an NE included in a
service is disconnected or a craft terminal is connected, causing the resulting service to be
incomplete.
To resolve: After the NE is uploaded or the craft is disconnected, reconnect the service to send
the missing VSIs to the LEs.
Parent Topic

12.10.1 Editing Services

The Edit Service window provides extensive service editing options, including access to parameters and
characteristics in the Create Service window panes. Services can also be edited for either immediate or
future effect in the network.
Service modification in LightSoft does not cause service interruption.
Service attributes can be edited provided the correct user capabilities are present. Services can be edited
even if the edit operation affects traffic. Endpoints can be edited or deleted; service endpoints cannot be
edited.
Specific EMSs do not support full editing of P2P services, such as changing ports or tunnels on an existing
P2P service.
NOTE: You can edit certain service attributes directly from Service List window panes using
the Edit Attributes function.
Some parameters present in both the Service Properties pane and the Edit window may be
enabled for editing only from one location (for example, certain EoS service parameters).
When using the Edit Service window, you can edit services for either immediate or future effect in the
network. For future application, the edit changes are exported to an XML file and put into effect by
importing the file into LightSoft; see Exporting Services. In this context, the Export operation provides the
following mode possibilities:
 Export for Edit mode: Creates an edited service on XML which Import uses to replace the existing
service.
 Export for Create mode: Creates a backup service that the Import uses to reinstate a deleted service.
If an existing P2P service is modified by configuring an alternate Policer Profile where the CIR is greater
than the existing profile, and if the Support automatic increase of tunnel bandwidth Preference variable is
true, LightSoft does the following:
 The currently selected tunnels are used if their bandwidth is sufficient for the CIR increase. If not,
another tunnel with sufficient bandwidth is selected.
 If no such tunnel exists, LightSoft verifies if it is possible to increase the bandwidth of the current
tunnel to support the modified service. If so, perform the tunnel bandwidth modification.
It is sometimes possible to change equipment endpoint configurations (for example, from GbE to FC-1G), or
to modify the rate setting of the TRP_C, without editing the service from LightSoft.
Parent Topic

12.10.1.1 Editing a Service

Services are edited using the Edit Ethernet Service window.
Figure 12-6: Edit Ethernet Service window
In general the service path is not editable in LightSoft. Edit the path of a PB P2P service as follows:
 Leave the path as is, originally defined in the EMS or LightSoft.
OR
 Clear the entire path, and either:
 Allow LightSoft to determine a direct path upon service completion.
OR
 Select a direct path (single direct EoS or direct ETY, not traversing another PB).
An EMS-acquired PB P2P service can involve multiple links, while a LightSoft-created service can have only
one link. If the path is cleared in LightSoft, its new path will involve a single direct link, whether
user-selected or LightSoft-determined.
PB P2P services are indicated only for specific use cases; see Configuring PB P2P Services between MCS
Cards.
To edit a service:
1. In the main window Services tab, in the General group, click Service List. The Service List window
opens.
2. In the Services pane:
 Select a service and click Edit service .

OR
 Right-click a service and select Edit Service.
The Edit Service window opens, showing the links used by the selected service.

3. Make the required changes to service parameters and/or endpoints. The window contains essentially
the same panes and parameters as the Create Service window; see Creating a Service.
4. PB P2P services: Adjust the service path as follows:
 Leave the P2P service path as is (originally defined in the EMS or LightSoft), as indicated in the
Networks tab S-VLAN Registered I-NNI Links pane.
OR
 Clear the entire path, and:
 Allow PathFinder to complete it.
OR
 Select a direct path (single direct EoS or direct ETY, not traversing another PB). The
selected EoS trail or ETY link is highlighted in the map and also appears in the S-VLAN
Registered I-NNI Links pane.
5. (Optional) Click Complete service . LightSoft determines how to implement the service and
displays the details in the Network pane.
warnings or nonfatal errors; see Performing Service Operations. If the Complete step encounters a
problem, see Diagnosing a Create Service Failure.
6. Click Activate service to activate the edit changes on the network.

warnings or nonfatal errors; see Performing Service Operations. If the Activate step encounters a
problem, see Diagnosing a Create Service Failure.
NOTE: If Complete Service was not performed previously, or if it was followed by an action
that changed the links used by the service (e.g., change of endpoint), it will automatically be
performed/repeated before the service is activated on the network.
7. To create an XML file as backup, click Export to XML .

Continue the procedure in Exporting Services , from Step 3.
For information how to implement the edited service in the network, see Importing Services.
Parent Topic
12.10.1 Editing Services
12.10.2 Deleting Services

You delete services in the Service List window. You can select and delete several services simultaneously.
All services are deleted the same way, whether created in LightSoft or in the EMS.
When a service is deleted, all VSI/FDFrs defined for the service are also automatically deleted. If this does
not occur (for example, if one of the NEs was disconnected at the time the service is deleted), the service
remains in the Service List window in an Incomplete or Failed state. The service is removed from the list
when all resources are deleted.

You can delete services for either immediate or future effect in the network. When the deletion is for
future application, its details are exported to an XML file and imported into LightSoft at a later time; see
Exporting Services.
A service is deleted by deleting:
 VSIs for the service at all PEs in the MPLS network.
 VSIs for the service at all LEs for which the service is defined in the PB network.
To delete a service:
opens.
2. In the Services pane, select the checkboxes of the service(s) you want to delete.
a. Right-click any selected line in the Services pane and select Delete.
OR
Select List and then Delete Service.
OR
Click Delete Service on the window toolbar.
A confirmation window opens.
b. Click OK to confirm. A completion message appears, describing the operation result; see
Performing Service Operations.
4. If you want the delete action to be implemented in the network at a later time, save the action in an
XML file, as follows:
 Click Export to XML .

OR
 Right-click one of the selected services and select Utilities and then Export. The Export Services
dialog box opens.
5. Continue the procedure as described in Exporting Services , from Step 4.
To implement the deletion in the network, see Importing Services.
Parent Topic

12.11 Acknowledging Service Modifications

In former LightSoft versions, EMS-created or modified services acquired to LightSoft were assigned
"Unacknowledged modification" status, so flagging the service's modifications for review. Details of
unacknowledged modifications enable the LightSoft user to verify each modification's validity.
This functionality is replaced by the Ethernet Service Inconsistency mechanism; see Service Acquisition and
ESI.
Parent Topic
12.12 CFM Maintenance Operations

CFM maintenance operations for LightSoft- and EMS-created service MAs are performed in the
Maintenance Operation window.
Only one operation can be performed at a time. However, additional operations can be performed
simultaneously on the same or a different MA/service in additional Maintenance Operation windows.
Figure 12-7: CFM Maintenance Operation window
You can perform the following maintenance operations:

 Loopback: Verifies bidirectional connectivity between a selected MEP and MEP/MIP of a service MA;
see Loopback.
 Link Trace: Traces the path from source MEP to target MP for fault isolation purposes by sending a
multicast message from a selected MEP to all other MEPs and MIPs on the same service MA; see Link
Trace.

 Continuity Check: Detects loss of continuity, incorrect network connections, and other defect
conditions. Each MEP sends multicast messages to every other MEP over all CCM-enabled MAs in the
currently selected service; see Continuity Check.
NOTE: Due to MAC aging, Link Trace may return incomplete or no results. To refresh MAC
Learning, it is recommended to perform Loopback before Link Trace; see Link Trace.
To start CFM maintenance operations:

1. Right-click a service in the Service List window Services pane and select CFM and then CFM MO. The
Maintenance Operation window opens; see Maintenance Operation Window for a Service.
2. For Loopback and Link Trace, select a source MEP and a target MEP/MIP; see Selecting Source/Target
for Loopback or Link Trace.
3. Continue the process as needed; see Loopback , Link Trace , and Continuity Check.
Parent Topic
12.12.1 Maintenance Operation Window for a Service

Perform maintenance operations for a service in the Maintenance Operation window. The selected service
name appears at the top of the window. Multiple windows can be opened simultaneously if you want to
perform operations on several entities at the same time (Loopback or Link Trace on MAs from the same or
different services, or Continuity Check on different services). The window icons are described in the
following table.
Table 12-5: Maintenance Operation window

Loopback Performs a Loopback test on a selected MA. Enabled when a
source MEP and a target MEP/MIP are selected; see Loopback.
Link Trace Performs a Link Trace test on a selected MA. Enabled when a
source MEP and a target MEP or MIP are selected; see Link Trace.
Continuity Check Performs a Continuity Check test on a selected MA. Enabled when
the Enable CCM checkbox is selected; see Continuity Check.
Print Prints the currently displayed left-side panes as an image to your
default printer; see Printing.
Export During Loopback or Link Trace, exports the information of the
Select Source and Select Target panes and the currently in-focus
Results tab to your default printer.
During Continuity Check, exports the analysis results - MA
summary (upper pane) and, if an MA line is selected, the
corresponding MEP/MIP results (lower pane).
Information is exported in a delimited format file, such as
comma-separated values (CSV), for import to Microsoft Excel or a
relational database application. See Exporting to CSV.

Service Summary pane

This pane summarizes the parameters of the service selected for the operation.
Figure 12-8: Service Summary pane
Select Source pane

Shows details of the source MEP for the Loopback or Link Trace test selected via Select Source MEP; see
Selecting Source/Target for Loopback or Link Trace.
Figure 12-9: Select Source pane
Table 12-6: Select Source pane fields
Field Description
MEPID ID of the source MEP.
If the MA involves a remote service endpoint, the MEP selected for the
source must belong to the managed LE; see Remote Service Endpoints.
Port Name Port associated with the MEP.
LE LE associated with the MEP.
Select Source MEP Opens the Select Source window for selecting a source MEP.
Select Target pane

Shows details of the target MEP/MIP for the Loopback or Link Trace test selected by clicking Select Target
MP; see Selecting Source/Target for Loopback or Link Trace.

Note: Both source and target must be selected within the same MA.
Figure 12-10: Select Target pane
Table 12-7: Select Target pane fields
Field Description
MPID ID of the target MEP/MIP.
Port Name Port associated with the MEP/MIP.
LE LE associated with the MEP/MIP.
MAC Address MAC address of the MEP/MIP. You can enter the address here or click
Select Target MP to identify the MEP/MIP by other means; see Selecting
Source/Target for Loopback or Link Trace.
If an MA involves a remote service endpoint, you must manually enter the
MAC address of the UME port each time a maintenance operation is
requested. LightSoft does not retain the MAC address from session to
session. See Remote Service Endpoints.
Select Target MP Opens the Select Target window for selecting a target MEP/MIP.
Results pane
This pane displays the results of maintenance operation tests.
For details, see Loopback , Link Trace , and Continuity Check.
Figure 12-11: Results pane
Parent Topic

12.12.2 Selecting Source/Target for Loopback or Link Trace

Maintenance operations are enabled for a service when:
 At least one MA has been configured on the service either via LightSoft or the EMS.
 A source MEP and a target MEP/MIP associated with a specific MA are selected. (Not needed for
Continuity Check, which is performed on all relevant MAs in the selected service.)
To select a source MEP and target MEP/MIP:

1. Open the Maintenance Operations window for a service; see CFM Maintenance Operations.
2. In the Select Source pane, select a source MEP, as follows:
a. Click Select Source MEP. The Select Source window opens, listing all the MAs defined for the
current service in the MA List pane; see Select Source and Select Target Windows.
b. Select an MA. The MEP pane lists only the managed MEPs of that MA. (The MEP that you select
cannot be unmanaged.)
c. Double-click a MEP, or select a MEP and click OK. The Select Source window closes and the Select
Source pane shows the MEPID, Port Name, and LE details of the selected MEP. The element
containing the MEP is highlighted in the map view.
NOTE: If the MA involves a remote service endpoint, the MEP selected as the source must
belong to the managed LE side of the service; see Remote Service Endpoints.
3. In the Select Target pane, select a target MEP/MIP.

The procedure differs for managed vs. unmanaged MEP/MIP (remote service endpoint) targets:
 Managed element:
The Step (a) procedure below is recommended. All the target details, including MAC
address, are automatically recorded. Step (b) (selection by MAC address) is more difficult
for this purpose.
 Unmanaged element:
The Step (a) procedure optionally records the MEPID of the target for the analysis. You
must also perform Step (b) to specify the MAC address.
 EMS-created MIPs: Do not always appear as target choices in the LightSoft Select Target
window. You can choose such a MIP by entering its MAC address in the MIP pane via Step
(b). See Multiple MAs for a Service.

a. Select Target Window Procedure:

 In the Select Target pane, click Select Target MP. The Select Target window opens with
the same MA you chose as source MEP in Step 2. The MEP and MIP panes list all the
MEPs/MIPs of this MA, including the unmanaged; see Select Source and Select Target
Windows.
 Double-click the required MEP/MIP, or select one and click OK.
NOTE: The target MEP and source MEP must be different.
The Select Target window closes and the Select Target pane shows the MEPID, Port
Name, and LE details of the selected MEP/MIP. The element containing the MEP/MIP is
highlighted in the map view.
Step (a) has the following effects for managed vs. unmanaged elements:
 Managed MEP/MIP: The MAC address automatically appears in the MAC Address field.
The target selection is completed.
 Unmanaged MEP/MIP: The MAC address remains blank and must be completed via the
MAC address selection procedure (Step (b), below).
b. MAC Address Selection Procedure: This step is mandatory for an unmanaged element and for
certain EMS-created MIPs that do not appear in the Select Target dialog box; see Multiple MAs
for a Service.
This step is not necessary for a managed element if Step (a) has already been performed.
 In the MAC Address field, enter the MAC address of the target MEP/MIP.
 Then click anywhere outside the field so that managed element details are reflected in
other fields.
Ensure that the MAC address corresponds to an element belonging to either the same MA
as selected for the source MEP, or a MEP different from that associated with the source
MEP.
Step (b) has the following effects for managed vs. unmanaged elements:

 Managed MEP/MIP: This step fills in all the target details according to the supplied MAC
address (replacing any previous content). If the MAC address is not found, all content is
removed. Check the MAC address and try again. (It is recommended to use only the Step
(a) procedure for managed element target selection.)
 Unmanaged MEP/MIP: The MAC address remains as you entered it. The MEPID from Step
(a) remains in place.
NOTE: MAC address validity is not checked immediately. If the MAC address is undefined, the
Loopback or Link Trace operation fails.
Parent Topic
12.12.2.1 Select Source and Select Target Windows

Click Select Source MEP and Select Target MP to open the Select Source and Select Target windows,
respectively. Use these windows to select a source MEP and a target MEP/MIP for the current Loopback or
Link Trace analysis; see Selecting Source/Target for Loopback or Link Trace.
The Select Source window shows a selected MEP within a selected MA. Its MA List and MEP panes contain
the same information as the same panes in the CFM tab. See MA List Pane and MEP and MIP Panes in the
Supporting Information Supplement, respectively.
Figure 12-12: Select Source window

The Select Target window shows a selected MIP within a selected MA (MEP or MIP can be selected). Its MA
List, MEP, and MIP panes contain the same information as the same panes in the CFM tab; see MA List
Pane and MEP and MIP Panes in the Supporting Information Supplement, respectively.
Figure 12-13: Select Target window
Parent Topic
12.12.2 Selecting Source/Target for Loopback or Link Trace
12.12.3 Loopback
Loopback verifies bidirectional connectivity between a selected MEP and MEP/MIP of a service MA. A
message is sent from a source MEP to a selected target MEP/MIP of the same MA. The target MEP/MIP
generates a reply message to the source, the receipt of which confirms the connectivity.
Figure 12-14: Loopback Protocol
The Loopback icon is enabled when a source MEP and a target MEP/MIP have been selected; see
Selecting Source/Target for Loopback or Link Trace.
The Results pane Loopback tab shows the results of each requested analysis on a separate line.

You can perform any number of loopback analyses by selecting different combinations of source and target.
The latest result appears in the top row.
The cumulative results are retained until you click Clear Table to delete them.
To perform Loopback:
1. Open the CFM Maintenance Operation window as described in CFM Maintenance Operations.
2. Select a source MEP and a target MEP/MIP; see Selecting Source/Target for Loopback or Link Trace.
3. Click Loopback . The action is performed. When completed, the result is displayed in the Results
pane Loopback tab.
Figure 12-15: Results Loopback pane
Table 12-8: Results pane Loopback tab functions

Clear Table Clears the cumulative analysis history.
Print Prints the information of the Select Source and Select Target
panes and the cumulative Loopback analysis results to your default
printer. See Printing in the Getting Started & Administration Guide.
Table 12-9: Results pane Loopback tab information
Column Description
MA MA Label from which the source and target for the current analysis were
selected; see MA Label in MA List Pane in the Supporting Information
Supplement.
Source ID MEP ID of the MEP selected as source for the analysis; see MEP ID in MEP
and MIP Panes in the Supporting Information Supplement.
Target ID MEP ID of the MEP selected as target for the analysis. N/A indicates that a
MIP or unmanaged element was selected (these do not have an equivalent
ID).
Target MAC Address MAC address of the target MEP/MIP (if applicable).
Result Succeeded or Failed.
Time Timestamp of the operation.
Parent Topic

12.12.4 Link Trace

Link Trace may be used to trace the path to a target MEP for fault isolation purposes. A selected source
MEP sends a multicast Link Trace Message (LTM) to identify adjacency relationships with remote MEPs and
MIPs in the same MA. The message body includes the MAC address of a target MEP that terminates the link
trace.
Figure 12-16: Link Trace protocol
The LTM typically begins at the source MEP with a "Time to live" (TTL) of 255 (depending on the
equipment). As the message traverses the first bridge (which then becomes aware of the source and target
MAC addresses), the bridge sends:
 A unicast LT Reply (LTR) back to the source, with the local MAC address and TTL decremented by 1 (to
254).
 An LTM forward to the next bridge toward the target. (If the NE is not aware of the target MEP MAC
address, no message is sent in either direction.)
Each next hop repeats the sequence of messages both back to the source (along the same path) and
forward one more hop towards the target. The TTL is decremented by one at each forward hop (second
bridge to 253, third bridge to 252, etc.). The Results table then shows, in descending order of TTL, the
bridge associated with each hop, its MAC address, and whether or not that bridge is the target
(intermediate bridges show target as No, while the final bridge in the list, with the lowest TTL, shows target
as Yes). The number of hops to the target is represented by the number of lines in the list.
The Link Trace sequence includes a prompt that recommends performing Loopback before Link Trace in
order to refresh MAC learning at the bridges. However, in some cases, it is useful to perform Link Trace
without or before Loopback in successive steps along the service path. For example:
 To observe differences in aging time between the bridges - which bridges recognize the MAC address
along the way.
 To trace the path to an unmanaged (or non-existent) MEP.
 To detect the location of a disconnection in the network.
Link Trace is enabled when a source MEP and a target MEP/MIP have been selected; see Selecting
Source/Target for Loopback or Link Trace.
You can perform any number of link trace analyses, selecting different combinations of source and target as
needed. Each analysis adds a new timestamp in the Results pane Link Trace tab Timestamp dropdown list,
representing a table of results. Choose a date to view its historical analysis.
All the cumulative result tables are retained until you click Clear Table to clear them.

To perform Link Trace:

1. Open the CFM Maintenance Operation window as described in CFM Maintenance Operations.
2. Select a source MEP and a target MP; see Selecting Source/Target for Loopback or Link Trace.
3. Click Link Trace . The following message may appear.
4. In the following cases it is recommended to perform Loopback before Link Trace to refresh MAC
learning:
a. To perform Loopback now, click Loopback and continue the procedure as described in
Loopback. Restart the Link Trace procedure after Loopback processing has finished.
b. To perform Link Trace now, click Link Trace. Processing starts. When completed, the result is
displayed in the Results pane Link Trace tab.
Table 12-10: Results pane Link Trace tab functions

Clear Table Clears cumulative analysis history (all the timestamps).
Highlight on Map If nothing is selected in the current test results table, highlights the
nodes associated with all MEPs/MIPs addressed by all lines of the
current test. When a specific line is selected, highlights in the map
the node associated with that MEP/MIP.
Print Prints the information of the Select Source and Select Target
panes and the Link Trace results corresponding to the currently
selected timestamp to your default printer; see Printing.

Table 12-11: Results pane Link Trace tab information
Column Description
Timestamp dropdown list Timestamp of the Link Trace analysis currently displayed in the table view.
TTL "Time to live" hop identifier. Starts with the value at the selected source,
decremented by one at each consecutive hop towards the selected target
(one per line in the table). Number of decrements therefore represents
the number of hops to the target.
MAC Address MAC address of local MEP/MIP at respective hop.
Role Role of entity represented by this MAC address. First line shows source,
intermediate hop lines transit, and last line target.
LE Name of LE associated with MEP/MIP at this hop.
Port Name of port associated with MEP/MIP at this hop.
MEPID MEP ID of the MEP at this hop. When the hop is at a MIP, N/A displayed
(MIP does not have a parallel ID and is identified by its MAC address).
Parent Topic
12.12.5 Continuity Check

Continuity Check is used to detect defect conditions such as:
 Loss of continuity
 Incorrect network connections - unintended connectivity:
 Between two MAs (mismerge)
 Within the MA with an unexpected MEP
 Other:
 Unexpected MA level
 Unexpected CCM period
Each MEP sends multicast messages to other MEPs.
Continuity Check OAM messages (CCMs) are multicast messages sent to each MEP by all other MEPs over
all CCM-enabled MAs in the service. The MEPs do not respond to the messages, but maintain records about
the status of other MEPs of the MA. MIPs are transparent to the CCM messages (see the following figure).
Figure 12-17: CCM protocol

The Continuity Check icon is enabled when Enable CCA is selected for at least one MA of a service;
see Adding an MA to a New Service. Continuity Check operates only on the MAs of a service for which CCM
is enabled. The results describe the continuity status OK or Fail from MEPs in enabled MAs to MEPs/MIPs in
the same or other enabled MAs over the selected service.
The Results pane Continuity Check tab shows two tables of information per analysis (distinguished by a
timestamp in the Timestamp dropdown list):
 Table of MAs within the service for which CCM is enabled and the analysis was performed. The table
shows the continuity status for the MA as a whole.
 Table of MEPs for a selected MA (in the MA table showing detailed continuity status information).
You can perform any number of Continuity Check analyses, selecting a different service as needed. Each
action generates a set of tables and a date in the Timestamp dropdown list by which specific analysis data
can be redisplayed.
The cumulative results are retained until you click Clear Table to clear them.
To perform Continuity Check:

1. Ensure that Enable CCA is selected for all the MAs you want to include in the operation.
2. Open the CFM Maintenance Operation window for a service, as described in CFM Maintenance
Operations.
3. Click Continuity Check . The action is performed. When concluded, the result is displayed in the
Results pane Continuity Check tab.
Table 12-12: Results pane Connectivity Check tab functions

Clear Table Clears the table of all history.
Print Prints relevant analysis results in table form to your default printer
(represented by the timestamp) - MA summary (upper pane) and, if
an MA line is selected, corresponding MEP results (lower pane). See
Printing.

Table 12-13: Results pane Connectivity Check tab information
Column Description
Timestamp dropdown list Timestamp of Continuity Check analysis currently displayed in table view.
Overall Connectivity Status by MA
MA MA for which Continuity Check was performed over selected services.
Level MD level of the MA
CoS CoS associated with the MA.
Overall Continuity Status Overall continuity status for the MA.
Detailed Connectivity Status by Maintenance Entity (MEP/MIP)
Report Source MEP identifier.
Subsequent columns show For each target MEP, one of the following statuses based on CCM reply
every target MEP involved in messages received by each source MEP from all other MEPs:
the analysis  OK: Replies consistently received from every target MEP.
 Fail: Failed to receive expected reply from at least one target MEP.
 Unknown: CCM currently disabled, thus no packets are being
sent/received.
 N/A:
 Source and target are the same MEP.
 Remote MEP is involved.
 Path to target includes an element that does not support CFM
(e.g. EIS card).
 CCM process does not have at least two participants. (MEPs might
be on same switch.)
Parent Topic
12.13 Data PM Management

Performance monitoring (PM) for data services can be enabled or disabled, and PMH reports accessed,
through the Service List window. For more information about PMH data collection and reports, see
Performance Monitoring in the Performance Monitoring Guide.
To enable/disable Ethernet service PMH:

1. From the Ethernet Service List, select the service(s) for which you want to enable/disable PMH.
2. Right-click and select PM Command.
The PM Command window opens.

3. Select Enable or Disable and select one or more checkbox:

 Port: Enable/disable PMH on ports.
 Policer and VSI: Enable/disable PMH on Policers and VSIs.
 Frame Delay: Enable/disable PMH on Frame Delays. Also select the MD level from the
dropdown box.
4. Click OK.
PMH is enabled/disabled for the selected services.
To view PMH data reports:

opens.
2. In the Services pane, select the checkboxes of the service(s) you want to delete.
3. Right-click and select Open PM Reports to open the current PM data reports for the selected services.
Parent Topic

12.14 Service Migration

The Tunnel Mode and VC Label Scheme attributes of a service can be changed after the service has been
activated through the Service Migration feature. Service Migration is typically used when migrating L-LSP
single label services to E-LSP regular services.
Note that service migration in this context is accomplished by, essentially, deleting the original service and
recreating it with the revised attribute settings. Automatic Service Migration simplifies this task by saving
all the configuration settings that have already been defined. The network operator only has to reset the
specific attributes that are being edited - everything else is preserved.
Prerequisites:
 To migrate a service to new types of tunnels, the new tunnels must already exist. Before beginning a
service migration, first create the new tunnels to be used; see Creating a Tunnel.
 Services must be migrated individually. If you are migrating multiple services, the procedure must be
completed separately for each service, one at a time.
 LightSoft creates a safe backup copy of the original service configuration as a safety measure and to
simplify service restoration if necessary. The backup data is stored in an XML file named according to
the service label (ServiceLabel.xml) and saved in the default NMS Services folder. Ensure that the
selected service has a meaningful value in the service label field, or the XML backup file will not be
named correctly.
CAUTION: Automatic service migration is accomplished in two stages: deletion of the original
service, and activation of the new version. For greater security, always choose the Backup
Service option.
To change a service attribute using Service Migration:

1. In the Ethernet Service List window, in the Services pane, right-click the service to be edited, and
select Service Operations and then Migrate Services.
2. A warning window opens, reminding you to create a backup file for the original service. Click Backup
& Continue (unless you are absolutely certain that you will not need to restore the service).

3. In the Migrate Ethernet Service window, edit the Tunnel Mode and VC Label Scheme service
attributes as necessary for the new service configuration and migration. In the Advanced Services
Parameters pane:
 Select the Tunnel Mode option (E-LSP or L-LSP).
 Select the VC Label Scheme option.
Note that with E-LSP tunnels the VC Label Scheme must be Regular.
4. Edit any other service attributes as necessary; see Creating a Service.
For example, the new service configuration may include H-VPLS services. The H-VPLS domains can be
defined and the services configured at this time; see Creating Multidomain Services.
NOTE: Migrating from L-LSP to E-LSP tunnels clears the existing entries in the Tunnel
Requirements table. New tunnels must be assigned to support the new service configuration.
Tunnels can be assigned automatically by LightSoft, or manually by the user.
5. (Optional) Manually select tunnels.

In the Tunnel Assignments area, manually select one or more tunnels; see Selecting Tunnels Manually
for a Service.
a. Click Select Tunnels to populate the Tunnel Assignments table. LightSoft fills in tunnel
options appropriate for the requirements of the domains that have been defined.
b. Manually assign tunnels to each row, choosing the appropriate bandwidth and CoS values.
c. Repeat this step any number of times until the entire domain structure is defined to your
satisfaction.
6. To complete the service tunnel calculations, click Complete. LightSoft automatically analyzes the new
service configuration to identify which tunnels are necessary, and adds them to the Tunnel
Assignments table.
7. To complete and activate the service, click Activate.
A warning window opens, reminding you that this action may be service-affecting. To proceed, click
Yes.
Parent Topic

12.15 Service Acquisition and ESI

EMS-originated services can be acquired to the LightSoft database and become available for viewing and
changes in the Service List window, exactly as for LightSoft-created services.
The current version of LightSoft distinguishes between the expected service structure as configured in
LightSoft and the actual structure configured in the network. When a service is changed in the network,
LightSoft does not automatically admit the change to the LightSoft DB. (This is similar to actual vs. expected
difference handling for trails and tunnels.)
Services uploaded from the EMS may sometimes be inconsistent with the expected service structure in
LightSoft or otherwise problematic, necessitating remedial action before being admitted to LightSoft. The
Service State indicates the presence and nature of the problem; see Service State in the Supporting
Information Supplement. It indicates whether the service:
 Does not exist in the LightSoft database (Not Admitted service)
 Is missing objects or has a different configuration in certain objects (Incomplete or Inconsistent
service)
 Failed LightSoft network-wide validation (Non Conformant service)
LightSoft provides the following mechanisms for warning and correcting problems of service state:
 Service Consistency counter informs about services with Inconsistent, Incomplete, and Non Admitted
states (see Service Inconsistency Counter in the Performance Monitoring Guide).
 Service List window provides operations for identifying problematic service states, and to remedy
Inconsistent, Incomplete, and Non Admitted services by admitting services to the LightSoft database
or imposing them on the EMS. See:
 Reconnecting Services in the LightSoft User Guide
 Toggling between Network and DB Service Views in the LightSoft User Guide
 Synchronizing Ethernet Services in the LightSoft User Guide
NOTE: In previous LightSoft versions, EMS-created or modified services were automatically

admitted to the LightSoft database, without regard for differences between EMS (actual) and
LightSoft (expected) configuration values. Whenever an EMS-initiated change occurred, the
service was flagged with an Unacknowledged Modification status. It was the user's
responsibility to investigate these services and to either acknowledge the modification or take
remedial action at the EMS level. The service remained in LightSoft "as is" until specific user
action was taken. From LightSoft V6, Inconsistent and Incomplete services can be repaired
through the LightSoft interface, and are admitted to LightSoft only by specific user request.
(The category of Not Admitted service did not exist since all services were automatically
admitted.)
The former Acknowledging Service Modifications procedure is no longer relevant.
Parent Topic

12.15.1 Synchronizing Ethernet Services

The following ESI operations can be accessed from the Services pane Service Operations shortcut menu.
Table 12-14: Service ESI operations
Operation Description
Checking Network Conformance Enables you to verify, before trying to admit a service, if the
actual network state of the service remains Conformant.
Admitting Services to DB Enables you to admit services which are Inconsistent,
Incomplete, or have not been admitted before, to the LightSoft
DB.
Deleting Services from DB Enables you to delete services from the LightSoft DB (the service
in the network is unchanged).
Imposing Services on the Network Enables you to impose on the network the service structure
configured via LightSoft (expected service type).
Deleting a Service Enables you to delete services from the network (the service in
the LightSoft DB is unchanged).
Parent Topic
12.15.2 Checking Network Conformance

A service that was modified in the network (using the EMS) automatically becomes Inconsistent or
Incomplete. Admitting the service in order to resolve this may result in a Non Conformant service. The
Check Network Conformance option enables you to verify, before trying to admit the service, if the actual
network state of the service remains Conformant (LightSoft does not consider EMS changes making the
service illegal).
If the service is found to be Non Conformant, the applicable reasons are shown.
The option is enabled for services in Inconsistent, Incomplete, or Not Admitted states.
To check network conformance of a service:

1. In the Services pane, select the service(s) for which you want to check conformance.
2. Right-click and select Service Operations and then Check Network Conformance. The Check Network
Conformance window opens.

3. Click OK to start the process.
A results window opens with two panes:

 Summary: Shows the number of services found to be Conformant vs. Non Conformant.
 Details: Shows the VPN ID of each Non Conformant service. When an ID is selected, the
corresponding reasons for each associated object of the service are shown.
4. Click Close.
Parent Topic
12.15.3 Admitting Services to DB

You can admit services of the following states to the LightSoft DB:
 Inconsistent: Admits the EMS-modified attributes to the DB.
 Incomplete: Deletes the endpoints/tunnels/VSIs missing in the EMS from the LightSoft DB.
 Not Admitted: Admits the newly created services.
Once admitted, the service state generally changes to OK.

The network change that caused a service to be Inconsistent or Incomplete can be responsible for the
service to fail network-wide validations. In this case, the Admit operation fails; see Service Inconsistency vs.
Non Conformance in Service State in the Supporting Information Supplement. You can optionally force
LightSoft to admit such services by selecting the Admit also if Non Conformant checkbox. In this case, the
service is admitted with the status Non Conformant; see Service Non Conformance Reasons in the
You can verify in advance if the Inconsistent or Incomplete service you want to admit is potentially Non
Conformant; see Checking Network Conformance.
The Admit Service operation is non-traffic-affecting.
To admit a service to the LightSoft database:

1. In the Services pane, select the service(s) you want to admit.
2. Right-click and select Service Operations and then Admit to DB. The Admit Service to DB window
opens.
3. Select the Admit also if Non Conformant checkbox, if needed.

4. Click OK. A successful completion message opens at the end of the process.
5. Click OK.
Parent Topic
12.15.4 Deleting Services from DB

You can delete services from the LightSoft DB. (The service in the network is unchanged.)
Deleting a service from the DB causes the service to become Not Admitted.
This option is enabled for all service states except Not Admitted (service does not exist in DB). It is
non-traffic-affecting.
NOTE: A service with no VSIs in the network is deleted altogether, as if Delete Service was
used.

To delete a service from the LightSoft database:

1. In the Services pane, select the service(s) you want to delete from the LightSoft database.
2. Right-click and select Service Operations and then Delete from DB. The Delete Service from DB
window opens.
3. Click OK to start the process. A successful completion message opens at the end of the process.
4. Click OK.
Parent Topic
12.15.5 Imposing Services on the Network

You can impose the service structure configured via LightSoft (expected service type) on the network.
This option is disabled for a service having one/more endpoints with Advanced configurations; see Working
with Advanced EMS-based Endpoint Configurations. This is because the DB (expected) service structure
does not contain all the information regarding the service endpoints.
This option is enabled for a service in any state. It is always traffic-affecting.
NOTE: A service with Advanced Configuration endpoints that was previously admitted and
subsequently becomes Inconsistent can only be readmitted to LightSoft, not to the EMS. See
Working with Advanced EMS-based Endpoint Configurations.

To impose a service on the network:

1. In the Services pane, select the service(s) you want to admit.
2. Right-click and select Service Operations and then Impose on Network. The Impose on Network
window opens.
4. Click OK.
Parent Topic
12.15.6 Deleting a Service

You can delete services from the network. (The service in the LightSoft DB is unchanged.)
If some VSIs are missing, the service is not deleted. If the service is incomplete because there are no VSIs, it
is deleted.
A Not Admitted service deleted from the network is deleted altogether.
This option is enabled for all service states and is traffic-affecting.
To delete a service from the network:

1. In the Services pane, select the service(s) you want to delete from the network.
2. Right-click and select Service Operations and then Delete from Network. The Delete from Network
window opens.

4. Click OK.
Parent Topic
12.16 Batch Service Operations

This section describes how to perform Create, Edit, and Delete service operations in a batch by exporting
and importing service definitions to/from an XML file. The Export operation enables you to save the data of
selected services in an XML file. The Import operation translates the data stored in the XML file and sends
this information to LightSoft according to the requested operation for each service in the file.
Records in the XML file specify the commands and parameters of actions. Both import and export records
coexist in the same XML file; see Import/Export Traffic Syntax.
LightSoft automatically generates a log file in the directory ~nms/NMSServices documenting the
import/export process. The log file name is the same as the XML file, with extension .log.
keywords, and how to parse the file. If required, the names of the tags in the DTD file can be changed
(contact your local Customer Support representative for details).
You can also export/import service XML files via UNIX, which may include prescheduling using the UNIX
crontab command; see the generic trail, tunnel and service export/import procedure in
Exporting/Importing Traffic Entities via UNIX.
Parent Topic
12.16.1 Exporting Services

This section describes how to export L2 Ethernet service definitions to an XML file for network contingency
planning and design purposes, or backups in case of system failure.
Exported services are automatically implemented in the network by the Import function according to
settings used for export.
Service definitions from the Service List window or in XML file format can be converted to CSV for viewing
in a relational database program; see Exporting Services to CSV.


This is performed in conjunction with changes to services or removal of services:
 Planned changes to an existing service are done via the Edit Service window; see Editing Services. The
services are exported to XML using the Export Services window's Export for Edit mode.
 Planned removal of existing services is done via the Service List window; see Deleting Services. The
services are exported to XML using the Export Services window's Export for Delete mode.
XML until they are needed. When the new network design is ready to be implemented, the planned
services can be imported to LightSoft as part of the active network.

Export services that can be restored if inadvertently deleted or corrupted:
 Deleted services are restored by importing. Select the original services from the Service List or Edit
Service window, and perform the export using the Export Services window's Export for Create mode.
 Corrupted existing services are restored by importing. Select the original services from the Service List
or Edit Service window, and perform the export using the Export Services window's Export for Edit
mode.
NOTE: Limitations apply for Export involving advanced endpoint configurations; see Working
with Advanced EMS-based Endpoint Configurations.
Parent Topic
12.16.1.1 Export Services Procedure

Services can be exported to XML using the Export Trails window. This example shows the window accessed
from the Service List window, including a list of services selected for export.
When accessed from the Create Service or Edit Service window, the list of services is omitted since the
export operation involves only one service.
Figure 12-18: Export Services window

NOTE: XML records are exported in the order in which they are displayed in the Service List
window, and eventually imported in the same order.
To export services to XML:

1. If you are creating an XML file for:
 Backup purposes: In the Service List window, select the service(s); see Performing Service
Operations.
You can also perform this action in the Create Service or Edit Service window on the current
service that has just been activated; see Creating a Service or Editing Services.
 Deleting services: In the Service List window, select the service(s) to be deleted (but do not click
Delete); see Deleting Services.
2. Click Export .
OR
If you are in the Service List window: In the Services pane, right-click a service and select Service
Utilities and then Export Services. The Export Services window opens.
3. In the Files pane, select an existing file name, or enter a name in the File Name field.
*, ?, !, |, \, /, ', ", {, },<, >, ;, <comma>, ^, (, ), $, ~, #, @, <space>, +, =, &
4. If the file already exists, two fields are enabled:

 To overwrite the existing file, select Overwrite file.
OR
 To add the services to the existing file, select Append to file (preserving its previous contents).
5. Select the Batch Operation to be applied on all the services to be exported:
 Backup purposes or Create to be applied at a future time: Select Create.
 Editing to be applied at a future time: Select Edit.
 Delete to be applied at a future time: Select Delete.
6. Click Export. The service definitions are saved as an XML file.
Clicking Abort at any time causes the operation to stop after the current service. An Exporting Failed
message opens. An export file is produced, containing definitions of the services that completed
processing up to that point.
Parent Topic

12.16.1.2 Exporting Services to CSV

You can export Service List window data to a delimited-format CSV file for subsequent import to Microsoft
Excel or a relational database application. LightSoft also enables you to export services in XML files to CSV
using a command line application.
To export services to CSV:

 See the generic procedure in Exporting List Data to CSV.

Parent Topic
12.16.2 Importing Services

This section describes L2 Ethernet service definition import from XML using LightSoft menu options. (You
can also import service XML files via UNIX; see Exporting/Importing Traffic Entities via UNIX.)
NOTES:
 Before importing services, ensure that all the required endpoints and resources are free
and available. If any are occupied, the Complete action, which is performed automatically
by the import, will fail.
details, see the note in Exporting Services.

To import service definitions from XML files via LightSoft:

1. In the main window Services tab, in the Utilities group, click Import Services. The Import Services
window opens.

3. (Optional) In the Import Options box, check Preserve original VC labels if you would like LightSoft to
preserve the original VC labels in the import XML file. This is important if the network is integrated
with third-party equipment configured for those specific label values. Otherwise, LightSoft assigns VC
labels as needed.
 Only check that the file format is valid: Checks the XML file structure validity for service import.
 Only check that the services in the file can be completed successfully: Checks file syntax and
verifies that service creation is feasible in accordance with network rules, availability of
resources, and so on. This action is similar to Complete in the Create Service procedure.
 Create, Edit, or Delete the services in the file: Checks syntax, finds a path, and either creates,
edits, or deletes the specified services in the network. The choice of action is determined
individually for each service listed in the file. For example, users may append a service creation
request to a file containing a list of services for deletion. Service mode is set at the time of
export.
Note that service creation here is similar to Activate in the Create Service procedure. Service
editing is similar to Activate in the Edit Service procedure. Service deletion is similar to the same
actions when accessed via the Service List window.

5. Click Import. Each service object in the XML file is executed (sequentially) according to the selection
option and corresponding services are reflected in the Service List window.
 If Create/Edit/Delete was selected, the file is imported and the services in it are created, edited,
or deleted from the database and network, as relevant.
 For Check file format or Check service integrity, checks the XML file structure validity or verifies
that service creation is feasible, as relevant.
The Status pane shows the total number of services processed and the number that processed successfully
or failed.
Clicking Abort at any time causes the operation to stop after the current service is processed. An Importing
Failed message opens. The services that completed processing up to that point will be imported.
Parent Topic

13 Provisioning Optical Trails
This section describes how to create and manage optical trails using various methodologies.
LightSoft supports optical trails in a multi-layer hierarchy:
 Optical Multiplex Section (OMS) trails
 Optical Channel (OCH) trails
 Optical Data Unit (ODU) trails
 LightPath (LP) trails
 EoS trails that traverse the optical layer
Optical trails are usually created and managed in the optical topology layer, as explained in Topology Layers
in the Getting Started & Administration Guide. The OCH layer provides a filtered view of the optical layer
showing logical OCH connections. This view can be useful when building traffic in the OTN, since the display
of virtual OCH links makes it easier to provision the corresponding ODU and unified LP-ODUk trails.
See Optical Trails for descriptions of the optical trail types. Note that the configuration capabilities available
depend on the underlying equipment. LightSoft enables only those features, capabilities, and options
relevant for the current equipment. For example:
 Some trail features are only available when working with cards optimized for Apollo OMLT platform
capabilities.
 Some features are not relevant for networks combining both XDM/NPT and Apollo platforms.
 Some types of protection are only available for certain cards or modules, such as ROADM cards.
 Different types of trails require different types of ports; LightSoft only enables user-selection of
appropriate ports.
 Service interworking between XDM/NPT and Apollo equipment may require installation of specific
cards, such as specific types of AoC, transponder, or combiner cards.
For specific network configuration questions, contact your local Customer Support representative.
NOTE: You can configure the default settings for optical trail configuration and behavior. See
Optical Trail Preferences in the Getting Started & Administration Guide.
13.1 Optical Concepts and Background Information

The following sections provide some key optical trail concepts; other concepts are explained in context:
 Optical Devices, Links, and Ports
 Optical Trails
 Optical Trail Protection
 Channels
 Alarms Master Mask (AMM)
Parent Topic

LightSoft® User Guide Provisioning Optical Trails
13.1.1 Optical Devices, Links, and Ports

The following figure illustrates typical optical elements and the corresponding pattern of optical trails.
Figure 13-1: Optical network example: typical elements and trails
The devices are connected by fiber of varying length – ranging from a few meters within a site, to tens or
even hundreds of kilometers between sites. In the previous graphic, fibers are denoted by a loop
. In this example, OCH trail traverses from end-to-end, running through the regenerator “R”. No
separate ODU trail is provisioned.
Client equipment at the network edge

The client equipment may consist of managed data and SDH ports, but in this example they are
represented by Unmanaged Elements (UMEs), indicated by "U" in the diagram. UMEs may be any
elements, such as transponders or OADMs, located anywhere in the network topology, but the term usually
describes customer terminals.
If the endpoint is on a line card without connected client equipment, individual trail provisioning cannot be
performed using the Create Trail window. In this case use the procedures described in Creating Optical
Trails Through Discovery or Optical Trail Acquisition by Synchronization.
Line cards
Any type of line card can be represented in the diagram by "L". Line cards are also grouped into the
following categories:
 Transponder ("T") - transmits the signal over a specific channel.
 Combiner ("C") - combines multiple input signals into a higher bitrate, aggregates different clients into
a specific optical channel, and transmits the signal over that channel; see Combiners in Optical
Networks.
 AoC cards are multiprotocol ADM on a Card modules supporting 10 Gbps Add/Drop Multiplexer (ADM)
service on a double card with up to 16 client ports with GbE, FC1G, FC2G, OTU1, and STM-16 services;
see AoC Card Topology.

Regenerator
A regenerator ("R) is a transponder used in a regeneration site to regenerate an optical channel through
optical 3-R regeneration. With older regenerators, the OCH trail traverses the regenerator and forms a
single end-to-end trail in the regenerator ports, as illustrated in the following diagram.
Figure 13-2: Regenerators in optical networks
Newer model regenerators generally terminate the OCH trail, forming multiple OCH trails in tandem, with
the corresponding ODU trail traversing the regenerator.
Fabric cards
Fabric cards, such as the FIOMR_16, FIO10_5, FIO40, and FIO100, provide ODU connectivity with both OTUk
and non-OTU client ports.
Multiplexing devices
 Terminal multiplexers/demultiplexers ("M" and "D" in the diagram).
 Optical Fixed Add/Drop Multiplexers (OADM) and Reconfigurable OADMs (ROADM).
Amplifiers
"A" in the diagram, including:
 According to network position:
 Boosters - in close proximity to a Mux.
 Pre-amplifiers - in close proximity to a DeMux.
 Inline amplifiers - for distance amplification, either standalone sites, or in close proximity to an
OADM. (Inline amplifiers cannot be used in conjunction with a ROADM. Similarly to a Mux or
DeMux, a ROADM is only used in conjunction with a pre-amplifier or booster).
 According to technology:
 Single amplifiers (a single gain block).
 Dual amplifiers, with two gain blocks acting independently of each other. Dual amplifier cards
include, for example, OFA_2, OFA_M, MO_OFA_PHBC, and MO_OFA_HBC.
 Dual-stage amplifiers with two gain blocks acting in tandem, and including a mid-stage
Dispersion Compensation Fiber (DCF). A DCF uses a negative dispersion index to compensate for
dispersion along the fiber. The OFA_M is a dual-stage amplifier.

Management Traffic Channels

C Band Optical Supervisory Channels (COSC) cards, OSC cards, C/T filters, and some types of amplifiers
enable transfer of management information via an outband signal between sites in the optical network. In
OMLT platforms, these should be connected using topology links. System management network control
entities can be viewed and managed through the Control Map; see Viewing and Managing Network Control
Entities in the Performance Monitoring Guide.
Optical Performance Monitor (OPM)

OPM is a monitoring tool placed next to a card (such as a Mux or OFA) that can be used to monitor ports of
various other cards. It is best configured in LightSoft as an LE together with the monitored card. It is not
part of the trail, but should be associated with the group. Double-clicking the icon opens the OPM
mechanism.
Links and ports

LightSoft optics uses the following main categories of links and ports:
 OTM links between OTS ports.
 OPS1 or OTU links between TRPs/CMBRs, multiplexing devices, and fabric cards.
 Physical links connecting the clients (for example, UMEs and SIOs) to transponders, combiners, fabric
cards, and similar cards.
 Virtual links, the link representation of trails in an underlying technology layer, such as SDH virtual
links resulting from an LP trail in the optical technology layer. For example, when a trail connects two
SDH cards to an optical network, the LP is represented in the SDH layer as a virtual link between the
two SDH ports.
NOTE: OTM links in LightSoft are indicated as OTS links at the EMS level.
Parent Topic
13.1.2 Types of Ports and Interfaces

OTN technology offers a range of rates up to 100 Gbps. OTN interfaces are supported by our equipment
through the following types of ports:
 Optical Transmission Section (OTS) ports for equipment with more than one wavelength supporting
OMS and OCH interfaces. Used, for example, in amplifiers or DCF cards, or in OADM or Mux/DeMux
cards for channelization purposes.
 Optical Channel ports (OCHP), for single-wavelength OCH interfaces.
 Optical Transport Unit (OTU) ports, for port rates ranging from OTU1 to OTU4, for comparable ODUk
interfaces ranging from ODU1 to ODU4. Also supported are the overclocked ODU2e, ODU2f, and
ODU3e rates. OTUs are used, for example, in OTU2 ports in TR10_4 cards, or for ODU interfaces
multiplexed to an OTUk port in an AoC10 or FIO10_5 card. Also used for our proprietary ODU0s
interface for ports with interface rates under 2.5G, and in OTU2x for interoperability with the XDM
AoC.

This section describes the different types of optical port and interface technology supported by LightSoft,
explaining the relationship between them.
Client rates include non OTN rates. The table includes a mapping of client rates (for example FC-4G,
HD-SDI-3G, and STM-64 port rates) to the relevant ODU interfaces. Port mapping is a conversion of these
client port rates to OTN rates.
Table 13-1: Port and interface terminology
Port types Interfaces

OTN High Order interfaces Low Order interfaces
(for multiplexing)
OCHP OCH ---
OTU1 (~2.5 Gbps) ODU1 2 x ODUslot or 2x ODU0
OTU2 (~10 Gbps) ODU2 Combinations totaling 10 Gbps, including up to:
 4 x ODU1;
 2x ODUF-FC400;
 2x ODUF-SDI3G;
 8x ODU0;
or a combination of these rates, that does not

exceed a total bandwidth of ODU2 bandwidth.
OTU2e (~10 Gbps) ODU2e ---
OTU2f (~10 Gbps) ODU2f ---
OTU2x (~10 Gbps) ODU2 Combinations totaling 10 Gbps, including up to

8 x SPO (when configured for XDM/NPT equipment).
OTU3e (~40 Gbps) ODU3e Any combinations totaling up to 40 Gbps, including:
 up to 4 x ODU2; or
 up to 4 x ODU2e; or
 up to 16 x ODU1
OTU4 (~100 Gbps) ODU4 Any combinations totaling up to 100Gbps, including:
 up to 10 x ODU2e; or
 up to 10 x ODUF-FC800; or
 up to 80 x ODU0
or a combination of these rates that does not

exceed a total bandwidth of ODU4.
Fiber Channel (FC)
FC-1G ODU0, ODU0s
FC-2G ODU1
FC-4G 2 x ODU1, ODUF-FC400

Port types Interfaces

FC-8G ODU2, ODUF-FC800
FC-10G ODU2f
Video
Video-270 ODU0, ODU0s
(270 Mbps)
HDSDI-1485 ODU1
(1.485 Gbps)
HD-SDI-3G ODUF-SDI3G
(3 Gbps)
SDH/SONET
STM-1/1e ODU0, ODU0s
OC-3/3e
STM-4 ODU0, ODU0s
OC-12
STM-16 ODU1
OC-48
STM-64 ODU2
OC-192
Layer 1
ETY1G/ETY1Ge ODU0, ODU0s
ETY1Gx  ODU0, ODU0s
OR
 SPO
(when configured for XDM/NPT equipment)
ETY10G ODU2
ETY10Goc ODU2e
Layer 2
GbE GbE
10 GbE 10 GbE
100 GbE 100 GbE
NOTE: ODUs is a proprietary rate.
Parent Topic

13.1.3 Optical Trails

In a typical optical network, components are configured into a hierarchy of OMS, OCH, ODU, and LP trails,
as illustrated in the following figure.
Figure 13-3: Hierarchy of optical trails
The Private ID attribute may be used to associate two more trails as a single service; see Trail Creation
Options.
LightSoft supports Optical Multiplex Section (OMS) trails, optical trails between multiplexing devices (MDs).
They can be uni- or bidirectional. They behave as server trails that carry multiple OCH trails in fixed groups -
typically DWDM - 16, 32, 40, 44, 80, or 88 channels, and CWDM - 4 or 8 channels. Amplifiers may be
included in the path of an OMS trail. Multiple OMSs, connected in tandem, cause alarms to be reported
only with respect to the directly associated OMS trail segments and not at other segments along the path.
Optical impairments that may affect OCH trail quality

Optical signal quality may be affected by a number of physical factors. Typical optical considerations
include:
 Optical Signal to Noise Ratio (OSNR): The power ratio between a signal transmitting meaningful
information and the unwanted background noise. The ratio of signal-to-noise must be kept high
enough to send meaningful optical signals over long distances.
 Dispersion: The "spreading" of a light pulse as it travels out from the source. Different signal
components travel at different velocities. The longer the distance traveled, the wider the "spread".
Equipment must compensate for dispersion to be able to send high data rates accurately over long
distances.
 Polarization Mode Dispersion (PMD): Optical signals within a fiber include two different light
polarizations. These move at different speeds due to asymmetries and stresses within the fiber,
including external forces and internal obstacles, creating another source of dispersion. The PMD must
be compensated in order to send high data rates over long distances.
Our optical equipment supports a set of optical network control parameters (ONCP) that enable proper
gain and power equalization settings along the optical network, managed through the control plane. ONCP
is used to monitor signal quality through a series of optical performance parameters and enable automatic
power control. The PathFinder tool utilizes ONCP data, taking optical impairment parameters into account
when provisioning OCH trail paths.
Parent Topic

13.1.3.1 Optical Channel (OCH) Trails

Optical Channel (OCH) trails
OCH trails are client trails of an OMS trail, utilizing the channels of the OMS trail. An OCH trail carries the LP
or ODU client input signal trails, one or more LPs or ODUs/ODU0 per OCH trail. For example, combiner
cards receive and combine multiple client signals (typically SDH or GbE) into a 2.5G, 10G, 40G or 100G
aggregate that can traverse one channel.
In general, both ends of an OCH trail terminate in a transceiver (transmitter/receiver) at the network edge.
In cases where a transponder is connected as regenerator between a pair of MDs (two OADMs and/or
Mux/DeMux), the OCH trail terminates in the regenerator, entering it on one trail segment and leaving on
another. For older cards, the OCH trail traverses the regenerator.
Parent Topic
13.1.3.2 ODU Trails

ODU trails
ODU trails are end-to-end optical trails that represent the ODU layer signal. An ODU trail may act as a
server to one or more LP trails or multiple lower-order ODU trails, or a combination of LP and ODU trails.
LightSoft V8 supports a wide range of ODU rates, where the specific available ODU rates depend on the
trails and the underlying equipment capabilities. For example, ODU0s and ODU1-2v rates are only available
as part of unified LP-ODUk trails, as explained at the end of this section. The following table explains the
relationship between different types of trails and the ODU and link resources they utilize.
From LightSoft v10, a new type of ODU multiplexing and 1.25Gb/s granularity are supported (see ODU
Multiplexing and Granularity in ODU and LP/ODU Unified Trails).
Table 13-2: Trails and their resources
Trail rate Potential server

(link or trail)
ODU0 (LP-ODUk)  ODU1
 ODU2
 ODU4
ODU0s (LP-ODUk)  ODU1
ODU1  OCH
 ODU3e
 ODU2/2e
 ODU2
 ODU4
ODU1-2v (LP-ODUk)  ODU3e
 ODU2/2e
 ODU2
ODUF-SDI3G (LP-ODUk)  ODU2

Trail rate Potential server

(link or trail)
ODUF-FC400 (LP-ODUk)  ODU2
ODUF-FC800 (LP-ODUk)  ODU3e
 ODU4
ODU2  OCH
 ODU4
 ODU3e
ODU2e  OCH
 ODU4
 ODU3e
ODU2/2e  OCH
 ODU4
 ODU3e
ODU3  OCH
ODU4  OCH
ODUk  OCH
 ODUn
In general:
 An ODUk trail must have a higher-order ODUn trail or an OCH trail configured as its server trail, as
listed in the preceding table. An ODUk trail cannot have an OMS trail or link as a direct server.
 All ODUk trails (except for trail types that are only used when they are included in LP-ODUk aggregate
trails, such as ODU0s and ODU1-2v) can use an OCH trail as a direct server, meaning no other ODUk
trail is configured in between.
 The endpoints of an ODUk trail must be on OTUn ports, where the rate of the port is equal to or
greater than the rate of the ODUk trail. For example, ODU2e trails can terminate in OTU2e or OTU3e
ports.
 ODU trails do not always have to be configured separately. Often an ODU trail is incorporated within
an OCH or LP trail. However, certain types of equipment or network configurations require the user to
configure ODU trails separately. For example, to provision multiple lower-order ODU or LP trails
multiplexed over an OCH trail, the network operator must provision a HO ODU trail to act as a server
for the lower-order trails. For example, the HO ODU trail must be configured with the same rate as the
OCH endpoints, such as OTU3 for CMR40 cards.
The OTN hierarchy does not require a strict set of intermediate layers. For example, an ODU1 trail can be a
direct client of an ODU3e trail. An ODU1 trail can also be a second level client, such as when the ODU1 trail
is a client of an ODU2 trail which in turn is a client of an ODU3 trail.
LightSoft implements these guidelines internally, offering network operators only the appropriate trail, link,
and endpoint port options. Note that where there is only a single option available, LightSoft selects and
configures it automatically, without requiring an additional selection step by the user. See Provisioning
ODU Trails.

Some cards require provisioning of specific types of server trails before provisioning services that traverse
or terminate on those cards, as described in the following table.
Table 13-3: Server trails required per card type
Card type Required server trail

AoC10 ODU2 server trail
CMR40 ODU3e server trail
FIO10_5 ODU2 server trail
with ODU1 client
FIO40 ODU3e server trail
AoC10, ODU1 server trail
AoC25,
FIO10_5,
FIO40,
FIOMR_16
with LP of LO (ODU0s/ODU0) trail
CMR100, FIO100 ODU4 server trail
Parent Topic
13.1.3.3 LP Trails
LP trails are end-to-end optical trails representing the client input signal. LP trails typically traverse from
UME to UME - end to end, irrespective of any regenerators in their paths. If not connected to client
equipment, (i.e., connected to UMEs), the LP trail terminates in the client port of the transponder,
combiner, or fabric card. See Optical Trail Creation Options.
LightSoft differentiates between types of LP trails through the payload parameter, for example, STM-n for
SDH clients, GbE for GbE clients, and FC-nG for FC clients. The same LP trail may be the client of multiple
OCH trails. LP trails can also use some types of links directly.
Parent Topic
13.1.3.4 Unified LP-ODU or OCH-ODU trails

Some equipment supports unified LP-ODUk trails, which are aggregates of LP trails with ODU components.
This involves mapping the rate of the client signal to the relevant ODUk interface. Unified LP-ODUk trails
are represented in LightSoft as standard LP trails. In other configurations, the ODU trails are incorporated
into the corresponding OCH trail layer. These trails are represented in the LightSoft GUI as standard OCH
trails.

To see the ODU components included in an LP or OCH trail, open the Trails List window and select the LP or
OCH trail of interest. If the trail includes an ODU component, the ODU element is listed in the ODU
Components attribute for that trail. You may also select a trail in the list, right click on that trail, and select
the Show ODU Components menu option.
It is possible to have a LP trail, with same client input signal with different ODU components, because of the
underlying equipment.
In LightSoft v10 and higher, the following new ODU interfaces are provided:
 ODU0
 ODUF-FC400
 ODUF-FC800
 ODUF-SDI3G
Client rates include non OTN rates (for example FC-4G, HD-SDI-3G, and STM-64 port rates). Port mapping is
a conversion of these client port rates to OTN rates.
Additional port mapping options introduced in LightSoft v10, provide greater efficiency of resource usage.
For example FC-8G can be mapped to ODU2 signal, which allocates 8 tributary slots, ODUF-FC800 new
interface requires only 7 tributary slots.
From LightSoft v10, a new type of ODU multiplexing and a granularity of 1.25Gbps are supported (see ODU
Multiplexing and Granularity in ODU and LP/ODU Unified Trails).
Parent Topic
13.1.3.5 ODU Multiplexing and Granularity in ODU and LP/ODU Unified

Trails
From LightSoft v10 and above, ODU trails and LP/ODU unified trails support a new type of ODU
multiplexing that includes the following benefits:
 Supports a lower granularity of 1.25Gbps (equivalent to a rate of ODU0).
 Supports a flat ODU hierarchy, that enables various ODUk resources of client trails to be multiplexed
directly into any higher order ODU server trail (for example, an ODU0, ODU1, and ODU2 resources can
be multiplexed directly into an ODU4 trail).
 Flexible resource allocation: if the capacity exists, client trails can use any ODU tributary slot in the
resource map, regardless of its location. (The resource map provides a representation of all of the
tributary slots available for the selected rate. A single tributary slot represents the minimum unit of
the ODU signal. For example, an ODU4 rate contains 80 tributary slots.)
 High order ODU trails can include ODUk trails of various rates. Therefore, ODU client trail rates that sit
on a single higher order ODU server trail do not need to be of a single, uniform type.
Parent Topic

13.1.3.6 High Order Trails

HO trails include SDH or EoS - Data over WDM trails. For certain types of data combiners, such as the
CMBR25_2, the client traffic is categorized as SDH or EoS - Data over WDM trails (due to the SDH fabric of
CMBR cards). The payload type of the trail indicates the specific value "ETH over WDM".
These trails are acquired through trail synchronization or Discovery. In the Trail Consistency Indicator
window, specify HO SDH as the trail rate that you want to acquire. The trail filtering mechanism includes a
Data over WDM trail filter.
Parent Topic
13.1.3.7 Optical trail implementation Examples

LightSoft-managed networks may include many different types of platforms, cards, and other equipment,
providing a wide range of capabilities. Not all hardware is capable of implementing all features, for
example, OMLT platforms offer a wider range of optical capabilities than Packet-OTS platforms. Most of
these differences are handled internally by LightSoft, which enables only options and fields appropriate for
the underlying hardware configuration. A typical difference is seen in the following optical network figures,
illustrating representative elements and patterns of optical trails.
In the first example, the OCH trail breaks in the middle at the line or regenerator cards. In this figure
LightSoft distinguishes between the ODU and LP trails, enabling the user to configure specific rates and
hierarchies. This equipment could also be used to provision multiple ODU layers, or a single unified LP-ODU
trail.
Figure 13-4: Optical network example: four distinct trail layers

In the second example, LightSoft incorporates the ODU trail into the LP trail, configuring a unified LP-ODUk
aggregate trail. The user is not able to configure specific ODU rates.
Figure 13-5: Optical network example: LP trail incorporating ODU trail
Parent Topic
13.1.4 Channels
Dense Wavelength Division Multiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM)
technologies, supported by LightSoft optics, describe the carriers over which optical signals are transmitted.
DWDM uses a grid of 40, 44, 80, or 88 frequencies from 191.70 THz to 196.05 THz. CWDM uses a grid of
four or eight channels denominated in wavelengths, from 1471 nm to 1611 nm. For detailed information re
frequency, wavelength, and channel spacing, see Channel Frequencies and Wavelengths.
In this manual, we refer to the wavelength or frequency carriers using the more generic term channels
(terms such as channel frequency or tuned frequency are avoided). Channels as defined here should not be
confused with OCH trails, which are also sometimes referred to in the literature as channels. In this manual
we refer to such trails as OCH trails.
For more information about optical channels, see Optical Trail Parameters.
Parent Topic
13.1.5 Alarms Master Mask (AMM)

When optical cards wake up following assignment, alarm monitoring and severity is as defined by default.
You can change the severity profile and have a different set of alarms reported or not reported. The AMM
mechanism controls alarm reporting for an object.
If the user selects Apply, then upon trail creation, LightSoft sets the AMM to ON for all the objects
encapsulated within the port that holds the trail endpoints with reported alarms. (AMM to OMS trails
include the OTS objects in which the OMS endpoints are encapsulated.) Upon trail deletion, the AMM no
longer monitors and reports alarms.
If the user selects Do Not Change, alarms are not reported. Users can go to the Edit Trails window to
change the settings.
Parent Topic

13.1.6 Optical Trail Protection

Optical trails can be configured with the following protection options:
 Underlying: Trail is protected due to protection that has been configured for the layer it traverses. For
example, if you are working with a protected OCH trail, then any LP or ODU trail using that OCH trail
enjoys underlying protection.
 Current and Underlying: Trail is protected both on current and underlying layers.
For multiroute OCH trails, the regular optical trail protections are replaced by multiroute equivalents. These
have the same meaning as their corresponding regular protections, but with the addition of multiroute
protection; see Optical Trail Parameters.
For ASON trails, see ASON Optical Trail Protection.
Parent Topic
13.1.6.1 Protection Quality

Protection quality is reported in the Trails pane; see the parameter description in Trails Pane Columns. The
value for optical trails varies according to the applicable protection and circumstances, as described in the
following table.
Table 13-4: Trail protection quality
Protection layer Trail protection quality

Undefined Unprotected.
Current Full if no segments (excluding DRI bridge’s segments) and SNCs (excluding
EPs, DNIs, and DRI bridges) are shared.
Shared Resources if some of the segments or SNCs are shared.
Underlying Full always if the physical link is protected. Server Trail Path Protection
Quality is its path protection quality.
Full if all owners of segments (excluding DRI bridge’s segments) have
protection quality Full.
Shared Resources if some owners of the segments have protection quality
less than Full.
Current & Underlying Partial if some SNCs are shared.
Partial if some shared segments (excluding DRI bridge’s segments) are not
Fully Underlying protected.
Otherwise Protection quality is Full.

NOTE: When working with multiroute OCH trails, trail protection quality is configured as
follows:
 Partial if all routes have a single point of failure (a link) in any of the two directions.
 Full if the two primary routes partially overlap but another route does not traverse this
overlap segment.
Parent Topic
13.1.6.2 ASON Optical Trail Protection

ASON Protection can be implemented for ODUk or LP trails over OCH server trails that that are designated
as ASON data links and ODU server trails using the corresponding ports. OCH trails designated as ASON data
links are indicated in the map with an 'A' ( ).
ASON provides much flexibility, enabling you to provide a range of differentiated services per trail. It
provides up to three protection levels, in addition to existing SNCP protection, including:
 1++ (Gold): Provides <50ms SNCP-based restoration. Creates a Protected (ODU or LP) 1++ Bidirectional
trail for high priority services. In the event of a problem on the main path, traffic is switched to the
protection path within 50 msec. During restoration, an additional restoration path is also created, to
provide a restoration option for any subsequent problem that could occur on the same path. Sub-50
msec restoration times are maintained "forever" for any number of failures, as long as valid
restoration paths are available.
This protection scheme is an extension of the traditional 1+1 path protection, with failure in the main
or protection path resulting in restoration of the failed path. 1++ protection has the advantage of
providing recovery from multiple consecutive failures. In the event of a failure, 1++ restores the failed
path via the control plane and builds a new protection trail, thereby remaining ready to deal with any
subsequent failures.
This option exceeds 'five nines', providing high service availability, with no service downtime. ASON
continuously builds a new protection trail after each fiber cut. This protection scheme is the most
bandwidth consuming, since traffic is duplicated at all times.
 1+1+R (Silver): first cut is <50ms SNCP-based restoration. ASON does restore the path after the first
cut. Any subsequent fiber cuts are restored within a few seconds. This option is less bandwidth
consuming than 1++, providing additional protection while allowing for efficient use of network
resources.
 1+R (Bronze): 1+R (Bronze) protection creates an unprotected 1+R bidirectional trail. In the event of a
problem on the main path, the system finds an alternative path using existing free resources. There is
no SNCP switching and traffic is restored dynamically within a few seconds.
Recovery paths are protected in the same way as the main path. New recovery paths can be
implemented as long as additional paths satisfying current criteria can be found. 1+R is also known as
reroute restoration.
1+R is an improvement over the corresponding unprotected option of regular SDH in that service is
restored dynamically on an alternate path within seconds, without operator intervention. Typically,
traffic is restored within one to two seconds. In more complex restoration topologies that contain a
large number of ASON nodes, restoration time can reach up to four seconds maximum.
All ASON CoS can be used in conjunction with underlying protection (for example, multiroute OCH trail).

NOTE: Non-ASONtrails can exist on an ASON network, even if they have non-ASON protection
e.g. 1+1 protection (current layer) standard SNCP protection.
Parent Topic
13.1.6.2.1 ASON Optical Trail Requirements

The following conditions must be considered when creating an ASON trail:
 For an ASON protected trail, ensure that only OMLT equipment is used.
 An ASON trail must include at least one ASON component. It can also include non-ASON components.
 ASON trails must be bidirectional, and a path must use the same resources in both forward and
backward directions.
 Only an OCH trail designated as an ASON data link can be used as an ASON server trail.
 Only LP and ODUk ASON trails with Payload Types 20 and 21 can be created.
 The ASON portion of a trail can only use OCH server trails that are designated as ASON data links.
 ASON protection is not supported on trails with DNI or DRI protection.
 Editing an existing non ASON trail so that it becomes an ASON-protected trail may be traffic affecting.
 For FIO100 cards, a non-ASON ODU4 server trail must be created using the same ports as those of the
corresponding OCH server trail. For FIO10_5/10_5B cards, a non-ASON ODU2 server trail should be
created.
WARNING: You can edit an existing OCH trail to become OCH and Data link (ASON link). This
action may be traffic affecting.
To create ASON protected ODU trail:

1. Create an OCH server trail and designate it as an ASON data link (see Provisioning OCH Trails).
2. Create a non-ASON ODU trail using the same ports as were used when creating the OCH server trail
(see Provisioning ODU Trails).
3. Create the relevant ODU or LP trail, as an ASON-protected trail.
Parent Topic

13.1.6.2.2 In the Event of a Failure

In the event of a failure, the ASON Path State for the provisioned trail changes to Rerouted. This indicates
that the trail has been a rerouted due to a link failure. The trail to which the path is rerouted is shown as a
dashed line on the LightSoft map.
For 1++ and 1+1+R protected paths: When calculating a new restoration path, the ASON control plane takes
into consideration the SRLGs of the main and protection paths, as follows:
 If the main path fails, the newly calculated restoration path should not have the same SRLGs as the
protection path (unless no other option exists). However if the main path fails, the restoration path
can use a link that has the same SRLG as the main path.
 If the protection path fails, the restoration path should not have the same SRLGs as the main path
(unless no other option exists).
To view ASON protected trails, and the current active path:

1. In the OCH layer, click Trails and then Trail List. The Trails List window opens.
2. Expand the Resource tree to view the provisioned resources and the current restoration (active) route
for the main and protection paths.
3. To view the active route, click (Show Active Route).
Parent Topic

Examples
 For 1++ (Gold):
By default, the main and protection paths are provisioned.
In event of a failure:
If the Main path fails, there is a switch to the Protection path (<50ms) and an alternative restoration
path is also created (for the Main path). The Protection path becomes the active path and the new
restoration path is shown as a dotted line in the LightSoft map.

If the active protection path fails, there is a switch to the restoration main path (<50ms) and a new
alternative restoration path is created immediately (for the Protection path).
This process continues as long as the necessary resources exist are available, or until the original main
path is restored.
To view the active path, click (Show Active Route). The active route is highlighted in dark blue.
To view details of all paths, open the Trail List window.
 For1+1+R (Silver) trails:
If the main path fails, there is a switch to the protection path (<50ms). If the protection path also fails,
at the time of failure, the control plane calculates an alternative restoration path and then performs
the switch.
 1+R:
An 1+R protection has only a main path. In the event of a failure of the main path, at the time of
failure, the control plane calculates an alternative restoration path and then performs the switch.
Parent Topic
13.1.6.2.2 In the Event of a Failure
13.1.6.3 Defining a Relationship between Ports or Cards

The following types of relationships between ports or cards facilitate protection or bidirectional
recognition:
 Bidirectional Paired Ports
 Protection Group Object (PGO)
Parent Topic

13.1.6.3.1 Bidirectional Paired Ports

A pair of unidirectional ports on the same card very often behave with certain bidirectional properties. A
relational pointer between them describes this relationship for the management. One port serves as the
source (Src) and one port serves as the destination (Snk), allowing them to behave in the NMS as a single
bidirectional port. When Discover Optical Trails or TCI are used to create trails, all ports with a relational
pointer on at least one end of the trail are treated as bidirectional. This association enables you to create a
bidirectional trail by selecting only a single port - the other port is automatically located by the PathFinder.
This feature is present through hard-coded modeling in the card and requires no user intervention. The
NMS allows users to disable this pairing and instead configure two independent unidirectional ports.
Behavior can be configured through the relevant optical port properties; see Optics Tab.
NOTES:
 In AoC10 and FIOMR_16 cards, service ports of up to 1.25G capacity must be paired in
order to enable co-routing of two such services (mapped into ODU0s) within a single
ODU1 server trail. Pairs are defined for the following port types:
 STM-1
 STM-1e
 STM-4
 FC100
 ETY1G
 ETY1Ge
 ETY1Gx
 ETY1Gxe
 VIDEO270
 The same pairing feature can be applied in other cases where pairs of ports are linked
together. This enables easier connectivity and routing calculations when provisioning the
trail. For example:
 In OLP_S2 and OMSP cards, LSNExt_SnkSrcPartner of each Path-A port points to the
respective Path-B port, and vice versa.
 In TR10_4 cards, LSNExt_SnkSrcPartner in each line port points the other line port.
Parent Topic
13.1.6.3.2 Protection Group Object (PGO)

Current protection for OCH trails is derived automatically if the line ports from the transponders are
associated by a protection group object (PGO, also known as an optical protection group) created in the
EMS. The OCH trail is created as protected OCH with main and protection paths.
In order to achieve an LP trail protection configuration, line card ports such as TRP or CMBR must be
installed in pairs. For example, two TRP cards (main and standby), using splitter and coupler accessories,
convey the same information from the network to the same client port along two different paths, with the
standby card transmitting in place of the main in the case of a breakdown.

For this functionality to operate, you must associate the two cards or ports at the EMS level. Configuring an
association between the two objects creates a PGO. If splitters and couplers are connected but this
configuration is not performed at one or both ends, the PGO relationship is not present in the cards and the
trail will be invalid.
For revertive mode PGs (traffic reverting to original port when problem is resolved), when IOP is configured
at the EMS and main and backup ports are determined, subsequent LightSoft top-down trail creation
ensures that the trail is not created if the PG of the revertive groups is not consistent on both sides; see
OCH Input Output Protection (IOP).
NOTE: OCH trails preexisting from LightSoft releases prior to V8 are independent, even if a
PGO is present. Those trails retain their old style, where only the LP is protected and the OCH
trail is not currently protected. To achieve OCH protection, those trails can be deleted and
recreated (from the LightSoft database, to avoid affecting traffic).
PGOs are typically configured through one of two different implementation options, depending on the
underlying equipment: XDM/NPT mode and Apollo mode. In Apollo equipment, the PGO is towards the
client side, while in XDM/NPT equipment, the PGO is towards the network side.
The following figures illustrate PGOs configured with XDM/NPT and Apollo equipment.
Figure 13-6: PGO-related line ports (XDM/NPT equipment)

Figure 13-7: PGO LP-protection (Apollo equipment)
Parent Topic
13.1.6.4 OMS Trail Protection

When an OMS trail connects a ROADM to the OMS Core, an OMSP or OLP card placed in between can act
as an optical switch, providing protection to the OMS trail (and OCH trails traversing it). OMS trails can be
unprotected or protected. Different types of protection are available, depending on the platform type.
Unprotected OMS trail

This diagram shows a simple unidirectional OMS trail.
Figure 13-8: Simple unidirectional OMS trail
Protected OMS trails for NPT/XDM equipment

OMS trail protection is derived from the network according to the presence of Optical Multiplex Section
Protection (OMSP) cards and their Protection groups, and/or the state of the underlying links (you can set
them to externally protected).

The following cases, typical of XDM and NPT equipment configurations, illustrate MSP 1+1 configurations,
called OMS Section Protection (OMSP), where the OMS trail (spanning from Mux to DeMux) is considered
"partially" protected. It is not fully protected because short fiber segments between MD and OMP cards are
unprotected. Only the in-line distance span between two OMSP cards is protected.
Figure 13-9: Partially protected OMS by presence of OMSP
An alternative protection option is for an OMS trail to be protected by underlying links. In this case one or
more links used by the OMS trail are specified as being external protected topology links. The resulting
OMS trail is then called an OMS trail with underlying protection.
Figure 13-10: Partially protected OMS by underlying links
The difference between the examples is the location of the amplifiers and their configuration - single point
of failure vs. Optical Fiber Amplifier (OFA) 4-fiber connection double amplifiers. The connections differ but
result in the same set of trails and nature of protection.
When configuring OMSP protection for XDM or NPT equipment, LightSoft displays the protected path as a
single path configured with underlying protection.

OMSP configuration for Apollo equipment

OMLT platforms, such as those in the Apollo family, configure OMSP protection slightly differently. OMSP
protection on Apollo platforms is implemented as 1:1 protection of the optical DWDM path, transparent to
the specific wavelength (OCH). The OMSP card directs the incoming transmitted signal to one fiber, and a
monitoring signal to a second fiber. The OMSP card constantly monitors the transmitted and monitoring
signals, automatically switching to the protection fiber when the main fiber is cut. LightSoft displays the
protected path as two paths, configured as the Main and Protection components. A typical configuration is
illustrated in the following figure.
Figure 13-11: OMSP protection for Apollo equipment
OMSP protection for Apollo platforms enables multispan protection as well, as illustrated in the following
figure.
Figure 13-12: OMSP multispan protection for Apollo equipment
NOTE: This OMSP protection configuration cannot be used in topologies that include fiber
spans containing amplifiers.

OLP protection for Apollo equipment

If your network topology includes a fiber-protected span that contains amplifiers, OMSP cards are unable to
provide the necessary level of protection at the required speed. A different configuration option is available
for OCH or OMS trails that provides OMSP-like protection, using an OLP_S2 card which enables
implementation of a 1+1 protection scheme for fiber protection, with both the main and protection fibers
transmitting the data signal. This is illustrated in the following figure.
Figure 13-13: OLP_S2 protection for Apollo equipment
OLP_S2 protection for Apollo platforms enables multispan protection as well, as illustrated in the following
figure.
Figure 13-14: OLP_S2 multispan protection for Apollo equipment
NOTE: Unidirectional OMS trails, and topologies that include fiber spans containing amplifiers,
can only be protected using OLP_S2 cards.
Parent Topic

13.1.6.5 OLP 1+1 Protection

Optical line protection (OLP) is a 1+1 protection scheme based on either signal power degradation or Loss
of Signal (LOS). OLP 1+1 provides < 50 msec protection that can be configured to revert automatically to the
main fiber upon repair. Operators use the service card line protection, providing protection against fiber
cuts. Protection is based on service card PM parameters, with automatic switching upon signal degradation.
Figure 13-15: Service card line protection
Parent Topic
13.1.6.6 OCH Input Output Protection (IOP)

For revertive mode PGs, when IOP is configured at the EMS and main and backup ports are determined,
subsequent LightSoft top-down trail creation ensures that:
 Main path is on the main port of the PG, and
 Protection path is on the protection port.
The trail is not created if the PG of the revertive groups is not consistent on both sides. This avoids a
situation where a trail would span main and protection ports when only such ports are available.
Trail creation by Optical Discovery or Acquisition allows this if needed.
An OCH trail with IOP protection provides Current & Underlying protection.
Parent Topic
13.1.6.7 User Defined Protection

Trails may be configured with user-defined protection, where the user defines the trail within LightSoft as
protected in some manner outside of the NMS's scope, such as through an external mechanism or on some
other level.
When defining a protected server trail, LightSoft maximizes diversity in the path and resource allocation.
This approach can be used as another method to provide the overlying client trails with a robust protected
infrastructure.
Parent Topic

13.1.6.8 Management Channels in Optical Networks

Construct the optical topology so that each COSC is combined in the same LE as the element (fiber
amplifier, Mux, or DeMux) that precedes or succeeds it. This enables a single OMS trail to span the entire
path, and avoids alarm-reporting problems caused by intermediate OMS trail terminations and multiple
OMSs in tandem. If you ensure that the OMS trail is end to end in this way, all alarms are displayed
regardless of where the alarmed devices are positioned.
OMS trails would otherwise terminate at each separate COSC LE, resulting in the formation of a string of
OMS trails rather than a single continuous OMS trail. Alarms would then be reported only with respect to
the directly associated OMS trail segments, or only on downstream segments, as follows:
 Card out alarms on a specific COSC are only seen on the directly adjoining OMS trails, and not on other
OMSs along the same path.
 Loss of Signal on an amplifier is seen only on the directly associated OMS segment, and not on other
segments along the same path.
To create a nonfragmented OMS trail:

1. In the optical layer, for each COSC, create a secondary LE that combines the ports of both the COSC
and the adjacent fiber amplifier, Mux, or DeMux; see Creating Secondary LEs.
2. Create internal links within the LE to continue the path between the ports (except for the COSC ports)
in the same way as existed before the secondary LEs were created; see Creating Topology Links.
Although the ports of the different devices continue to be serially connected by multiple links, they
are visually represented in LightSoft by a single LE icon (amplifier, Mux, or DeMux). The COSC is not
explicitly visible in the optical layer map view.
Figure 13-16: COSCs in optical networks
This enables the Discover Optical Trails process to create a single OMS trail that spans the entire path
between MDs. It also enables the links between the sites to have the correct alarm status, since the alarm
status is derived from the amplifier rather than from the COSC.
Parent Topic

13.1.6.8.1 COSCs in XDM/NPT Optical Networks

Construct the optical topology so that each COSC is combined in the same LE as the element (fiber
amplifier, Mux, or DeMux) that precedes or succeeds it. This enables a single OMS trail to span the entire
path, and avoids alarm-reporting problems caused by intermediate OMS trail terminations and multiple
OMSs in tandem. If you ensure that the OMS trail is end to end in this way, all alarms are displayed
regardless of where the alarmed devices are positioned.
OMS trails would otherwise terminate at each separate COSC LE, resulting in the formation of a string of
OMS trails rather than a single continuous OMS trail. Alarms would then be reported only with respect to
the directly associated OMS trail segments, or only on downstream segments, as follows:
 Card out alarms on a specific COSC are only seen on the directly adjoining OMS trails, and not on other
OMSs along the same path.
 Loss of Signal on an amplifier is seen only on the directly associated OMS segment, and not on other
segments along the same path.
To create a nonfragmented OMS trail:

1. In the optical layer, for each COSC, create a secondary LE that combines the ports of both the COSC
and the adjacent fiber amplifier, Mux, or DeMux; see Creating Secondary LEs.
2. Create internal links within the LE to continue the path between the ports (except for the COSC ports)
in the same way as existed before the secondary LEs were created; see Creating Topology Links.
Although the ports of the different devices continue to be serially connected by multiple links, they
are visually represented in LightSoft by a single LE icon (amplifier, Mux, or DeMux). The COSC is not
explicitly visible in the optical layer map view.
Figure 13-17: COSCs in optical networks
This enables the Discover Optical Trails process to create a single OMS trail that spans the entire path
between MDs. It also enables the links between the sites to have the correct alarm status, since the alarm
status is derived from the amplifier rather than from the COSC.
Parent Topic

13.1.6.8.2 OSCs in Apollo Networks

Construct the optical topology so that each OSC port (2M or 100M) is linked to an OSC Channel port on an
amplifier or C/T filter.
Each card is assigned its own unique LE identity and can be utilized by other LEs as needed.
The corresponding OMS trails are configured through the amplifier or C/T filter cards. The amplifier or C/T
filter must be configured with an additional link dedicated to the OSC functionality.
The relevant OSC alarms are displayed on the OSC link (between the OSC card and the amplifier or C/T
filter). This allows the user to distinguish between alarms on the management traffic links and alarms on
the parallel service traffic trails.
To create an OMS trail on Apollo equipment:

1. In the optical layer, for each card participating in the management traffic link, create a unique LE; see
Creating Secondary LEs.
2. Create links between the OSC ports (2M or 100M) and the OSChannel ports on the corresponding
amplifier or C/T filter; see Creating Topology Links.
3. Create links between the Mux/DeMux cards at the trail endpoints running through the amplifiers and
C/T filters participating in the OMS trail. This enables the Discover Optical Trails process to create a
single OMS trail that spans the entire path between MDs.

Note that a few different OSC port configurations are available. The OSC card offers a choice of 2M and
100M OSC ports. OSC channel ports on C/T filters as well as amplifier cards can be connected to either 2M
or 100M ports on the OSC card, depending on the network requirements. Some amplifiers offer an
additional option, with the OSC channel port on the amplifier connected to its own 100M OSC port. Some
of these variations are illustrated in the following figure.
Figure 13-18: OSC topology - 2M and 100M options
Parent Topic

13.1.6.9 Combiners in Optical Networks

Optical combiners are characterized by multiple service ports, each connecting to a UME/client equipment.
Combiners are typically configured through one of two different implementation modes, depending on the
underlying equipment.
When working with standard ODU equipment, including Apollo combiners as well as selected cards on
XDM/NPT platforms that support the ODU layer (such as the CMBR10_T), the ODU trail spans the
combiners. When working with classic WDM equipment on XDM/NPT platforms, there is no ODU spanning
the combiners. The LP traverses from UME to UME. The following figure illustrates a typical Apollo
topology, including the range of each type of trail.
Figure 13-19: Typical Apollo combiner topology
Parent Topic
13.2 Initial System Setup

After the network is configured using the LCT or EMS, and necessary links have been set up in LightSoft, the
trail creation methodologies described in this section can be used. The channel of OCH card ports can be
configured from either the EMS or from LightSoft while creating a trail.
NOTE: OTM links in LightSoft are indicated as OTS links at the EMS level.
To perform initial setup of the system:

1. Configure all possible elements and cards in the network, using the EMS and/or LCT (slot assignment
and setup of cards and ports, as described in the installation and user guides), to enable them to
accommodate traffic.
2. Create links using the LightSoft Create Link feature; see Creating Topology Links. These links can be
internal between ports in a single NE, and/or between ports in different NEs, depending on the
network topology.

When working with Apollo OMLT platforms, fiber connectivity must be configured between ports
connected through physical fibers; see Fiber Connectivity. Fiber connectivity can be defined either
bottom up (defined in STMS, and automatically uploaded to LightSoft, or top-down (defined in
LightSoft during topology link creation, and automatically downloaded to STMS). When creating links
in the STMS, fiber connectivity information is uploaded to LightSoft by default (Report to LightSoft
checkbox selected in STMS). LightSoft creates the relevant topology links and updates the link
parameters accordingly.
NOTE: For EMS with Functional Topology Map (FTM) is installed, use the FTM to create OTM
and OPS topology links in the EMS, and upload them to LightSoft; see FTM/PELES and OCH
Exception: The channel of an OPS port in an OCH line card (transponder) must be
synchronized with the channel of the add-port in an ROADM. This can be done in the EMS by
linking the TRP to the ROADM port in FTM. This can also be done in LightSoft while creating a
trail.
3. Complete the minimum necessary elements and links in LightSoft, such as the UMEs and links to
transponders or combiners.
Parent Topic
13.2.1 Laser Configuration

By default, when a trail is created, LightSoft automatically turns on the laser in the NE to enable traffic to
flow. Similarly, LightSoft automatically turns off the laser when a trail is deleted.
If you do not want LightSoft to automatically change the laser state, select the Preferences window Don’t
change the laser state on create and delete checkbox. (See Optical Trail Preferences in the Getting Started
& Administration Guide.) Then the laser will remain as configured.
The Properties for Port window Laser Configuration parameter indicates if the laser is configured to be on
or off. You can view or modify the current configuration at any time, manually overriding LightSoft’s action
if needed. See Port Properties - Optics Tab in the LightSoft User Guide.
Automatically turning the laser off upon trail and XC deletion means that while the channel remains
configured, the laser is off and laser traffic does not traverse the network. The laser is not simply
transmitting without reason in the absence of traffic, which is advisable for many reasons:
 Safety
 Energy efficiency
 Minimizing wear and tear on the equipment
 Avoiding a possible conflict
NOTE: Trail creation and deletion may also have Power Control or PELES channel implications;
see Power Control Channels and Trail Creation/Deletion in the LightSoft User Guide.
Parent Topic

13.2.2 Power Control Channels and Trail Creation/Deletion

When OCH trails are created or deleted, the number of channels being transmitted is changed. You may
need to recalculate this number (reflected in the NE’s Power Control attribute) or the PELES mechanism in
the EMS that administers certain Power Control functionalities. A message window opens making sure that
the number of channels configured in PELES or in the Power Control remains appropriate. This is
recommended if a significant number of channels have been added or deleted.
Parent Topic
13.3 Acquiring/Importing Optical Trails

Automatically
This section describes how to acquire or import optical trails automatically.
Parent Topic
13.3.1 Optical Trail Creation Options

Optical (and optical-based SDH) trails can be created in the following ways:
 Acquisition by Synchronization
Trails can also be acquired directly through the Trail Synchronization window. This method
synchronizes the trails to be carried by a selected link or the entire network, importing the trail
information from the EMS to the LightSoft database. Trails that do not meet predetermined
classification rules can be created only through synchronization; see Optical Trail Acquisition by
Synchronization.
 Automatic Discovery
The Discover Optical Trails feature can be used to automatically acquire all OMS, OCH, ODU, LP-ODU,
LP, and EoS trails from EMS systems in a single operation. Discovery is recursive for all optical layers.
See Creating Optical Trails Through Discovery.
NOTE: Discovery acquires trails involving all existing XCs. In networks involving cards with
non-fixed XCs (such as AoC or ROADM), the XCs must be configured in advance in the EMS
before Discovery is attempted. See Before you start Discovery in Creating Optical Trails
Through Discovery.

 Individual Trail Provisioning

You can create individual OMS, OCH, ODU, LP-ODU, and LP trails using an interface very similar to that
used for SDH trail creation. This allows control over trail attributes such as the trail label.
Top-down trail creation is not supported for revertive trails between active and standby cards. In
these cases trail creation by Optical Discovery or Acquisition can be used if needed. See OCH Input
Output Protection (IOP).
See Provisioning Optical Trails Manually and its associated sections:
 Provisioning OMS Trails
 Provisioning OCH Trails
 Provisioning ODU Trails
 Provisioning LP Trails
EoS trails that traverse the optical layer

EoS trails that traverse the optical layer (as needed in the case of certain data combiners) are created by
the Discover Optical Trails feature (in addition to the requisite optical trails); see Creating Optical Trails
Through Discovery. These EoS trails can also be created by admitting the HO SDH trail using the Trail
Consistency Indicator window; see Performing Trail Synchronization.
Other optical topology actions

Optical trail parameters can be edited and optical trails can be deleted. Optical components can be inserted
or removed from links, with existing trails automatically arranged to accommodate the changes. Multiple
LP trails can also be associated as a single service. See Other Actions on Optical Trails.
Optical LEs may be created either before or after optical trails are created.
OPTIONAL FEATURE: The optical trail provisioning mechanisms are subject to the optical
layer being enabled. This is a fully integrated add-on capability, available on a cost basis. If not
purchased, the functionality and related menu options are unavailable.
Parent Topic
13.3 Acquiring/Importing Optical Trails Automatically
13.3.2 Creating Optical Trails Through Discovery

The Discover Optical Trails feature automatically acquires in a single operation all optical trails associated
with optical links (selected or all) that do not already have trails configured. The process automatically
acquires optical trails, as follows:
 For each selected OMS link, it creates an OMS trail as well as client OCH and LP-ODU trails (if any of
these do not already exist).
 For each selected OCH link (provided the prerequisite OMS trail exists), it creates an OCH trail as well
as the client LP-ODU trail (if any of these do not already exist).
 For each selected LP-ODU link (provided the prerequisite OCH trail exists), it creates an LP-ODU trail (if
this does not already exist).

The process additionally acquires all associated HO trails (EoS-VC-4, VC-4, etc.) that meet predetermined
classification rules (end in valid endpoints).
NOTE: In each case, for a trail to be created on the selected link, the prerequisite trails must
already exist.
Discover Optical Trails is especially useful when the system is first installed - because of fixed filters and
routings in the network, it is more efficient than individual trail creation. Default trail parameter values are
assigned; see Optical Trail Parameters. After the basic trails are created, the individual optical trail
provisioning methodology affords greater control over the individual trail creation process.
Discover Optical Trails is generally performed as part of an iterative process, as follows:
 Use of Discover Optical Trails to acquire a bulk of trails at a time.
 Trail synchronization to diagnose the trails that fail.
 Subsequent correction of the problems interfering with the acquisition process.
 Repetition of the cycle until all possible trails are acquired.
After the Discover Optical Trails is performed in a system, trail creation activities can typically be limited to
individual OCH and LP-ODU trails. OMS trails can also be created if needed.
Discovery process
 Discover Optical Trails only creates valid end-to-end trails that meet predetermined classification
rules.
 If Discover Optical Trails is stopped before completion, the process is aborted only after trails already
in progress are created.
 If logout occurs before Discovery is completed, the process is aborted only after your confirmation;
see Logging Out.
Prerequisites
 Only equipment where XCs are entirely EMS-configured can be used for trail creation using Optical
Trail Discovery or TCI acquisition. AoC, OMCM25_4, and ROADM cards with configurable XCs that were
EMS-configured cannot be used in top-down OCH and LP-ODU trail creation. All EMS setups must be
reevaluated and any EMS-configured XCs not in use removed. This allows LightSoft to create its own
XCs as required for LightSoft top-down trail creation.
LightSoft uploads XCs for configurable optical cards (AoC, OMCM25_4, and ROADM) from the EMS as
non-fixed. (Earlier LightSoft versions uploaded the XCs as fixed.)
 If optical trails are being acquired, and you require pairs of unidirectional trails (rather than
bidirectional) between transponders and/or combiners, before starting the trail acquisition process set
the Properties for Port window Bi-directional Admit Trail parameter to Disabled on every relevant
endpoint port of the trail. This disables the Sink-Source Partner and causes unidirectional trails to be
created. If the parameter is left enabled on a port, the acquisition process creates a bidirectional
optical trail. See the parameter description in Port Properties - Optics Tab.
 The steps described in Initial System Setup must be completed before Discover Optical Trails can be
performed.

To create optical trails through discovery:

1. (Optional) In the main window, select the area containing the links over which you want to acquire
trails, and in the Trails tab, in the Utilities group, click Discover Optical Trails. (If no area is selected,
the operation is performed on all links in the network.) The Discover Optical Trails window opens.
NOTE: For optimal results, a selection should include OTM links and not only the links from
the MD to the line card.
2. Click Start. A confirmation message opens.

3. Click Yes. All trails in the selection that meet predetermined classification rules (ending in valid
endpoints) are acquired. Trails are acquired in the following order: OMS, then OCH, then LP-ODU,
then EoS - Data over WDM.
The Discover Optical Trails Result window shows the number of acquired and failed trails sorted
according to their rates - OMS, OCH, LP, and HO SDH (for EoS-VC-4, VC-4, etc.). SDH, GbE, and DSR are
summarized as LP, the difference between them reflected in the Payload type trail parameter.
4. Click Show to open the Trail List window filtered on the trails that were just created.
5. Diagnose optical acquisition problems by performing trail synchronization using the Trail Consistency
Indicator window; see Synchronizing Trails.
a. In the TCI window, synchronize one type of optical trails at a time - OMS, OCH, and/or LP-ODU
trails. The order of analysis depends on the type of failure. For example, OCH and LP acquisition
failures are often a result of OMS problems, so OMS trail failure should usually be checked
before OCH and LP failures. However, if the OMS trail was created successfully but the LP or
OCH trails failed, the OCH trail should first be checked.
Trails that are already acquired are not reflected in the TCI window, since trail synchronization
only relates to links.

b. Failed trails are seen in the Network window as flex. For each failed trail, perform the following
corrective actions:
 Verify that the EMS cards are set up and configured correctly.
 Verify that the connections in LightSoft are correct.
The cause of failure is often an absent or wrong connection. For example, if an LP trail is
requested and combiners at opposite ends involve different channels, the OCH trail between
them is created but the LP trail fails. (The TCI indicates that an LP failed at specific endpoints.)
6. After corrections are completed, perform Discover Optical Trails again from Step 1, to try to acquire
the previously failed trails.
7. If some trails still fail, repeat the cycle of trail synchronization and correction described in Step 5, and
perform Discover Optical Trails again. Perform as many iterations as needed until all trails are
acquired.
Parent Topic
13.3.3 Optical Trail Acquisition by Synchronization

Individual trails can also be acquired directly through the Trail Synchronization window. This method
synchronizes the trails to be carried by a selected link, importing the trail information from the EMS to the
LightSoft database.
Acquisition by synchronization is particularly useful when normal trail creation procedures (via Discovery
process or individual optical trail provision in LightSoft) is ineffective, and has created a trail that does not
meet the classification rules.
This process involves the following steps:
 Creating links between the relevant ports, either through link discovery from EMSs or from LightSoft.
 Synchronizing trails in the appropriate order of priority.
Once the relevant links are created, synchronize (acquire) the relevant trails by importing the relevant trail
information to the LightSoft database via the TCI window. Selected trail information is sent to the network
during this process (such as the trail ID and path type).
Synchronize trails in the following order of priority:
1. OMS trails.
2. OCH trails.
3. ODU trails. Create rates of a higher capacity first.
4. LP or LP-ODU trails.
NOTE: Some trail types may not be relevant to your network configuration. Available options
depend on the underlying equipment.

Notes
 If optical trails are being acquired and you require pairs of unidirectional trails (rather than
bidirectional) before starting the trail acquisition process, you must set the Properties for Port
window Bi-directional Admit Trail parameter to Disabled on every relevant endpoint port of the trail.
This causes the creation of unidirectional trails. If the parameter is left enabled on a port, the
acquisition process creates a bidirectional optical trail (where applicable). See the parameter
description in Port Properties - Optics Tab.
 This procedure assumes you have already configured the corresponding slot assignments, card setup
(including port configurations), and channel setup, as described in the corresponding EMS
documentation.
 In certain cases, it may be necessary to create UMEs to represent UMEs in the optical layer. These
UMEs are connected to MEs via topology links.
If all trail components (endpoints, XCs) were correctly configured in the network, either implicitly by the
system (as part of equipment configuration), or explicitly by you (e.g., via EMS), a trail can be created in
LightSoft using Discovery or TCI acquisition. However, since LightSoft considers XCs that are explicitly
configured in EMS as utilized, these XCs cannot be used in top-down trail creation. Therefore, it is
recommended to re-evaluate all explicitly created XCs and remove those which are not in use.
Parent Topic
13.3.3.1 Creating Links for Synchronization

Before performing trail creation via TCI, create links between the relevant ports through discovery (see
Creating Optical Trails Through Discovery), or directly (see Creating Topology Links). Basic guidelines are:
 Links can include internal links between ports in a single NE, links between ports in two different NEs,
or a combination of the two, depending on the network topology. Creation of optical LEs may be
performed before or after the creation of the optical trails.
 OMS trails are usually created between a multiplexer or a ROADM and a demultiplexer or ROADM.
Amplifiers and other aggregate cards may be in the path of an OMS trail. An OMS trail can contain
cards that provide dispersion compensation to delay deterioration of the photonic signal, such as DCF
and/or DCM cards. It cannot aggregate cards.
 OCH trails are usually created between transponders, combiners, regenerators, and FIO cards. An OMS
trail can contain one OCH trail for each available channel. For example, an OMS trail with 40 channels
can contain up to 40 OCH client trails.
 ODU trails are usually created between transponders, combiners, and FIO cards. An ODU trail must
have an OCH trail or an ODU trail of a higher order as its server trail. An ODU trail can have multiple
OCH or ODU server trails.
 LP trail endpoints usually consist of a client port connected to the transponder (in the case of SDH or
other clients that are connected to a transponder), or the client port of the transponder. An LP trail
may be the client of multiple OCH trails. (LightSoft does not differentiate between LPs for SDH or data
clients. This information is reflected in the trail's payload type parameter.)
Parent Topic

13.3.3.2 Creating Trails with TCI
NOTE: Before performing TCI, ensure the relevant topology links are created.
To acquire a trail via TCI:

1. In the main window, select the optical layer.
2. To run TCI for a single trail, select at least one of the segments you want the trail to traverse, and in
the Trails tab, General area, click Trail Consistency. The Trail Consistency window opens.
OR
To run TCI for all trails of a specific rate, from the Trail Consistency window, select the trail rate. TCI is
performed on all objects that raise a TCI counter for that rate.
3. In the Parameters area, select the trail rate you require.

4. To acquire trails from the network to the NMS only, select the Monitor Mode checkbox.
5. (Recommended) Deselect the Auto Admit to Database - Flex checkbox. This prevents trails with Trail
Status OK from being admitted automatically to the NMS.
6. For a trail in which the main path is distinct from the protected path, to prevent creation of a flex
trail, deselect the Use Connectivity Only checkbox.
7. Click Start. The acquisition process begins. When complete, the Trail Synchronization window opens
displaying the following windows: Network Trails Sequence, DataBase Trails Sequence, and Queue.
See Trail Synchronization Window.

8. In the Network Trails Sequence window, select the checkbox for the trail you want to synchronize,
and click Trail Admit . The trail is transferred to the Queue window.
9. Select the trail in the Queue window, and click Activate . A message is displayed and a green
checkmark is displayed next to the trail, to indicate trail acquisition is successful. The trail is displayed
in both the Network and the Database windows, and in the Trail List window with Trail State OK.
NOTE: It is recommended to change the default name given to the trail by the system; see
Editing Trails.
Parent Topic
13.3.3.3 ODU Trail Acquisition Rules for Non-OMLT Equipment

If you are not working with OMLT equipment, the following rules apply:
 An ODU2 trail that overlaps an OCH trail is not acquired.
 Acquired ODU trails that do not comply with the EP rules will be flex.
 If TCI is performed on an ODU trail where the user selected a segment that ends on the CMBR40’s
aggregate port, LightSoft does not attempt to create an ODU trail through the ODU XC that ends on
the 10 GbE or STM-64 client ports, because this XC is marked as LP Traversing.
 Two paths of an ODU trail are associated (and an X protected trail is defined) if they have the same
Trail ID, even if the trail has no PG as applies to other optical trails.
 An ODU trail with two EPs is Current (and Underlying) protected if one of the underlying OCH trails has
three EPs (e.g., a splitter/coupler as in Schematic 1 Appendix F).
NOTE: If the underlying OCH trail has multiple routes but only two EPs, the routes are
transparent to the ODU and the trail is only underlying protected. (This is the same as an LP
trail with underlying OCH trails.)
 An ODU trail with an underlying X protected OCH trail is considered current (and underlying) protected
(e.g., Schematic 3 in Appendix F).
 An X protected ODU trail with revertive PGs on both sides may have the Main EP on one side
connected to the Protection EP on the other side (this does not render the trail flex).

 Where possible, the path type is determined based on revertive PGs. If there are none or if they
provide ambiguous clues, the Path Type on the ODU XCs determines the path type. Otherwise,
LightSoft may define the path type arbitrarily. (The criteria for this arbitrary selection should be
consistent, e.g., lowest XC ID.)
 The path type can be determined by a PG on midtrail ports with ODU XCs traversed by the ODU trail.
Parent Topic
13.4 Provisioning Optical Trails Manually

Parent Topic
13.4.1 Introduction to Optical Trail Provisioning

You can create OMS, OCH, ODU, and LP trails using an interface very similar to that used for SDH trail
creation.
Figure 13-20: Create Trail window for optics
The individual optical trail provisioning methodology described in this section affords control over the
specification of trail parameters, such as the trail label and AMM. After specifying the trail parameters and
endpoints of the path on which the required service is to be set, LightSoft automatically performs all the
provisioning operations.

LightSoft works with an internal PathFinder utility to optimize the new trail route. For example, when
configuring a new OCH trail, PathFinder incorporates any specific NEs or segments that you selected and
completes the routes and paths by choosing the remaining required segments.
PathFinder optimizes the trail routes based on user-selected criteria. Different criteria may apply to SDH
and optical trails. The user selects trail management constraint criteria against which the PathFinder
algorithm evaluates potential paths for a trail, as described in Trail Creation Management Preferences in
the Getting Started & Administration Guide. For example:
 Criteria priorities are determined according to their order of selection. If the first selected criterion is
Distance, the shortest-distance path is used for the trail. If the first-priority criterion is satisfied by
more than one path, those paths are evaluated against the second-priority criterion, etc., until a single
optimal path is identified.
Note that with these criteria, an exact match is not necessarily required. The user can also set a
Tolerance level, indicating that matches within a certain tolerance range are acceptable. This enables
an intelligent flexibility that enhances PathFinder efficiency and trail optimization capabilities.
 PathFinder employs powerful heuristics to minimize shared resources in the following order of
priority: segments/server trails, ducts (SRLG), platforms (MEs), and cards.
 For multiroute paths, PathFinder promotes higher protection quality server trails:
 Multiroute or Current & Multiroute protected trails: Unprotected links/server trails have
priority over protected links/server trails.
 Underlying & Multiroute or Current & Underlying & Multiroute protected trails: The reverse
applies.
 PathFinder identifies paths/routes that consider your Optical Constraint choices, one or more of the
following:
 Number of Server Trails: Least number of hops (server trails/link segments).
 Availability: Path that satisfies the preconfigured min. and max. available capacity for links in
the new trail.
 Assigned Cost: Path with the lowest cost assessment (1 to 1,000 units). Note that this value is
set in the link properties.
 Length: Shortest path. The value of each link used for this purpose can be set in the link
properties.
 OSNR Weight: Estimated OSNR value assigned per OMS trail, calculated internally by LightSoft,
based on the physical signal parameters. Higher OSNR values correlate with better signal
quality. Assigning a greater priority to OSNR Weight values means that PathFinder gives these
values greater importance when provisioning an OCH trail.
Individual LP trails can be created only if the necessary underlying server trails (ODU, OCH, and/or OMS)
already exist. Individual OCH trails can be created only if their underlying links and/or OMS server trails
exist. OMS trails can be created individually as needed if the underlying links are in place.
If equipment along the path has not been configured or is missing, PathFinder does not find the trail path,
and a warning appears. Configure the equipment and then repeat the provisioning request.
Certain endpoint validations are performed by the Create Trail process; see OMS Trail Endpoint Validations
, OCH Trail Endpoint Validations , and LP Trail Endpoint Validations.
Individual trail creation only creates valid end-to-end trails that meet predetermined classification rules.

The laser is turned on/off by default when an optical trail is created/deleted; see Laser Configuration in the
If an optical trail's actual protection differs from that specified by the user, it still completes successfully.
For example, if the requested Current protected trail is in fact also Underlying protected, trail creation
succeeds (is Current & Underlying protected) with a message.
See Initial System Setup for optical trail creation prerequisites. Additional prerequisites apply for each type
of trail, as described in the following sections.
NOTES:
 AoC, OMCM25_4, and ROADM cards with configurable XCs that were EMS-configured
cannot be used in top-down OCH and LP trail creation. All EMS setups must be
reevaluated and any EMS-configured XCs not in use removed. This allows LightSoft to
create its own XCs as required for LightSoft top-down trail creation. Alternatively, only
equipment where XCs are entirely EMS-configured can be used for trail creation using
Optical Trail Discovery or TCI acquisition.
 LightSoft uploads XCs for configurable optical cards (AoC, OMCM25_4, and ROADM) from
the EMS as non-fixed. (Earlier LightSoft versions uploaded the XCs as fixed.)
Parent Topic
13.4.2 Provisioning OMS Trails

OMS trails are uni- or bidirectional optical trails between multiplexing devices (MDs). They behave as server
trails that carry multiple OCH trails in fixed groups. OMS trails can be created individually using the
procedure in this section. Typically, OMS trails are created using Discover Optical Trails.
Prerequisites
 As described in Introduction to Optical Trail Provisioning.
 All necessary photonic layer cards with OTS ports (such as Mux, DeMux, OFA, CT filters, and OADM)
must be installed, configured in the EMS, and linked.
 All necessary topology links must be configured appropriately.
OMS trail creation workflow

The following steps represent the workflow for creating an OMS trail:
1. Define the basic OMS trail parameters.
2. Define the advanced OMS trail parameters.
3. Select endpoints.
4. Complete and activate the trail.

To create an individual OMS trail:

1. Select the Optical topology layer.
2. (Optional) In the main window select the objects containing the relevant objects. (When Pathfinder
searches for trails, it relates to the relevant topology, not only the displayed elements.)
3. In the Trails tab, in the General group, click Create Trail. The Create Trail window opens.
If nothing was preselected in the main window, the map shows all the objects, otherwise the map
contains only the selected objects and the links between them.
4. Select the Trail Parameters tab.
5. In the Basic Trail Parameters pane, edit one or more of the following parameters, as needed:
 Label and Customer names (optional): See the parameter description in Basic Trail Parameters
Pane.
 Protection: Unprotected, Current Layer, Underlying Layer, or Current and Underlying; see
Optical Trail Protection and protection type definitions in Trails Pane Columns.
 Rate: OMS.
 Directionality: Unidirectional or Bidirectional.
NOTE: The protection options offered by LightSoft when provisioning a new trail depend on
whether they can be supported by the underlying equipment. Protection options that are not
supported by the hardware cannot be provisioned in LightSoft. For example, if the user tries to
provision an OMS trail choosing Current protection, but the underlying equipment does not
support this capability, then LightSoft creates an unprotected trail and notifies the user with a
warning message.
6. In the Advanced Protection pane, configure protection settings, where relevant. Protection fields that
are not relevant to the trail being provisioned are grayed out. See Defining Trail Protection.

7. In the Advanced Trail Parameters pane, edit one or more of the following parameters, as needed. If
trail parameters are not specified, LightSoft sets default values.
 In the Comments field, type a free text comment about the trail.
 From the Service Indicator dropdown list, select a service level indicator.
 In the Private ID field, type a Private ID value. This attribute may be used to associate two more
trails as a single service.
 Click an Alarm Master Mask option, determining whether faults on objects in the trail path
generate alarms; see Alarms Master Mask (AMM) :
 Apply: (default) Enables trail object masking in the EMS for all trail objects regardless of
any specific EMS settings (alarms are generated on all trail objects).
 Do not change: Leaves the AMM on trail objects unchanged. Alarms are received on
specific objects in accordance with the current EMS settings. On some equipment, AMM is
set to Apply by default, in which case setting the parameter to Do not change leaves the
equipment AMM as monitored.
 Click a User Usage State option, overriding the system usage state:
 Idle: Trail is set to Idle even if the actual state is Active. Idle trails are not connected to
traffic and if the system usage state is also idle can be deleted from the Trails pane; see
Deleting Trails.
 Active: Trail is set to Active even if the actual state is Idle. Active trails are connected to
traffic and cannot be deleted.
8. Select endpoints to define the path on which the service is created (function enabled only after a trail
rate is selected):
 Right-click an LE in the map, and choose Select Endpoint. The Endpoint Selection window
opens. The ports that are free and conform to the selected trail rate are available for selection.
The window and procedure is similar to that for SDH trail creation, described in Select Segment
Pane.
 Select endpoint ports. Typically one endpoint is sufficient. See OMS Trail Endpoint Selection for
specific instructions concerning directionality and the number of endpoints needed in specific
cases.
The selected endpoints are reflected in the Endpoints List pane.
9. (Optional) In the window map, select the specific segments you want the trail to span (using the SHIFT
key). This is useful if you are creating a long trail that spans more than one segment. If segments are
not selected, LightSoft creates the trail according to PathFinder optimization considerations.

10. Click Complete trail and Activate trail . Clicking Complete finds and verifies the path and
shows the results in the map, but does not create the trail until Activate is performed. LightSoft does
the following:
a. Based on the priorities and constraints defined by the user in the User Preferences window,
PathFinder identifies the optimal path between the endpoints (see Trail Management
Constraint Preferences in the Getting Started & Administration Guide).
If a path between the endpoints is not found, a failure message is generated.
b. Derives the protection state of the trail from the network and the underlying links state. If the
derived state is different from the selected, a message is generated and the state is set as
derived from the network.
c. Validates the compatibility of the endpoints; see OMS Trail Endpoint Validations. OMS trail
validation is completed according to the criteria selected in the User Preferences window.
d. Downloads to EMS (according to trail rate):
 Label and customer, if set differently in Step 4.
 AMM state.
 Trail ID.
e. Creates the trail.
f. LightSoft analyzes the new OMS trail path equipment and assigns the OMS trail an initial OSNR
Weight value. This may later be used by PathFinder when provisioning a new OCH trail over this
OMS server trail (depending on the PathFinder constraint preferences configured by the user in
Trail Creation Management Preferences in the Getting Started & Administration Guide).
Note that OSNR Weight values calculated automatically by LightSoft for certain types of
underlying equipment cannot be changed by the user. However, OSNR Weight values for other
equipment, such as Packet-OTS platforms, are based on default LightSoft settings and can be
edited. Trail parameters can be viewed and edited through the Trail List window, using the
general procedure described in Editing Trails.
Parent Topic
13.4.2.1 OMS Trail Endpoint Selection

You can configure OMS trails to be either uni- or bidirectional.
13.4.2.1.1 Unidirectional OMS Trail

When Unidirectional is selected as the trail directionality, select the OTS-Src and/or the OTS-Snk at the
extremities of the trail. You can select one or both endpoints. In most cases a single endpoint is sufficient to
define the trail path. The "add" and/or the "drop" of a bidirectional endpoint can also be used as endpoints
to create a unidirectional trail. LightSoft automatically creates the trail based on the selections.

13.4.2.1.2 Bidirectional OMS Trail

When Bidirectional is selected as the trail directionality, one or two endpoints are needed to define an
optical trail. (Selecting more endpoints is not allowed.)
One endpoint
In a configuration where elements at opposite ends of the path include pairs of Src/Snk endpoint ports (so
are bidirectionally related), only a single endpoint selection is needed to uniquely identify the bidirectional
OMS trail. See Defining a Relationship between Ports or Cards.
In this example, a Mux and DeMux reside on the same card with bidirectionally related ports. The path
extends to an OADM, which also includes related ports on the same card. (Amplifiers in the path do not
affect the OMS trail.) Selecting any one of the four possible endpoints is sufficient to define the
bidirectional OMS trail.
Figure 13-21: Two-card configuration
Similarly in a 3-card configuration, if, for example, there is an OADM with Snk/Src bidirectionally related
ports on the same card on one side and 40-channel Mux and DeMux on separate cards (no bidirectional
relation) on the other side, a single endpoint (one of the related ports) is sufficient to define the trail.
Figure 13-22: Three-card configuration

Two endpoints
If the bidirectional relation (see Bidirectional Paired Ports) is absent on both sides of the directional path
(for example, four cards with 40-channel Mux and DeMux on each side), two endpoints must be selected -
one endpoint in each directional path.
Figure 13-23: Four-card configuration
NOTE: Each of the two selected endpoints must be in a different directional path. If the
endpoints are selected on the same unidirectional path, a unidirectional trail results,
regardless of whether Bidirectional was specified as the required trail type.
Parent Topic
13.4.2.2 OMS Trail Endpoint Validations

The following endpoint compatibility validations are performed when an OMS trail is created:
 When connecting OTS/OMS ports, the endpoints must have some channels in common.
 CWDM and DWDM endpoints cannot be connected.
These anomalies are not included in the TCI Details pane inconsistency counts.
Parent Topic
13.4.3 Provisioning OCH Trails

OCH trails are client trails of an OMS trail, utilizing the channels of the OMS trail. An OCH trail carries the LP
or ODU client input signal trails, one or more LP or ODU per OCH trail.
Prerequisites
Before starting OCH trail creation, make sure the following have been created:
 All topology links.
 For a single route trail, the relevant OMS trail.

 For a multiroute trail, OMS trails between all ROADMs and Mux/DeMux and ROADM/ROADM that
exist along the trail.
 For a protected trail, ensure the main and standby cards to be used as endpoints are associated in the
EMS.
 OCH trails can be designated as ASON data links. They appear as ASON links in the OCH layer ( ). To
create an OCH ASON data link, ensure that only OMLT equipment is used. ASON trails must be
bidirectional, and a path must use the same resources in both forward and backward directions.
IMPORTANT: When working with OMLT platforms, the following configuration steps are
essential and must be completed before provisioning OCH trails:
1. Configure the ports to be used for trail endpoints at the EMS level, through a GCT to STMS.
Ensure that the Tx and Rx channels at the endpoint ports are configured with matching or
compatible values.
2. Provision and configure the topology links to be used by the trail with the same (or
compatible) channels:
 The Tx channel at endpoint port A must be the same as the Rx channel at endpoint
port Z. All links in the A-Z direction along the trail route should be using the same
channel.
 The Tx channel at endpoint port Z must be the same as the Rx channel at endpoint
port A. All links in the Z-A direction along the trail route should be using the same
channel.
 In bidirectional trails, signal traffic in the two directions is independent and can be
configured with two different channels. The two directions do not have to use the
same channel.
For convenience, Tx and Rx channel values for each endpoint, when configured, are listed next
to the endpoint in the Endpoint Selection tree, illustrated in Defining OCH Trail Endpoints. This
makes it easier to verify that the endpoint ports have been configured correctly before
provisioning the OCH trail.
If the endpoint channels do not match, reset the channel selections through the Endpoint
Selection window. Endpoint channels can also be reset through the Port Property window for
that port or the port's link.
OCH trail creation workflow

These are the steps of the workflow to create an OCH trail:
1. Define the basic OCH trail parameters.
2. Define the trail protection you require. For multiroute trails, define the number of routes you require.
3. Define the advanced OCH trail parameters.
4. Select the path completion method. During path completion, you can optionally define part of the
path, or the entire path that each route traverses. Alternatively, LightSoft can define the route
automatically.
5. Complete and activate the trail. LightSoft can calculate the optimal path that each route traverses, or
you can define part or all of the path explicitly. You can also add DRI protection.

To configure an OCH trail:

 Label and Customer names (optional); see the parameter description in Basic Trail Parameters
Pane.
 Protection: Select the protection that you require. Options vary depending on the topology and
rate selected; see Optical Trail Protection and the Protection type definition in Trails Pane
Columns.
 Rate: OCH.
 Directionality of traffic: Unidirectional or Bidirectional. Note that OCH trails can utilize different
channels for forward and backward directions, but the corresponding endpoint channels must
be the same. This means that the Tx channel at endpoint A must be the same as the Rx channel
at endpoint Z. When working with ROADM cards, keep in mind that ROADM8A cards support
bidirectional trails only, while ROADM8A_50 cards support both uni- and bidirectional trails.
 (ASON only) Build ASON Data Link: Select the checkbox to create an OCH data link. When the
OCH link is created, an 'A' indicates that the link is an ASON link (
6. In the Advanced Protection pane, configure protection settings. Protection fields not relevant to the
trail being provisioned are grayed out. See Defining Trail Protection.

Deleting Trails.
The relevant trail properties are automatically listed in the Trail Properties pane.
8. Select endpoints to define the path on which the OCH trail should be created. See Defining OCH Trail
Endpoints.
9. (Optional) You may select specific segments that you want the trail to span. See OCH Segment
Selection.
10. Select the Endpoints & Path tab.
11. In the Path Completion Method pane, select the path completion method.
 Auto-Complete (default): PathFinder automatically suggests an optimal path for the trail based
on the minimum user selections, in accordance with applicable user preferences.
 Explicit Selection: When selected, LightSoft presumes that all of the trail’s segments are
selected manually and does not automatically select any segments at all.
See Selecting a Path Completion Method.
12. Complete and activate the trail.

A status window displayed at the end of the Complete/Activate stage indicates the state of the new trail
and provides links to more information.
Figure 13-24: OCH trail activation window
The trail may be classified as invalid if the estimated OSNR is out of the valid range or if there are significant
active alarms. If a trail route includes significant active alarms, the trail is immediately invalidated and the
OSNR status is not checked.
The status window includes the following sections and options:
 Summary pane: Displays overall results of activation request, as well as the actions completed at the
NMS and EMS levels.
 Trail Validation Status pane: Provides the following information about the OCH trail status:
 Validation
 Estimated OSNR
 Alarms
 Show Trail Alarms: Enabled if there are any alarms active along the route of this trail. Opens a window
displaying the relevant alarms.
 Show OSNR Details: Opens a window providing detailed information about the estimated OSNR for up
to four trail segments (reflecting the newly configured path running in each direction for both the
main and protection routes).
OSNR values that are labeled 'out of range' indicate that the current trail route is not able to transmit
a clear traffic signal. Click OSNR Optimization to request that PathFinder search for an alternative
path route with an acceptable OSNR value.
The following table identifies a typical range of OSNR values that may be displayed in the Show OSNR
Details window with the corresponding Pre-FEC BER values. Keep in mind that higher OSNR values
correlate with smaller BER values, both of which correlate with better signal quality.

Table 13-5: Estimated OSNR displayed in LightSoft, based on pre-FEC BER
10G FEC 10Ge FEC 40G 100G Pre-FEC BER

0 0 0 0<1 X > 10-2
0 0 0 1 10-2 > X > 10-3
0 0<1 0<1 3 10-3 > X > 10-4
0<1 2 2 6 10-4 > X > 10-5
2 4 4 7 10-5 > X > 10-6
4 5 6 8 10-6 > X > 10-7
5 5 7 9 10-7 > X > 10-8
5 6 8 > 10 10-8 > X > 10-9
6 7 > 10 > 10 10-9 > X > 10-10
>7 >8 > 10 > 10 10-10 > X
 OSNR Optimization: Enabled only if the trail is invalid because the OSNR is out of range. Click to
request that PathFinder search for an alternative path route with an improved OSNR value.
When you do this, LightSoft makes OSNR Weight optimization the first priority when PathFinder
calculates a path for this trail. This change of priority for the OSNR criteria does not change the
PathFinder constraints configured through the User Preferences windows. (See Configuring User and
System Preferences in the Getting Started & Administration Guide.)
Note that a trail's OSNR weight values are displayed and edited through the Trail List window. Some
OSNR weight values are based on default LightSoft settings and can be edited by the user. OSNR
weight values calculated automatically by LightSoft for other types of underlying equipment cannot
be changed by the user.
 Show Trail Alarms: Enabled only if there are active alarms for this trail. Click to display more
information about the trail alarms.
 Delete: Click to delete the new trail.
 OK: Click to close the window.
Parent Topic
13.4.3.1 Defining OCH Trail Endpoints

The OCH trail provisioning procedure includes a step selecting endpoints; see Provisioning OCH Trails. The
selected endpoints define the path on which the service is created. The function is enabled only after a trail
rate is selected, and the number of endpoints to be selected depends on the trail type; see OCH Endpoint
Selection.

IMPORTANT: When working with OMLT platforms, the same channels must be selected at the
corresponding endpoints. This means that the Tx channel at endpoint A must be the same as
the Rx channel at endpoint Z, and vice versa. For convenience, Tx and Rx channel values for
each endpoint, when configured, are listed next to the endpoint in the Endpoint Selection
tree, as illustrated in this section. This makes it easier to verify that the endpoint ports have
been configured correctly before provisioning the OCH trail.
To define OCH trail endpoints:

1. Select the two LEs on the map that are to be the two endpoints for the new OCH trail.
(This process can also be completed separately for each endpoint but is more efficient for both
endpoints simultaneously.)
2. Right-click and choose Select Endpoint. The Select Endpoint window opens, listing both LEs with their
ports displayed in a tree structure. Enabled nodes represent ports that are available for selection as
endpoints. The Tx and Rx channels configured for each port (if any) are listed next to the port in the
tree.
3. (Optional) Select the appropriate Add/Drop mode. Default mode for bidirectional trails is Add&Drop.
If the object selected is a termination point, all mode options are enabled and may be Add, Drop, or
Add&Drop.
4. (Optional) Select the protection scheme for the endpoint: Main, Protection, or Both.
5. Select two ports with matching channel values to serve as trail endpoints. Selecting an endpoint
displays the Tx channel in the Selected Port Details field and enables the Change (Channel) button.

TIPS:
 Only nodes that are compatible with your Add/Drop and protection scheme choices are
available for selection.
 Main and Protection nodes are annotated in the list with and icons,
respectively, alongside the channel indication.
 The output (Tx) and input (Rx) frequencies for each node, if configured, are listed next to
the node.
6. If the port channels are configured appropriately, click Select Port to choose those endpoints.
When working with OMLT platforms, you must select endpoints that were already configured with
the appropriate channel settings when the prerequisite links were provisioned, with the Tx channel of
the A endpoint matching the Rx channel of the Z endpoint, and vice versa.
TIP: If the endpoint channels do not match, reset the channel selections through the Endpoint
Selection window. Endpoint channels can also be reset through the Port Property window for
that port or the port's link.
7. When working with Packet-OTS platforms, endpoint channels can be selected and reconfigured if
necessary. Click the Tx or Rx Change (Channel) button to open a Channel Selection window showing
the currently applicable channel (in blue, if any).
a. Click the relevant cell to select a channel. (The channel range displayed varies according to
underlying equipment. For example, a set of 88 channels with 50 GHz spacing would be listed in
the tab with channel numbers ranging from 191.70 to 196.05.).
b. (OTU ports only) When changing the Tx channel, optionally select the Copy to Rx Frequency
checkbox to automatically duplicate the selected frequency to the Rx channel.

NOTES:
 If the channel is not yet defined (has a "zero" channel), a channel must be selected before
the port is allowed to be selected as an endpoint.
 If the channel is already defined, and this is a Src endpoint, ensure that the port's channel
frequency is compatible with interconnected object channels.
 If the connection is to a Mux device, only the relevant Mux channel is available. Other
channels are black.
)
c. Click Apply to set the channel.

d. The Frequency configuration succeeded message opens. Click OK. The channel selection takes
effect immediately in the network, whether or not the trail is subsequently activated.
e. The Set to Zero choice sets the channel to its initial unassigned state, releasing the selected
channel, and temporarily postponing the channel reservation; (The port cannot be selected as
an endpoint unless it has a valid channel.)
8. Grayed nodes may represent ports that are available as endpoints but for which the channel was not
yet configured in the EMS or LightSoft. The Channel field is enabled but shows a "zero" frequency. To
make this port fully available as an endpoint, define the port channel, as described in the preceding
step.
Other grayed nodes are either already occupied or not compatible, with the Channel field disabled. It
may show "Not valid for selected node", or a popup window may show This port does not support
tunable frequencies. Such a node is not available for selection as an endpoint.
9. Complete the selection of the current endpoints:
a. Click anywhere in the Select Endpoint window to close the Channel Selector window.
b. Click Close to close the Select Endpoint window.
The selected endpoints are reflected in the Endpoints List pane.
Parent Topic
13.4.3.2 Selecting OCH Segments

The OCH trail provisioning procedure involves a segment selection step; see Provisioning OCH Trails.
You can select some or all the required segments for the trail, predefining its route as you need. This is
useful if you are creating a long trail that spans more than one segment. If segments are not selected,
LightSoft selects any required additional segments to complete the route according to PathFinder
optimization considerations.

To select some or all segments for the trail:

1. If the trail is protected, in the window toolbar, select the path for which you want to select segments:
 Main to choose segments for only the main path (you will choose protection path segments, if
needed, in another cycle of the procedure).
 Protection to choose segments for only the protection path (you will choose the main path
segments in another cycle of the procedure).
 Both to define shared segments that overlap the main and protection paths.
2. If Multiroutes or DRI applies, specify the exact route or bridge for which the segments must be
associated.
A separate cycle of the procedure is required for the primary route and every specific secondary route
number and bridge number.
In the Select Segment pane, the Primary Route and Secondary Route options are enabled when
Multi-Route is selected, and the Bridge option is enabled when DRI is selected.
These fields are used to allocate segments to a specific path, route, or bridge. Each selection must be
done in a separate allocation cycle:
a. To allocate segments to the Primary route:
 Select Primary Route.
 Continue to select segments for the Primary route.
b. To allocate segments to a Secondary route:
 Select Secondary Route.
 Select the applicable route number on the spinner.
 Continue to select segments for that specific route.
c. To allocate segments to a DRI bridge:
 Select Bridge.
 Select the applicable bridge number on the spinner.
 Continue to select segments for that specific bridge.
3. In the window map, select specific segments that you want the trail, or specific path/route, to span
(according to their availability) using the SHIFT key. As you select the topology links for the trail, they
are highlighted in the map view and listed in the Resource Tree pane under:
 Headings: Main or Protection
and
 Subheadings: Primary, Secondary route # (up to 16),
and Bridge route # (up to 16)

4. Select a specific channel for each segment; see OCH Segment and Channel Selection. If resources are
not selected, LightSoft assigns them according to PathFinder optimization considerations.
For each segment for which specific resources are needed:
a. Click a link or multilink. The Select Segment pane shows the available links.
Note: If the link is unidirectional, you must double-click. A single click may give a message that
"no resources are available."
b. Double-click a port. The Select Resource pane shows a matrix of the available resources
(channels for OCH trails or SPO resources for LP trails).
c. Select the required channel for the OCH trail segment.
NOTE: Ensure that the segment's channel is consistent with the endpoint channel. If channels
are different, and in the absence of a regenerator to correct the channel, the trail does not
complete. For complex trails, segments can be selected before endpoints. Then frequencies
on endpoints can be set to be consistent with channels on adjacent segments.

d. If another segment direction is also needed, repeat the current step on the other port.
5. Repeat the procedure for each additional route and bridge for which manual segment selections are
needed.
Parent Topic
13.4.3.3 DRI Protection

Trail protection can further be enhanced through the use of DRI that enables you to create one or more
bridges connecting a main endpoint on one side of the trail to a protection endpoint on the other. The
bridge provides an alternative route in the event of a fiber cut on the main or protection route. In this way
DRI provides trail protection in even more scenarios of multiple fiber cuts than the options provided when
limiting route restoration only to endpoints of the same route (main or protection).
NOTE: In V9 DRI is supported for OCH, ODUk, and LP trails.
For multiroute OCH trails, DRI protection is only available when using the following ROADM types:
 ROADM8A: Supports bidirectional trails only.
 ROADM8A_50: Supports uni- and bidirectional trails.
Parent Topic
13.4.3.3.1 Prerequisites
The following prerequisites are required for a DRI trail:
 For OCH trails, compatible ROADM cards are defined in the network.
 LP and ODUk DRI trails require Fabric FIO or AOC cards.
 A single route or multiroute trail with at least one main and one protection path are defined. For a
single route trail, the Protection is Current or Current & Underlying.
 For a multiroute trail, the Protection is Current & Multiroute or Current & Underlying & Multiroute.
 The required main and protection segments have been selected.
 The trail completion method has been selected.
 ASON trails cannot include DRI protection.
Parent Topic

13.4.3.3.2 Defining DRI Protection
To define DRI protection:

1. Select the Trails Parameters tab.
2. In the Basic Trails Parameters pane, select the DRI checkbox.
3. Select the Endpoints and Paths tab.
4. (Mandatory for OCH trails only) In the Select Segment pane:
a. Click Bridge.
b. In the Bridge field, enter or select a number by which to identify the bridge (default = 1).
5. (Mandatory for OCH trails only) Define bridge segments for the main to protection direction:
a. In the Path field, click Main to select the path on which the bridge should appear.
b. In the map, click the link with which you want to create the main bridge. The segments
contained in the link are displayed in the Select Segment area.
c. In the Select Segment pane Port2 column, select the arrow for the segment that is going in the
correct direction for the main path endpoint.
The bridge icon is added to the Resource Tree and displays the selected segment.
d. Right-click the segment in the Resource Tree and select DRI Bridge. The Define DRI Bridge
window opens.

e. Select the Source Endpoint for the main bridge, and click OK. A DRI icon is shown next to the
segment in the Resource Tree. The segment appears in the Resource Tree and the DRI Bridge
icon is displayed, showing the bridge number.
f. Repeat this step for the opposite direction of the main path.
6. In the Path field, click Protection and repeat the previous step to create the Protection bridge.
7. Click Complete and then click Activate.
IMPORTANT: If the DRI checkbox is cleared after defining one or more DRI bridges, all DRI
bridge information is lost and must be redefined.
Parent Topic
13.4.3.3.3 Deleting DRI Bridges

When a bridge is deleted, other bridges, routes, and paths are not affected.
Since bridge numbers do not need to be consecutive, deleting a bridge does not affect the numbering of
other bridges.
To delete a bridge:
 In the Resource Tree, right-click the bridge node and click Remove.
OR
 Select a segment under the bridge node, and click Remove All.
NOTE: To ensure DRI bridge deletion is complete, you must delete bridges under both the
main and protection paths.
Parent Topic

13.4.3.3.4 Viewing DRIs

Optical DRI bridge segments are displayed in the Resource Tree under the relevant associated path:
 Main-to-Protection direction segment is shown under the main path.
 Protection-to-Main direction segment is shown under the protection path.
In the Resource Tree, the main and protection nodes with associated DRI bridges have subnodes for the
bridges. To distinguish between them, bridges are numbered with label Bridge n (n = number, up to 16).
The route number of routes associated with each bridge is shown next to the bridge label. Routes that
traverse the XC at bridge endpoints are called Associated routes. For example, routes that traverse the two
bridge endpoints on the main path are shown next to this bridge label on the main path branch. Note that a
route can traverse one of the main endpoints of a bridge but not the other. This is why the route is
considered to be “associated with” the bridge and not “protected by” it.
The leaves of the bridge nodes are the bridge segments. DRI bridge segments are shown by a bridge icon
under a numbered bridge node for multiroute and non-multiroute trails. Select a bridge node in the
Resource Tree to highlight the segment in the map.
When a trail has an underlying trail and/or DRI bridge, if selecting a single segment, all segments connected
with routes and DRIs are highlighted in the map.
Figure 13-25: Resource Tree displaying multiroute trail with DRI bridge
Parent Topic
13.4.3.4 Understanding OCH Endpoint and Segment Selection

This section explains some of the requirements when selecting OCH endpoints and segments.
Parent Topic

13.4.3.4.1 OCH Endpoint Selection

To fully define an OCH trail, LightSoft must be aware of up to eight endpoints.
LightSoft can assist in their selection. Only two or four endpoints must be selected manually and the
remaining automatically, provided:
 A protection group (PG) is present on at least one trail side,
and
 The Auto select sink-source partner and PG peer checkbox is selected (default) (see the checkbox
description in Optical Trail Preferences in the Getting Started & Administration Guide).
If the checkbox is cleared, all the required endpoints (up to eight) must be selected manually.
The max. eight endpoints (2 x 2 x 2 = 8) that LightSoft requires comprise:
 An endpoint in each of two directions (Src for forward and Snk for backward). (Applies to
unidirectional ports only.)
If the checkbox is selected, when you select one Snk-Src partner port (e.g., Snk side), LightSoft
automatically selects the other-direction port (e.g., Src side); see Bidirectional Paired Ports. Hence
only one endpoint needs to be selected for this purpose. (This aspect is not relevant for bidirectional
ports as the directional relationship is implicit.)
 An endpoint in each of two paths (main and protection). (Applies to protected trails only.)
If the checkbox is selected and two cards have a PG-association, when you select one protection port,
LightSoft automatically selects the peer port on the associated card. Then only one endpoint needs to
be selected for this purpose; see Protection Group Object (PGO).
 Corresponding endpoints on two sides of the trail. You must select one or two endpoints each for
direction and path on the other side of the trail, in the same way as you do for the first side. (Applies
to all trail types.)
These endpoint selections are always required because, with configurable XCs and multiple
route/endpoint possibilities (for example, with a mesh topology of ROADMs), the other side endpoint
is indeterminate. The OCH trail path is not predetermined by specific hardware link/fiber connections.
(If all XCs were fixed and non-configurable, a single endpoint could define the entire trail path.)
If the checkbox is selected and PGs are present, upon the minimal endpoint selection, the companion
endpoint(s) (if applicable) are reflected immediately in the Endpoints List pane.
In this case, only certain endpoints need to be selected manually. The number and trail type are shown in
the following table.
Table 13-6: Trail type and endpoints
Trail type Number of endpoints required

Unidirectional LP One directional endpoint x two sides = 2.
Top-down-created OCH trails must be bidirectional. Trail creation by
Optical Discovery or Acquisition allows unidirectional OCH trails if
needed.
Bidirectional trails
Unprotected OCH or LP One endpoint on two sides = 2.
Protected P2P OCH or LP One endpoint on two sides = 2.

X-Protected OCH or LP With PG: One path endpoint x two sides = 2.

Without PG: Two path endpoints x two sides = 4.
With PG on only one side: 3.
Y-Protected LP With PG: 2.

Without PG: 3.
Bidirectional Y-protected OCH trails must be acquired. They cannot be
created top down via the LightSoft Create Trail procedure.
NOTES:
 The automatic selection of Snk-Src partner port mechanism applies only to bidirectional
OCH or LP trails.
 The Scheme parameter in the Trail List window Trail Parameters pane Protection tab
shows:
 None if PGs are present in the trail.
 User Defined Protection if no PG is present in the trail. Hence, regardless of whether
the Auto select sink-source partner and PG peer checkbox was selected in the trail
preferences, all required endpoints were manually selected without LightSoft
assistance.
See Trail Properties Pane - Protection Tab.
Parent Topic
13.4.3.4.2 OCH Trail Endpoint Validations

The following endpoint compatibility validations are performed when an OCH trail is created:
 Forward Error Correction (FEC)
The FEC type at both endpoints must be equal. Possible values are No-FEC, FEC, and EFEC. There is no
warning of incompatibility. The trail is still created even if an incompatibility is present.
 Payload type
Payload type of the two endpoints must be equal. If the trail is created using the Create Trail window,
a warning appears if they are not. (There is no warning if the trail is created using Optical Trail
Discovery.) The trail is still created even if an incompatibility is present.
NOTE: For certain optical cards, automatic validations of trail endpoints compatibility are
limited. For example, for continuous bitrate cards, compatibility of bitrate settings at each end
is not verified. You must view the trail Payload Type attribute determined by the trail
endpoints' client type setting to ensure that the settings are consistent.
Parent Topic

13.4.3.4.3 OCH Endpoint Channel Selection

Selecting an OCH trail endpoint also requires ensuring that the Src line card port has a valid channel
selected and that the Src line card port channel is compatible with channels set on other trail objects.
The channel on line cards can be:
 Configured as part of LightSoft Create Trail endpoint port selection, as described in Provisioning OCH
Trails.
NOTE: The channel setting is independent of the actual Create Trail process and any selection
takes effect in the network immediately, whether or not a trail is subsequently activated.
 Adjusted via the Properties for Port window; see Port Properties - Optics Tab.
 Preconfigured in the EMS, appearing automatically in LightSoft. The EMS-configured setting can be
changed in LightSoft as allowed by compatibility requirements. (This may be limited if the port is
connected to non-ROADM equipment.)
“Zero” indicates no channel is currently configured. A valid channel value must be set before the endpoint
can be usable.
The following considerations apply to endpoint channel selection:
 Mux/DeMuxes have physical ports with built-in channels. Hence, a TRP or CMBR line port connected
to a Mux/DeMux must be set according to the channel on the adjacent link, or to Zero. Other channels
are not selectable.
 In general, line ports of cards connected without Mux/DeMuxes between them can be set to any
channel.
 Because of configurable XCs, a ROADM’s logical ports can be set to any frequency.
 Channels set in LightSoft are automatically downloaded to the EMS.
Parent Topic
13.4.3.4.4 Spreading/Spacing Channel Validations

An OCH trail that starts with 100 GHz spread cannot traverse OMS (server) trails of 50 GHz spacing. You can
opt to skip this validation by clearing the Validate Channel Spread/Spacing option in the Preferences
window, as explained in Optical Trail Preferences in the Getting Started & Administration Guide.
Parent Topic

13.4.3.4.5 OCH Trail Channel Notes

OCH trails may have multiple channels, either a different channel in each direction or a longitudinal split in
one direction, with one channel up to a point continuing on another channel. If a trail is created with a
single continuous channel from end to end in a direction, it must have the same channel along the whole
path.
Trails with different channels on Src and Snk ports are supported only on Mux/DeMux devices, not on
ROADMs.
The channel in use at the input of a receiver (TRP or CMBR) is assigned the channel value "zero", meaning
its channel is determined by the transmitter.
SDH cards have single bidirectional ports (not two related unidirectional ports) and connect to two ports in
the MD (Snk and Src). As the transmitter and receiver are in the same port (a transceiver port), the same
(non-zero) channel is indicated for both transmitting and receiving.
Therefore a "zero" channel is indicated only on receive (Snk) ports and never on transmit (Src) or
bidirectional ports. If this is not the case, or if any other channel mismatch is present, the trail is not
created.
Parent Topic
13.4.3.4.6 OCH Segment and Channel Selection

The trail creation process, described in Provisioning OCH Trails , optionally includes selection of specific
segments that the trail should span, thereby partially or fully predetermining the trail path. Typically, a
single segment selection suffices to force completion of remaining segments along the intended path.
If segments are not selected, LightSoft defines the top-down OCH trail path according to PathFinder
optimization considerations, as follows:
1. PathFinder prefers paths that have the least number of segments.
2. PathFinder then prefers paths where all segments have the same Src endpoint channel (Src Fwd at
one end, Src Bwd at the other) as the Src endpoint. (Snk endpoint frequencies do not affect the
process.)
3. The same-channel paths take precedence over paths where the channel is changed by a regenerator.
4. Other optimization mechanisms may apply; see Protected Trail SRLG Intersection Minimization.
User segment selection may be helpful for the following purposes:
 PathFinder may have to be explicitly guided to a regenerator that must be in the trail path. This is
done by selecting the segment that precedes the regenerator.
 PathFinder selects a path that is optimal from the topology map perspective but impractical in terms
of photonic characteristics of the network. For example, the optical signal noise ratio (OSNR) may be
too high. PathFinder may need to be manually guided to a path that meets OSNR specifications.

Channel selection on a segment

You can optionally select resources on the selected segments.
 OCH: A specific channel; see the relevant step in Provisioning OCH Trails.
 LP: Specific SPO resources; see LP Trail SPO Resource Selection.
If resources are not selected, LightSoft assigns resources automatically according to PathFinder
optimization considerations.
Parent Topic
13.4.3.5 Viewing and Modifying Routes

This section describes how to manage, copy, and delete routes.
Parent Topic
13.4.3.5.1 Copying Routes

Copying routes allows you to easily create multiple routes that differ by only a few segments.
You can copy an existing route to any empty route position or to the position that follows the last used
route. For example, if a path has a Primary route, and Secondary routes number 1 and 3, you can copy one
of these routes either to the “empty slot” (Secondary 2) or to a new position which is Secondary 4.
(Secondary routes are not necessarily consecutively numbered. There may be gaps in the sequence.)
Routes are copied as a whole, including all the segments of the selected route.
Routes can be copied both before and after the trail is completed.
The Copy operation does not apply to bridge nodes or segments.
To copy a route:
 In the Resource tree, right-click the route and click Copy Route. A submenu opens with a list of open
slots from which to choose.
Parent Topic

13.4.3.5.2 Managing Routes

You can perform the following actions in the Edit Trail window:
 Add Secondary routes to a multiroute trail. This is done the same way as creating a trail; see Creating
Multiroute OCH Trails.
 Copy routes; see Copying Routes.
 Edit segments on any route.
 Add routes, by explicitly selecting segments or letting PathFinder auto-complete the routes, in
essentially the same way as in trail creation.
 Change a multiroute OCH trail to a regular OCH trail by clearing the Multiroute checkbox. All
Secondary routes associated with the trail are deleted.
 Change an unprotected regular trail to a multiroute trail by selecting the Multiroute checkbox. The
Protection value becomes Multiroute and the existing path becomes the Primary route. You can then
add Secondary routes as needed.
 Change a protected non-multiroute OCH trail to multiroute by selecting the Multiroute checkbox. The
existing paths become the Primary routes. You can then add Secondary routes as needed.
 Edit a non-ASON OCH trail as a server trail for ASON protected ODU and LP trails. Edit the OCH trails
and select the Build ASON Data Link checkbox to designate the OCH trail as an ASON data links (see
Provisioning OCH Trails).
NOTE: Changing routes is traffic-affecting. Changing XCs used by the Primary route is
non-traffic-affecting.
Parent Topic
13.4.3.5.3 Deleting Routes

You can delete any routes of a path (Primary or any Secondary). Other routes are not affected and the
numbers of remaining Secondary routes do not change. (Gaps in the route number sequence are allowed.)
If routes are deleted from the Resource Tree pane but the number of routes in the Basic Trail Parameters
pane remains unchanged:
 If the Path Completion Method is Auto Complete or Custom Completion, when Complete is run,
LightSoft creates other routes instead of the deleted ones.
 If the Path Completion Method is Explicit Selection, deleting routes from the Resource Tree pane is
sufficient.
You cannot delete routes simply by reducing the number of routes in the Basic Trail Parameters pane.
LightSoft regards this as a problem and issues a warning.

To delete a route from a path:

 Right-click the route’s node on the Resource Tree and select Remove.
OR
 Right-click a segment under the route’s node, and select Remove All. This acts only on a route’s
segments and not on segments of the whole path.
OR
 Delete all the segments under the route node, one by one, by right-clicking a segment and clicking
Remove.
Parent Topic
13.4.3.5.4 Deleting ASON Optical Data Links

You can delete an ASON Data Link from an OCH trail. Before you start, delete any ASON trails (LP or ODU)
that traverse the OCH trail that you want to edit.
To delete an ASON data link from an OCH trail:

1. Select the Optical or OCH topology layer.
2. In the Trails tab, in the General group, click Edit Trail. The Edit Trail window opens.
3. In the Basic Parameters tab, clear the Build ASON Data Link checkbox.
4. Edit the trail parameters, as required.
5. Click Complete. The trail is edited, and the ASON data link(s) removed.
Parent Topic
13.4.3.5.5 Viewing Multiroute Trails

Multiroute trails are colored in the trail map, as follows:
 Main and Protection paths are pink and blue, respectively.
 Segments used by both a main and a protection path route are colored purple.
 All routes of a multiroute path have the same color.
In the Resource Tree pane, a multiroute trail's main and protection nodes have subnodes for all their
routes:
 Primary route node is labeled Primary.
 Secondary route nodes are labeled Secondary n (n = 1 to 16), ordered by the route number. The
Secondary route numbers are not necessarily sequential and may have gaps.

Selecting path or route nodes or segment leaves in the Resource Tree pane highlights the corresponding
segments in the map.
In the Resource List pane, the Path column for regular OCH trails is represented as Route for multiroute
OCH trails. The values in that column are Primary or Secondary n, where n is the route number.
Figure 13-26: Resource tree representation of multiroute trail with DRI bridge
Parent Topic
13.4.3.6 OCH Trail Supporting and Reference Information

This section provides supporting and reference information that may be useful when creating OCH trails.
Parent Topic
13.4.3.6.1 X and Y Protected OCH Trails

X protected trails
Optical trails with four or eight endpoints are referred to as X-protected and can be created top down. The
Trail Parameters pane Trail Type is X.
Y protected trails
Optical trails with three endpoints are referred to as Y-protected and can only be acquired. The Trail
Parameters pane Trail Type is Y.
X and Y virtual links

X and Y trails project X and Y virtual links on other layers:
 OCH X and Y trails as virtual links in the OCH layer; see OCH X and Y Virtual Links.
 LP X and Y trails as virtual links in the Ethernet and SDH layers; see LP X and Y Virtual Links.
Parent Topic

13.4.3.6.2 FTM/PELES and OCH Link/Trail Creation in LightSoft - Workflow

FTM is an EMS feature that sets up a functional topology map. In the process, it assists card configuration
and automatically receives the OTM and OPS links from the EMS. In addition, FTM is a prerequisite for
running the EMS Enhanced Automatic Power Control (Enhanced APC) feature, also known as Power
Equalization of Optical Links (PELES). See the EMS-MPT User Guide.
The following is a summary of OCH topology link and link creation with different configurations. For the
detailed procedures, see the EMS-MPT User Guide.
OCH topology link creation
If FTM is installed:
1. Create topology links in FTM.
2. Upload links from FTM to LightSoft.
If FTM is not installed:

 Create topology links in LightSoft; see Creating Topology Links.
OCH trail creation/deletion

See also Provisioning OCH Trails and Other Actions on Optical Trails
In a non-ROADM network, or if PELES/FTM is installed:

1. Create/delete OCH trails in LightSoft.
2. Perform “repair chains” using PELES.
In a ROADM network, or if PELES/FTM is not installed:

1. Create or delete OCH trails in LightSoft.
2. Manually update the number of channels in the EMS with power equalization using APC.
Parent Topic

13.4.3.6.3 Multiroute OCH Trails

Multiroute OCH trails provide an additional measure of protection for optical traffic. Each path on the trail
(main path of an otherwise unprotected trail, or main and protection paths of a protected trail) can have
multiple routes for additional redundancy. The following example shows a simple "unprotected"
bidirectional OCH trail, whose single (main) path has two routes - one primary and one secondary.
Figure 13-27: A1: 1 trail, 1 path, 2 routes
Multiroute paths are supported by restoration-capable cards, such as ROADM8A, ROADM8A50, or

TRP10_4, in a regenerator configuration where on-board traffic protection can be used to create multiroute
paths. Some typical topologies are described in A: Multiroute Topologies.
A multiroute OCH trail's main and protection paths each have the following routes:
 One Primary route - generally the path's most diverse route, having the least resources in common
with other routes of the same path.
 One or more Secondary routes.
The primary route of the main path is regarded as the trail's active route, while the primary route of the
protection path is regarded as the standby route (route on the inactive path that becomes active when a
protection switch occurs at the endpoints).
Multiroute trail characteristics

 A trail is considered multiroute if at least one of the paths has multiple routes.
 Routes of the same path must all converge to a single endpoint on both sides.
 Routes of the same path may have overlapping segments but cannot overlap completely in any
direction. (Routes of different paths may have overlapping segments, even using the same channel.
This means a XC leg may carry routes belonging to both paths.)
 Main and protection paths may use different channels. The paths and their routes may also use
different channels in forward and backward directions.
 As with other OCH trails, multiroute trails support both X and Y protection topologies; see Y protection
example schematics 6 and 10 in A: Multiroute Topologies.
 A multiroute topology can include a mix of:
 Equipment that supports unidirectional OCH XCs
 Equipment that supports only bidirectional OCH XCs
Parent Topic

13.4.3.6.4 Optical DRI Bridges

In network topologies with restoration-capable cards, DRI bridges can enhance trail protection. Additional
connections can be created between main and protection endpoints on either side of the trail. These
protect the trail in even more multiple fiber-cuts scenarios than when connections are limited to the same
path endpoints.
Depending on the topology, this can be done in two ways:
 DRI connections for both main and protection connections traverse a single link. Therefore, all four
channel streams between the two sides (main and protection in each trail direction) all share the same
link. To enable this configuration, traffic in each trail direction must use a different channel. This is
illustrated in the following figure, where eastbound traffic uses channel 22 (green line), and
westbound traffic uses channel 21 (pink line).
Figure 13-28: B2: Optical DRI bridge type B with two sub-bridges
 DRI connections for main and protection connections traverse two separate links. Therefore, traffic on
the four channel streams between the two sides (main and protection in each trail direction) can all be
configured on the same channel. This is illustrated in the following figure.
Figure 13-29: B1: Optical DRI bridge type A
Parent Topic

Optical DRI Bridge Characteristics

Optical DRI characteristics
Optical DRI bridge is supported for trails in the following cases:
 Supports uni- and bidirectional trails. The DRI bridge directionality is the same as that of the trail.
 For OCH trails, both paths should use the same channel in a given direction (forward or backward), if
applicable.
OCH bidirectional trails support the following optical DRI bridge types:
 Type A: Symmetrical or asymmetrical OCH bidirectional trails; see Example B1.
 Type B: Asymmetrical bidirectional OCH trails only; see examples B2 and B3.
OCH trails can be symmetrical or asymmetrical (different channels in forward and backward directions).
Optical DRI sub-bridges

 An optical DRI bridge must contain exactly two DRI sub-bridges.
 Each sub-bridge must contain directions, as follows:
 Bidirectional OCH trail: Both forward and backward directions.
 Unidirectional OCH trail: Only forward direction.
 Each sub-bridge has two endpoints, which are the Switch TP of an OCH XC (applies to both uni- and
bidirectional trails, including asymmetric trails).
 A sub-bridge must connect at least one main-path route on one side of the sub-bridge to at least one
protection-path route on the other side of the sub-bridge such that a main endpoint on one trail side
is connected to a protection endpoint on the other trail side. (This ensures the DRI sub-bridge does not
connect main and protection endpoints on the same side of the trail.)
 A sub-bridge may contain one or more server trails or links, and two or more XCs.
 XCs, server trails, and links used by a sub-bridge can also be used by other routes of the trail that
contain the sub-bridge.
 Sub-bridges are not related to specific routes; they are related to the paths.
The following two characteristics ensure that the pair of sub-bridges constitutes a genuine optical DRI
bridge and are not two unrelated sub-bridges:
 The sub-bridge endpoints are designated as main or protection, as follows: If you follow the track that
traverses the sub-bridge from the trail’s main endpoint to the protection endpoint, the first sub-bridge
EP you encounter is called the main while the second one is called the protection.
 To be a valid optical DRI bridge, the two sub-bridges must have at least one direct connection
between:
 The degree ports of their main EPs.
 The degree ports of their protection EPs.
Parent Topic

Comparing DRI Bridging and Multiroute Protection

The introduction of restoration-capable cards enabled the creation of multiroute trails and/or optical DRI
bridges.
A Multiroute trail can have several routes traversing different segments, but sharing the same endpoints.
Routes can be part of either the main or protection trail, but cannot connect main to protect starting at a
main endpoint of one side and end on a protection endpoint on the other side or vice versa.
In contrast, the function of a DRI bridge is to connect the existing main and protection paths, and so
provide additional protection. Traffic flows from the main endpoint on one side, and bridges to the
protection path where it continues. The bridge itself does not carry the traffic end-to-end.
Adding a bridge between the rings allows for the occurrence of up to two failures on the main and
protection at the same time. In the simple case of main and protection paths at the top and bottom of two
rings, if a fiber fails on the main path, traffic can jump to the Protection path. The bridge facilitates the flow
of traffic from the remaining intact segment on the main path, providing a bridge over to the intact
segment of the protection. Similarly in the event of a protection path failure, main and protection are
related and can protect each other.
Figure 13-30: DRI bridge bypassing failures on main and protection paths
Optical DRI differs from SDH DRI:

 From XCs and topology points of view.
 Optical DRI has two sub categories, A and B.
Bridge-like functionality without a bridge

Multiroutes can be used to simulate the functionality of the DRI bridge.
A main path secondary route can overlap or use the same XC legs as a protection path secondary route,
intersecting at a common segment. If both of these routes use the same frequency (color) (for example,
each path transmitting in Freq 21), then the intersecting fiber has only one instance of Freq 21 and traffic
can flow two ways. This results in bridge-like functionality without building a bridge.
Parent Topic

13.4.3.6.5 Regenerator Expected in OCH Trail Path

If the channel was not assigned, following the topology link creation, then before starting the OCH trail
creation activities, you need to assign the regenerators to Src port channels in each direction. Otherwise
PathFinder will perceive a discontinuity and ignore the path that includes the regenerator. The regenerator
configuration can be done:
 In the EMS – using the Card Setup option or the Module Info tab; see the relevant EMS User Guide.
 In LightSoft – in the Properties for Port window; see Port Properties - Optics Tab.
Once the frequencies are set, PathFinder can consider including the regenerator in the trail path.
You can direct PathFinder to traverse the particular regenerator by selecting the preceding segment (in the
same way as with other equipment); see the segment selection step in Provisioning OCH Trails.
The following channel selection conditions apply (Otherwise the trail will not complete):
 The regenerator Snk port must have the same channel as the preceding endpoint.
 The regenerator Src port must have the same channel as the other side endpoint.
 Regenerators cannot be set with four different frequencies (asymmetric), only to two.
Only Regenerator Src ports can be configured, meaning each Src/Snk has the same frequency.
Regenerator ports behave like add/drop (line) ports in all configuration aspects (for example Laser state
configuration).
Parent Topic
13.4.3.6.6 ROADMs and AoCs Automatically Configured

ROADM and AoC cards are configurable, either manually via the EMS or automatically through LightSoft
trail creation.
 LightSoft determines the optimal OCH route over a mesh of ROADMs where XCs are not known in
advance, and automatically configures the ROADM XCs.
 AoC cards involved in LP trails are similarly automatically configured.
Parent Topic

13.4.3.6.7 System Limitations - OCH

1. Not supported:
 P2MP of unidirectional OCH trails
 Path finding of multiple routes simultaneously
 Path finding of routes with user defined priorities (e.g. ignore route diversity)
 Completely automated path finding of Optical DRI bridges
 Segment exclusion in path finding
 Channel finding (the user must specify the channel)
 CWDM and DWDM channels on the same fiber
 16 CWDM channels
 A number of UMEs (e.g. 80 channel MD UME)
 Bidirectional OMS on a single fiber
2. Reason for the failure of path finding is not shown clearly
3. Individual routes are undistinguishable in the map (e.g. cannot show two routes simultaneously)
4. Active route is not shown in the same map with the rest of the trail’s routes
5. Direction of active route is not shown
6. Optical impairments are not taken into account in path finding
Parent Topic

13.4.3.6.8 OCH Trail Use Cases

Optical devices accommodate two directions of transmission (bidirectional OCH trail), using either
unidirectional or bidirectional ports.
Transponders and combiners are pure optical cards with unidirectional ports where the Snk and Src are in
different objects. In the diagram below, each transponder uses OPS_Src and OPS_Snk ports to separately
connect the westside Mux and DeMux.
Figure 13-31: OCH Trail Use Case 2
In the diagram below, the card's related unidirectional ports OPS_Src_1 and OPS_Snk_2 connect to the
westside Mux and DeMux, while the unidirectional ports OPS_Snk_1 and OPS_Src_2 connect to the client
equipment.

SDH cards with bidirectional ports having Snk and Src in a single object connect to both the input of a Mux
and the output of a DeMux. In the diagram below, each SDH card uses a single port to connect to both the
westside Mux and DeMux.
Figure 13-32: OCH Trail Use Case 2
In the diagram below, the card's bidirectional port OPS_1 connects to the west Mux and DeMux, while the
bidirectional port OPS_2 connects to the client equipment.
Parent Topic
13.4.4 Displaying the Active Route/Path

You can display the active route of any OCH trail, or ASON-protected trail in the trail map. The active route
is presented on demand and is not refreshed automatically.
The active route appears in the map and the resource tree. Segments are colored according to the trails to
which they belong.
In the Resource Tree pane, active route segments are shown under their respective route/bridge nodes.
This means:
 An active segment that belongs to several routes is shown under all of them.
 Active segments that are shown may not comprise the whole route.
If the active routes in the forward and backward directions do not overlap, both appear in the map
(directionality is not indicated).
If the OCH trail is protected but has no PGs, then the active routes of both main and protection routes
appear in the map. (LightSoft does not distinguish which specific route is active.)

To present the active route in the map:

 Right-click a trail in the trail list, and select Show > Show Active Route (operation allowed only for one
trail at a time).
To see the active route in parallel to the whole trail:

1. Open two instances of the trail list.
2. Present the active route in one while presenting the whole trail in the other.
To view the active route for an ASON protected trail:

1. In the OCH layer, click Trails and then Trail List. The Trails List window opens.
2. To view the active route, click (Show Active Route). The active route is highlighted in blue.
Parent Topic
13.4.5 Provisioning ODU Trails

ODU trails are end-to-end optical trails that represent the ODU layer signal. An ODU trail may act as a
server to one or more LP trails, or multiple lower-order ODU trails, or a combination of LP and ODU trails.
Prerequisites
Before starting ODU trail creation, verify that the necessary server topology has been configured, including
the underlying physical ports and links, as well as the OMS and OCH trails.
To create an ASON-protected ODU trail:
 Ensure that the underlying OCH trails are configured as an ASON trails (see Provisioning OCH Trails).
 Ensure at least one segment of the trail is an ODU short server trail.
 ASON-protected ODU trails can only be created where the capacity is ODU0, ODU1, ODU2, or ODU2e.
 For DRI protected trails, see also DRI Protection
ODU trail creation workflow

The following steps represent the workflow for creating an ODU trail:
1. Define the basic ODU trail parameters.
2. Define the advanced ODU trail parameters.
3. Select endpoints.
4. Select the path completion method. During path completion, you can optionally define selected parts
of the path, or the entire path that each route traverses. Alternatively LightSoft can define the route
automatically.
5. Complete and activate the trail. LightSoft can calculate the optimal path that each route traverses, or
you can define part or all of the path explicitly.

To create individual ODU trails:

 Label and Customer name (optional); see the parameter description in Basic Trail Parameters
Pane.
 Rate: Select ODU.
 Capacity: Select one of the following capacity options:
ODU1, ODU2 (default), ODU2e, ODU3e, and ODU4.
 Protection:
 For non-ASON trails, select either:
Unprotected: Trail is unprotected and has a main path only.
Current: Trail is protected in the current layer only. Trail has a main and protection path.
Underlying: Main path with underlying protection (at least one segment of the trail is
protected by the underlying layer).
Current & Underlying: Trail is protected on both the current and the underlying layer.
See Optical Trail Protection and the Protection type definition in Trails Pane Columns.
 For ASON protected trails, in the Advanced Protection area, select the ASON checkbox and
then select either:
1++ (Gold); 1+1+R (Silver); or 1+R (Bronze). For details see ASON Optical Trail Protection.

 Directionality: Select either:

 Unidirectional: transport traffic in one direction.
 Bidirectional: transport traffic in two directions.
6. Configure protection settings in the Advanced Protection pane, where relevant; see Defining Trail
Protection. To configure DNI protection, select the DNI checkbox (selected by default). When
selected, LightSoft configures DNI protection automatically, where relevant. To configure DRI
protection, see DRI Protection.
Deleting Trails.

10. Right-click an LE in the map and choose Select Endpoint. The Endpoint Selection window opens. The
ports that are free and conform to the selected trail rate and capacity are available for selection.
11. Select endpoint ports. At this point, you may either select specific resources yourself, or have
LightSoft select the appropriate port resources for you automatically.
a. If you prefer to have LightSoft complete the resource allocation process automatically, click
Select Port. The selected endpoints are reflected in the Endpoints List pane.
b. If you prefer to explicitly select a port resource, choose a specific resource from the table of
resources available for the selected port, displayed to the right of the endpoint tree, and click
Close.
When provisioning an ODU trail, LightSoft organizes the available resources by ODU rate
capacity, displayed in a series of ODU tabs in the Select Resource pane, as illustrated in the
preceding figure. By default LightSoft opens that pane, if relevant, with the ODU tab that most
closely matches the trail being provisioned.
Note that for bidirectional trails, you must select the same resources in both directions.
CAUTION: If you prefer to manually choose port resources, do not click Select Port or
LightSoft will disregard the manual resource selections and choose port resources
automatically.
12. (Optional) You may optionally choose to select specific segments that the trail should span. In the
window map, for each segment that you want to include, right-click the segment and choose Select
Segment.

The selected segment is reflected in the Select Segment pane, highlighted in the preceding figure.
13. (Optional) You may optionally choose to select a specific server trail from the list of servers that have
been provisioned for that segment (usually OCH trails or high-order ODU trails). Choose a server trail
from the Select Server Trail pane, highlighted in the preceding figure.
14. (Optional) You may optionally choose to select a specific resource from the table of resources
available for allocation for the selected segment (or server trail, if selected). Resources appropriate to
the trail configuration you have specified are displayed in the Select Resource pane, highlighted in the
preceding figure.
For example, if you are provisioning an ODU trail with ODU1 rate capacity, LightSoft organizes the
available resources by ODU rate capacity, displayed in a series of ODU tabs, as illustrated in the
preceding figure. In this case, LightSoft opens that pane with the ODU1 tab displayed, since that is the
rate that most closely matches the trail being provisioned.
the following:
a. Finds the path between the endpoints, optimized according to PathFinder criteria. If trail
parameters are not specified, LightSoft sets default values; see Optical Trail Parameters. If a
path between the endpoints is not found, a failure message is generated.

c. Validates the compatibility of the endpoints.
 Label and customer, if set differently in Step 4
 AMM state
Parent Topic
13.4.6 Provisioning LP Trails

LP trails are end-to-end optical trails representing the client input signal, typically traversing between client
equipment endpoints. Endpoints may be at objects represented within LightSoft or may be at UMEs. If not
connected to client equipment that is represented in LightSoft, the LP trail terminates in the client port of
the transponder, combiner, or fabric card. See Optical Trails.
LP trails can be created individually using the procedure in this section. Their prerequisite OMS, OCH, and
ODU server trails (where needed) must already exist before beginning LP trail creation; see Provisioning
OMS Trails.
Protected LP trails can be configured for P2P and P2MP trails with X-protection or Y-protection. The
following unprotected LP trail types and directionalities support top down trail creation as described in this
section:
 P2P trails (unidirectional and bidirectional)
 P2MP (unidirectional)
Trails can also be created by acquisition (see Creating Optical Trails Through Discovery and Creating LP
Trails with TCI).
A P2MP LP trail can be configured as either protected or unprotected, and can be used as a server or
service trail, as needed. An unprotected P2MP LP trail is configured with a single Add endpoint and multiple
Drop endpoints. A protected P2MP trail can be configured with either two Add endpoints (where the EP
paths are Main and Protection), or a single Add endpoint (where the EP path is defined as Both). In a
protected P2MP trail, the path value for all Drop endpoints must be defined as Both.

The trail topology can include multiple branching points, enabling creation of a hierarchical tree topology.
Branches are implemented through configuration of up to four branching ports in a switching node. When
designing the trail path, ensure that no branch subsequently re-enters a switching node along the trail path.
A typical unprotected P2MP branching trail topology is illustrated in the following figure.
Figure 13-33: Unprotected P2MP LP trail topology
If the user creates a P2MP LP trail that has a peer trail, then once the first EP of the new trail is selected and
its directionality is confirmed to be identical to that of the peer trail, LightSoft automatically completes all
the other EPs of the new trail, to match the EPs of the existing peer trail. This convenient service is
automatic; the user is notified and allowed to cancel the action.
An LP trail path must traverse the same path type as the underlying OCH trail. So, for example, the main
path of a P2MP LP cannot traverse the protection path of an underlying Y protected OCH trail. When
working on classic equipment, multiple LPs can be defined on the same OCH, which is useful in the case of
combiners. When working on standard equipment, LP trails may incorporate the relevant ODU components
in a unified LP-ODU trail.
To see the ODU components included in an LP trail, open the Trails List window and select the LP trail of
interest. If the trail includes an ODU component, the rate of the ODU is listed in the ODU Components
attribute for that trail. You may also select a trail in the list, right click on that trail, and select the Show
ODU Components menu option.

Prerequisites when creating an ASON-Protected LP Trail:

To create an ASON-protected LP trail:
 Ensure that the underlying OCH trails are configured as an ASON trails (see Provisioning OCH Trails).
 Ensure at least one segment of the server trail is an ODU short server trail.
 ASON-protected LP trail capacity must be either:
 Any (Non-SPO) or
 ODU-Structured with one of the following values: STM-1, STM4, STM-16, STM-64, FC-1G, FC-2G,
FC-8G, FC-10G, GbE, 10GbE.
General prerequisites for optical trail creation are described in Introduction to Optical Trail Provisioning.
To create individual LP trails:

Figure 13-34: Creating LP trails: basic trail parameters
 Label and Customer name (optional); see the parameter description in Basic Trail Parameters
Pane.
 Rate: Select LP.

 Capacity: Select the appropriate capacity for this trail.

 Any (Non-SPO): Default. For ASON trails, this option must be selected. Not relevant for
AoC cards.
 SPO-Structured: A choice of STM-1, STM-4, STM-16, FC-1G, FC-2G, FC-4G, GbE, and GbE-8.
Generally used for AoC cards.
 ODU-Structured: A choice of STM-1, STM-4, STM-16, STM-64, FC-1G, FC-2G, FC-4G, FC-8G,
FC-10G, GbE, 10GbE, 100 GbE, Video-270, HD-SDI-1485, and HD-SDI-3G.
 Protection: For non-ASON trails, select either:
 Unprotected: Trail is unprotected and has a main path only.
 Current: Trail is protected in the current layer only. Trail has a main and protection path.
 Underlying: Main path with underlying protection (at least one segment of the trail is
protected by the underlying layer).
 Current & Underlying: Trail is protected on both the current and the underlying layer.
See Optical Trail Protection and the Protection type definition in Trails Pane Columns.
 Protection: For ASON trails:
 Ensure that the capacity selected is either Any (Non-SPO) or ODU-Structured with one of
the following values: STM-1, STM4, STM-16, STM-64, FC-1G, FC-2G, FC-8G, FC-10G, GbE,
10GbE.
 Select the ASON Protection level you require:
1++ (Gold); 1+1+R (Silver); or 1+R (Bronze). For details see ASON Optical Trail Protection.
 Directionality: Select either:
 Unidirectional: Transport traffic in one direction (not supported for ASON trails).
 Bidirectional: Transport traffic in two directions.
NOTES:
 The capacity rate selection must be compatible with the port capacity available along the
trail path. Otherwise PathFinder will not find a suitable path.
 When provisioning a new LP trail, you may choose to keep the Any default capacity
selection even if you are working with SPO or ODU structured capacities. However, if
LightSoft realizes during trail completion/activation that one of the ODU options would be
more appropriate for this path, LightSoft changes the setting accordingly.
 For ASON LP trails, you must select either Any (Non-SPO) or ODU-Structured with one of
the following values: STM-1, STM4, STM-16, STM-64, FC-1G, FC-2G, FC-8G, FC-10G, GbE,
10GbE.
6. Configure protection settings in the Advanced Protection pane, where relevant; see Defining Trail
Protection. To configure DNI protection, select the DNI checkbox (selected by default). When
selected, LightSoft configures DNI protection automatically, where relevant. To configure DRI
protection, see DRI Protection.

Deleting Trails.
8. If the LP trail has an Ethernet payload type, select the View on Ethernet Layer checkbox if the trail
should be visible as a virtual link in the Ethernet layer; see Trails and Virtual Links.
TIP: LightSoft automatically configures DNI XCs for top-down-created protected LP trails on
XDM AoC ADM cards, and Apollo platforms. DNI applies to every LP protection topology,
regardless of card location or trail route. There is no need to set any option. See Automatic
DNI Protection for ODUk and LP Trails.

11. Right-click an LE in the map and choose Select Endpoint. The Endpoint Selection window opens. The
ports that are free and conform to the selected trail rate and capacity are available for selection.
Choose the appropriate endpoint configuration options at the top of the window: Main, Protection,
or Both, and Add, Drop, or Add&Drop.
12. Select endpoint ports and click Select Port. The selected endpoints are added in the Endpoint List
pane. LightSoft finds related endpoints where needed, working according to the endpoint selection
and trail directionality. Endpoint selection guidelines depend on the type of trail being provisioned:
 Unidirectional LP: Select the unidirectional endpoint either the Src at one end or the Snk at the
other. Ensure that the endpoints do not connect to OCH line cards that are associated for
protection, and are not connected through splitter-coupler fibers.
 Protected Bidirectional LP: Select the UME or client line card (e.g. noncolored SIO) ports that
should be the LP endpoints and are connected through splitter-couplers to line card client ports.

 P2MP Unidirectional LP: LP P2MP trails can be configured for data services with multiple
endpoints. In unprotected services, one endpoint is the Add point and the others are the Drop
points. Protected trails have two Add endpoints defined, as explained earlier in this topic. The
following figure illustrates a Select Endpoint window with one Add and one Drop endpoint
selected, as indicated by the arrow icons.
You can toggle an endpoint mode between Add and Drop through the Endpoints List:
13. (Optional) You may optionally choose to select specific segments that the trail should span. In the
window map, for each segment that you want to include, right-click the segment and choose Select
Segment.

The selected segment is reflected in the Select Segment pane, highlighted in the preceding figure.
14. (Optional) You may optionally choose to select a specific server trail from the list of servers that have
been provisioned for that segment. Choose a server trail from the Select Server Trail pane,
highlighted in the preceding figure.
15. (Optional) You may optionally choose to select a specific resource from the table of resources
available for allocation for the selected segment (or server trail, if selected). Resources appropriate to
the trail configuration you have specified are displayed in the Select Resource pane, highlighted in the
preceding figure.
For example, if you are provisioning an LP trail with ODU rate capacity, LightSoft organizes the
available resources by ODU rate capacity, displayed in a series of ODU tabs, as illustrated in the
preceding figure. By default LightSoft opens that pane, if selected, with the ODU tab that most closely
matches the trail being provisioned.
Alternatively, if you are provisioning an LP trail with SPO rate capacity, SPO resources would be
selected from a single table map, as illustrated in the following figure. For background information,
see LP Trail SPO Resource Selection.

NOTE: It is sufficient to select one resource.

If too few resources are selected for the specified rate, LightSoft automatically fills in the
remaining required resources at completion time. For example, if you know where in the
matrix you want the resources placed, you can select one resource and the remaining
resources are filled in automatically.
If too many resources are selected (e.g. 8 when a GBE LP needs only 7) the trail will not
complete.
the following:
a. Finds the path between the endpoints, optimized according to PathFinder criteria. If trail
parameters are not specified, LightSoft sets default values; see Optical Trail Parameters. If a
path between the endpoints is not found, a failure message is generated.
c. Validates the compatibility of the endpoints; see LP Trail Endpoint Validations.
 Label and customer, if set differently in Step 4
 AMM state
 AoC XC
NOTE: When provisioning a new LP trail, you may choose to keep the Any default capacity
selection even if you are working with SPO or ODU structured capacities. However, if LightSoft
realizes during trail completion/activation that one of the ODU options would be more
appropriate for this path, LightSoft changes the setting accordingly.
Parent Topic

13.4.6.1 LP Trail Endpoint Selection

Essentially the same conditions as the OCH case apply - see OCH Endpoint Selection , but with the
endpoints on TRPs (UMEs) at the ends of the path instead of MDs.
The following issues are specific to LP trail creation:
 Select LP endpoint ports according to trail directionality, as follows:
 Protected Bidirectional LP: Select the UME or client line card (e.g. noncolored SIO) ports that
should be the LP endpoints and are connected through splitter-couplers to line card client ports.
 Unprotected Unidirectional LP: Select the unidirectional endpoint either the Src at one end or
the Snk at the other. Ensure that the endpoints do not connect to OCH line cards that are
associated for protection, and are not connected through splitter-coupler fibers.
 LP trails can be created with UME, SIO (non-colored) or data card ports as endpoints for protected or
unprotected LP; see Protected LP with Endpoints in UMEs.
Parent Topic
13.4.6.2 LP Trail Endpoint Validations

The following endpoint compatibility validations are performed when an LP trail is created:
Forward Endpoint Correction (FEC)

The FEC type at both endpoints should be equal. The possible values are No-FEC, FEC, and EFEC. There is no
warning of incompatibility. The trail is still created even if an incompatibility is present.
Payload type
Payload type of the two endpoints should be equal. If the trail is created using Create Trail window, a
warning appears if different payloads are present at the endpoints. (No warning appears if the trail is
created using Optical Trail Discovery.) The trail is still created even if an incompatibility is present.
Endpoint correlation
LightSoft does not validate that the selected LP endpoint types are the same. However since resources used
by the LP are checked for consistency, inconsistent endpoint types are usually also identified For example, a
trail with a mixture of GBE and GBE8 SNCs will be disallowed because the numbers of SPO resources will
differ.
For trails on non-SPO equipment (for example transponders and combiners), consistency validation is not
available. The user should refer to the rate indications on the port labels and ensure not to choose
non-compatible ports.
NOTE: For certain optical cards, automatic validations of trail endpoints compatibility are
limited. For example, for continuous bitrate cards, compatibility of bitrate settings at each end
is not verified. You should view the trail Payload Type attribute determined by the trail
endpoints' client type setting to ensure that the settings are consistent.
Parent Topic

13.4.6.3 LP Trail SPO Resource Selection

An LP trail that traverses AoC and/or OMCM25_4 cards generally occupies a number of specific payload
object (SPO) resources.
The SPO resources available and used are represented in a resource matrix in the Select Resource pane:
 AoC resource matrix - size is OTU2 (64 SPOs).
 OMCM25_4 resource matrix - size is OTU1 (16 SPOs).
Different LP services require different numbers of SPO resources, for example:
 GBE (also known as GBE7) - 7 SPOs
 GBE8 - 8 SPOs
 FC1G - 6 SPOs
 FC2G - 12 SPOs
 STM-1 - 1 SPO
 STM-4 - 4 SPOs
The SPO resources are typically selected automatically as part of the LightSoft top-down trail creation
process, or may be selected manually if there is a special need. If selected manually:
 If too few resources are selected for the specified rate, LightSoft automatically fills in the remaining
required resources at completion time. For example, if you know where in the matrix you want the
resources placed, you can select one resource and the remaining resources are filled in automatically.
 If too many resources are selected (e.g. 8 when a GBE LP needs only 7) the trail will not complete.
For details about manual resource selection, see the resource selection step in Provisioning LP Trails.
SPO resource availability can be monitored by means of an availability map and tables.
The SPO resources may generally be distributed anywhere in the matrix and need not necessarily be
contiguous. (Exceptions apply for STM-X rates; see SPOs between AoC Cards - STM-x OTU2 Connection
Limitations.)
Parent Topic
13.4.6.3.1 SPOs between AoC Cards - STM-x OTU2 Connection Limitations

Limitations apply to SPO placement when an STM-4 or STM-16 LP trail’s endpoints are in two AoC cards:
 STM-4 and STM-16: All (4 or 16) SPO resources must be contiguous; see Resource Calculation Notes.
 STM-16 only: Resources must be at fixed offsets. Allocation of SPOs can start only in four specific SPO
numbers: 1, 17, 33, and 47 (assuming SPO numbering starts from 1).
Parent Topic

13.4.6.3.2 SPOs between Two OMCM25_4 Cards

When two OMCM25_4 cards are connected to each other (directly or via Mux devices) through aggregate
side ports, the SPOs are located in the connection between them. The resources allowed on the OTU1
depend on the port selected and required service type. Limitations apply, for example:
 Only STM-1 or STM-4 service types can be on port#3. Other service types must be set on other ports.
 Non-changeable allocation of SPOs. for example, if the OMCM25_4 client port #1 needed as STM-1, its
place in SPO matrix is fixed.
 Specific resource placement for STM-1, STM-4, Fiber Channel 1Giga, GBE7).
Parent Topic
13.4.6.3.3 SPOs between OMCM25_4 and AoC Cards

When an OMCM25_4 card is connected to an AoC card at the correct client side, the SPOs are located on
the OTU1 in the connection between them. The restrictions described in SPOs between Two OMCM25_4
Cards apply.
Once the services continue to the AoC, the up-to-16 SPO resources can be mapped to any SPO on the AoC’s
larger (64) OTU2 matrix, with the exception of the limitations described in SPOs between AoC Cards - STM-x
OTU2 Connection Limitations.
NOTE: LightSoft doesn't differentiate between card configurations (i.e. two OMCM25_4s vs.
OMCM25_4 - AoC). The SPO resource map shows the presence of each contained resource,
but not if they are available for selection – they may already be used by a trail or are
otherwise restricted. For example:
 Port #3 is restricted to STM-x service types.
 OMCM25_4 may have EMS-defined groups. Then selecting a master a resource, for
example at port 1, causes automatic and invariable and slave resource selections at port 2
to 8 (of 16). Once the master or any slave resource is selected, the entire group is
automatically selected.
Parent Topic
13.4.6.3.4 P2MP LPs involving AoC and OMCM25_4 Cards

The only required actions required in the EMS before creating the trail top down in LightSoft is to assign the
card and its ports. When the trail is created, LightSoft sends the channel, path, and XCs to the EMS. In this
case, the EMS simply adopts the LightSoft-created XCs.
Parent Topic

13.4.6.3.5 Older Card Resources

SPOs are only relevant for the OMCM25_4 and AoC cards. Older cards have two types of resources:
 TRPs and older combiners have a monolithic resource (cannot be broken down). The optical trail is a
single entity along the whole path, even though comprises several resources.
 Combiner 10T (only exception) has four resources which are ODU1s.
Parent Topic
13.4.6.4 Coupling LP Trails

Two or more trails may be associated as a single service using the Private ID attribute. You should assign
the same ID to the trails. When viewing the trails in the Trail List window, sort the list lines by Private ID to
group the trails that have the same Private ID; see Sorting List Lines.
Parent Topic
13.4.6.5 LP X and Y Virtual Links

An LP X trail (see X and Y Protected OCH Trails can project a virtual X link on other layers:
 LP X GBE trail as a virtual X link in the Ethernet layer
 LP X SDH trail (created with AoC ADMs) as a virtual X link in the SDH layer.
The protection is configured in the EMS.
Rules applying to OCH X links also apply to LP X links; see OCH X and Y Virtual Links.
Parent Topic

13.4.6.6 LP Trail Use Cases

Unprotected LP without UME
The LP trail can be created between GbE client ports of AoC or OMCM_25_4 cards without protection
association (PGO present). (An LP trail that includes transponders or combiners needs to be connected with
UMEs or SIOs as endpoints.)
Figure 13-35: Unprotected LP without UME
Protected LP with endpoints in UMEs

UME, SIO (noncolored), or data card ports for protected or unprotected LP.
The example shows the LP trail traversing from UME to UME and protected by the OCH trail.
Figure 13-36: Protected LP with endpoints in UMEs

Protected LP without splitter-coupler or UME

The LP trail can be created between GbE client ports of AoC or OMCM_25_4 cards, with or without
protection association (PGO present).
Figure 13-37: Protected LP without splitter-coupler or UME
DRI protected LP or ODU2 trail

DRI protection can be added to OCH, ODUk or LP trails (see DRI Protection).
In this example, you can see a Bidirectional DRI bridge has been added to an LP or ODUK trail
Figure 13-38: Bidirectional DRI Bridge of an LP or ODU2 Trail

DRI bridge topology using Apollo AoC cards for a LP or ODUk trail
This example shows a DRI Bridge topology using Apollo AoC Cards for a LP or ODUk DRI protected trail.
Figure 13-39: LP or ODUk DRI bridge using Apollo AoC Cards
Parent Topic
13.4.6.7 AoC Card Topology

LightSoft supports 10 Gbps Add/Drop Multiplexer (ADM) service on a double card for GbE, FC1, FC2, OTU1,
and STM-16 services. This convenient ADM on a Card (AoC) module replaces larger, more cumbersome and
complex ADM units.
AoC benefits include the ability to route client signals to different locations along the optical ring, as well as
per service selectable protection and drop&continue features, useful for E line service and multi service
applications. The AoC can also be used as a multi rate combiner up to OTU2. With all these capabilities built
in, the AoC combines the cost efficiency of an optical platform with the granularity and flexibility previously
available only in SDH networks. For more information about the range of AoC features and capabilities, see
the NPT and XDM General Descriptions.
The diagram below shows an unprotected LP starting on a UME, traversing an OMCM25_4 card on one
side, and directly through to a AoC card on the other side. (OCH trails must be created between the
OMCM25_4 and AoC card, and between the AoC cards before creating the LP trail.) The diagram shows the
following aspects of AoC connection:

 AoC ring topology.

 Two aggregating stages. LP can first traverse an OMCM25_4 card where signals are aggregated to
OTU1, and then traverse an AoC where a second aggregation is performed to OTU2.
 Non-symmetry. An LP trail that starts on one type of aggregator/combiner can terminate on a
different type.
Parent Topic
13.4.6.8 OMCM25_4 (4xAny) Combiner Card Topology

Ports of older combiners can accommodate only one service type on the same combiner. The 4xAny
combiner is more versatile, able to accommodate multiple client port types, for example, GbE and STM-4,
on the same combiner. The LPs which traverse these client ports have corresponding payloads (for
example, GbE and STM-4).
Figure 13-40: OMCM25_4 combiner card topology example
The 4xAny combiner has a variety of other important features. For example, unlike most older combiners,
LP is able to traverse the combiner. For more information, see the XDM General Description.
Parent Topic
13.4.7 Migrating non-ASON Optical Trails to ASON Protected

Optical Trails
You can migrate multiple non-ASON trails to ASON protected trails, as follows.
 OCH trails are migrated to ASON data links.
 ODU and LP trails are migrated to ASON protected trails. (ASON data links represent the server trails
for ODU and LP ASON-protected trails. Before performing migration on ODU and LP trails, you must
ensure that the relevant data links have been created.)

NOTE: Ensure the trails that you want to migrate comply with ASON trail requirements before
performing migration (see ASON Optical Trail Requirements).
To migrate multiple trails to/from ASON protection:

1. In the Trail List window select the trails that you want to migrate.
2. Right-click one of the selected trails and click Trail Operations and then ASON Operations, and then
either Add ASON Protection. The Add ASON Protection window opens, displaying a list of the trails
that are to be migrated.
3. Click OK. LightSoft migrates the trails. When migrating trails to ASON, unprotected trails are changed
to ASON 1+R (bronze) trails, and protected trails are changed to ASON 1++ (gold) trails by default. A
summary window is displayed, showing the total number of trails that succeeded or failed the
migration process.
Parent Topic
13.4.8 Defining Trail Protection

You can create either single or multiroute trails, with optional DNI or DRI protection:
 Single route protection (page 13-103): Define a main path, and optionally a protection path, each with
a single route.
 Multiroute protection (page 13-103): Define a main path and optionally a protection path, with at
least one path having two or more routes.
 DRI Protection (page 13-59): In certain network topologies, you can define additional segments (DRI
bridge) to connect the main and protection paths. The bridge provides an alternative route in the
event of a fiber cut on the main or protection route.
 DNI protection: Certain network topologies can include DNI protection. Where applicable, this is
implemented internally by LightSoft.
You can also create optical trails with ASON protection (see ASON Optical Trail Protection).
NOTE: DNI and DRI protection cannot be used in conjunction with ASON Protection.
Parent Topic

13.4.8.1 Single Route Protection
To define single route protection:

1. In the Basic Trail Parameters area of the Trail Parameters tab, clear the Multi Route checkbox.
2. In the Protection dropdown list, select the trail protection:
 Unprotected: trail is unprotected and has a main path only.
 Current: trail is protected on the current layer only. Trail has a main and protection path.
 Underlying: main path with underlying protection (on at least one segment of the trail).
 Current & Underlying: trail is protected on both the current and the underlying layer.
3. Define Advanced Parameters, if required.
4. Continue to define the path completion method; see Selecting a Path Completion Method. If you
want to define DRI protection, do so after selecting the trail completion method.
Parent Topic
13.4.8.2 Multiroute Protection

Multiroute trail protection is available when using the following ROADM types:
 ROADM8A: supports bidirectional trails only.
 ROADM8A_50: supports unidirectional or bidirectional trails.
For information about Multiroute trails, see Multiroute OCH Trails.
NOTE: The maximum number of multiroutes that can be created is limited by the topology
(up to a maximum of 16 per path).
To define Multiroute protection:

1. In the Basic Trail Parameters pane of the Trail Parameters tab select the Multi Route checkbox.
Multiroute protection options are enabled.
2. In the Protection dropdown list, select the multiroute trail protection:
 Multiroute: a single main path with two or more main routes.
 Current & Multi Route: (default) IOP protection has two paths - main and protection. At least
one path has two or more routes. (for example, one main and three protection, or three main
and no protection). Routes always have one primary route, and optionally up to 15 secondary
routes.
 Underlying & Multiroute: Underlying protection (at least one segment of the trail is protected)
together with Multiroute protection (protection consists of a single main path with two or more
main routes.)
 Current & Underlying & MultiRoute: IOP protection has two paths - main and protection. At
least one path has two or more routes. Underlying protection on one or more segment.

3. In the Advanced Protection area:

a. In the Main Routes field, enter the number of main routes (default = 2).
b. In the Protection Routes field, enter or select the number of protection routes (default -=2; max.
= 15). Not available for Multiroute (single main path only) protection.
c. Define Advanced Parameters, if required.
4. Continue to define the Multiroute path completion method and endpoints; see Selecting a Path
Completion Method.
Parent Topic
13.4.8.3 Automatic DNI Protection for ODUk and LP Trails

To provide the most robust protection, when creating a trail, main and protection paths should be both
node diverse and link diverse. In the event that main and protection paths must go through the same NE,
LightSoft provides an additional level of protection, automatically creating DNI protection.
Figure 13-41: DNI Protection
Although the NE remains a single point of failure, trail with DNI can still survive two fiber cuts that occur on
a different path and different side of the DNI.
Figure 13-42: DNI Provides an Alternative Path

In Apollo platforms, DNI protection is supported for unidirectional or bidirectional ODUk or LP trails that are
protected in the current layer. DNI can be created on ODUk or LP trails with four OTUn ports, (where n > k).
DNI is supported when using FIO cards only. In this way, DNI can provide an extra level of protection
without consuming additional resources.
In XDM platforms, LightSoft automatically configures DNI XCs for top-down-created protected
unidirectional or bidirectional LP trails on AoC ADM cards in XDM platforms. The following diagram depicts
an optical DNI in an XDM platform, comprising four ports - two aggregate OTU2 ports and two client OTU1
ports. In the absence of user preselections, LightSoft automatically determines the current main and
protection paths.
Figure 13-43: Optical DNI representation
To provide DNI protection on relevant topology, select the DNI checkbox during trail creation. When
checked, PF attempts to create DNI protection on every LE in the trail that is traversed by both main and
protection paths. For a bidirectional trail, all DNIs are bidirectional. The total number of DNIs in the trail is
displayed in the Trail Properties window DNI Nodes field.
NOTE: Dual Ring Interworking (DRI) is available for LP trails on XDM platforms, but must be
manually configured in the EMS. See Dual Ring Interworking.
Parent Topic

13.4.9 Selecting a Path Completion Method

Once the protection methods are specified and the number of routes defined, you can complete each trail
manually or automatically. For OCH trails, you can also use a combination of manual or automatic trail
completion.
NOTE: DRI bridge protection should only be defined after trail completion is performed.
Path completion methods include:

 Auto-complete: Enable LightSoft to calculate the entire route automatically, or select part of the route
and PathFinder selects the remaining segments. PathFinder automatically calculates the optimal route
for all main and protection routes according to the optical trail preferences defined.
 Explicit Selection: Define the entire route manually, selecting each segment that you want the route
to traverse.
 Custom Selection (multiroute OCH trails only): Select the completion method for each route
individually. For example, you can select Auto-complete for one route and Explicit Selection for a
different route.
Parent Topic
13.4.9.1 Using Autocomplete

Using the Auto-complete trail completion method, LightSoft uses PathFinder to automatically calculate the
optimal trail for all main and protection routes defined in the Advanced Protection area. It also provides
the option to explicitly select one or more segments that PathFinder must use when calculating the optimal
trail.
To create all routes automatically:

1. Select the Endpoints & Paths tab.
2. In the Path Completion Method pane, click Auto-complete.
3. Click Complete. LightSoft automatically creates the optimal trail according to the number of main and
protection routes stated in the Trail Parameters tab. Optimal trails are calculated based on the
parameters defined in the Optical Trail Preferences window.
4. (Optional) To create a DRI bridge, see DRI Protection.
5. Click Activate.

To define part of a route explicitly and use LightSoft to complete the trail
automatically:
1. Select the Endpoints & Paths tab
2. In the Path Completion Method area, click Autocomplete.
3. Select the relevant endpoints for the path.
4. Select the route that you want to include explicit segments:

5. In the Path field, click either Main or Protection.
6. (Multiroute only) In the Select Segment pane, click either Primary or Secondary, and for Secondary,
type or select the number of the route you want to define.
NOTE: A primary route must be defined before secondary routes can be defined. Give each
secondary route a different route number to distinguish between them.

7. To include a specific segment in the selected route:

a. In the map, click the segment that you want to explicitly include in the route. The links
associated with the segment are displayed in the Select Segment pane.
b. In the Select Segment pane, click the link once to include it in the specified route or click it twice
to remove it.
An icon for the route is added to the Resource Tree and each explicitly selected link is displayed
under the icon.
c. Repeat this step until all of the links that you want LightSoft to use explicitly are added (for both
main and protection routes).
8. Repeat the previous steps for all routes that you want to define explicitly.
9. Click Complete. LightSoft selects all explicit segments and calculates the optimal segments to use to
create the most efficient trail.
11. Click Activate.
Parent Topic

13.4.9.2 Using Explicit Trail Completion

Use the Explicit trail completion method to define all segments that you want a path to traverse. Explicit
selection requires you to manually define all segments for all routes traversing the same path. If any of the
required segments are missing, an error message is displayed when completing the path.
NOTE: For Multiroute paths, first define the primary route segments, and then define all
secondary routes. Each secondary route is given a separate number in the Select Segments
area of the Endpoints & Paths tab, to enable you to differentiate between secondary routes.
To define the entire route explicitly:

1. In the Endpoints & Paths tab, in the Path Completion Method area, click Explicit Selection.
2. Select the relevant endpoints for the path.
3. Select the route that you want to work with:

a. In the Path field, select either Main or Protection.
Figure 13-44: Path field
b. (Multiroute only) In the Select Segment pane, click either Primary or Secondary, and for
Secondary, type or select the number of the route you want to define.
NOTE: A primary route must be defined before a secondary route can be defined. Give each
secondary route a different route number to distinguish between them.

4. To explicitly define a segment on the selected route:

a. In the map, click the segment that you want to explicitly include in the route. The links
associated with the segment are displayed in the Select Segment pane.
b. In the Select Segment pane, click the link once to include it in the specified route or click it twice
to remove a link.
An icon for the route is added to the Resource Tree and each explicitly selected link is displayed under
the icon.
c. Repeat this step until all of the links are explicitly defined for that route.
5. Repeat the previous steps for all routes (main and protection).
6. Click Complete. LightSoft completes the trail using the segments specified.
NOTE: If not all segments are defined, an error message is displayed. Define the missing
segments and then click Complete.

8. Click Activate.
TIP: You can duplicate a route in the Resource Tree and modify it to create a similar route. To
duplicate a route, right-click the route in the resource tree, and select Copy to > New Route.
The route is duplicated in the tree.
Parent Topic

13.4.9.3 Customized OCH Trail Completion

The Custom Selection option is available for multiroute OCH trails only. Use Custom Selection to define
selected routes using Explicit Selection and selected routes using Autocomplete.
Custom Selection displays a list of all routes that have been defined with a checkbox next to each entry.
Select a route to define it using the Explicit Selection method. All unselected routes are completed by
PathFinder using the Autocomplete method.
NOTE: If you want to define only part of a route explicitly when using Custom Selection, make
sure the route is not selected in the Custom Selection dropdown, otherwise LightSoft
attempts to complete the trail as Explicit Selection and an error message generated during
path completion, asking you to define the missing segments.
To define the path completion method using Custom Selection:

1. Define all the routes for which the route must be selected explicitly; see Using Explicit Trail
Completion.
2. In Endpoints & Paths tab click Custom Selection. All available routes are listed in the dropdown list.
3. In the Custom Selection dropdown list, select each route that you want to include in Explicit
Selection. A check is displayed next to each selected route.
4. Click Complete. All selected routes are completed using Explicit Selection and all other routes are
completed using Autocomplete.
6. Click Activate.
Parent Topic
13.4.10 AoC Configuration Troubleshooting

An issue occurs intermittently with AoC ADM cards in XDM platforms, configured in specific topologies:
 Ring topologies, with AoC ADM connected to OMCM25_4 cards via OTU1 client ports.
 Mesh topologies with AoC ADM OTU1 client ports connected, as well as aggregate OTU2 ports.
The issue is not relevant to the more typical case of AoC ADM cards located at a network edge.
During SNCP-protected trail creation, LightSoft’s PathFinder may intermittently select two OTU1 ports on
the same AoC cards, so trail creation fails and the following message is displayed: "Two inputs to the same
port are not supported from the same card."

Use the following procedure when this issue occurs:

 Manually select client OTU1 ports that are on different cards of the AoC card pair.
 Assign different SRLGs to the OTU1 ports of each card, for example, SRLG1 to the ports of the first card
and SRLG2 to the ports of the second card. This forces PathFinder to assign the main and protection
ports to different SRLGs.
Parent Topic
13.5 Viewing and Editing Optical Trail Attributes

Certain trail attributes can be edited after the trail has been provisioned. Simply open the Trail List window,
select the trail, and edit attribute values in the Trail Properties pane, as described in Editing Trails. For
example, you can modify the Trail Label, Private ID, and Customer parameters, redefine the trail route, or
change the protection type. A trail’s directionality cannot be edited.
Note that OSNR Weight values for certain types of underlying equipment, such as Packet-OTS platforms,
are based on default LightSoft settings, and these values can be edited by the user. However, OSNR Weight
values that are calculated automatically by LightSoft for other types of underlying equipment cannot be
changed by the user.
NOTE: If a unidirectional LP trail is created via bidirectional ports (for example, GbE, having 7
SPOs), the other direction resources (7 SPOs) will not be available for other purposes. The
other side port will not be available, for example, for a unidirectional trail in the opposite
direction.
Parent Topic
13.6 Viewing Trail Optical Parameters

LightSoft collects and analyzes PM values for OCH trails at the trail endpoints, as described in Viewing
Current Trail Performance Data in the Performance Monitoring Guide. This data is useful for monitoring
and troubleshooting.
LightSoft also collects data for a set of Optimized Network Communications Protocol (ONCP) optical
parameters for OCH trails. This data is retrieved on request by the user and reflects the current real-time
values per port. This data is available for Apollo platforms. Note that ONCP thresholds (min, max) are
dynamic; they are updated from the EMS, with actual values depending on the underlying equipment.
When available, min and max values are included in the tooltip displayed when moving the mouse over the
parameter in the Optical Parameters table, as illustrated in the following figure.
Figure 13-45: Optical Trail Parameters table tooltip

TIP: Network operators can request optical parameter data for OCH trails and save that data
to a file for viewing and analysis in Excel. For example, the optical parameter values can be
graphed and the data from different times compared.
To view optical trail PM data:

2. In the Trails pane of the Trail List window, select checkboxes of the relevant trails.
3. Select Trail Utilities >> Optical Parameters to open the Trail Optical Parameters window listing the
current PM values for that trail.
Optical parameters are listed for each direction of the optical trails. Parameter values effectively
define the trail and the points that it traverses, uniquely identifying that trail. Trail points are listed in
the order in which they appear in the trail, organized and listed separately for each main and
protection route, running in each direction. A typical listing is illustrated in the following figure.
Figure 13-46: Optical trail parameters table
4. ONCP values can be displayed in the table in either text or chart format. Click in the toolbar
to toggle between the two formats, as described here. (Note that these features are only enabled in
the relevant data columns.)
 Text: Values are listed as numbers. Hovering over the column cells opens a tooltip with the
relevant threshold (min, max) values for that column's parameter, enabling the user to
understand the context of the current parameter value.
 Chart: Values are displayed as a colored bar filling in the appropriate percentage of the table
cell. Bar color indicates whether the value is outside the acceptable range for that parameter.
For example, if the current parameter value lies halfway between the parameter's min and max
values, then a green bar fills in 50% of the table cell width. If the current parameter value is
greater than the parameter's max value, then the value is represented by a red bar. Hovering
over a table cell with the mouse opens a tooltip with the min and max threshold values for that
table cell.

When working in Chart display format, a parameter's column edges (left and right) by default
represent the minimum (left) and maximum (right) values currently defined for that parameter.
Since different rows may represent different equipment and different min/max values, the
minimum value defined for the left side of the column is actually the absolute minimum of all
the threshold minimums and actual values for all rows in that column. Similarly, the maximum
value defined for the right side of the column is actually the absolute maximum of all the
threshold maximums and actual values for all rows in that column. In this manner, all the
colored data bars for that column can be displayed with an appropriate relative length.
Table 13-7: Trail Optical Parameters window toolbar

Draw Optical Display optical parameter values (in the relevant columns) in either text or
Parameters graphic (chart) format.
Select all Selects all trails in Trails pane.
Unselect all Unselects all trails in Trails pane.
Refresh Reloads the Trail List window and Trails pane, showing newly created trails.
All trails in Trails pane become unselected. Trails continue to be listed
according to the active filter.
Show Filter
Filters the records listed in the Trail Optical Parameters window. Opens the
Optical Performance Trail Filter selection window, similar to the filter
selection window described in Filtering Performance Monitoring Data< in
the Performance Monitoring Guide.
Open Opens a GCT session for this termination point; see Accessing EMSs.
Export to CSV Exports list data to a delimited format file like CSV for import to Microsoft
Excel or a relational database application. See Exporting to CSV.
Print selected Prints contents of Trails pane or selected trails only.
trails
Table 13-8: Trail Optical Parameter fields
Column Description
OCH and OMS trail parameters
N Number of the TP in the list.
Trail Label User-defined label for the associated trail.
Trail ID System ID for the associated trail.
ME Name ME in which the TP resides.
LE Name LE where the TP resides in the current topology layer.
TP Name Name of the TP.

Column Description
Role Role of the TP in the trail:
 Incoming: PM counters of the traffic coming into the network
 Endpoint: PM counters for the TPs of the network PM
 Intermediate: PM counters for intermediate TPs
Path Main, Protection, Both, or Mixed.
Trail Direction Direction of the trail:
 A to Z (forward)
 Z to A (reverse)
Note that the TPs are listed sequentially in the table, appearing in the order in
which they are used in the trail path route. This means that a TP may be
duplicated in the table list, since it is listed separately for each time that it
appears in a trail path route.
TP Direction Directionality of this TP along the trail path route:
 In (towards the device)
 Out (towards the fiber)
Route ID ID(s) of the route(s) to which the TP belongs in the OCH MR trail:
 Empty (non-OCH MR trail)
 0-15 (individual number for TPs that are included in one route)
 List of IDs (for TPs that are included in multiple routes)
Timestamp Time the last period started counting. If counts are unavailable (for example:
ONCP not supported by the NE, there is some loss of connectivity between the
LightSoft and the NE, or there is an equipment problem), the timestamp cell
may be empty or a reason may be provided.
Connection Type Indicates if the link for which this TP serves as an endpoint is Internal or
External.
Expected Span Loss Typical span loss, in dB, anticipated for this TP, given the underlying equipment
(accumulated) and configuration. In OCH trails, relevant only for OLP_S2 cards.
Actual Span Loss Actual span loss, in dB, measured for this TP. In OCH trails, relevant only for
(accumulated) OLP_S2 cards.
OMS trail parameters
Total Power Total power of this TP, in dBm.
Number of Channels Number of channels carried by this TP. Total number depends on channel
spacing capabilities and configuration of the underlying equipment.
Average Power per Average amount of power, in dBm, available to each channel. A function of the
Channel total power capacity and the number of channels configured for this TP.
Initial Gain Initial gain configured during installation, relevant for amplifiers only, in dBm.
Actual Gain Actual gain, relevant for amplifiers only, in dBm.
Actual RAMAN Gain Actual gain, relevant for hybrid amplifiers only, in dBm.
Actual Tilt Actual gain shape tilt value, relevant for amplifiers only, in dBm.
OCH trail parameters

Column Description
Frequency Signal wavelength, in THz (ITU grid).
Signal Type Signal type (bitrate and format).
Power Signal power, in dBm.
Dispersion Cumulative signal dispersion, in psec/nm.
OSNR Optical signal to noise ratio, in dB/0.1 nm.
PMD Cumulative Polarization Mode Dispersion for signal, in psec.
PDL Cumulative Polarization Dependent Loss, in dB.
Accumulated Cumulative signal input power, in dBm.
Nonlinearity
Spreading Identifies ability to match 50 GHz grid networks.
Overall Traveled Distance Cumulative travel distance, in km.

Estimated OSNR Margin Estimation of OSNR margin available before breaking FEC threshold, based on
periodic corrected error reports, relevant for OTU ports.
Parent Topic
13.7 Deleting Optical Trails

For information about deleting trails, see Deleting Trails.
NOTES:
 You cannot delete a trail that has clients traversing it or where the "User Usage State" is
active.
 When an optical trail is deleted, the AMM of the endpoint ports is reset to the
nonreported state.
 Optical trail deletion is traffic affecting.
 The laser is turned on/off by default when an optical trail is created/deleted; see Laser
Configuration in the Getting Started & Administration Guide.
 If Functional Topology Map (FTM) is installed, OCH trails should be created or deleted in
the EMS using FTM and uploaded to LightSoft. For more details, see FTM/PELES and OCH
 OCH trail creation or deletion may have Power Control or PELES channel implications; see
Power Control Channels and Trail Creation/Deletion.
Parent Topic

13.8 Inserting and Removing Optical Components

For information about inserting, deleting, and replacing OTN layer components to/from links, see Inserting
and Removing NEs in Links.
Parent Topic
13.9 Optical Trails Supporting Information and

Schematics
This section provides supporting information for optical trail creation, and schematics to understand
scenarios such as multiroute, optical DRI and, ODU and OCH trail topologies.
Parent Topic
13.9.1 Viewing Optical Channel Availability

Optical Availability tables show the state of channels through a selected DWDM or CWDM OMS trail. As
well as occupied (In-use) or blocked channels, the tables show channels that are both free and can be
added and dropped at the trail end sites.
The availability table menu and toolbar options offer easy navigation to OMS trails, OCH trails, and alarms.
NOTE: The LightSoft Resource Availability on Links features are important tools for network
traffic planning. At a glance you can see the available capacity in the network as a whole and
on specific SDH links/multilinks. See Viewing Resource Availability on Links.
Parent Topic
13.9 Optical Trails Supporting Information and Schematics

13.9.1.1 Optical Availability Tables

Optical channel availability can be analyzed for single or multiple OMS trails (unidirectional or
bidirectional). (Two unidirectional trails with related endpoints are considered as a single bidirectional
trail.)
The following window opens when a single trail is selected (unidirectional or bidirectional). The title bar
displays the OMS trail label.
Figure 13-47: Optical Availability Table, single trail selection
In this bidirectional trail example, the cell for channel 195.8 is , meaning In-use in one direction
and Free in the other direction. The color coding possibilities are described in detail below.
DWDM tables show cells for 40, 44, 80 or 88 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. (See also Channel Frequencies and Wavelengths.)
In both tables, each channel cell represents an intersection set of channel states per represented
direction/trail, color coded as follows:
The first three legend colors imply the same state in all directions/trails per channel:
 (white) indicates a channel is not in-use, blocked, or disconnected in a ROADM (configurable

SNCs).
 (dark blue) indicates a channel where an OCH trail traverses OMS sections. The OCH trail
originates from at least one endpoint or passes through both.
 (black) indicates a channel is blocked at one/both endpoints by a group OADM, a

red-blue filter, or a dropped channel without OCH. The Connection state of OCH CTPs of the blocked
channels in a grouped OADM is set to Blocked. In single trail availability examples, the C band eight
middle channels are blocked to use.
 (light blue) indicates different states between directions/segments per channel (not
applicable to single unidirectional trail selection), for example, a channel is:
 In use in one direction or trail and free in the other direction or other trails.
 Blocked in one direction or trail and either in use or free in the other direction or other trails.

The bottom-of-window Legend describes the color coding. The color coding is customizable; see Modifying
Availability Info Colors.
The summary at the bottom of the table shows the number of channels in each state. In the case of
bidirectional trail selections, two numbers are shown for each state, separated by a slash (for example,
2/3), showing the number of channels having that state per trail direction.
The Split Table icon is enabled for single bidirectional trail selections (or unidirectional trails with
related endpoints) and multiple trail selections. Clicking this opens individual split tables for each direction
or trail. The table headers show the direction of each segment.
Figure 13-48: Optical Availability Table after Split icon is selected
Notice that the channel 195.8, described as "Mixed" in the intersection table, is shown in the split tables as
in use in one direction and free in the other. Compare this with the original table.
Table 13-9: Utilization Table menu and toolbar options

View
Split Table Enabled for bidirectional trail selections (or unidirectional trails
with related endpoints). Opens individual split tables for each
direction.
Refresh Refreshes the Optical Availability Table window to show the
current resource availability information and color coding. The
Last Update time stamp in the right corner of the status bar
shows the date/time of the last refresh.
The window is automatically refreshed when new preferences
are applied.
Preferences Enables you to change the colors representing Available and
Unavailable statuses; see Modifying Availability Preferences in


Sub Lambda View Toggles between the Sub Lambda View, shows at a glance where
/Lambda View available LP resources can be found for In-use OMS channels
(see Sub Lambda View), and the Lambda View, which presents
the availability of channels (lambdas) for assignment to a new
OCH trail (described in this section).
When LightSoft determines if a channel is free or is In-use, it
considers ODU2 resources used by both LP and ODU trails.
Legend Shows or hides the status bar legend and Last Updated time
stamp.
Print Prints the current list or map to any Postscript network printer,
as well as to Postscript-formatted files; see Printing and
Exporting to File. For information about the report format, see
Printing and Exporting Availability Information.
Export to CSV Exports the data to a delimited format file, such as
comma-separated values (CSV), for import to Microsoft Excel or
a relational database application. See Exporting to CSV. For
information about the report format, see Printing and Exporting
Availability Information.
Close Closes the Optical Availability Table window.
Alarms
Show OMS Alarms Opens the Current Alarms window showing the alarms on the
selected OMS trail.
Show OCH Alarms Opens the Current Alarms window showing the alarms on all
OCH trails traversing the selected OMS trail.
Trails
Show OMS Trails Opens the Trail List window showing the selected OMS trail.
Show All OCH Trails Opens the Trail List window showing all OCH trails traversing the
selected OMS trail.
Show All ODU Trails Opens the Trail List window showing all ODU trails traversing the
selected trail.
Show All LP Trails Opens the Trail List window showing all LP trails traversing the
selected OCH trail. Enabled when an In-use channel is selected.
Parent Topic

13.9.1.1.1 Resource Calculation Notes

When LightSoft determines if a channel is free or is In-use,
it considers ODU2 resources used by both LP and ODU2 trails.
LP resources can be SPO, ODU, or a Non-Structured resources.
The Availability fraction for a channel with a Non-Structured single monolithic resource is either zero or 100
percent.
Channels with SPO resources (Sub-Lambda view) use SPO-Structured (a single SPO) in the calculation.
Number of SPO resources needed for each LP type:
 GbE (7), GbE8 (8), FC1G (6), FC2G (12), STM-1 (1), STM-4 (4), STM-16 (16).
STM-16 LP available SPO resource calculation restrictions:
 All 16 SPO resources must be consecutive.
 Allocation of SPOs can start only in four specific SPO numbers: 1, 17, 33, and 47 (assuming SPO
numbering starts from 1).
STM-4 LP available SPO resource calculation restriction (on an OCH with a total of 64 SPO resources
(connecting two AoC cards):
All four SPO resources must be consecutive. There is no restriction on their offset.
Parent Topic
13.9.1.1 Optical Availability Tables
13.9.1.2 Sub Lambda View

The Optical Availability Table window has two views. The main Lambda View, (described in Optical
Availability Tables) presents the availability of channels (lambdas) for assignment to a new OCH trail.
A Sub-Lambda View can also be displayed by clicking the Sub Lambda View icon in the Optical
Availability Table window menu bar. It shows at a glance where available LP and ODU resources can be
found on an OMS. It shows the fraction of available resources / the total number of resources for In-use
channels, and where their used LP resources are identical in both directions (if two directions). Color coding
on each channel indicates the fraction of available resources / the total number of resources. For example,
if a channel has a total of 16 SPOs and 14 of them are available, the table cell shows a color code for the
range 51-99% (symmetrically In-use channel in a combined table or In-use channel in a split table).

“Symmetric” in this context implies that the used resources in both directions are identical. In this view,
channels not symmetrically In-use (called Undeterminable) do not show availability of LP resources and
have a separate color code. Note that symmetry is relevant only in combined tables.
Figure 13-49: Optical Availability Table OCH Sub Lambda View
The bottom-of-window Legend describes the color coding. The color coding is customizable; see Modifying
Availability Info Colors.
You can open the LP trail list for In-use channel (or multiple channels) that is selected by the user. This can
be done in either view, and on either a split or combined table.
Channels that are mixed, or In-use but non-symmetrical, may be viewable after a table is split in two.
Resources shown for such channels (after the split) refer to the relevant direction.
Rules for displaying the fraction of available resources (e.g. when table split is required) apply for resources
used by both LP and ODU2 trails.
Parent Topic

13.9.1.3 Opening Availability Tables

Optical Availability tables can be opened for OMS trails in the optical layer or the physical layer. You can
open multiple independent tables at the same time.
You can refresh an open table without reselecting the OMS trail set.
To open an availability table:

1. In the Physical or optical layer, select one or more links or trails:
 Underlying link(s) of OMS trail(s) in the LightSoft main window or Trail List window map.
OR
 OMS trail(s) in the Trails pane of the Trail List window.
OR
 OTM (= OTS) link(s) in the Create Trail or Availability Map window.
Selected multiple links cannot include a mixture of external and internal links (between and within
LEs). Multiple internal links must relate to the same LE (must be selected in the same expanded
internal links window).
Other conditions apply to multiple trail selection, for example, that the two selections involve the
same technology.
2. Select Availability from the shortcut menu. The appropriate optical availability table opens:
 Selecting a unidirectional OMS trail yields the availability table of the channels carried by the
trail.
 Selecting two or more OMS trails yields the intersections of the channels carried by all the
selected trails.
If one or more of the selected links carry no OMS trail, an error message is displayed that prompts
you to create the OMS trail.
Only OTM links are recognized for purposes of optical channel availability. (The Availability option
works differently according to the link rate type. If a SDH link is selected, resource availability on
those links is displayed; see Viewing Resource Availability on Links.)
NOTE: Meaningful availability tables require appropriate trail set selections. (For example, for
a bidirectional OMS table, select the two unidirectional trails going in both directions.) When
using area select, ensure not to include links that may introduce OMS trails that are foreign to
the required path, causing an invalid intersection.

Examples of OMS trail selections

The following examples show the links that should be selected to view unidirectional or bidirectional trail
availability:
 Unidirectional availability when a single OMS trail spans the MDs at both ends - select the connecting
link.
 Bidirectional availability - select any two links, one in each direction.
 Bidirectional availability between multiple LEs - select one link for each unidirectional OMS of the links
that form the entire path. For example, between three LEs, select four links, one for each
unidirectional OMS.
Parent Topic
13.9.1.4 Navigating from the Availability Table
You can perform the following navigations from the availability table:
1. Open the following windows directly from the availability table:
 Trail List window with the OMS trail(s) filtered in.
 Current Alarm window with notifications involving the trails filtered in.
2. Select an in-use channel in the availability table and ask to open:
 Trail List window with the OCH trail filtered.
 In the Trail List window, open a GCT on an MD to access:
 Internal view of MD that starts or ends the tandem chain of trails (accessible through the
OTS_Src or OTS_Snk that bound the chain of trails).
 Internal or setup view of the OCH line card connected to the drop or add SNC of the
respective channel at the ends of the path.
3. Select one or several in-use channels in the availability table view (use CTRL or SHIFT keys to select
several) and ask to open the Trail List window filtered to show the trails related to the selected
channels.
4. Open the Trail List window from the availability table view without selecting any channel - All OMS or
All OCH.
The filter shows all the trails that relate to the in-use channels in the table.
Parent Topic

13.9.1.5 Printing and Exporting Availability Information

You can generate reports of optical channel availability information, either as a printout or exported to a
delimited format file (such as CSV), for import to Microsoft Excel or a relational database application.
To generate availability reports from the Optical Availability Table window:
 Printout: In the Optical Availability Table window, select the Print option; see Printing.
 Export to file: In the Optical Availability Table window, select the Export to CSV option; see
Viewing Availability Data in CSV Format.
Parent Topic
13.9.1.5.1 Report Format

The report title shows the OMS trail ID and its endpoints. A list of underlying links is provided. The Optical
Availability table information columns are:
 Channel value (for DWDM channels, 192.1 to 196)
 Channel state (Free, In-use, or Blocked)
 OCH payload type (DSR, ODU1, or N/A)
If the table is the intersection of two or more OMS trails, the report title shows: "Intersection of N OMS
trails". The list of trails is provided with their underlying links (Optical Availability columns listed after each).
Parent Topic
13.9.1.5 Printing and Exporting Availability Information
13.9.2 Channel Frequencies and Wavelengths

Dense Wavelength Division Multiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM)
technologies, supported by LightSoft optics, describe the carriers over which optical signals are transmitted.
DWDM and CWDM use grids of frequencies and wavelengths, as described in the following sections:
 DWDM Frequencies and Wavelengths
 CWDM Wavelengths
For more information about the channel terminology, see Channels.
Parent Topic

13.9.2.1 DWDM Frequencies and Wavelengths

DWDM uses a grid of 40/44 or 80/88 channels on the C band, from 191.70 THz to 196.05 THz (spaced at
100 or 50 GHz, respectively), as listed in the following table.
Table 13-10: DWDM Frequencies and Wavelengths
Channel spacing 100 Channel spacing

ITU T channel number Channel frequency (THz) Channel wavelength (nm)
GHz 50 GHz
17 191.70 1563.86
17.5 191.75 1563.45
18 191.80 1563.05
18.5 191.85 1562.64
19 191.90 1562.23
19.5 191.95 1561.83
20 192.00 1561.42
20.5 192.05 1561.01
21 192.10 1560.61
21.5 192.15 1560.20
22 192.20 1559.79
22.5 192.25 1559.39
23 192.30 1558.98
23.5 192.35 1558.58
24 192.40 1558.17
24.5 192.45 1557.77
25 192.50 1557.36
25.5 192.55 1556.96
26 192.60 1556.55
26.5 192.65 1556.15
27 192.70 1555.75
27.5 192.75 1555.34
28 192.80 1554.94
28.5 192.85 1554.54
29 192.90 1554.13
29.5 192.95 1553.73
30 193.00 1553.33
30.5 193.05 1552.93
31 193.10 1552.52


GHz 50 GHz
31.5 193.15 1552.12

32 193.20 1551.72
32.5 193.25 1551.32
33 193.30 1550.92
33.5 193.35 1550.52
34 193.40 1550.12
34.5 193.45 1549.72
35 193.50 1549.32
35.5 193.55 1548.91
36 193.60 1548.51
36.5 193.65 1548.11
37 193.70 1547.72
37.5 193.75 1547.32
38 193.80 1546.92
38.5 193.85 1546.52
39 193.90 1546.12
39.5 193.95 1545.72
40 194.00 1545.32
40.5 194.05 1544.92
41 194.10 1544.53
41.5 194.15 1544.13
42 194.20 1543.73
42.5 194.25 1543.33
43 194.30 1542.94
43.5 194.35 1542.54
44 194.40 1542.14
44.5 194.45 1541.75
45 194.50 1541.35
45.5 194.55 1540.95
46 194.60 1540.56
46.5 194.65 1540.16
47 194.70 1539.77
47.5 194.75 1539.37
48 194.80 1538.98


GHz 50 GHz
48.5 194.85 1538.58

49 194.90 1538.19
49.5 194.95 1537.79
50 195.00 1537.40
50.5 195.05 1537.00
51 195.10 1536.61
51.5 195.15 1536.22
52 195.20 1535.82
52.5 195.25 1535.43
53 195.30 1535.04
53.5 195.35 1534.64
54 195.40 1534.25
54.5 195.45 1533.86
55 195.50 1533.47
55.5 195.55 1533.07
56 195.60 1532.68
56.5 195.65 1532.29
57 195.70 1531.90
57.5 195.75 1531.51
58 195.80 1531.12
58.5 195.85 1530.72
59 195.90 1530.33
59.5 195.95 1529.94
60 196.00 1529.55
60.5 196.05 1529.16
Parent Topic

13.9.2.2 CWDM Wavelengths

CWDM uses a grid of four or eight channels denominated in wavelengths, from 1471 nm to 1611 nm
(8-channel) or 1511 to 1571 (4-channel), as listed in the following table.
Table 13-11: CWDM Wavelengths
Nominal central wavelengths (nm) for

8-channel system 4-channel system
spacing of 20 nm
1471
1491
1511
1531
1551
1571
1591
1611
Parent Topic
13.9.3 Schematics: Multiroute OCH Trails, Optical DRI

Parent Topic
13.9.3.1 A: Multiroute Topologies

Example A1: 1 trail, 1 path, 2 routes


Example A3: 1 trail, 2 paths, 4 routes (2 routes per path)

Figure 13-52: A3: 1 trail, 2 paths, 4 routes (2 routes per path)
Example A4: 2 trails, 2 paths, 4 routes (2 routes per path, XCs in Y TRP are at the LP
trail)
Figure 13-53: A4: 2 trails, 2 paths, 4 routes (2 routes per path, XCs in Y TRP are at the LP trail)

Example A6: 1 trail, 2 paths, 2 routes (XCs in the Y TRP are at the LP trail)
Figure 13-55: A6: 1 trail, 2 paths, 2 routes (XCs in the Y TRP are at the LP trail)





Example A12: 1 trail, 2 paths, 2 routes (endpoints are on the AoC client ports)
Figure 13-61: A12: 1 trail, 2 paths, 2 routes (endpoints are on the AoC client ports)
Example A13: 1 trail, 2 paths, 4 routes (2 routes per path, XCs in the Y TRP are at
the LP trail)
Figure 13-62: A13: 1 trail, 2 paths, 4 routes (2 routes per path, XCs in the Y TRP are at the LP trail)
Example A14: 1 trail, 2 paths, 2 routes (user-defined protection)

Figure 13-63: A14: 1 trail, 2 paths, 2 routes (user-defined protection)

Example A16: 1 trail, 2 paths, 2 routes (non-multiroute X-protected trail)

Figure 13-65: A16: 1 trail, 2 paths, 2 routes (non-multiroute X-protected trail)
Parent Topic
13.9.3.2 B: Optical DRI Topologies

Example B1: Optical DRI bridge type A
Figure 13-66: B1: Optical DRI bridge type A

Example B2: Optical DRI bridge type B with two sub-bridges

Figure 13-67: B2: Optical DRI bridge type B with two sub-bridges
Example B3: Optical DRI bridge type B with one sub-bridge

Figure 13-68: B3: Optical DRI bridge type B with one sub-bridge
Example B4: Enhanced protection by overlapping main and protection routes

Figure 13-69: B4: Enhanced protection by overlapping main and protection routes

Example B5: Protected trail with multiple routes and two DRI bridges of type B
Figure 13-70: B5: Protected trail with multiple routes and two DRI bridges of type B
Example B6: Protected trail with multiple routes and DRI bridges of type B with
multiple segments
Figure 13-71: B6: Protected trail with multiple routes and DRI bridges of type B with multiple segments
Example B7: Protected DRI bridges of type A using Y regenerators

Figure 13-72: B7: Protected DRI bridges of type A using Y regenerators
Parent Topic

13.9.3.3 C: Local Drop Sites

Example C1: Local drop site with equipment protection and fixed channels using
Mux/DeMux
Figure 13-73: C1: Local drop site with equipment protection and fixed channels using Mux/DeMux
Example C2: Local drop site with channel selection flexibility (colorless) using
ROADM8E-ROADM8I with no protection
Figure 13-74: C2: Local drop site with channel selection flexibility (colorless) using ROADM8E-ROADM8I
with no protection

Example C3: Local drop site that mixes ROADM8A and ROADM2A
Figure 13-75: C3: Local drop site that mixes ROADM8A and ROADM2A
Parent Topic

13.9.3.4 D: Various Multiroute Trail Topologies

Example D1: Customer network with a possible superimposed multiroute OCH trail
Figure 13-76: D1: Customer network with a possible superimposed multiroute OCH trail
Example D2: Multiroute OCH trail with amplifier and regenerator in paths,
common segments and XCs used by main and protection routes
Figure 13-77: D2: Multiroute OCH trail with amplifier and regenerator in paths, common segments and
XCs used by main and protection routes

Example D3: Multiroute OCH trail cannot traverse ODU XCs in CMBR40 cloud
Figure 13-78: D3: Multiroute OCH trail cannot traverse ODU XCs in CMBR40 cloud
Example D4: Trivial case of multiroute OCH trail with ambiguous marking of path
type
Figure 13-79: D4: Trivial case of multiroute OCH trail with ambiguous marking of path type
Example D5: Multiroute OCH trail with overlapping main and protection routes
Figure 13-80: D5: Multiroute OCH trail with overlapping main and protection routes
Parent Topic

13.9.3.5 E: ODU Trails with Multiroute OCH Trail Topologies

Example E1: Two multiroute OCH trails with ODU2 client trail
Figure 13-81: E1: Two multiroute OCH trails with ODU2 client trail
Example E2: ODU2 trail with a multiroute OCH server trail

Figure 13-82: E2: ODU2 trail with multiroute OCH server trail
Parent Topic
13.9.3.6 F: Protected ODU and OCH Trail Topologies

Example F1: Protected ODU2 and edge OCH trails
Figure 13-83: F1: Protected ODU2 and edge OCH trails

Example F2: Protected ODU2 and left side edge OCH trails
Figure 13-84: F2: Protected ODU2 and left side edge OCH trails
Example F3: Externally protected ODU2 trail

Figure 13-85: F3: Externally protected ODU2 trail
Example F4: Protected ODU2 and edge OCH trails

Figure 13-86: F4: Protected ODU2 and edge OCH trails

Example F5: Protected ODU2 with protected OCH server trails

Figure 13-87: F5: Protected ODU2 with protected OCH server trails
Parent Topic
13.9.3.7 G: Various ODU Trail Topologies

Example G1: LP trail as client of ODU2 and OCH trails
Figure 13-88: G1: LP trail as client of ODU2 and OCH trails
Parent Topic

14 Migrating Optical Trails
LightSoft's network management system facilitates upgrading and expanding your optical network. The
process of adding, upgrading, replacing or removing equipment involves the migration of trails from the old
configuration to the new.
Use Optical Trail migration to facilitate the following network improvements:
 Upgrading equipment to enhance existing functionality. E.g., replacing OADM cards with ROADM
cards, or replacing the ROADM2D with a multi-degree ROADM.
 Expanding the existing network. E.g., adding a new ROADM site, or expanding an existing AOC ring.
 Inserting new equipment to increase capacity. E.g., inserting a pair of CMBR40 cards into an existing
OTU2 link.
The process of migrating optical trails involves several steps that can be performed from a single window.
The Migrate Trail window enables you to view trails associated with the existing (old) topology, create the
new topology, and migrate the trails.
Optical Trails Migration should be performed when inserting ROADMs, fixed OADMs, or replacing an XDM
ROADM8D by Apollo ROADM9A because these equipment changes require OCH trail provisioning.
However, when inserting amplifiers or CT Filters into OTS links Optical Trails Migration is not required, as it
is not necessary to perform provisioning of OCH trails when adding this equipment. In such cases,
performing TCI is sufficient.
NOTE: Advanced Trail Operations, and Topology Change administrative capabilities are
required to perform trails migration. The user ID must also have access to the 'All Resources'
domain.
Only one user can use the Migration tool at a time.
14.1 Workflow
Migration of optical trails involves the following steps:
1. Prepare the network topology for migration:
a. Move the old (source) link(s) to maintenance mode. )
b. Create the new topology links, including the equipment to which you are migrating.
2. Create the replacement path(s):
a. Select the links that you want to replace and defining them as old links in the replacement list.
b. Select the links to which you want to migrate the trails and defining them as new links in the
replacement list.
3. Migrate the trails to the new topology. If required, this also includes:
a. Discover the relevant optical trails for the new links.
4. Delete old links and XCs, which deletes the current links, downloads new links to STMS at the EMS
level, and deletes any redundant XCs.
These steps are described in detail in this section.

LightSoft® User Guide Migrating Optical Trails
Parent Topic
14.2 Limitations
NEs must be managed by a single STMS
Migration of optical trails involves the creation and deletion of topology links. Currently, topology links can
only be created between NEs that are managed by the same STMS. Topology links cannot be created
between NEs that are managed by two different STMSs. Therefore, the following use cases are not
supported:
 Inserting an object between NEs that are managed by different STMSs.
 Removing an object that would require the creation of a topology link between NEs that are managed
by different STMSs.
Traffic-affecting period
The traffic hit due to the migration process is calculated from the time the old link is deleted in the NMS
until the physical fibers are connected (in the field) in the new path.
Rate-consistent NEs
Optical trail migration is only relevant when the inserted or replaced equipment uses XCs of the same rate
as the trails that are to be migrated. Otherwise, inserting the equipment and performing TCI is sufficient.
For example, when inserting ROADMs or replacing XDM OADMs with Apollo ROADMs, optical trail
migration should be applied, since these components have OCH XCs. However, when inserting an amplifier,
it is sufficient to change the topology and then perform TCI, since there are no OCH XCs in the amplifier.
Parent Topic
14.3 Preparing the Network Topology

Before creating and migrating trails, prepare the network. This involves the following steps:
 Placing the existing links in maintenance mode. It is only possible to connect two links to a single port
if at least one link is in maintenance mode.
 Creating the new network topology: Create the new links and connect them to the relevant ports on
the new equipment.
Parent Topic

14.3.1 Placing Links in Maintenance Mode

 It is not possible to connect two links to the same port unless the one of the links is in maintenance
mode. Place the old link(s) in maintenance before you start creating the new topology.
To place link(s) in maintenance mode:

 In the Migrate Trail window topology map, press SHIFT, select the link(s) that you want to replace and
click . Selected links are placed in maintenance mode and turn white.
To return links to operational mode:

 In the Migrate Trail window topology map, press SHIFT, select the link(s) that you want to replace and
click . Selected links are placed in operational mode and turn back to their original color.
Parent Topic
14.3.2 Creating New Topology Links

When the old links are in maintenance mode, create the new topology links. During the trail migration
process, you can create the new topology without leaving the Migrate Trails window.
To create new topology links:

1. In the Migrate Trails window press SHIFT and in the Migrate Trails topology map, select the new LEs
and the destination port.
2. In the Main window, click the Topology tab, and in the Create area, click Topology Link. The Create
Topology Link window opens.

3. In the Port Selection area, select the ports that you require and click Apply. (See also Creating
Topology Links.)
4. Repeat the previous steps for all new links that you want to create.
Parent Topic
14.4 Migrating Trails

Migrating the trails involves the following:
 Creating the replacement path(s):
 Defining the links that you want to replace as old links.
 Defining the links to which you want to migrate the trails as new links.
 Retrieving the trails: Display the list of trails that are going to be migrated. All trails that are one layer
above the optical server trails are migrated. Trails at subsequent layers are migrated automatically
together with the migrated trail.
 Validating the trails: All trails must be validated to prevent error during the migration process.
Validation is an essential step in the trail migration process. If even a single trail fails, the entire
process is not executed. In addition, validation identifies trails that need to be migrated manually; see
Manually. Perform validation to identify any trail that needs to be migrated manually using a different
tool (e.g. Edit Trail).

During validation LightSoft checks whether the trails can traverse the new links, and it performs
optical discovery, where required. HO (OMS) trails are created automatically on the replacement
links, if they have not yet been created manually via top-down or optical trail discovery (TCI).
Following validation, trail status displays the following information
 OK in NMS: trails are ok to be migrated.
 Skip: trails cannot be migrated automatically. This usually applies to trails that are unidirectional
or flex.
 Failed: migration validation failed. Check connections are valid and repeat validation.
 Activating trail migration: perform the migration. Migration is performed in LightSoft. The migrated
trails are then downloaded to the network.
 Manually migrating trails: manually migrate any trails that were identified as requiring manual
intervention during validation.
NOTE: Migrating trails is traffic affecting.
To define and migrate trails:

1. To define links as old links:
a. In the Migrate Trails window Replacement Paths List area click . A new path entry is added
to the Replacement Paths List area. )
b. In the Migrate Trails topology area, click the path containing the old links. A window opens
displaying the path and details of all links in the path.
c. In the Old column, select the checkbox of each link you want to define as an old link, or click Add
all as old. All selected links are added to the path as old links. The number of old links added to
that path is listed in the Replacement Paths List area, and the link details are displayed in the
Replacement Path Details area.
d. Repeat this step for all paths you want to migrate.
2. Click (Show optical trails to be migrated).

3. To define links as new links:
a. In the Migrate Trails window Replacement Paths List area select the path to which you want to
add the new links.
b. In the Migrate Trails topology area, click the path containing the new links. A window opens
displaying the path and details of all links in the path.
c. In the New column, select the checkbox of each link you want to define as a new link, or click Add
all as new. The number of new links added to that path is listed in the Replacement Paths List
area, and the link details are displayed in the Replacement Path Details area.
4. (Optional) To remove a path from the Replacement Paths List, click .

5. Click . Trail validation is performed, and any server trails required are created automatically. A
message is displayed when the process is complete. The Migration Status column shows the status of
each trail in the trail list area.
6. Click . Migration begins, and a confirmation window opens.

7. To start the migration, click Yes. Validation is performed and migration begins. A confirmation
message is displayed when migration is complete.
8. To delete all old links, after migration is complete click .
Parent Topic
14.4.1 Manually
Migration must be performed manually in the following scenarios:
 Migrating unidirectional trails. Edit the trail manually to route it through the new links and define the
link direction explicitly.
 Removing a protection switch during migration. Reroute the protection trail before migration.
 Migrating DRI trails. Correct trails to non-flex, or manually edit the DRI trails to traverse the new links.
 Trails with Trails State that is not OK. Correct trail state to OK, or manually edit the trail to traverse the
new links.
 Unprotected multichannel trail.
Parent Topic
14.4 Migrating Trails

LightSoft V10.1 User Guide PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LightSoft V10.1 User Guide PDF

Uploaded by

Copyright:

Available Formats

LightSoft®

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

ECI's management applications run on VMWare virtualization hypervisors.

© Copyright by ECI, 2002-2014. All rights reserved worldwide.

2 Managing Elements and Groups .................................................................. 2-1

ECI Telecom Ltd. Proprietary iii

2.5 Working with UMEs ............................................................................................................. 2-56

3 ETH/MPLS Networking ................................................................................ 3-1

ECI Telecom Ltd. Proprietary iv

3.10 PB Network Properties ........................................................................................................ 3-23

4 Topology Links and Ports ............................................................................. 4-1

ECI Telecom Ltd. Proprietary v

4.5 Performing Trail Failure Analysis ......................................................................................... 4-84

ECI Telecom Ltd. Proprietary vi

4.13.8 Radio Tab............................................................................................................................. 4-148

5 Provisioning SDH and EoS/MoT Trails .......................................................... 5-1

ECI Telecom Ltd. Proprietary vii

5.5.1 Before Starting ASON Trail Creation ..................................................................................... 5-43

6 Performing Actions on Trails and Links ........................................................ 6-1

ECI Telecom Ltd. Proprietary viii

6.5 Performing Trail Operations ................................................................................................ 6-31

ECI Telecom Ltd. Proprietary ix

7 Synchronizing Trails ..................................................................................... 7-1

8 Provisioning MPLS Tunnels .......................................................................... 8-1

ECI Telecom Ltd. Proprietary x

8.3.7 Setting the FRR Protection Mode .......................................................................................... 8-31

9 Performing Actions on Tunnels.................................................................... 9-1

ECI Telecom Ltd. Proprietary xi

9.11.2 Editing Tunnel Bandwidth ..................................................................................................... 9-41

10 Synchronizing Tunnels ............................................................................... 10-1

11 Provisioning Ethernet Services .................................................................. 11-1

ECI Telecom Ltd. Proprietary xii

11.4 Creating Freeform Services ................................................................................................ 11-60

ECI Telecom Ltd. Proprietary xiii

12 Performing Actions on Ethernet Services ................................................... 12-1

ECI Telecom Ltd. Proprietary xiv

12.8.2 Working with Advanced Service Filters ............................................................................... 12-16

13 Provisioning Optical Trails ......................................................................... 13-1

ECI Telecom Ltd. Proprietary xv

13.3.1 Optical Trail Creation Options ............................................................................................. 13-33

14 Migrating Optical Trails ............................................................................. 14-1

ECI Telecom Ltd. Proprietary xvi

ECI Telecom Ltd. Proprietary xvii

Figure 2-41: Properties for EMS window ..................................................................................................... 2-89

ECI Telecom Ltd. Proprietary xviii

Figure 4-15: Availability Chart: PSI tab ......................................................................................................... 4-52

ECI Telecom Ltd. Proprietary xix

Figure 5-5: Endpoints & Path tab ................................................................................................................. 5-18

ECI Telecom Ltd. Proprietary xx

Figure 6-18: Insert PE process ...................................................................................................................... 6-57

ECI Telecom Ltd. Proprietary xxi

Figure 8-30: Endpoints pane......................................................................................................................... 8-51

ECI Telecom Ltd. Proprietary xxii

Figure 11-16: Generalized PE Dual-Homing Topology ............................................................................... 11-22

ECI Telecom Ltd. Proprietary xxiii

ECI Telecom Ltd. Proprietary xxiv

Figure 13-42: DNI Provides an Alternative Path ....................................................................................... 13-104

ECI Telecom Ltd. Proprietary xxv

ECI Telecom Ltd. Proprietary xxvi

ECI Telecom Ltd. Proprietary xxvii

ECI Telecom Ltd. Proprietary xxviii

Table 6-3: Trails pane shortcut menu options................................................................................................ 6-8

ECI Telecom Ltd. Proprietary xxix