This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
01 03/09/2010 Released M.Ierace Hu Xiaosong/S.Beretto
Scope This section provides information as to which products this migration procedure can be applied. Please consult the list below to find all the software releases to which it can be applied.
TMN
Software
Releases
NR9.2 1350 OMS-HPUX 9.1.1.14.6 or above
EML 9.1.1.40 P12, RP4, RP5 ... RP16 or above
SDH 9.1.1.41 P08, P10, P11, P12, P13, P14 or above
NE
Software
Releases
TSS320 3.2(3.21.60)or above
TSS160 3.2 (3.21.60)or above
Migration Tools No migration tools was used
2.2 Tested Software Releases
Scope The following software releases were used during the validation tests. Below is a list of all the Software releases to which this procedure was applied.
Scope This section describes the restrictions on TMN during the migration.
General
Restrictions
No 4F-MSPring take over support .
No customized Alarm Severity Assignment Profile take over.
No threshold profiles take over.
No Performance Monitoring setting and data take over. The Path/Trail take-over feature does NOT include take-over of PM measures(this is according to requirements and specifications). Only 24h measures are automatically enabled, but just because this is SDH default behaviour (i.e. it does not depend on the fact that they are already enabled or not on the NE).
Network freeze During the migration process, the configuration containing all the NEs to migrate should be stopped. No implementation or de-implementation on paths passing through the NEs under migration has to be performed.
• definition, allocation and de-allocation of paths
Important: no implementation or de-implementation on paths passing through the NEs under migration has to be performed.
3.4 Hardware Restriction
Scope
No Hardware Restriction
3.5 Network Topology Restriction
Scope
The take-over of Ethernet path (virtually concatenated or not) is not available.
It is not possible to obtain an X path if the main and the spare route are completely disjointed; in this case, two paths will be created.
There are particular configurations that the take-over process is not able to manage or it should be chosen how to manage them (e.g. because there are different possible choices).
In particular:
• 140Mb transport not-terminated on both sides are handled as paths (and not as trails)
• unidirectional paths with only two legs ending on two different nodes (or on a single virtual node) are treated as broadcast (and not as Y paths)
• SNCP paths/trails that have two branches ending on the same External-Network are automatically closed by the system on a single NAP (i.e. they are not treated as an Y path or trail)
• SNCP paths/trails not-terminated on both sides (even if terminated with bridge&switch connections on the real NEs), cannot be recognized as they are (i.e. as an X paths) and are thus uploaded as we separate paths
Scope Before migration begins, all preconditions listed below have to be checked for each involved network.
Note: This task has to be done by the migration project team as early as possible.
Read documents You must have a look to the list of documents put in section 1.2. It is your responsibility to decide what you need to read.
DCN The DCN requires the following items to be fulfilled :
• DCN must be designed according to the NR9.2 requirements
• OSI+IP connectivity between the 1350MS and all the NEs
• The DCN must have high availability and be stable
Remote access from Alcatel-Lucent to the customer premises should be configured to allow Alcatel units to logon in case of serious problems
Passwords The following passwords are needed during Migration:
• UNIX password for root user of 1350OMS
• MS-GUI password for at least one user with administrator-profile
Licences and Keys All needed licenses and keys are identified in the NR9.1 PL1 product documentation.
During the Migration no specific Licenses are needed.
Support Prepare a list of phone numbers of people who can help you in case of problems during migration. Don’t forget to inform those people about your planned migration, so they are prepared for your questions and can be contacted during the migration.
Network Backup Before migration starts, perform a data backup on customer network.
This backup could be used to recover from failure during migration (see Rollback procedure described in Appendix A).
Other-
precondition
All the NEs are to be reachable via DCN and supervised by EML
No provisioning at all is allowed at EML/CT level during the network takeover
Each step can be executed only if the previous one is completely successful.
To plan(together with customer) the definitions in 1350OMS-SDH Network(s), sub-network, external networks, all the physical connections that related with External-Network.
Sub-network, external networks, all the physical connections that related with External-Network can’t takeover from 1350OMS-SDH.
Planning The whole migration must be planned in detail, including following constraints :
• Human resource planning
• Access to customer sites
• Remote access for Alcatel-Lucent units in case of serious problems
• Preparation (see preconditions in section 4.1)
• Migration time (see § 4.3)
Manpower The amount of manpower needed depends on the network size and migration planning.
People performing the migration should have the following skills :
• Knowledge of the 1350 OMS 9.1.1 MNT-2 platform
• Knowledge of the equipment
Calamity and
Recovery
Procedures
Before the migration begins, establishment of procedures on calamity handling and how to recover the network, is considered wise (see sections 1 and 5).
Migration Time In order to be able to organise needed resources, the migration project leader can use approximate migration times given in table below about various actions and tasks to be done during the migration.
SDH Network Takeover
Action
Duration
Downtime of:
Supervision Traffic
Preparation several weeks before 1 day NO NO
Preparation just before the migration 4 hours NO NO
Take Over physical connetcions 15 min per NE NO NO
Take Over NPAs 15 min per NE NO NO
Take Over Path 10 min per NE NO NO
Times are given assuming involved field engineers are skilled and no unexpected troubles occur. Some extra time for troubleshooting and unexpected situations is usually required to be taken into account in the calculation of the total time of a migration.
Table 1 : Approximate time for NT9.1 - Management Domain Change-SDH Network Takeover For TL1 NEs
Introduction This chapter describes in details, sorted by main steps, the actions to be done during SDH Take Over. Last section focuses on post migration activities (e.g. Verify correctly working network).
Notes :
Preconditions listed in section 4.1 have to be checked before migration begins.
In case of serious problem during or just after migration, you can use procedure described in Appendix A.
5.1 Preparation several weeks before
Scope Before starting this procedure, certain preparations have to be done in order to ensure a successful migration. These preparations are described below.
Before starting the migration, perform a complete Network Backup of the involved SDH & EML Domain. This will assure that in case of a failure you are able to restore the backup and recover without traffic impact.
Perform the backup according to the system administration guide and check carefully backup log files to make sure the backup was successful.
5.2 Preparation just before the migration
Scope The activities described in this chapter should be done immediately before the migration.
Verify Start
Condition
Just before you start the migration, you must verify the network is stable and that you don't have any unexplainable alarms.
Do the following on the EML and/or SDH:
Verify EML and SDH are started and running the correct software.
Make sure that the EML and SDH are aligned with the Network Elements. If this is not the case, you must fix this first.
Check MIB
Alignment
(optional)
Optionally, a consistency Audit/Download on the Network Element to be migrated can be done. If this operation has been performed quite recently, it could be decided to skip this step; but it’s recommended to perform it. This operation allows to be sure that there were no misalignments before migration and allows to simplify the analysis of the misalignments after the migration.
Before starting the migration you should try to minimize the number of alarms on the NEs to be migrated. Analyze carefully the current alarms, from EML and from SDH, raised on the NEs to be migrated and try to clear as much active alarms as possible. After the migration, you will be able to analyze which alarms are caused by the migration process and which alarms have already existed before the migration.
Important: Printout or take notes of the current alarm lists from EML and SDH managing the NEs to be migrated.
Network
freeze
From this point onwards no configuration has to be done on the affected part of the network. This must be clearly communicated to the customer! This restriction will remain until the migration is completed!
The only allowed operation should be:
• alarm and performance monitoring.
• definition, allocation and de-allocation of paths.
• creation of planned PM measurement.
Important: no implementation or de-implementation on paths passing through the NE under migration have to be performed.
5.3 Upload physical layer
Scope In this subchapter the users get all information on what has to be done to upload the physical layer into SDH. If the network’s size doesn’t fit with the maximum freezing time allowed by the customer the upload can be performed in several steps. Anyway it is not allowed to continue with the next chapter until the whole “physical” layer has been uploaded
Put NEs in
download
disable
Must put all involved NE as download disable. Otherwise, physical connection takeover will scratch the cross connections on NE.
1. Open the web portal of 1350OMS, Search->Physical->Nodes
2. Select one Network Element related to takeover action.
3. Select “Automatic Generation of Trace Identifier”.
4. As a result of the command, the sent value of J0 is generated for the selected port or for all the ports belong to the selected topology. Only if no value has already been set(The 1350OMS-SDH will not overwrite the NON-DEFAULT value). So, it’s recommended to check J0’s initial value on each SDH ports, and make sure
5. After “Automatic Generation of Trace Identifier” finished, click Back, select “Physical Connectivity from J0”, click Apply.
6. As a result of the command, the physical connections are automatically created for the selected port or for all the ports belong to the selected topology.
7. Implement all the discovered Physical Connections.
Repeat steps 2 to 7 for each Network Element related to takeover .
Note: Between step4 and step5 a break of at least 15 minutes should be done to ensure that everything will be correctly set, transported and synchronized.
Check/Creat
e the needed
connections
for TL1 NEs
and External
1. Check/Create all the needed External Networks in maps according to the network design or implementation;
2. List for each node’s appointed SDH ports (i.e. not yet involved in a physical connection; for each of this create the real physical connection towards the corresponding NE or the relevant external Networks (creating it if not existing)
Warning: For the physical connections with the external networks, must create and implement with the option ‘Preserve Au4 concatenation’ set to True (when relevant).
Upload NAPs
in SDH
From SDH, upload all the NEs’ NAPs:
1. Select one Node related to takeover action
2. Actions -> SDH -> Configuration -> Upload NAPs
5.4 Upload Multiplex Section Layer
Scope In this subchapter the users get all information on what has to be done to upload the MS layer into 1350OMS-SDH. If the network’s size does not fit with the maximum freezing time allowed by the customer the upload can be performed in several steps. Anyway it is not possible to continue with the next chapter until the whole “MS” layer has been uploaded.
Linear MSP
take over
This feature allows uploading of different kind of Linear Multiplex Section Protection scheme, as e.g. (1+1) and (m:n).
The MSP schemes are used to provide a protection for working channels set up between two NEs. Following preconditions are requested:
• The physical connections, which implement such scheme, should be already present in 1350OMS-SDH database. If one or more of these connections are not found, a message is sent to the User to suggest the calling of the “Upload Physical Connectivity” command before to re-start the ‘upload NPA’ command.
• The protection blocks characteristics should be consistent. If not, an error message is sent to the User.
Do these steps to upload linear MSP:
1. Select a topology (sub-network or network), and select Actions->SDH->Upload Protection Schema.
2. Select “Linear MSP” from NPA Type, click Apply.
When a consistent MSP scheme is found, a new NPA (including the involved NEs and the related physical connections) is created in 1350OMS-SDH database. Users can also set the ‘implement’ option with true.
• If ‘implement’ is True, after creating the discovered NPAs in 1350OMS-SDH database, these NPAs will be implemented too.
• If this option is False, the NPA can be manually implemented by the User later on.(recommended)
2f MS-SPRing
Take Over
Do these steps to upload 2f MS-SPRing:
1. Select a topology (sub-network or network), and select Actions->SDH->Upload Protection Schema.
2. Select “2f MS-SPring” from NPA Type, click Apply
When a consistent 2f MS-SPring scheme is found, a new NPA (including the involved NEs and the related physical connections) is created in 1350OMS-SDH database. Users can also set the ‘implement’ option with true.
5.5 Upload complete SDH paths & trails
Scope In this subchapter the users get all information on what has to be done to upload complete SDH paths & trails.
The feature allows the automatic creation (and the allocation, implementation and commissioning as well) of paths/trails starting from the actual configuration of the NEs.
Warning: The procedure takes over the complete network splitting this activity per
layers; only the previous step is successfully completed the next one can take place. (the complete network take over split per network partitioning is not considered reliable and effective, because trail/path take over cannot succeed if all the relevant supporting MS and physical resources have not been properly discovered).
Note: If the path/trail takeover operation – started from a big topology, e.g. sub-network does not find all the paths, repeat the operation starting from a more delimited object (node, physical connection, CTP or NAP).
The created path/trail has the following characteristics:
• the User label of the created path/trail is automatically calculated by the system
• the ASAP profiles of the involved TPs are not uploaded
• the info of the created path/trail are set according to the following:
² “path Type”, “path Rate” and “protection Type” according to the information retrieved from the NE
² “alarm Propagation Rule” is set to “when Implemented”
² “pdh Alarm Enabling Rule” and “sdh Alarm Enabling Rule” are set to “on Implementation”
² “pm Automatic” is set to true (the PM related to the created path/trail are started according to the 1350OMS-SDH rules)
² the other info are set to the 1350OMS-SDH default values
It tells you that takeover can be started on one or more of the following objects:
• NAP
• CAP
• CTP
• port
• physical connection
• link connection
• topology (node, 1st and 2nd level sub-network, network)
Note: We used node as take over objects and we recommend you to use it that way, you can find in this picture.
Note: If the path/trail takeover operation – started from a big topology, e.g. sub-network does not find all the paths, repeat the operation starting from a more delimited object (node, physical connection, CTP or NAP).
You can choose “Allocated/Implemented/commissioned” as Required configuration state to ask SDH to Allocated, Implemented or commissioned automatically, after the found paths are defined.
Click Apply, the path/trail involving the provided information is created (allocated, implemented and commissioned) inside the 1350OMS-SDH DB
Note: We select “Allocated” during take over test, and implement it manually after take over finished, you can find in this picture.
5.6 Network checks
Scope In this subchapter the users get all information on what has to be done to check that the network takeover was successful and a list of hints to solve possible problems
Content of
the chapter
Network checks guide you to performing double checks on 1350OMS-SDH DB consistency against network configuration; 1350OMS-SDH offers “Mark Audit” feature to do this.
Mark Audit capability can be applied on a-per-NE-basis (download disabled mode); the Audit report contains the list of NE misaligned resources.
1350OMS-SDH Users are also able to identify which of the misaligned resources can cause traffic impact in case 1350OMS-SDH downloads its own configuration (i.e. cross connection, paths trace…). So the operator can manually apply the proper actions at 1350OMS-SDH level before performing a forced download onto the NE.
Overview of activities:
• NE Synchronization (Optional)
• EML Alignment
• Check alignment
• Download enable
NE
Synchronizat
ion
(Optional)
It allows updating the ports attributes. Do the following steps :
1. Select Nodes that related to takeover action.
2. Perform: Actions -> SDH->Synchronize ->Synchronize NE
3. Wait until the Synchronization finished.
4. Repeat steps 1-3 for each NE.
Note: if you have many NE under the same EML you could also perform synchronization directly from the EML.
Check Now it is important to check the alignment between 1350OMS-SDH and the migrated
1. Select one of the migrated Network Elements on map. The Configuration Download status should already be "disabled".
2. Execute the command Actions-> SDH->Consistency Audit-> Mark Audit. This operation could take several minutes.
3. Wait until the Consistency finished.
4. Browse all misalignments by performing Search -> Node -> Not_Aligned TPs and Cross Connections
5. Analyse and understand all misalignment, if any. Refer to “ APPENDIX B : Misalignment Analysis “for more information about some kinds of possible misalignments. Important: you MUST NOT proceed until you have understood and clarified at least all the traffic affecting misalignment.
6. Repeat steps 2-5 for each NE.
Note: The following steps could be dangerous part of the migration because the 1350OMS-SDH database will be forced down to NE. Therefore if you have any REAL traffic-affecting misalignments on the NE you could have traffic failures.
Warning: Do not do perform the following steps unless you are sure that you do not
have any traffic affecting misalignments between 1350OMS-SDH and NEs!
Download
enable
Enable the download: Actions ->Node->Configure Download -> Enable. Note: this operation downloads only misaligned objects and therefore should be fast.
Verify that consistency download was successful and that no misalignments are still present.
5.7 Post Migration Activities
Introduction In this subchapter the users get all information on what has to be done correctly hand-hover the network to the customer.
Alarm
Synchroni-
zation
You may now synchronize alarms on 1350OMS-SDH:
1. Open the map of 1350OMS.
2. Browse one Network Element.
3. Select it and use the menu Actions ->Node-> Synchronize ->Synchronize Alarms.
4. Repeat step 2 and 4 for each NE.
Configure Because Alarm Severity Assignment Profile cannot be taken over, all needed ASAP
Overview The action list below defines the actions to perform network backup/restore
NMS backup Open backup SDH tool from web portal (in Data Management). Create and save a new job including all objects to be “saved” and launch the run command of the new created job.
NMS restore Open restore SDH tool from web portal (in Data Management). Select job that you backup before and restore it.
Overview This appendix could be useful if you have misalignments between the configuration in the 1350OMS Database and that of the OMSN. Once you have read this appendix, if you still have some traffic affecting misalignments that you do not understand, you should contact Alcatel-Lucent TEC before you enable the download!
How to Browse
Misaligned Objects
Do the following steps:
1. Start and Raise Up the 1350OMS Network Management GUI.
2. Select Search -> Physical -> Nodes to open the Nodes list.
3. Pull the scroll bar to the right and check the four items: Counter of not aligned objects, Counter of configuration mismatch objects, Counter of failed to align objects, Traffic Affected Not Aligned Counter.
4. If there is a counter of these items in the migrated node, select the node and search -> Node -> Not Aligned Tps and Cross Connection.
5. Then in the Not Aligned Tps and Cross Connection List check the objects.
6. Select one of the objects and right click -> Search -> Show Misalignment
In the next list four attributes (Misaligned Attributes, Error Type, Request Type, and Log Time) will be shown.
How to Deal with
Misaligned Objects
Gathering the information of the misalignment attributes you have to do the analysis for the different type before you enable the download. If you do not understand, you should contact Alcatel-lucent TEC for help.