MTP Level 3 UA (M3UA)

M3UA [137] provides for the transport of MTP Level 3-user part signaling (such as ISUP and SCCP) over IP using SCTP. RFC 3332 defines and supplements it with an Implementers Guide [138]. M3UA provides for seamless operation between the user part peers by fully supporting the MTP Level 3 upper-layer primitives. M3UA can be used between an SG and an MGC or IP-resident database, or between two IPSP.

The most common use for M3UA is between a SG and a MGC or IP-resident databases (such as SCPs). The SG receives SS7 signaling over standard SS7 links. It terminates MTP Levels 1 to 3 and provides message distribution, or routing, of the user part messages that is destined for MGCs or IP-resident databases. The MGCs can send to other MGCs via the SG.

Figure 14-11 shows the protocol stacks at each network element for using M3UA between a SG and a MGC. The SEP, or SEP, is a node in the SS7 network. The NIF, or Nodal Interworking Function, provides for the interworking of SS7 and IP. RFC 3332 does not define the functionality of the NIF because it was considered out of scope.

The M3UA on the MGC or IP-resident database supports the MTP Level upper-layer primitives so the user parts are unaware that MTP is terminated on the SG. The MTP service primitives [49] consist of the following:

• MTP Transfer request and indication

• MTP Pause indication

• MTP Resume indication

• MTP Status indication

The MTP Transfer primitive is used to pass user data. MTP Pause indicates that an Affected Point Code is Unavailable, and MTP Resume indicates that an Affected Point Code is Available. MTP Status provides congestion and User Part Availability information on an Affected Point Code. Later, in the Messages and Formats description of M3UA messages, it will be clear how these primitives are supported.

The M3UA layer on the SGP must maintain the state of all the configured ASPs and ASes. M3UA at the ASP must maintain the state of all configured SGPs and SGs.

The M3UA layer on the SG supports message distribution of incoming messages from the SS7 and IP-based sources. The distribution is based on matching the incoming message against the Routing Keys. When a Routing Key is selected, the Application Server state is checked to see if it is active. An Active Application Server has at least one ASP that is ready to receive data messages. If the Application Server is active, the message is forwarded to the appropriate ASP(s) that support the AS.

To determine the appropriate ASP, the SG must take into account the AS's traffic mode. There are three possible traffic modes: Override, Load Share, and Broadcast. Override traffic mode is basically an Active-Standby arrangement in which one ASP is active for receiving data messages and one or more ASPs are Standby. In this case, the SGP sends to the active ASP. In Load Share mode, one or more ASPs can be active. The SGP load shares across the active ASPs using an implementation-specific algorithm. Finally, in Broadcast mode, one or more ASPs can be active, and the SGP sends the data message to each active ASP.

The M3UA layer on the ASP must also make decisions about the distribution of outgoing messages. To do so, the M3UA layer maintains the availability and congestion state of the routes to remote SS7 destinations. An M3UA route refers to a path through an SG to an SS7 destination. If an SS7 destination is available through more than one route (more than one SG), the M3UA layer must perform some additional functions. In addition to keeping the state of each route, M3UA must also derive the overall state from the individual route states. The derived state is provided to the upper layer. Also, if each individual route is available, the M3UA should load balance across the available routes. Further, if the SG consists of more than one SGP, M3UA should load share across the available SGPs.

The M3UA layer at the SGP and ASP must maintain the state of each SCTP association. M3UA uses a client-server model with the ASP defaulting to the client and SG as the server. However, both SG and ASP should be able to be provisioned as the client or server. The client side of the relationship is responsible for establishing the association.

During the establishment of the association, several inbound and outbound streams are negotiated between the SCTP peers. The M3UA layer at both the SGP and ASP can assign data traffic to individual streams based on some parameter that ensures proper sequencing of messages, such as SLS.

M3UA has an Internet Assigned Numbers Authority (IANA) registered port number of 2905. It also has an IANA registered SCTP payload protocol identifier value of 3.

Messages and Formats

All of the UA layers use the same common header format. The common header includes the version, message type, message class, and message length. Figure 14-12 shows the format of the common message header.

The RFC provides the list of currently defined message classes and types. Several values are reserved for future extensions. IANA provides a registry of these extensions at the following Web site:

http://www.iana.org/assignments/sigtran-adapt

Table 14-1 lists the M3UA message classes and types.

Table 14-1. M3UA Message Classes and Types

Msg Class Value	Message Class and Type Names	Msg Type Value
0	Management (MGMT) messages
	Error message	0
	Notify message	1
1	Transfer messages
	Protocol Data	1
