In this section:
Note
The following section is only applicable to the DSC Platform.
Purpose of this Feature
Traditionally, replacing existing STPs A and B with new STPs A' and B' (referred to as STPs A and B and STPs A' and B', respectively in this document) requires additional point codes (PCs) for STPs A' and B'. Additionally, as each adjacent end node X is migrated, there is possibly substantial maintenance work required on this node to reconfigure routing tables to use the STPs A' and B'. The migrated nodes might belong to partners that are reluctant to take on this amount of configuration change. This feature can minimize this configuration change and the disruption to adjacent nodes during the STP replacement by allowing STPs A' and B' to use the same point codes as STPs A and B for the duration of the migration exercise.
More specifically, the purpose of this feature is to ensure that an STP replacement takes place without introducing an outage in the network and without reconfiguring routing tables on anything other than the STPs A and B or the STPs A' and B' (see the following illustration).
Replacing STPs A and B with STPs A' and B', respectively
Feature Overview
This feature allows you to replace a PC in a message using PC Mapping entries provisioned on a linkset. The PC mapping functionality is used to replace the STPs A and B (see the following illustration) in a network with STPs A' and B' that use the same point codes (referred to as PC A and PC B in this document). During the migration, both STPs coexist with the same local point code on the network. PC Mapping functionality is required on the interconnecting linkset to allow proper PC handling in a given message.
Note
The terms PC Mapping Table and PC Mapping can be used interchangeably in this document.
As shown in the following illustration, the feature introduces the ability at STPs A' and B' to map point codes, so each of the STPs A, B, A' and B' see a different adjacent PC. In particular, A is configured with a new linkset to adjacent point code A', while A' is configured with a new linkset to adjacent point code A" and the PC mapping allows link alignment and other MTP3 procedures to work as expected.
Mapping Configuration Example
Note
Information about the linksets AB' and BA' are not included in this section to make the diagrams simpler.
PC Mappings Tab
Clicking this tab displays another screen that you can use for creating PC Mapping objects, each identified by a unique name. The PC Mapping object supports the following three record types:
The linkset Basic Configuration screen has a new PC Mapping Table Name field (see the following illustration) which allows the linkset to replace the PC of the incoming and outgoing message as specified in the associated PC Mapping. PC modifications for incoming messages are applied as soon as the MSU is received, therefore, before Gateway Screening (GWS) or other internal processing. PC modification for outgoing messages are applied after all other handling, including outgoing Gateway Screening and Redirection (refer to Configuring the Gateway Screening and MSU Tracing).
PC Mapping Attribute
The Linkset also adds new values to the existing Originating Point Code (OPC) Verification field to provide additional tools during an STP replacement.
OPC Verification Field New Values
Backwards Compatibility
Caution
OPC Verification is not backward compatible.
The MTP3 continues to be able to process its old configuration files without a change in message handling behavior over an upgrade. Older configuration files do not contain the new object types, hence, the new features are not invoked and behavior configured before an upgrade is unchanged by the upgrade. The enumeration associated with the Linkset OPC Verification object in the MTP3 UI has changed such that new values have been added and the DISABLED value has been renamed as LPC_MATEPC.
Caution
The new enumeration value LPC_MATEPC specifies the same behavior (with respect to MSU validation) as the old enumeration value DISABLED. When upgrading existing linksets, an old value of DISABLED corresponds to a value of LPC_MATEPC after the upgrade. Users of the SNMP MIB should consider that the numeric value of the old DISABLED and the new LPC_MATEPC are the same.
For more information about OPC Verification, see the OPC Verification attribute help text.
Note
To access the OPC Verification help text, follow the path listed in the preceding screen capture and click the question mark beside the attribute.
The path, also referred to as breadcrumbs in this library, is displayed at the top of a screen. For example,
For more information about this Web UI feature, see the appropriate section in the Web UI and Menu UI Guide.
Terminology
The terms used in this document are listed and defined in the following table:
Terminology
| Term | Definition |
|---|---|
| Message Transfer Part Layer 2 (MTP2) | Used for point-to-point message exchange |
| Message Transfer Part Layer 3 (MTP3) | Used for message routing |
| Message Signal Unit (MSU) | A message sent on a link between MTP nodes using MTP2 |
| Service Indicator (SI) | The SI is a 4-bit field within an MSU that indicates the user to which the message belongs. The following service indicator values are of interest in this document:
|
| H1/H0 | MSUs with SI 0,1 or 2 use two 4-bit fields as H0 and H1 to identify different types of management messages. The H0 is used to identify families of relates messages and the H1 identifies messages within this family. For example, the TFM family is all messages with H0 4 (binary 0100) and consists of TFP (H1=1), TCP (H1=2), TFR(H1=3), TCR (H1=4), TFA (H1=5) and TCA (H1=6) messages. |
| Signaling Links Test Message (SLTM) | SLTM and the corresponding Signaling Linkset Acknowledgement (SLTA) are network testing and maintenance message that are exchanged when a link between MTP nodes comes in service. In many SS7 Variants SLTM/SLTA messages are exchanged periodically while the link is in service. SLTM and SLTA messages are sent only on the link under test and are not routed. |
| In Japanese national SS7 Variants, the SRT and the corresponding Signaling Route Acknowledgement (SRA) are testing and maintenance messages that are used for the following two purposes:
Two non-standard terms are used in this document for the two different cases:
The corresponding acknowledgements are called Link SRA and Route SRA messages, respectively. |
| The UPU, TFC, and RCT signals are MTP3 network management messages (SI 0) that are routed through the network and not just to adjacent nodes. |
| MTP3 Adjacent Management Messages (Adjacent Management Messages, or AM Messages) | MTP3 coordinates with adjacent MTP3 nodes using Signaling Network Management (SNM) messages to coordinate traffic and route procedures to circumvent failures. A number of these message types are only sent to adjacent nodes, but can be sent using any available route. NOTE: These message types do not have to be sent on the direct linkset. The SNM messages are of particular interest during migrations and pose special problems that are different than for messages that are only sent on the direct linkset between nodes. NOTE: The terms MTP3 Adjacent Management Messages, or AM Messages can be used interchangeably in this document.These messages consist of MTP3 Signaling Network Management Messages with a Service Indicator (SI) of 0 that are intended for the adjacent node but which can be sent using an indirect path. More precisely, it is all MSUs with SI 0 and in the following H0 families: Changeover (CHM), Emergency Changeover (ECM), Transfer (TFM), Routeset Test (RSM), Management Inhibiting (MIM), Traffic Restart Message (TRM). A simpler way of describing this category can be by exclusion; therefore, it is all MTP3 messages with SI 0 except Routeset Congestion Test (RCT), Transfer Controlled (TFC) and User Part Unavailable (UPU). |
Note
For the additional information about STP Replacement, see the following:
Overview
Content Tools