STP Replacement Example Part 2 - Migration Procedure

Migration Procedure

The following information provides an example procedure for migrating STPs using Point Code Mapping.

1. Take a backup

   Always a good idea before performing maintenance. Perform other backups as needed as migration steps are completed.
   
   

2. Verify starting configuration

   The starting configuration of STPs A' and B' should be as depicted in the Initial Configuration illustration, especially the routing costs at MTP3, Local Point Codes and PC Mappings, and the GTT Configuration.
   
   

3. Decide which Adjacent Node (in this example S) to migrate

   If possible, communicate with the owner of the migrating node to ensure appropriate MTP routing priorities towards STPs A and B at node S.

   1. MTP3 Routing check at nodes S and T

      It is 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 would 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 these nodes, if possible (see section MTP3 Routing check at S and T, Consequences of Unexpected Routing At S towards A, Combined with U being unavailable to S). In some failure cases, other routing costs could cause extensive message loss. This routing cost should be confirmed with the adjacent operator before beginning the migration. The following is an example of preferred routing costs of S towards A and B.

      Click to read more...

      Node	Destination	Adjacent	Cost	Comment
      S	A	A	10	This route using the direct linkset should be the only route using the lowest cost.
      S	A	B	20	The relative costs of the routes through B and through the C-link are not so important.
      S	A	T	30
      S	B	B	10	This route using the direct linkset should be the only route using the lowest cost.
      S	B	A	20	This route being lower than through node T allows AM messages to correctly arrive at STP B' after SA has been migrated, and during the SB migration. If this cost is higher than the cost of the C-link, the relatively minor repercussions are discussed more in section Bring Down SB.
      S	B	T	30

      The following is also acceptable.

      Node	Destination	Adjacent	Cost	Comment
      S	A	A	10	This route using the direct linkset should be the only route using the lowest cost.
      S	A	T	20
      S	A	B	30

      The following is also acceptable.

      Node	Destination	Adjacent	Cost	Comment
      S	A	A	10	This route using the direct linkset should be the only route using the lowest cost.
      S	A	B	20

      The following is also acceptable.

      Node	Destination	Adjacent	Cost	Comment
      S	A	A	10	This route using the direct linkset should be the only route using the lowest cost.
      S	A	T	20

       

      The following table is not acceptable (see section MTP3 Routing check at S and T, Consequences of Unexpected Routing At S towards A, Combined with U being unavailable to S):

      This Routing Table at S towards destination A is NOT GOOD.
      Node	Destination	Adjacent	Cost	Comment
      S	A	A	10	Might be trouble. The direct linkset is not the only linkset with the lowest cost.
      S	A	B	10
      S	A	T	30

      This table is also not acceptable (see section MTP3 Routing check at S and T, Consequences of Unexpected Routing At S towards A, Combined with U being unavailable to S): 

      This Routing Table at S towards destination A is NOT GOOD.
      Node	Destination	Adjacent	Cost	Comment
      S	A	B	10	Might be trouble, the direct linkset is not the lowest cost.
      S	A	A	20

      Consequences of Unexpected Routing at S towards A, combined with U being unavailable to S

      The following is an example from part way through a migration.

      

      As an example, suppose that node node U becomes unavailable to node S. In this case, node S should send TFP messages to all adjacent nodes so they can route traffic to node U through other routes. If the MTP3 Routing at node S towards DPC A does not use the direct linkset as the lowest cost route, the TFP messages from node S to STP A regarding node U might go to the STP A instead of to the STP A' (through paths SBA or STA). The consequence is that STP A' does not receive important route management messages (TFP, TFA, and so on). Therefore, STP A continues to send MSUs with DPC U to node S, where they are discarded. This scenario could cause MSU loss until node S has been fully migrated (or, if the alternate route is through node T, until node T is also migrated), or node S re-establishes contact with node U.

      This scenario possibility is somewhat rare (it requires that node U become unavailable to node S during the migration, and also that node S does not have the direct linkset to STP A as the lowest cost route for DPC A), but is potentially serious and should, if possible, be verified with the adjacent operator before migrating nodes S and T.

   2. Configure Migration Records for S/T towards A/B

      PC Mapping Name: Right Boundary
      Migration Records
      OPC	DPC	Message Category	New DPC
      S	A	MTP3 Adjacent Management Messages	A"
      S	B	MTP3 Adjacent Management Messages	B''
      T	A	MTP3 Adjacent Management Messages	A''
      T	B	MTP3 Adjacent Management Messages	B''

      On the C-link at STP A’, configure migration records to block MTP3 Adjacent Management Messages from STP B’ to node S (OPC B, DPC S New DPC Discard). If node S is part of an STP pair with node T as its mate, also block AM messages with OPC B and DPC T. 

      PC Mapping Name: New_A_C_LINK
      Migration Records
      OPC	DPC	Message Category	New DPC
      B' (OPC B)	S	MTP3 Adjacent Management Messages	Discard
      B' (OPC B)	T	MTP3 Adjacent Management Messages	Discard

      
      The migration configuration is at the following stage in network configuration and you are ready to start the migration.

      
      
      

   3. Bring down the SA linkset 

      The first step in the migration is to bring down the linkset SA.

      

      At this point, node S and STP A perform a changeover, exchanging messages through indirect routes.

      Verify that traffic is completing successfully.

      Note

      This verification is not mentioned again, but perform it from time to time throughout the migration.

      Click to read more...

      Before bringing down SA, traffic to DPC U from various sources flows through the network as follows:

      

      The traffic to DPC S is as follows:

      

      After taking down linkset SA, MSUs to DPC U behave as expected:

      

      Traffic to DPC S also works out, but maybe not in the most intuitive way:

      
       

      Specifically, the traffic from STP A' with DPC S goes through STP B and not through STP A, because of the route costs at STPs A and A' and because of MTP3 preventive TFP procedures. When MTP3 starts using an alternate route, it sends a preventive TFP to all alternate routes of higher priority. Hence, you get the following route states before and after the SA linkset is taken out of service. The result that both STPs A and A' send messages with DPC S through STP B.

      Node	DPC	APC	Cost	State with SA available	State with SA unavailable	Comments
      A	S	S	10	Available	Unavailable (Linkset Inactive)
      A	S	A'	20	Unavailable (Route Prohibited)	Unavailable (Route Prohibited)	The A'S linkset is unavailable, so STP A' is sending to node S using STPs A and B. Hence, STP A' has sent preventive TFPs to STPs A and B concerning node S.
      A	S	B'	20	Unavailable (Route Prohibited)	Unavailable (Route Prohibited)	The B'S linkset is unavailable, so STP B' is sending to node S using STPs A and B. Hence, STP B' has sent preventive TFPs to STPs A and B concerning node S.
      A	S	B	30	Available	Available	When STP A starts using this route, it sends a preventive TFP to all alternate routes of higher priority (normal MTP3 preventive TFP procedures).
      A'	S	S	10	Unavailable (Linkset Inactive)	Unavailable (Linkset Inactive)
      A'	S	A	20	Available	Unavailable (Route Prohibited)	When SA becomes inaccessible STP A attempts to use the cost 20 route through STP A, but that is prohibited. Hence, STP A moves to the cost 30 route through STP B. By normal preventive TFP procedures, STP A sends a preventive TFP also to all higher priority alternate routes, making this route prohibited.
      A'	S	B	20	Available	Available
      A'	S	B'	30	Available	Available

      Preventive TFP procedures affect the routing of MSUs from STPs A, B, A' and B' towards nodes S and T in the following steps. This is highlighted using diagrams in the following sections, but the preventive TFP procedures are not mentioned again.

   4. At STP A, delete the AS Linkset 

      From this point, on STP A does not need to exchange MTP3 Adjacent Management Messages with node S. To prevent confusion and possibly unexpected MTP3 procedures, these message exchanges should now be blocked. The simplest way to do this is to delete the AS linkset on STP A; other options of differing complexity are available if needed, contact Customer Support for details.  

       
      

   5. Delete the migration record for OPC S DPC A New DPC A” at both A’ and B’  

      As of this step, when node S sends any AM Messages with DPC A, it means STP A'. Update the migration records at both STP A' and STP B' from the RightBoundary PC Mapping to reflect this understanding. Specifically, delete the record with OPC S DPC A New DPC A", so the Migration Records in the RightBoundary PC Mapping are as follows:

      PC Mapping Name: Right Boundary
      Migration Records
      OPC	DPC	Message Category	New DPC
      S	B	MTP3 Adjacent Management Messages	B''
      T	A	MTP3 Adjacent Management Messages	A''
      T	B	MTP3 Adjacent Management Messages	B''

      
       

   6. Connect SA' 
      
      

      Bring up the SA' linkset, as shown in the following diagram. Wait for changeback to complete (a few seconds). Sanity check.  
      

      

      If the MTP3 Routing at node S towards DPC A uses the direct linkset as the lowest cost route, node S can now send AM messages to STP A' on the direct linkset (previously these would have gone to STP A). STP A' can now discover the state of nodes accessible through node S by the response method. For example, node S can now send STP A' a TFP concerning node U on the direct linkset.

      At this step, traffic should be flowing correctly between any end nodes, with or without GTT.

      Traffic with DPC U is as follows:

      

      Traffic with DPC S is as follows:

      
       

   7. Bring down SB 

      Bring down the SB linkset. Wait a few seconds for changeover to complete through the indirect route STB or SA'B.
      
      

      Click to read more...

      MSUs towards DPC U are as follows:

      

      MSUs towards DPC S are as follows:

      

      If the routes from node S to STP B have STP A as a higher priority route than node T, then AM messages should be delivered correctly using the path SA'B.

      If instead the routes from node S to STP B have node T as a higher priority route than STP A, then AM messages should be delivered using STB. However, suppose that later in the migration SB' comes up and then fails. In this case, the changeover messages intended for STP B' arrive at STP B instead, which could result in transient message loss. Once both nodes S and T have been migrated, this concern disappears. Since SB' should not fail during the migration, and since the consequences are transient then this should be a relatively minor concern.
       

   8. At B, delete the BS linkset

      When the changeover has completed  SB is not expected to come back up.

      Prevent STP B from sending AM messages to node S by deleting the linkset from STP B to node S, or by blocking these messages on all routes from STP B to node S. If the current routes from STP B to node S are only through STPs A' or B', this can be done using a Migration Record with the Discard modifier on the middle boundary.
      

   9. Delete the Migration Record for OPC S DPC B New DPC B” at both A’ and B’

      From this step, an MTP3 Adjacent Management Message from node S to STP B are intended for STP B' and not STP B. Change the migration records at STPs A' and B' to reflect this interpretation.

      PC Mapping Name: Right Boundary
      Migration Records
      OPC	DPC	Message Category	New DPC
      T	A	MTP3 Adjacent Management Messages	A''
      T	B	MTP3 Adjacent Management Messages	B''

      Click to read more...

      

   10. At STP A', delete the Migration Record on the C-link: OPC B DPC S New DPC Discard

       Now that SB does not come back up, you can allow STP B' to send AM messages to node S through STP A' by removing the Migration Record at STP A' that was blocking these messages.

       PC Mapping Name: New_A_C_LINK
       Migration Records
       OPC	DPC	Message Category	New DPC
       B' (OPC B)	T	MTP3 Adjacent Management Messages	Discard

       If the routes from node S to STP B have STP A as a higher priority route than node T, AM messages should be delivered correctly through the path SA'B'. If instead these management messages go through node T, they arrive at STP B until SB' is up. If SB' fails after that, changeover messages intended for STP B' arrive at STP B instead, which could result in transient message loss. Once both nodes S and T have been migrated, this concern no longer exist. Since SB' should not fail during the migration, and since the consequences are transient, this scenario should be a minor concern.

       Click to read more...

       

   11. Connect SB'  

       With these changes in place, you can now bring up the SB' linkset. Wait for changeback to complete (a few seconds). Sanity check.

       Click to read more...

       

       MSUs with DPC U flow are as follows:

       

       MSUs with DPC S flow are as follows:

       

   12. If node S is an STP, migrate the mate STP T using the same procedure

       After nodes S and T has been migrated:

       

   13. Take a backup

   14. Update GTT at STP A'  

       Update the GTT translations at STPs A’ and B’ so that MSUs which should go to/through node S or node T now go there directly, rather than through STPs A”, B” or G”. This step may be done later if required.
       
       

   15. Clean up after migration of nodes S and T

       To clean up after the migration of nodes S and T, do the following.

       1. At STP A and B, if not already done, delete the AS and BS linksets and all routes that use these linksets (all such traffic should now be going through STPs A’ and B’).

       2. At STPs A' and B', any remaining routes that use STPs A and B to access nodes S, T, U, V, and so on can be removed.

          The migration of node S (and nodeT) to the STPs A’ and B’ is now complete.
           

   16. Take a backup 
        