2	SS7 Signaling Network Management (SSNM) messages
	Destination Unavailable (DUNA)	1
	Destination Available (DAVA)	2
	Destination State Audit (DAUD)	3
	Signaling Congestion (SCON)	4
	Destination User Part Unavailable (DUPU)	5
	Destination Restricted	6
3	ASP State Maintenance (ASPSM) messages
	ASP Up	1
	ASP Down	2
	Heartbeat	3
	ASP Up Acknowledge	4
	ASP Down Acknowledge	5
	Heartbeat Acknowledge	6
4	ASP Traffic Maintenance (ASPTM) messages
	ASP Active	1
	ASP Inactive	2
	ASP Active Acknowledge	3
	ASP Inactive Acknowledge	4
9	Routing Key Management (RKM) messages
	Registration Request	1
	Registration Response	2
	Deregistration Request	3
	Deregistration Response	4

In addition, all UA Layers use the Tag, Length, Value (TLV) format for all parameters in a message. Figure 14-13 shows the TLV format.

Transfer Messages

There is only one transfer message: the Payload Data message type.

The Payload message type maps directly to the MTP Transfer primitive. It contains the OPC, DPC, Service Indicator Octet (SIO), SLS, and ISUP information. In addition, it can contain a Routing Context, Network Appearance, and/or Correlation Identifier.

The Routing Context associates the message with a configured Routing Key, or Application Server. It must be present if the SCTP association supports more than one Application Server.

The Network Appearance provides the SS7 network context for the point codes in the message. It is useful in the situation in which a SG is connected to more than one SS7 network and the traffic associated with these different networks is sent to the ASP over a single SCTP association. An example is the case of an SG in multiple national networks. The same Signaling Point Code value can be reused within these different national networks, and Network Appearance is needed to provide uniqueness. The Network Appearance might be necessary to indicate the format of the OPC and DPC.

The Correlation Identifier provides a unique identifier for the message that the sending M3UA assigns.

SS7 Signaling Network Management (SSNM) Messages

The SSNM messages map to the other MTP primitives: MTP Pause, MTP Resume, and MTP Status. In addition, there is support for the ASP to audit the state of an SS7 destination.

The Routing Context and Network Appearance parameters are optional in these messages just as they are in the Protocol Data message. The same rules apply.

The following are SSNM messages:

• Destination Unavailable (DUNA)— The DUNA message maps to the MTP Pause primitive. The SGP sends it to all concerned ASPs to indicate that one or more SS7 destinations are unreachable. The message can be generated from an SS7 network event if an ASP sends a message to an unavailable SS7 destination or when the ASP audits the SS7 destination. The DUNA contains the Affected Point Code parameter, which allocates 24 bits for the point code and 8 bits for a mask field. Figure 14-14 shows the Affected Point Code parameter.

  Figure 14-14. Affected Point Code Parameter

  

  
  

  The mask field indicates a number of bits in the point code value that are wild-carded. For example, ANSI networks use the mask field to indicate that all point codes in a cluster are unavailable by setting the mask field to a value of 8.

  The DUNA can also contain a Network Appearance, Routing Context, and/or Info String parameters. Again, the Routing Context must be sent if the SCTP association supports more than one Application Server. The Routing Context parameter contains all of the Routing Contexts that apply to concerned traffic flows that are affected by the state change of the SS7 destination.

• Destination Available (DAVA)— The DAVA message maps to the MTP Resume primitive. An SGP sends it to all concerned ASPs to indicate that one or more SS7 destinations are reachable. The message can be generated from an SS7 network event, or when the ASP audits the SS7 destination. It contains the same parameters as the DUNA.

• Destination State Audit (DAUD)— The DAUD message does not map to an MTP primitive. It is sent by the ASP to audit SS7 destinations that are of interest. The parameters in the message are identical to those in the DUNA.

• Signaling Congestion (SCON)— The SCON message maps to the MTP Status primitive. The SGP sends it to all concerned ASPs when the SG determines or is notified that the congestion state of an SS7 destination has changed, or in response to an ASP's Protocol Data or DAUD message. Like the DUNA and DAVA, it contains the Affected Point Code, Routing Context, Network Appearance, and Info String parameters. In addition, it includes optional Concerned Point Code and Congestion Indication parameters.

• Destination User Part Unavailable (DUPU)— The DUPU message maps to the MTP Status primitive. The SGP sends it to concerned ASPs to indicate the availability of a user part. It contains the same parameters as the DUNA message, and a User/Cause parameter that provides the user part that is affected and the unavailability cause.

