STP Replacement Example Part 1 - Setup and Checks

This section provides an example of the steps used to migrate an adjacent STP pair from the existing to the new STPs during an STP Replacement (STPs A and B to STPs A' and B', respectively). The steps to migrate a single end-node are similar. Assuming the following network that is partway through an STP Replacement, the following example shows steps to migrate STPs S and T so they connect with STPs A' and B' instead of STPs A and B.

In the following diagram, the dashed line above the text Middle Boundary represents the effect of PC Mapping on the middle boundary. So, on the linkset between STPs A and A', STP A thinks it is aligning links against Adjacent Point Code  3.102.3 while STP A' thinks it is aligning links against 3.102.2.

Migrating an Adjacent STP Pair from the STPs A and B to STPs A' and B' During an STP Replacement

During this sample migration procedure, some screen captures are provided. These screen captures use the PCs shown in the preceding illustration. The PCs for this illustration are presented in a table as follows:

Limitations

During the STP migration, a substantial portion of network traffic flows between the STP A/B and STPs A'/B'. The links between these STPs must have sufficient capacity for this traffic.

The STPs A and B that are being replaced are assumed to perform MTP3 routing and possibly GTT, no other functions have been considered. In particular, the STPs acting as M3UA SGs has not been considered.

Some national SS7 Variants (Japanese NTT and TTC, New Zealand) can use SRT messages as an end-to-end test of the status of nonadjacent entities. If the operator performing the STP replacement wants to initiate an SRT test towards a remote destination from one of the migrating STPs A, B, A' or B' towards a remote destination, that is on the other side of the other set of STPs, a modified two-step test procedure is required (refer to section Change in SRT Manual Test Procedure for more details).

A maximum of 1000 PC Mapping Records can be created (of any type) across all NAs. This number is not configurable. No associated MSA counter is supported.

During the migration, PCs are required for STPs A' and B'. PCs are also assigned to STPs A'' and B'' that represent STPs A and B between STPs A' and B'. These PCs have very limited implications to the network, but ideally they would be owned by the operator doing the migration to avoid any unforeseen collisions. If GTT is performed on STPs A and B, several ways are available to manage the migration of GTT traffic. If GTT is performed using Alias Point Code G, the configuration of A' and B' can be simplified if a PC G'' is available to represent Alias Point Code G at STPs A' and B'. The point codes A', B', A'', B'' and G'' (if used) should be owned by the operator for the duration of the migration.

When migrating nodes S and T from STPs A/B to A'/B', it is highly recommended that the routing tables at nodes S and T towards STPs A and B use the direct linkset as the lowest cost route, and that there be no other route of lowest cost. This assertion should be checked with the operator of nodes S and T before beginning the migration of nodes S and T, if possible.

Depending on this route configuration, if there are additional unexpected failures during a migration, important MTP3 management messages like TFPs could end up going to STP A instead of STP A', potentially causing extensive message loss (refer to section MTP3 Routing check at nodes S and T, Consequences of Unexpected Routing At S towards A, Combined with U being unavailable to S).

Initial Configuration Process

The network topology for the initial configuration process is as follows:

Initial Configuration

Local Point Codes and PC Mappings

The point code of STPs A and A' are both A. Due to the PC Mapping on the middle boundary, STP A' sees STP A as PC A" and STP B' sees STP B as PC B".

The Middle Boundary table is applied on STP A' and B' on the linksets AA', AB', BA' and BB'.

Middle Boundary A Prime

The PC Mapping Table Right Boundary is applied to all linksets configured at A' and B', other than the C-link and linksets AA', AB', BA' and BB'.

Both STP A and STP B still perform GTT that can send messages across the right boundary. TFP and SSP messages that come back in response to make it to STP A or STP B are expected.

The linksets A'S and A'T (currently down) use the PC Mapping Right Boundary. These linksets can be created and their table assigned any time before the migration of nodes S and T. When the linksets and corresponding routesets have been created, STP A' tries to send AM messages to nodes S and T. As these AM messages pass through the middle boundary, their OPC changes from STP A to STP A'. When these AM messages are received at nodes S and T their OPC is unrecognized, so the messages are discarded (MTP3 Adjacent Management messages from a non-adjacent node are discarded). Depending on the configuration of nodes S and T, these messages could cause alarms to be raised, but otherwise they should cause no difficulties in the network.