4. When all migrations are completed...

   When all migrations are completed, do the following:
    

   1. GTT should now be updated at STPs A’ and B’ (if it has not been updated already) so that STPs A'', B'' and G” are no longer used for partial GTT; instead, all traffic should be sent across the right boundary towards its final destination.
       

   2. Verify that the linksets AA’, AB', BA' and BB’ are carrying no traffic.
       

   3. The linksets AA', BB' (and other across the middle boundary, if any) can be taken out of service. Any routes that use them can be deleted. The linksets can be deleted.
       

   4. The mapping tables for all linksets can be set to the empty mapping, and the mapping tables deleted.

      STPs A' and B' should now be operating as normal STPs with local PCs A and B and GTT alias point code G.
       

   5. Take a backup.
       
      The STP replacement is now completed.

Additional Information on Message Flows

SRT, SRA, USN Messages

 This section describes some challenges that exist in correctly handling SRT, SRA and USN messages in SS7 National Variants for Japan and New Zealand. The Link SRT/SRA messages and a number of cases with Route SRT/SRA messages are straightforward, but there are challenges in correctly handling Route SRT messages that originate from one of the migrating STPs (A,B,A' or B') and which cross the middle boundary.

Consider again this network, partway through a migration.

SRT and SRA messages are used in Japanese networks immediately after a link comes in service. This message exchange during migration is similar to the SLTM/SLTA exchange and requires no special treatment beyond the PC Mapping already discussed.