• Destination Restricted (DRST)— –The SGP sends the DRST message to concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are restricted from that SG's point of view. It is also sent in response to a DAUD, if appropriate. It contains the same parameters as the DUNA message.

ASPSM and ASPTM Messages

Together, the ASPSM and ASPTM messages provide a means of controlling the state of the ASP. Further, the state of the ASP feeds into the state machine of each AS it serves. Therefore, these messages also provide a means of controlling the state of the AS.

As the RFC suggested, an ASP can have one of three states: ASP-Down, ASP-Inactive, or ASP-Active. ASP-Down indicates that the ASP is unavailable. ASP-Inactive indicates that the ASP is available but is not yet ready to send or receive data traffic. Finally, ASP-Active indicates that the ASP is available and desires to send and receive data traffic.

The RFC also suggests the following AS states: AS-Down, AS-Inactive, AS-Pending, and AS-Active. The AS-Down state indicates that all ASPs in the AS are in the ASP down state. The AS-Inactive state indicates that at least one ASP in the AS is in the ASP-Inactive state, and that no ASPs in the AS are in the ASP active state. The AS-Active state indicates that at least one ASP in the AS is in the ASP-Active state. The AS-Pending state is a transitory state; it is entered when the last active ASP transitions to ASP inactive or ASP-Down. It provides a means for the AS to recover without losing any messages if another ASP quickly becomes active.

Further, to provide an additional reliability measure, an optional heartbeat mechanism ensures that the M3UA peers are still available. Either side can initiate a heartbeat message, and the other side must respond with a heartbeat acknowledgement.

Following are ASPSM messages:

• ASP Up message— The ASP Up message is used to transition from ASP down to ASP-INACTIVE.

• ASP Up Acknowledge message— The ASP Up Acknowledge message is sent in response to an ASP Up message. The ASP does not consider itself in the ASP inactive state until the acknowledgement is received.

• ASP Down message— The ASP Down message is used to transition to ASP down from any other state.

• ASP Down Acknowledge message— The ASP Down Acknowledge message is sent in response to an ASP Down message. The SGP can also asynchronously send this message if, for instance, the SGP is going out of service. The ASP transitions to ASP down when it receives this message.

• Heartbeat message— The Heartbeat message is used to query if the peer is still available.

• Heartbeat Acknowledge message— The Heartbeat Acknowledge message is sent in response to the Heartbeat message.

The following are ASPTM messages:

• ASP Active message— The ASP Active message is used to transition from ASP inactive to ASP active.

• ASP Active Acknowledge message— The ASP Active Acknowledge message is sent in response to an ASP Active message. The ASP does not consider itself in the ASP active state until the acknowledgement is received.

• ASP Inactive message— The ASP Inactive message is used to transition from ASP active to ASP inactive.

• ASP Inactive Acknowledge message— The ASP Inactive Acknowledge message is sent in response to an ASP Inactive message. This message can also be sent asynchronously by the SGP if, for instance, an Application Server is taken out of service. The ASP transitions to ASP inactive when it receives this message.

Management (MGMT) Messages

There are two MGMT messages: Notify and Error.

The Error message provides a means of notifying the peer of an error event associated with a received message. There are a few errors worth noting because they can indicate a configuration error between the peers: "Invalid Routing Context," "Invalid Network Appearance" and "No Configured AS for ASP" errors.

The Notify message is used to notify appropriate ASPs in the ASP inactive state of Application Server state changes. It can also indicate a lack of resources for load share or that an alternate ASP has become active for an Application Server(s). Finally, it can be used to indicate an ASP failure.

Routing Key Management (RKM) Messages

As noted, Routing Keys can be statically or dynamically provisioned. The means for static provisioning is outside the scope of M3UA, but it could include a Command Line Interface (CLI) or network management system.

The RKM messages provide a means for dynamic provisioning of Routing Keys from an ASP to an SGP or between two IPSPs. These messages and procedures are optional so they do not have to be implemented by a SG or MGC:

• Registration Request and Response messages— The Registration Request message is used to register a Routing Key with the SGP or peer IPSP. The Registration Response is used to provide a response (success or failure) to the registration. Included in the response is the Routing Context assigned to the Routing Key.

• Deregistration Request and Response messages— The Deregistration Request message is used to deregister a Routing Key with the SGP or peer IPSP. It must contain the Routing Context provided in the Registration Response message. The Deregistration Response is used to respond (success or failure) to the deregistration.

SS7/C7 Variant Specifics

Mostly, M3UA is independent of the SS7/C7 variant that it is transporting. However, there are parameters that depend on the variant.