Right Boudary A Prime No Migration Records

 

MTP3 Routing

Same as when configuring routing in any STP quad, it is recommended that you use consistent routing priorities to avoid the possibility of circular routing in failure conditions.

In the following example, a preference to use the C-link as the last resort (highest cost route). Therefore, if STP A' is configured with a linkset to node S, STP A' prefers to reach node S using the direct linkset, then the routes through STP A" and STP B" and finally through the C-link. This general preference is assumed on all the STPs A, B, A' and B' (see the following illustration).

Example Migration with Point Codes

The following table shows the MTP3 routing table at STP A'. Because of PC mapping, this table looks a little unusual. The adjacent nodes are identified by their node names in the Network Topology for the Initial Configuration Example illustration. These names often represent the point codes used when provisioning the routing tables, but remember that STP A' thinks of STP A as point code A'' and thinks of STP B' as point code B. Similarly, STP B' thinks of STP B as point code B'' and thinks of STP A' as point code A.

At STP A, several different routing costs are possible.

MTP3 All Routes at A' Part 1

Example for MTP3 All Routes at A' Part 2.

MTP3 All Routes at A' Part 2

MTP3 All Routes at B' Part 1

Example for MTP3 All Routes at B' Part 2.

MTP3 All Routes at B' Part 1

Caution About Circular Routing

For additional information about preventive TFPs and circular routing, consult GR-82-CORE Issue 10 Appendix A: Changes for E-Links and Complex Network Architectures.

During the migration procedure, the STP pairs A/B and A'/B' have routes through each other to reach the nodes that are being migrated. Typically, when STP pairs can route to each other to reach a node, the route costs to reach the migrated node should be consistent across the STPs A,B,A' and B' so that preventive TFP procedures can correctly stop routing loops. As shown in the following diagram, inconsistent routing costs must be avoided.

For example, suppose you are migrating node X from STPs A/B to STPs A'/B' and that node X becomes unavailable. If the first alternate routes towards node X are inconsistent like this

As illustrated in the following screen capture, the above scenario results in a configuration that must be avoided.

Circular Routing

To avoid this issue, provision the STPs so that they all agree what the best and alternate paths should be. In this case, it is sufficient to provision STPs A' and B' consistently, so the direct linkset is the lowest cost, the routes through STPs A and B are next, and the C-link is the highest cost, then normal preventive TFP procedures break the loop.

GTT Configuration

Some flexibility exists in how GTT records are migrated between STPs A/B and STPs A'/B'.

It is assumed that STPs A and B are configured for GTT and that their translations (GT to destination) are managed as usual during the migrations (that is, the fact that there is a migration does not affect which GT's should go to which destinations).

GTT at STPs A' and B' is initially configured with all translations indicating that partial GTT should be performed with the next stage of translation on STPs A or B (possibly using destination G" to send to alias point code G on A/B). This use of partial GTT bypasses some traps with OPC Verification while ensuring that the final destination receives an OPC that it recognizes and can reply to.

In the following example, it is assumed that if STPs A and B use alias PC G for translations then STPs A' and B' also have alias point code G for GTT.

There is an extra GTT lookup going from right to left:

After nodes X and Y have been migrated, but before GTT records on STPs A' and B' have been updated, GTT lookups still bounce through STPs A and B.

At some point after migration of nodes X and Y, GTT records on STPs A' and B' can be updated to avoid bouncing traffic through A/B when going from the right side to the right side.

This change can be done as soon as nodes X and Y have been migrated, or can be delayed until all nodes have been migrated. The only rule that should be respected on STPs  A' and B' is to use partial GTT through STPs A and B if the final destination is on the other side of the middle boundary.

This information should give a sufficient understanding of how the GTT translations and MTP3 routing work together during the migration, so the GTT message flows are not repeated during the remaining migration steps (refer to STP Replacement Example Part 2 - Migration Procedure).