Link SRTs between STPs  A and A' function the same way as SLT messages in other SS7 Variants:

Route SRTs between nodes X and Z work the same way as MTP3 Routed User Data (the SRT is shown here, the SRA or USN reply is similar):

Consider the following:

• SRT, SRA or USN messages originated by STP A and going to the left are unaffected by PC Mappings and work as usual.

• SRT, SRA or USN messages originated by STP A' and going to the right are unaffected by PC Mappings and work as usual.

• SRT, SRA or USN messages originating on the left and with DPC A are handled by STP A as usual. Similarly, SRT, SRA or USN messages originated on the right with DPC A are handled by STP A'.

Problematic Scenario

The problematic scenarios occur when Route SRTs are originated from STPs A, B, A' or B' and cross the middle boundary. It is expected this to be a concern for manually initiated tests only.

If STP A tries to send an SRT towards end node X through STP A', the following message can be expected. The problem is that the PC A'' which we use between STPs A' and B' to identify STP A is unknown by nodes to the right of the right boundary, so the outgoing OPC to STP A has to be mapped and then the SRA is handled by STP A' and does not make it back to the originator.

Note 1: Trouble! We have lost the original OPC.

Note 2: The SRA is now handled by STP A', so STP A does not get its answer.

Change in SRT Manual Test Procedure

Both STP A and A' are under your control. So, instead of instructing STP A to test destination end node X, you can do the following:

• test end node X from STP A' and
• check at STP A that the route to end node X through STP A' is available

These two checks should give confidence in the routing of user traffic from STP A to end node X. This also gives confidence in the ability of end node X to route back to point code A, since STP A' and A use the same PC on MSUs sent across the right boundary.

A similar test is appropriate at STP A' for testing the status of destinations that are accessed across the middle boundary.