TNMS

s Layer Restrictions At Optical Protections Technical Note

Confidential

Technical Note: Layer Restrictions at Optical ProtectionDate Issue/State Name Comments2002/03/28 1. issue TNMS Core V8.0 Woller / Dold Initial creation2003/09/30 2. issue TNMS Core V8.5 Woller Adapted to TNMS Core V8.52004/04/30 3. issue TNMS Core V9.0 Pieper Adapted to TNMS Core V9.0

1 IntroductionTNMS Core V9.0 supports the automatic detection and routing of paths via NE's which support optical protection. The OCU family realizes the optical protection with the OCP card while the FSP 3000 uses the protection module (PM).

In order to achieve the best routing results, some care has to be taken during the creation of the port connections which terminate at the PM module or the OCP card. Additionally, the operator has to modify automatically created port connections terminating at these cards (these are NE-'internal' port connections, not visible on the network map but accessible via the port connection list of the NE).

This document will first state the general rules, illustrated afterwards by some examples. The following advantages will be achieved by following these rules: The path analyser will achieve the most simple and most intuitive results. The number of server paths will be reduced.

2 Concerned NE's FSP 3000 R2.2 (=Waveline MN 3.1) equipped with PM module FSP 3000 R2.3 (=Waveline MN 3.2) equipped with PM module FSP 3000 R3.1 equipped with PM module OCU 1.2.5 equipped with OCP card OCU 2.1.5 equipped with OCP card OCU 2.2 equipped with OCP card OCU 2.6 equipped with OCP card

3 The General RulesThe operator has to restrict the layer of port connections terminating at OCP/PM cards. This can be done via "Restrict To"-field of the port connection property page.

BEWARE: Port connections terminating at the same OCP/PM card have to be restricted to the same layer.

Do not forget 'internal' port connections which are accessible via the context menu of a NE. E.g.Figure 1: OCU 1.2.5: internal PC's and PC's to the "other NE" must be restricted to same layer

No paths must pass the port connection when changing the layer restriction. This applies to managed and unmanaged paths!

