Signaling System No.7 Protocol Architecture And Sevices part 18

Signaling Message Handling MTP3 processes all incoming MSUs to determine whether they should be sent to one of the MTP3 users or routed to another destination. The term "MTP3 user" refers to any user of MTP3 services, as indicated by the Service Indicator in the SIO. This includes messages generated by MTP3 itself, such as SNM, or those that are passed down from the User Parts at level 4 of the SS7 protocol, like ISUP and SCCP. The term "MTP User Part" is also used, but more specifically refers to the User Parts at level 4. When a node generates an MSU, MTP3 is responsible for determining how to route the message toward its destination using the DPC in the Routing Label and the Network Indicator in the SIO. Figure 7-8 shows how MTP3 message processing can be divided into three discrete functions: discrimination, distribution, and routing. Figure 7-8. Signaling Message Handling [View full size image] Discrimination Message discrimination is the task of determining whether an incoming message is destined for the node that is currently processing the message. Message discrimination makes this determination using both the NI and the DPC. Each node's Point Code is defined as belonging to a particular network type. The network types are those that are specified by the NI, discussed earlier in this chapter. An ISC will have both a National network and International type, with Point Codes in each. Nodes that do not function as an ISC are generally identified as a National network with a single Point Code. In some cases, multiple Point Codes can identify a national node; for example, a network operator might use both National and National Spare network types at a network node, with Point Codes in each network. The NI in an incoming message's SIO is examined to determine the network type for which the message is destined. Each time a node receives a message, it must ask, "Is it for me?" The node asks the question by comparing the incoming DPC in the Routing Label to its own Point Code. If the Point Codes match, the message is sent to Message Distribution for processing. If the Point Codes do not match, the message is sent to the Routing function if the node is capable of routing. A Signaling End Point (SEP), such as an SSP or SCP, is not capable of routing messages; only an STP or an Integrated Node with transfer functionality (SSP/STP) can forward messages. Distribution When the discrimination function has determined that a message is destined for the current node, it performs the distribution process by examining the Service Indicator, which is part of the SIO in the Routing Label. The Service Indicator designates which MTP3 user to send the message to for further processing. For example, MTP3 SNM processes a message with a Service Indicator of 0 (SNM messages), while a message with a Service Indicator of 5 is sent to ISUP for processing. Within SS7 protocol implementations, the Service Indicator is a means of directing the message to the next logical stage of processing. Routing Routing takes place when it has been determined that a message is to be sent to another node. There are two circumstances in which this occurs. The first is when a node originates a message to be sent to the network. For example, an MTP3 user (such as ISUP or SCCP) generates a message for MTP3 to send. The second is when an STP has received a message that is destined for another node. The routing function is invoked if the discrimination function has determined that the received message is not destined for the STP. If a Signaling End Point (SSP or SCP) receives a message and the discrimination function determines that the message is not for that node, the message is discarded because these nodes do not have transfer capability. A User Part Unavailable (UPU) is sent to the originating node to indicate that the message could not be delivered. In other words, SEPs can only route the messages they originate. A node examines one or more routing tables to attempt to find a match for the DPC to which the message is to be routed. In the case where a node transfers the message, the DPC from the incoming message's Routing Label determines the route to the destination. MTP3 uses next- hop routing so the destination can be an adjacent node, or simply the next node en route to the final destination. The implementation of the routing tables is vendor dependent; ultimately, however, the DPC must be associated with a linkset (or combined linkset) for sending the message. Figure 7-9 shows an example of a routeset table. The routeset table contains routesets for all of the possible destinations that can be reached. The table is searched to find a match for the DPC to be routed. If a match is found in the list of routesets, a linkset is chosen from the available routes associated with the routeset. After choosing a linkset, a link is selected from the linkset over which the message will be transmitted. In the example, the discrimination function has determined that Point Code 200-1-2 does not match the point code of the current STP, and has therefore passed the message to the routing function. The routing table is searched for a match for DPC 200-1-2, and a match is found at the second entry. The routeset contains two routes: LS_1 and LS_3, which represent linkset 1 and linkset 3. In this example, a priority field with the highest priority number is the preferred route, so linkset LS_3 is chosen to send the message to DPC 200-1-2. The priority field used here should not be confused with the message priority field of MTP3. Again, the actual implementation of routing tables is vendor specific, and a vendor might choose to label this field differently. Figure 7-9. Routing Table Lookup ANSI Network and Cluster Routing Routing is often performed in a hierarchical fashion. In ANSI networks, messages can be routed by matching only part of the DPC. The match is done on a portion of the Most Significant Bits of the DPC, allowing messages to be routed using fewer entries in the routing tables. This saves on administration overhead and eliminates the need for detailed information about node addresses. It is especially useful when dealing with traffic that is destined for another operator's network. For example, it is quite common to aggregate routes using network or cluster routing. With network routing, a route is selected by matching only the network octet of the DPC; when cluster routing is used, the network and cluster octet of the DPC must be matched to a routing table entry, as shown in Figure 7-10. Figure 7-10. Example of ANSI Cluster Routing Alias Point Code Routing An alias Point Code is a secondary PC used, in addition to the unique primary Point Code, for identifying a node. Another common name for an alias is a Capability Point Code. Multiple nodes (usually two) share the alias PC; this allows messages to be routed to either node using a common PC. The alias PC is typically used to identify a pair of STPs. Its primary purpose is to allow the load sharing of SCCP traffic across the STP pair. Because SMH discrimination at either STP will accept a message with the alias PC, the message can be delivered to the SCCP User Part, where GTT is performed. Figure 7-11 shows an example using an alias PC. The PC for STP 1 is 200-1-1, and the PC for STP 2 is 200-1-2. The alias PC 200-1-10 is used to identify both STP 1 and STP 2. As a result, SSP A can route messages requiring SCCP GTT to 200-1-10 while load sharing across STP 1 and STP 2. Since STP 1 and STP 2 each must have a unique PC, SSP A cannot perform load sharing of SCCP traffic to the STP pair using the unique PC of either STP. However, the alias PC allows either node to accept and process the message. Figure 7-11. Example of Alias Point Code Routing Message Load Sharing A properly designed SS7 network employs alternate message paths to create network redundancy. User traffic is typically load-shared across different paths to maintain a balanced load on network equipment. Load sharing also ensures that problems on each path are detected quickly because they are carrying traffic. There are two types of SS7 load sharing: • Load-sharing across linksets in a combined linkset • Load-sharing across links within a linkset Link selection is done when a node originates messages for normal MTP3 user traffic so that overall traffic distribution is even across the links. The actual algorithm for generating the SLS code is not specified by the SS7 standards, but the result should be as even a traffic distribution as possible. There are times when load sharing is not desired, as outlined later in this section and in the section, "Load sharing and MTP3 User Parts." When load sharing is used, the SLS field determines the distribution of messages across linksets and links as they traverse the network. The originating node generates an SLS code and places it into the Routing Label. At each node in the message path the SLS is used to map the message to a specific link and, if using a combined linkset, to a specific linkset. Load Sharing and MTP3 User Parts As previously mentioned, a general goal of SS7 routing is to attempt to distribute traffic evenly across links as much as possible. However, there are special considerations within the MTP3 user parts when the SLS codes are being generated. The SLS codes for messages related to a particular communications exchange, such as an ISUP call, are generated with the same value. If different SLS values for messages belonging to the same call were used, there would be an increased chance of out-of-sequence messages because they could take different network routes, affecting the order in which they are received. Figure 7-12 shows a phone call being signaled between SSP A and SSP B using ISUP. SSP A generates the same SLS code 0100 for all messages associated with this particular call. This causes the same linkset and link to be chosen for each of the messages. The same linkset/link selection algorithm is applied at subsequent network nodes, resulting in the same choice of linkset and links each time. This ensures that all messages take the same path through the network and minimizes the chance for messages within a specific communications exchange to be mis-sequenced. Messages from SSP B that are related to the same call use SLS code 0101 for all messages. Figure 7-12. SLS Generation for In-Sequence Delivery Of course, the possibility always exists that network failures can cause alternate paths to be taken; this increases the chance for out-of-sequence delivery. The previous example showed the SLS values for an individual phone call. However, the same principle applies to other User Part communication exchanges, such as SCCP. SCCP generates the same SLS values to be used by MTP when the in-sequence delivery option is set within SCCP. The least significant bits of the Circuit Identification Code (CIC) are placed in the SLS field when the MTP3 user is the Telephone User Part (TUP). All messages related to a particular call use the same CIC, resulting in the same SLS value in each message. Chapter 8, "ISDN User Part (ISUP)," explains the CIC. Messages generated by MTP3 (SNM, SNT, and SNTS messages) replace the SLS field with the Signaling Link Code (SLC). No load sharing is performed for these messages. Although there are exceptions, the SLC usually specifies the signaling link to be used when sending a message. The "Signaling Network Management" section discusses the SLC and its specific use. SLS in ITU-T Networks ITU-T networks use a four-bit SLS value. The SLS value remains the same as the message travels through the network. If a combined linkset is being used, one bit of the SLS code is used to select the linkset at each node. The remaining bits are used to select the link within the linkset. If a combined linkset is not being used, all bits can be used to select a link within the linkset. The ITU-T standards are not explicit about which bits are used for link and linkset selection. SLS in ANSI Networks ANSI networks use an eight-bit SLS code. The SLS code was originally 5 bits, but was later increased to 8 bits to provide better distribution across links. At a SEP, the least significant bit of the SLS is used for linkset selection and the remaining bits are used for link selection if the message is being routed over a combined linkset. All bits are used to select the link when routing over a single linkset. The least significant bit is also used for linkset selection at an intermediate node routing over a combined linkset; however, only the three most significant bits and the second through fourth least significant bits are concatenated for link selection. When routing over a single linkset at the intermediate node, the three most significant bits are concatenated with the four least significant bits to form an SLS code for choosing a link. Using SLS bit rotation is the standard method of load sharing in ANSI networks. The original SLS code is right bit-shifted before the message is transmitted onto the link. The bit rotation occurs at each node, before the message is transmitted. An exception to this scheme is that SLS rotation is not performed for messages transmitted over C-Links. Bit rotation is only done on the five least significant bits to maintain backward compatibility with five-bit SLS codes. Figure 7-13 shows an example of SLS rotation for messages that originate at SSP A. The least significant bit is used to choose the linkset from a combined linkset to STP 1 or STP 2. After linkset and link selection and before message transmission, a right bit rotation is performed on the five least significant bits. At STP 1 and STP 2, a single linkset is used to route the message to SSP B. Figure 7-13. SLS Rotation Comparing the IP and MTP3 Protocols The MTP3 message handling is similar to the Internet Protocol (IP) in some respects. For those who are familiar with IP, a comparison of the two protocols helps to put MTP3 in perspective. This is not intended to suggest an exact comparison; rather, to relate something that is known about one protocol to something similar in the other. The main point is that both protocols are packet based and designed to deliver messages to a higher layer service at a node in the network. It is not surprising that there are a number of commonalities given that the requirements are similar. In fact, studying a number of communications transport protocols shows that many share a common functionality and structure, with each diverging slightly to address its particular requirements. Table 7-3 lists an association of key IP packet fields with their MTP3 counterparts. Table 7-3. Comparison of IP and MTP3 Packet Fields IP SS7 Source IP Address Originating Point Code Destination IP Address Destination Point Code Protocol Service Indicator Precedence (part of TOS field) Priority Data User Data In addition to the similarity in the packet fields, the network nodes and their functions also share common aspects. A typical IP network contains a number of hosts that communicate with other hosts, sometimes in different networks. Routers connect the different networks and allow hosts to communicate with each other. The SS7 network's SSP and SCP nodes can be viewed in much the same way as hosts in the IP network. The STP node in an SS7 network is similar to the IP router. It is used to interconnect various hosts in a hierarchical fashion and to route messages between different networks. One important distinction in this analogy is that the STP only uses static routes; it has no "routing protocols," such as those used in IP networks. While network design varies greatly between the two different types of networks, both networks employ a means of hierarchical address structure to allow for layered network design. The IP network uses classes A, B, and C, which are identified by the bit mask structure of the address. The hierarchical structure in SS7 is created by dividing the Point Code bits into identifiers that specify a level within the network. The identifiers are different in ITU-T and ANSI, but they function in the same manner. For example, ANSI creates this hierarchy by dividing the Point Code into network, cluster, and member. Both IP and SS7 have their own uniqueness; no analogy is perfect, but they do share similarities. MTP3 Message Handling Example To better understand the entire process of Message Handling, consider the example in Figure 7-14. Here, SP A is a typical SSP with two linksets connecting it to the SS7 network via an STP. Suppose that SSP A sends and receives ISUP traffic with SSP B. There is no need to be concerned with the details of ISUP at the moment— only the fact that an SSP A User Part (ISUP) needs to communicate via MTP3 with an SSP B User Part (ISUP). SSP A is setting up a call to SSP B and needs to send an ISUP message. It requests MTP3 to send a message (routing function). The payload (ISUP information) is placed in the MTP3 SIF User Info field. The destination indicated by the user part is placed in the Routing Label's DPC field. The Point Code of the node sending the message (SSP A) is placed in the OPC field. The SLS is generated and placed in the Routing Label's SLS field. MTP3 attempts to find a routeset for the Destination Point Code in its routing table; it finds a match and determines which route is associated with the routeset. The SLS is examined and a link for transmitting the message is selected. The message arrives at STP 1. Upon receiving the message, the STP examines the DPC and compares it to its own Point Code (discrimination function). The comparison fails because the DPC is the Point Code for SSP B. This causes the STP to attempt to route the message. The STP searches its routing table to find a match for the DPC. It finds a match, selects a linkset to route the message, and puts the SLS code into the message, which is modified using bit rotation, if necessary (ANSI networks). The message arrives at SSP B and is passed to MTP3 Signaling Message Handling. SSP B compares the message's DPC to its own Point Code (discrimination function) and determines that it matches. The SI is then examined to determine which User Part should receive the message (distribution function). An SI of 5 identifies the User Info as ISUP, and the message is passed to the ISUP layer for processing. This completes MTP3 message handling for this message. Figure 7-14. Example of Message Handling [View full size image]