CHOOSING THE LAYER: Do not care if the "Other NE" is a SHDH NE: If the "Other NE" in figure 1 is a SDH NE (e.g. a

SL64), no adjustments have to be made. In cases of doubt, one can check the tooltip for the port of the "other NE" (see Figure 2. If the terminated layer set (TL) of this port include SDH layers (e.g. one of the following: RS64, MS64, RS16, MS16, etc), everything should work fine. However, it would be also possible to restrict the terminated layer set of Port Connections in this case in order to reduce the number of server paths, see example in chapter 4.3 Two FSP3000 with PM Module, with SDH NEs

Otherwise, restrict to layer OCH: If the "Other NE" is not a SDH NE (in the sense explained above), but if the port connections between the "Other NE" and the OCP/PM card can be restricted to "OCH", choose "OCH".

Copyright Siemens AG 2003 all rights reservedICN CP D NM EM2 Technical Note

document.doc page 1/12


Confidential

Figure 1

Figure 2

Only if you have no other choice, restrict to "OPTICAL": fFor some NE's (e.g. certain WL8 and 16, MTS 1.1E, MTS 1.1A, MTS 2.03, hiT 7550 types), the layer of the port connection to the other NE can only be restricted to "OPTICAL". In this case, restrict the internal port connections to "OPTICAL", too. Note, that these are very rare cases, in which the protection card is connected directly (i.e. without any transponder or multiplexer cards) to the optical line equipment. (This is the default setting which gives usable results in all cases. However, the results obtained are often not very user friendly or intuitive - see example below).



Figure 2


Confidential3.1 New NE introduced to TNMSWhenever new NEs equipped with OCP or PM Card having already configured port assignments are to be introduced to TNMS Core, proceed as follows: Deactivate the Path Aanalyszer in the TNMS cClient: Choose “Disable Analyzer” on Unmanaged

Paths Tree. Activate the NE in the DCN management of the TNMS Sys. Admin. Move the NE icon to its place on the TNMS network map and create the port connections

connected to the NE. Choose the layers according to the rules described above. Check also the adjacent NE's: these NE's might have internal port connections, too. Make sure

that the layer setting is consistent with the rules explained above. Activate the Path Analyzer analyser in the TNMS Cclient.This procedure ensures, there is no further adjustment necessary and avoids eventually conflicting unmanaged paths.

3.2 Migration from TNMS Core V7V8.5After migration, the Terminated Layer Set of port connections involving OCP/PM cards (thus involving GENP ports) is might be restricted to "OPTICAL" by default. Generally, the same layer set restriction set up in TNMS Core V8.0/ V8.5 will be used in TNMS Core V9.0. However, a change of the layer set restriction is recommended in all cases stated above in chapter “General Rules”, if haven’t been performed yet. Note, that the path representation might change in some cases between V8/V8.5 and V9.0 when not following this recommendation (even though the path possibly appeared as desired in V8 already).If this needs to be changed, proceed as follows:

Follow the instructions given during the migration process on Migration Wizard’s page 3: The system offers to adapt the layer sets of port connections before the actual path migration is started. This ensures that no paths (in TNMS database) pass the concerned port connections. It is highly recommended to adapt the port connection layer sets very carefully at this step, because a wrong setting may result in split paths in TNMS database.

Start the usual path migration. No further steps are necessary.

3.3 Later changesIf later changes have to be made, when both general rules 3.1 and 3.2 have not been complied, proceed as follows: Deactivate the Path Analyzer in the TNMS Client: Choose “Disable Analyzer” on Unmanaged

Paths Tree.Deactivate the analyser in TNMS client Open “Port Connection Properties” and check the paths using this port connection. All paths on

layers OPTICAL, OCH, RSx, MSx have to be deleted from managed or unmanaged path tree. In order to make sure, that no cross connection will be deleted and no alarm mask setting will be changed, the concerned NEs have to be deactivated in DCN Management of TNMS SysAdmin first! Attention: The deletion of server paths will affect all client paths, which might to be adapted manually after changing the layer set!

Restrict the layer sets of the port connections in “Port Connection Properties” window according to the rules described above at “CHOOSING THE LAYER”.

Activate the Path Analyzer in the TNMS Client.Activate the analyser in the TNMS client. “Adopt nNetwork rRoute” for all concerned client paths, if necessary.




Confidential4 Examples

4.1 Two OCU 1.2.5 with OCP, without further SDH NEs

4.1.1 Two OCU 1.2.5 with OCP: uUsing the default settingThis first example will show the results obtained by the Path Analyzer if the operator just uses the default settings and doesn't adjust any layer restrictions. Remember that the default setting is "OPTICAL".

This examples (see Figure 3) uses two OCU 1.2.5, both configured in the same way as Figure 1 shows (but without any "other NE"). Thus each NE contains one OCP card and four OCR 10G cards. Both NE's are connected by four unidirectional port connections, and each NE contains additionally four internal port connections. The internal port connections connect the OCP card with the 4 OCR 10G cards:

Figure 3

The following two pictures (Figure 4 and Figure 5) that the Analyzer finds 4 paths in the OCH layer and 4 paths on the RS64 layer. The pictures what these paths look like.



OCU125_001

OCP OCR10G

OCR10G

OCR10G

OCR10G

OCU125_002

OCPOCR10G

OCR10G

OCR10G

OCR10G


Confidential

Figure 4

Figure 5




Confidential4.1.2 Two OCU 1.2.5 with OCP: oOptimiszed lLayer rRestrictionsThis example shows the same situation as above, but this time all internal PCs have been restricted to OCH. The Figure 6 shows how to do this.

Figure 6

The next picture, Figure 7 shows, that the Analyzer finds just one bi-directional path instead of the 8 unidirectional paths above.




Confidential

Figure 7

4.2 Two FSP3000 with PM Module, without SDH NEs

This examples (see Figure 8) uses two FSP3000 SL 3.1, both configured with PM Modules and WCM Transponder Cards implementing both Tributary and Line side. Thus each NE contains one PM Module and two WCM Cards. Both NE's are connected by two bidirectional port connections, and each NE contains additionally two internal port connections. These internal port connections connect the PM Module with both WCM Cards:

Figure 8



FSP3000_001

PM WCM

WCM

FSP3000_002

PMWCM

WCM


Confidential4.2.1 Using the default settingUnlike the possibly expected end-to-end protected path on RS16 layer, two independent RS16 paths with common half-open protected OCH server are found using the default layer restrictions, see Figure10 for RS16 client path in collapsed expansion mode and Figure 10 for RS16 client path with its expanded half-open protected OCH server paths.

Figure 9




Confidential

Figure 10

4.2.2 Optimized Layer RestrictionsThis example shows the same situation as above, but this time all internal PCs have been restricted to OCH, see Figure 11. Procedure for restricting the layer set as shown in Figure 6




Confidential

Figure 11

4.3 Two FSP3000 with PM Module, with SDH NEsAs already mentioned in cahpter 3 General Rules, it is not mandatory to restrict layer sets of port connections in network topologies like shown in Figure 12, i.e. SDH NEs are connected directly to OCP or PM Cards on both ends. If it is for some reasons required to reduce the number of server paths, one can proceed as described herein.

Figure 12

4.3.1 Using the default settingUsing the default layer restrictions shoud lead in all cases to a complete end-to-end SDH path between ports of both adjacent SDH NEs, see Figure 13: Since the PM Module is connected directly to STM-16 ports in an SDH NE, the Path Analyzer detects an MS16 trail between both SDH NEs. It uses 4 independent server paths (two RS16 server paths are used once, two OCH server paths are used twice on both sides).



FSP3000_001

PM WCM

WCM

FSP3000_002

PMWCM

WCM

SDH NE

SDH NE


Confidential

Figure 13

4.3.2 Optimized Layer RestrictionsIn order to reduce the number of server paths as displayed in Figure 13, layer sets can be resticted as well to layer OCH. The result (without unnecessary server paths) is displayed in Figure 14.




Confidential

Figure 14



TNMS

Documents

Transcript of TNMS