RFC 4666
Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
4. Procedures
The M3UA layer needs to respond to various local primitives it receives from other layers, as well as to the messages that it receives from the peer M3UA layer. This section describes the M3UA procedures in response to these events.4.1. Procedures to Support the M3UA-User
4.1.1. Receipt of Primitives from the M3UA-User
On receiving an MTP-TRANSFER request primitive from an upper layer at an ASP/IPSP, or the nodal interworking function at an SGP, the M3UA layer sends a corresponding DATA message (see Section 3) to its M3UA peer. The M3UA peer receiving the DATA message sends an MTP-TRANSFER indication primitive to the upper layer. The M3UA message distribution function (see Section 1.4.2.1) determines the Application Server (AS) by comparing the information in the MTP-TRANSFER request primitive with a provisioned Routing Key. From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE state is selected and a DATA message is constructed and issued on the corresponding SCTP association. If more than one ASP is in the ASP- ACTIVE state (i.e., traffic is to be loadshared across more than one ASP), one of the ASPs in the ASP-ACTIVE state is selected from the list. If the ASPs are in Broadcast Mode, all active ASPs will be selected, and the message will be sent to each of the active ASPs. The selection algorithm is implementation dependent but could, for example, be round robin or based on the SLS or ISUP CIC. The appropriate selection algorithm must be chosen carefully, as it is dependent on application assumptions and understanding of the degree of state coordination between the ASP-ACTIVE ASPs in the AS. In addition, the message needs to be sent on the appropriate SCTP stream, again taking care to meet the message sequencing needs of the signalling application. DATA messages MUST be sent on an SCTP stream other than stream '0'. When there is no Routing Key match, or only a partial match, for an incoming SS7 message, a default treatment MAY be specified. Possible solutions are to provide a default Application Server at the SGP that directs all unallocated traffic to a (set of) default ASP(s), or to drop the message and provide a notification to Layer Management in an M-ERROR indication primitive. The treatment of unallocated traffic is implementation dependent.
4.2. Receipt of Primitives from the Layer Management
On receiving primitives from the local Layer Management, the M3UA layer will take the requested action and provide an appropriate response primitive to Layer Management. An M-SCTP_ESTABLISH request primitive from Layer Management at an ASP or IPSP will initiate the establishment of an SCTP association. The M3UA layer will attempt to establish an SCTP association with the remote M3UA peer by sending an SCTP-ASSOCIATE primitive to the local SCTP layer. When an SCTP association has been successfully established, the SCTP will send an SCTP-COMMUNICATION_UP notification primitive to the local M3UA layer. At the SGP or IPSP that initiated the request, the M3UA layer will send an M-SCTP_ESTABLISH confirm primitive to Layer Management when the association setup is complete. At the peer M3UA layer, an M-SCTP_ESTABLISH indication primitive is sent to Layer Management upon successful completion of an incoming SCTP association setup. An M-SCTP_RELEASE request primitive from Layer Management initiates the teardown of an SCTP association. The M3UA layer accomplishes a graceful shutdown of the SCTP association by sending an SCTP-SHUTDOWN primitive to the SCTP layer. When the graceful shutdown of the SCTP association has been accomplished, the SCTP layer returns an SCTP-SHUTDOWN_COMPLETE notification primitive to the local M3UA layer. At the M3UA Layer that initiated the request, the M3UA layer will send an M- SCTP_RELEASE confirm primitive to Layer Management when the association shutdown is complete. At the peer M3UA Layer, an M- SCTP_RELEASE indication primitive is sent to Layer Management upon abort or successful shutdown of an SCTP association. An M-SCTP_STATUS request primitive supports a Layer Management query of the local status of a particular SCTP association. The M3UA layer simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS primitive to the SCTP layer. When the SCTP responds, the M3UA layer maps the association status information to an M-SCTP_STATUS confirm primitive. No peer protocol is invoked. Similar LM-to-M3UA-to-SCTP and/or SCTP-to-M3UA-to-LM primitive mappings can be described for the various other SCTP Upper Layer primitives in RFC2960 [18], such as INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT, REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET PROTOCOL PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, and NETWORK STATUS CHANGE. Alternatively, these SCTP Upper Layer
primitives (and Status as well) can be considered, for modeling purposes, as a Layer Management interaction directly with the SCTP Layer. M-NOTIFY indication and M-ERROR indication primitives indicate to Layer Management the notification or error information contained in a received M3UA Notify or Error message, respectively. These indications can also be generated based on local M3UA events. An M-ASP_STATUS request primitive supports a Layer Management query of the status of a particular local or remote ASP. The M3UA layer responds with the status in an M-ASP_STATUS confirm primitive. No M3UA peer protocol is invoked. An M-AS_STATUS request supports a Layer Management query of the status of a particular AS. The M3UA responds with an M-AS_STATUS confirm primitive. No M3UA peer protocol is invoked. M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE, and M-ASP_INACTIVE request primitives allow Layer Management at an ASP to initiate state changes. Upon successful completion, a corresponding confirm primitive is provided by the M3UA layer to Layer Management. If an invocation is unsuccessful, an Error indication primitive is provided in the primitive. These requests result in outgoing ASP Up, ASP Down, ASP Active, and ASP Inactive messages to the remote M3UA peer at an SGP or IPSP.4.2.1. Receipt of M3UA Peer Management Messages
Upon successful state changes resulting from reception of ASP Up, ASP Down, ASP Active, and ASP Inactive messages from a peer M3UA, the M3UA layer MAY invoke corresponding M-ASP_UP, M-ASP_DOWN, M- ASP_ACTIVE, M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-AS_DOWN indication primitives to the local Layer Management. M-NOTIFY indication and M-ERROR indication primitives indicate to Layer Management the notification or error information contained in a received M3UA Notify or Error message. These indications can also be generated based on local M3UA events. All non-Transfer and non-SSNM messages, except BEAT and BEAT Ack, SHOULD be sent with sequenced delivery to ensure ordering. ASPTM messages MAY be sent on one of the streams used to carry the data traffic related to the Routing Context(s), to minimize possible message loss. BEAT and BEAT Ack messages MAY be sent using out-of- order delivery and MAY be sent on any stream.
4.3. AS and ASP/IPSP State Maintenance
The M3UA layer on the SGP maintains the state of each remote ASP, in each Application Server that the ASP is configured to receive traffic, as input to the M3UA message distribution function. Similarly, where IPSPs use M3UA in a point-to-point fashion, the M3UA layer in an IPSP maintains the state of remote IPSPs. Two IPSP models are defined as follows: 1. IPSP Single Exchange (SE) model. Only a single exchange of ASPTM and ASPSM messages is needed to change the IPSP states. This means that a set of requests from one end and acknowledgements from the other will be enough. The RK must define both sides of the traffic flow. Each exchange of ASPTM or ASPSM messages can be initiated by either IPSP. For this exchange, the initiating IPSP follows the procedures described in Section 4.3.1. 2. IPSP Double Exchange (DE) model. A double exchange of ASPTM and ASPSM messages is normally needed (ASPSM single exchange is optional as a simplification). Each exchange of ASPTM or ASPSM messages can be initiated by either IPSP. The RKs define the traffic to be directed to the peer as in the AS-SG model. Therefore, two different RKs are usually used, one installed on each peer. When using double exchanges for ASPSM messages, the management of the connection in the two directions is considered independent. This means that connections from IPSP-A to IPSP-B is handled independently of connections from IPSP-B to IPSP-A. Therefore, it could happen that only one of the two directions is activated or closed, while the other remains in the same state as it was. When using single exchange of ASPSM, what is seen as a simplification, only the activation phase (ASPTM messages) is independent for each of the two directions. In this case, it could happen that the sending of the ASPSM from IPSP-A or IPSP-B could have an effect in the whole communication, as it is defined in the standard SG-AS communication. Because of these differences, there should be an agreement on the way ASPSM messages are being handled before starting DE-IPSP communication. In order to ensure interoperability, an M3UA implementation supporting IPSP communication MUST support the IPSP SE model and MAY implement the IPSP DE model.
In Section 4.3.1, ASP/IPSP States are described. In Section 4.3.2, only the SGP-ASP scenario is described. All of the procedures referring to an AS served by ASPs are also applicable to ASes served by IPSPs. In Section 4.3.3, only the Management procedures for the SGP-ASP scenario are described. The corresponding Management procedures for IPSPs are directly implied. The remaining sections contain specific IPSP Considerations subsections.4.3.1. ASP/IPSP States
The state of each remote ASP/IPSP, in each AS that it is configured to operate, is maintained in the peer M3UA layer (i.e., in the SGP or peer IPSP, respectively). The state of a particular ASP/IPSP in a particular AS changes due to events. The events include: * Receipt of messages from the peer M3UA layer at the ASP/IPSP; * Receipt of some messages from the peer M3UA layer at other ASPs/IPSPs in the AS (e.g., ASP Active message indicating "Override"); * Receipt of indications from the SCTP layer; and * Local Management intervention. The ASP/C-IPSP/D-IPSP state transition diagram is shown in Figure 3. The possible states of an ASP/D-IPSP/C-IPSP are: ASP-DOWN: The remote M3UA peer at the ASP/IPSP is unavailable, and/or the related SCTP association is down. Initially, all ASPs/IPSPs will be in this state. An ASP/IPSP in this state SHOULD NOT be sent any M3UA messages, with the exception of Heartbeat, ASP Down Ack, and Error messages. ASP-INACTIVE: The remote M3UA peer at the ASP/IPSP is available (and the related SCTP association is up), but application traffic is stopped. In this state, the ASP/IPSP SHOULD NOT be sent any DATA or SSNM messages for the AS for which the ASP/IPSP is inactive. ASP-ACTIVE: The remote M3UA peer at the ASP/IPSP is available and application traffic is active (for a particular Routing Context or set of Routing Contexts). SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication Down Indication to the Upper Layer Protocol (M3UA) on an SGP. The local SCTP layer will send this indication when it detects the loss
of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as either a SHUTDOWN_COMPLETE notification or a COMMUNICATION_LOST notification from the SCTP layer. SCTP RI: The local SCTP layer's Restart indication to the upper-layer protocol (M3UA) on an SG. The local SCTP will send this indication when it detects a restart from the peer SCTP layer. +--------------+ | | +----------------------| ASP-ACTIVE | | Other ASP/ +-------| | | IPSP in AS | +--------------+ | Overrides | ^ | | | ASPAC/ | | ASPIA/ | |[ASPAC-Ack]| | [ASPIA-Ack] | | | v | | +--------------+ | | | | | +------>| ASP-INACTIVE | | | | | +--------------+ | ^ | ASPDN/ | | | ASPDN / [ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /] SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/ SCTP RI | | | SCTP RI | | v | +--------------+ | | | +--------------------->| ASP-DOWN | | | +--------------+ Figure 3: ASP State Transition Diagram, per AS The transitions are depicted as a result of the reception of ASP*M messages or other events. In some of the transitions, there are some messages in brackets. They mean that for a given node the state transition will be different, depending on its role: whether or not it is generating the ASP*M request message (i.e., ASPUP, ASPAC, ASPIA or ASPDN) or simply receiving it. In a peer-to-peer based architecture (IPSP), this role may change between the peers. The transitions not in brackets are valid to track the states of ASPs and IPSPs that send an ASP*M request message at the peer node.
The transition in brackets may be used in an ASP or in the IPSP that
receives an ASP*M request to track the peer SGP/IPSP states,
respectively. There may be an SGP per AS state machine at ASPs.
Then, the transitions in brackets can be used for the IPSP DE model
communication (DE-IPSPs) and are related to the special cases when
just one ASP*M messages exchange is needed, as follows:
- ASPSM messages. When ASPSM messages are exchanged using only a
single exchange (only one request and one acknowledgement).
Example (see Section 5.6.2): Whenever a DE-IPSP is taking the
leading role to start communication to a peer DE-IPSP, it sends an
ASP Up message to the peer DE-IPSP. The peer MAY consider the
initiating DE-IPSPs to be in ASP-INACTIVE state, as it already sent
a message, and answer back with ASP Up Ack. Upon receipt of this
answer by the initiating DE-IPSP, it also MAY consider the peer to
be in ASP-INACTIVE state, since it did respond. Therefore, a
second ASP Up message exchange to be started by the peer DE-IPSP
could be avoided. In this case, the receipt of ASP Up Ack will
turn into a state change.
- ASPTM messages. When sending ASPTM messages to activate/deactivate
all the traffic independently of routing keys by not specifying any
RC, a single exchange could be sufficient.
4.3.2. AS States
The state of the AS is maintained in the M3UA layer on the SGPs. The
state of an AS changes due to events. These events include:
* ASP state transitions
* Recovery timer triggers
The possible states of an AS are:
AS-DOWN: The Application Server is unavailable. This state implies
that all related ASPs are in ASP-DOWN state for this AS. Initially
the AS will be in this state. An Application Server is in the AS-
DOWN state when it is removed from a configuration.
AS-INACTIVE: The Application Server is available, but no application
traffic is active. One or more related ASPs are in ASP-INACTIVE
state, and/or the number of related ASPs in ASP-ACTIVE state has not
reached n (n is the number of ASPs required to be in ASP-ACTIVE state
before AS can transition to AS-ACTIVE; n = 1 for Override Traffic
Mode) for this AS. The recovery timer T(r) is not running or has
expired.
AS-ACTIVE: The Application Server is available and application traffic is active. The AS moves to this state after being in AS- INACTIVE and getting n ASPs (n is the number of ASPs required to be in ASP-ACTIVE state before AS can transition to AS-ACTIVE; n = 1 for Override Traffic Mode) in ASP-ACTIVE state or after reaching AS- ACTIVE and keeping one or more ASPs in ASP-ACTIVE state. When one ASP is considered enough to handle traffic (smooth start), the AS in AS-INACTIVE MAY reach the AS-ACTIVE as soon as the first ASP moves to the ASP-ACTIVE state. AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP DOWN and it was the last remaining active ASP in the AS. A recovery timer T(r) SHOULD be started, and all incoming signalling messages SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, the AS is moved to the AS-ACTIVE state, and all the queued messages will be sent to the ASP. If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no alternative, the SGP may stop queuing messages and discard all previously queued messages. The AS will move to the AS-INACTIVE state if at least one ASP is in ASP-INACTIVE; otherwise, it will move to AS-DOWN state. Figure 4 shows an example AS state machine for the case where the AS/ASP data is preconfigured and is an n+k redundancy model. In other cases where the AS/ASP configuration data is created dynamically, there would be differences in the state machine, especially at creation of the AS. +----------+ IA2AC +-------------+ | AS- |---------------------------->| AS- | | INACTIVE | | ACTIVE | | |<----------- | | +----------+ \ +-------------+ ^ | \ ^ | | | IA2DN \ PN2IA | | AC2PN | | \ | | DN2IA | | \ PN2AC | | | v \ | v +----------+ \ +-------------+ | | ----------| | | AS-DOWN | | AS-PENDING | | | PN2DN | (queueing) | | |<----------------------------| | +----------+ +-------------+ Figure 4: AS State Transition Diagram
DN2IA: One ASP moves from ASP-DOWN to ASP-INACTIVE state. IA2DN: The last ASP in ASP-INACTIVE moves to ASP-DOWN, causing all the ASPs to be in ASP-DOWN state. IA2AC: One ASP moves to ASP-ACTIVE, causing the number of ASPs in the ASP-ACTIVE state to be n. In a special case of smooth start, this transition MAY be done when the first ASP moves to ASP-ACTIVE state. AC2PN: The last ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP-DOWN states, causing the number of ASPs in ASP-ACTIVE to drop below 1. PN2AC: One ASP moves to ASP-ACTIVE. PN2IA: T(r) expiry; an ASP is in ASP-INACTIVE state but no ASPs are in ASP-ACTIVE state. PN2DN: T(r) expiry; all the ASPs are in ASP-DOWN state. An AS becomes AS-ACTIVE right after n ASPs reach the ASP-ACTIVE state during the startup phase (except for smooth start). Once the traffic is flowing, an AS keeps the AS-ACTIVE state till the last ASP turns to another state different from ASP-ACTIVE, avoiding unnecessary traffic disturbances as long as there are ASPs available (this assumes that the system will not always be exposed to the maximum load). There are other cases where the AS/ASP configuration data is created dynamically. In those cases there would be differences in the state machine, especially at creation of the AS. For example, where the AS/ASP configuration data is not created until Registration of the first ASP, the AS-INACTIVE state is entered directly upon the nth successful REG REQ from an ASP belonging to that AS. Another example is where the AS/ASP configuration data is not created until the nth ASP successfully enters the ASP-ACTIVE state. In this latter case, the AS-ACTIVE state is entered directly.4.3.3. M3UA Management Procedures for Primitives
Before the establishment of an SCTP association, the ASP state at both the SGP and ASP is assumed to be in the state ASP-DOWN. Once the SCTP association is established (see Section 4.2), assuming that the local M3UA-User is ready, the local M3UA ASP Maintenance (ASPM) function will initiate the relevant procedures, using the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey the ASP state to the SGP (see Section 4.3.4).
If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN or SCTP-RESTART indication primitive from the underlying SCTP layer, it will inform the Layer Management by invoking the M-SCTP_STATUS indication primitive. The state of the ASP will be moved to ASP- DOWN. At an ASP, the MTP3-User will be informed of the unavailability of any affected SS7 destinations through the use of MTP-PAUSE indication primitives. In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re-establish the SCTP Association. This MAY be done by the M3UA layer automatically, or Layer Management MAY reestablish using the M-SCTP_ESTABLISH request primitive. In the case of an SCTP-RESTART indication at an ASP, the ASP is now considered to be in the ASP-DOWN state by its M3UA peer. The ASP, if it is to recover, must begin any recovery with the ASP-Up procedure.4.3.4. ASPM Procedures for Peer-to-Peer Messages
4.3.4.1. ASP Up Procedures
After an ASP has successfully established an SCTP association to an SGP, the SGP waits for the ASP to send an ASP Up message, indicating that the ASP M3UA peer is available. The ASP is always the initiator of the ASP Up message. This action MAY be initiated at the ASP by an M-ASP_UP request primitive from Layer Management or MAY be initiated automatically by an M3UA management function. When an ASP Up message is received at an SGP and, internally, the remote ASP is in the ASP-DOWN state and is not considered locked out for local management reasons, the SGP marks the remote ASP in the state ASP-INACTIVE and informs Layer Management with an M-ASP_Up indication primitive. If the SGP is aware, via current configuration data, which Application Servers the ASP is configured to operate in, the SGP updates the ASP state to ASP-INACTIVE in each AS that it is a member. Alternatively, the SGP may move the ASP into a pool of Inactive ASPs available for future configuration within Application Servers, determined in a subsequent Registration Request or ASP Active procedure. If the ASP Up message contains an ASP Identifier, the SGP should save the ASP Identifier for that ASP. The SGP MUST send an ASP Up Ack message in response to a received ASP Up message even if the ASP is already marked as ASP-INACTIVE at the SGP.
If for any local reason (e.g., management lockout) the SGP cannot respond with an ASP Up Ack message, the SGP responds to an ASP Up message with an Error message with the reason "Refused - Management Blocking". At the ASP, the ASP Up Ack message received is not acknowledged. Layer Management is informed with an M-ASP_UP confirm primitive. When the ASP sends an ASP Up message, it starts timer T(ack). If the ASP does not receive a response to an ASP Up message within T(ack), the ASP MAY restart T(ack) and resend ASP Up messages until it receives an ASP Up Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Up messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_UP confirm primitive carrying a negative indication. The ASP must wait for the ASP Up Ack message before sending any other M3UA messages (e.g., ASP Active or REG REQ). If the SGP receives any other M3UA messages before an ASP Up message is received (other than ASP Down; see Section 4.3.4.2), the SGP MAY discard them. If an ASP Up message is received and, internally, the remote ASP is in the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as an Error message ("Unexpected Message"). In addition, the remote ASP state is changed to ASP-INACTIVE in all relevant Application Servers, and all registered Routing Keys are considered deregistered. If an ASP Up message is received and, internally, the remote ASP is already in the ASP-INACTIVE state, an ASP Up Ack message is returned, and no further action is taken. If the ASP receives an unexpected ASP Up Ack message, the ASP should consider itself in the ASP-INACTIVE state. If the ASP was not in the ASP-INACTIVE state, it SHOULD send an Error message and then initiate procedures to return itself to its previous state.4.3.4.1.1. M3UA Version Control and ASP Up
If an ASP Up message with an unsupported version is received, the receiving end responds with an Error message, indicating the version the receiving node supports and notifies Layer Management. See Section 4.8 for more on this issue.4.3.4.1.2. IPSP Considerations (ASP Up)
An IPSP may be considered in the ASP-INACTIVE state after an ASP Up or ASP Up Ack has been received from it. An IPSP can be considered
in the ASP-DOWN state after an ASP Down or ASP Down Ack has been received from it. The IPSP may inform Layer Management of the change in state of the remote IPSP using M-ASP_UP or M-ASP_DN indication or confirmation primitives. Alternatively, when using the IPSP DE model, an interchange of ASP Up messages from each end MUST be performed. Four messages are needed for completion. If for any local reason (e.g., management lockout) an IPSP cannot respond to an ASP Up message with an ASP Up Ack message, it responds to an ASP Up message with an Error message with the reason "Refused Management Blocking" and leaves the remote IPSP in the ASP-DOWN state.4.3.4.2. ASP-Down Procedures
The ASP will send an ASP Down message to an SGP when the ASP wishes to be removed from service in all Application Servers that it is a member and no longer receive any DATA, SSNM or, ASPTM messages. This action MAY be initiated at the ASP by an M-ASP_DOWN request primitive from Layer Management or MAY be initiated automatically by an M3UA management function. Whether the ASP is permanently removed from any AS is a function of configuration management. In the case where the ASP previously used the Registration procedures (see Section 4.4.1) to register within Application Servers but has not deregistered from all of them prior to sending the ASP Down message, the SGP MUST consider the ASP Deregistered in all Application Servers that it is still a member. The SGP marks the ASP as ASP-DOWN, informs Layer Management with an M-ASP_Down indication primitive, and returns an ASP Down Ack message to the ASP. The SGP MUST send an ASP Down Ack message in response to a received ASP Down message from the ASP even if the ASP is already marked as ASP-DOWN at the SGP. At the ASP, the ASP Down Ack message received is not acknowledged. Layer Management is informed with an M-ASP_DOWN confirm primitive. If the ASP receives an ASP Down Ack without having sent an ASP Down message, the ASP should now consider itself to be in the ASP-DOWN state. If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state, the ASP should then initiate procedures to return itself to its previous state.
When the ASP sends an ASP Down message, it starts timer T(ack). If the ASP does not receive a response to an ASP Down message within T(ack), the ASP MAY restart T(ack) and resend ASP Down messages until it receives an ASP Down Ack message. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Down messages MAY be put under control of Layer Management. In this method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive, carrying a negative indication.4.3.4.3. ASP Active Procedures
Anytime after the ASP has received an ASP Up Ack message from the SGP or IPSP, the ASP MAY send an ASP Active message to the SGP, indicating that the ASP is ready to start processing traffic. This action MAY be initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer Management or MAY be initiated automatically by an M3UA management function. In the case where an ASP wishes to process the traffic for more than one Application Server across a common SCTP association, the ASP Active message(s) SHOULD contain a list of one or more Routing Contexts to indicate for which Application Servers the ASP Active message applies. It is not necessary for the ASP to include all Routing Contexts of interest in a single ASP Active message, thus requesting to become active in all Routing Contexts at the same time. Multiple ASP Active messages MAY be used to activate within the Application Servers independently, or in sets. In the case where an ASP Active message does not contain a Routing Context parameter, the receiver must know, via configuration data, which Application Server(s) the ASP is a member. For the Application Servers for which the ASP can be successfully activated, the SGP or IPSP responds with one or more ASP Active Ack messages, including the associated Routing Context(s) and reflecting any Traffic Mode Type value present in the related ASP Active message. The Routing Context parameter MUST be included in the ASP Active Ack message(s) if the received ASP Active message contained any Routing Contexts. Depending on any Traffic Mode Type request in the ASP Active message, or local configuration data if there is no request, the SGP moves the ASP to the correct ASP traffic state within the associated Application Server(s). Layer Management is informed with an M-ASP_Active indication. If the SGP or IPSP receives any Data messages before an ASP Active message is received, the SGP or IPSP MAY discard them. By sending an ASP Active Ack message, the SGP or IPSP is now ready to receive and send traffic for the related Routing Context(s). The ASP SHOULD NOT send Data or SSNM messages for the related Routing Context(s) before receiving an ASP Active Ack message, or it will risk message loss.
Multiple ASP Active Ack messages MAY be used in response to an ASP
Active message containing multiple Routing Contexts, allowing the SGP
or IPSP to independently acknowledge the ASP Active message for
different (sets of) Routing Contexts.
The ASP Active message will be responded to in the following way as a
function of the presence/need of the RC parameter:
- If the RC parameter is included in the ASP Active message and the
corresponding RK has been previously defined (by either static
configuration or dynamic registration), the peer node MUST respond
with an ASP Active Ack message. If for any local reason (e.g.,
management lockout) the SGP responds to an ASP Active message with
an Error message with reason "Refused Management Blocking".
- If the RC parameter is included in the ASP Active message and a
corresponding RK has not been previously defined (by either static
configuration or dynamic registration), the peer MUST respond with
an ERROR message with the Error Code "No configured AS for ASP".
- If (1) the RC parameter is not included in the ASP Active message,
(2) there are RKs defined (by either static configuration or
dynamic registration) and (3) RC is not mandatory, the peer node
SHOULD respond with an ASP Active Ack message and activate all the
RKs it has defined for that specific ASP.
- If (!) the RC parameter is not included in the ASP Active message,
(2) there are RKs defined (by either static configuration or
dynamic registration), (3) and RC is mandatory, the peer node MUST
respond with an ERROR message with the Error Code "Missing
Parameter".
- If (1) the RC parameter is not included in the ASP Active message,
(2) there are RKs defined (by either static configuration or
dynamic registration) and (3) RC is not mandatory, the peer node
MUST respond with an ASP Active Ack message if it is ready to
handle traffic; otherwise, it will send an ERROR message with the
Error Code "No Configured AS for ASP" (meaning that it is not ready
to become active).
- If the RC parameter is not included in the ASP Active message and
there are no RKs defined, the peer node SHOULD respond with and
ERROR message with the Error Code "Invalid Routing Context".
Independently of the RC, the SGP MUST send an ASP Active Ack message
in response to a received ASP Active message from the ASP, if the ASP
is already marked in the APS-ACTIVE state.
At the ASP, the ASP Active Ack message received is not acknowledged.
Layer Management is informed with an M-ASP_ACTIVE confirm primitive.
It is possible for the ASP to receive Data messages before the ASP
Active Ack message as the ASP Active Ack and Data messages from an SG
or IPSP may be sent on different SCTP streams. Message loss is
possible, as the ASP does not consider itself in the ASP-ACTIVE state
until receipt of the ASP Active Ack message.
When the ASP sends an ASP Active message, it starts the timer T(ack).
If the ASP does not receive a response to an ASP Active message
within T(ack), the ASP MAY restart T(ack) and resend ASP Active
messages until it receives an ASP Active Ack message. T(ack) is
provisionable, with a default of 2 seconds. Alternatively,
retransmission of ASP Active messages MAY be put under control of
Layer Management. In this method, expiry of T(ack) results in an M-
ASP_ACTIVE confirm primitive carrying a negative indication.
There are three modes of Application Server traffic handling in the
SGP M3UA layer: Override, Loadshare and Broadcast. When included,
the Traffic Mode Type parameter in the ASP Active message indicates
the traffic handling mode to be used in a particular Application
Server. If the SGP determines that the mode indicated in an ASP
Active message is unsupported or incompatible with the mode currently
configured for the AS, the SGP responds with an Error message
("Unsupported / Invalid Traffic Handling Mode"). If the traffic
handling mode of the Application Server is not already known via
configuration data, then the traffic handling mode indicated in the
first ASP Active message causing the transition of the Application
Server state to AS-ACTIVE MAY be used to set the mode.
In the case of an Override mode AS, receipt of an ASP Active message
at an SGP causes the (re)direction of all traffic for the AS to the
ASP that sent the ASP Active message. Any previously active ASP in
the AS is now considered to be in the state ASP-INACTIVE and SHOULD
no longer receive traffic from the SGP within the AS. The SGP or
IPSP then MUST send a Notify message ("Alternate ASP_Active") to the
previously active ASP in the AS and SHOULD stop traffic to/from that
ASP. The ASP receiving this Notify MUST consider itself now in the
ASP-INACTIVE state, if it is not already aware of this via inter-ASP
communication with the Overriding ASP.
In the case of a Loadshare mode AS, receipt of an ASP Active message
at an SGP or IPSP causes direction of traffic to the ASP sending the
ASP Active message, in addition to all the other ASPs that are
currently active in the AS. The algorithm at the SGP for loadsharing
traffic within an AS to all the active ASPs is implementation
dependent. The algorithm could, for example, be round-robin or based
on information in the Data message (e.g., the SLS, SCCP SSN, or ISUP
CIC value). An SGP or IPSP, upon receipt of an ASP Active message for the first ASP in a Loadshare AS, MAY choose not to direct traffic to a newly active ASP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources. For the n+k redundancy case, ASPs that are in that AS should coordinate among themselves the number of active ASPs in the AS and should start sending traffic only after n ASPs are active. All ASPs within a loadsharing mode AS must be able to process any Data message received for the AS, to accommodate any potential failover or rebalancing of the offered load. In the case of a Broadcast mode AS, receipt of an ASP Active message at an SGP or IPSP causes direction of traffic to the ASP sending the ASP Active message, in addition to all the other ASPs that are currently active in the AS. The algorithm at the SGP for broadcasting traffic within an AS to all the active ASPs is a simple broadcast algorithm, where every message is sent to each of the active ASPs. At startup or restart phases, an SGP or IPSP, upon receipt of an ASP Active message for the first ASP in a Loadshare AS, SHOULD NOT direct traffic to a newly active ASP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources. An SGP or IPSP, upon receipt of an ASP Active message for the first ASP in a Broadcast AS, MAY choose not to direct traffic to a newly active ASP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources. For the n+k redundancy case, ASPs that are in that AS should coordinate among themselves the number of active ASPs in the AS and should start sending traffic only after n ASPs are active. Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP MUST tag the first DATA message broadcast in each traffic flow with a unique Correlation Id parameter. The purpose of this Id is to permit the newly active ASP to synchronize its processing of traffic in each traffic flow with the other ASPs in the broadcast group.
4.3.4.3.1. IPSP Considerations (ASP Active)
Either of the IPSPs can initiate communication. When an IPSP receives an ASP Active, it should mark the peer as ASP-ACTIVE and return an ASP Active Ack message. An ASP receiving an ASP Active Ack message may mark the peer as ASP-Active, if it is not already in the ASP-ACTIVE state. Alternatively, when using the IPSP DE model, an interchange of ASP Active messages from each end MUST be performed. Four messages are needed for completion.4.3.4.4. ASP Inactive Procedures
When an ASP wishes to withdraw from receiving traffic within an AS or the ASP wants to initiate the process of deactivation, the ASP sends an ASP Inactive message to the SGP or IPSP. An ASP Inactive message MUST always be responded to by the peer (although other messages may be sent in the middle) in the following way: - If the received ASP Inactive message contains an RC parameter and the corresponding RK is defined (by either static configuration or dynamic registration), the SGP/IPSP MUST respond with an ASP Inactive Ack message. - If the received ASP Inactive message contains an RC parameter that is not defined (by either static configuration or dynamic registration), the SGP/IPSP MUST respond with an ERROR message with the Error Code "Invalid Routing Context". - If the received ASP Inactive message does not contain an RC parameter and the RK is defined (by either static configuration or dynamic registration), the SGP/IPSP must turn the ASP/IPSP to ASP-INACTIVE state in all the ASes it serves and MUST respond with an ASP Inactive Ack message. - If the received ASP Inactive message does not contain an RC parameter and the RK is not defined (by either static configuration or dynamic registration), the SGP/IPSP MUST respond with an ERROR message with the Error Code "No configured AS for ASP". The action of sending the ASP Inactive message MAY be initiated at the ASP by an M-ASP_INACTIVE request primitive from Layer Management or MAY be initiated automatically by an M3UA management function. In the case where an ASP is processing the traffic for more than one
Application Server across a common SCTP association, the ASP Inactive
message contains one or more Routing Contexts to indicate for which
Application Servers the ASP Inactive message applies.
In the case where an ASP Inactive message does not contain a Routing
Context parameter, the receiver must know, via configuration data,
which Application Servers the ASP is a member of and then move the
ASP to the ASP-INACTIVE state in all Application Servers.
In the case of an Override mode AS, where another ASP has already
taken over the traffic within the AS with an ASP Active ("Override")
message, the ASP that sends the ASP Inactive message is already
considered to be in ASP-INACTIVE state by the SGP. An ASP Inactive
Ack message is sent to the ASP, after ensuring that all traffic is
stopped to the ASP.
In the case of a Loadshare mode AS, the SGP moves the ASP to the
ASP-INACTIVE state, and the AS traffic is reallocated across the
remaining ASPs in the state ASP-ACTIVE, as per the loadsharing
algorithm currently used within the AS. A Notify message
("Insufficient ASP resources active in AS") MAY be sent to all
inactive ASPs, if required. An ASP Inactive Ack message is sent to
the ASP after all traffic is halted, and Layer Management is informed
with an M-ASP_INACTIVE indication primitive.
In the case of a Broadcast mode AS, the SGP moves the ASP to the
ASP-INACTIVE state, and the AS traffic is broadcast only to the
remaining ASPs in the state ASP-ACTIVE. A Notify message
("Insufficient ASP resources active in AS") MAY be sent to all
inactive ASPs, if required. An ASP Inactive Ack message is sent to
the ASP after all traffic is halted, and Layer Management is informed
with an M-ASP_INACTIVE indication primitive.
Multiple ASP Inactive Ack messages MAY be used in response to an ASP
Inactive message containing multiple Routing Contexts, allowing the
SGP or IPSP to independently acknowledge for different (sets of)
Routing Contexts. The SGP or IPSP sends an Error message ("Invalid
Routing Context") message for each invalid or unconfigured Routing
Context value in a received ASP Inactive message.
The SGP MUST send an ASP Inactive Ack message in response to a
received ASP Inactive message from the ASP; the ASP is already marked
as ASP-INACTIVE at the SGP.
At the ASP, the ASP Inactive Ack message received is not
acknowledged. Layer Management is informed with an M-ASP_INACTIVE
confirm primitive. If the ASP receives an ASP Inactive Ack without
having sent an ASP Inactive message, the ASP should now consider
itself to be in the ASP-INACTIVE state. If the ASP was previously in
the ASP-ACTIVE state, the ASP should then initiate procedures to
return itself to its previous state.
When the ASP sends an ASP Inactive message, it starts the timer
T(ack). If the ASP does not receive a response to an ASP Inactive
message within T(ack), the ASP MAY restart T(ack) and resend ASP
Inactive messages until it receives an ASP Inactive Ack message.
T(ack) is provisionable, with a default of 2 seconds. Alternatively,
retransmission of ASP Inactive messages MAY be put under control of
Layer Management. In this method, expiry of T(ack) results in an M-
ASP_Inactive confirm primitive carrying a negative indication.
If no other ASPs in the Application Server are in the state ASP-
ACTIVE, the SGP MUST send a Notify message ("AS-Pending") to all ASPs
in the AS that are in the state ASP-INACTIVE. The SGP SHOULD start
buffering the incoming messages for T(r) seconds, after which
messages MAY be discarded. T(r) is configurable by the network
operator. If the SGP receives an ASP Active message from an ASP in
the AS before expiry of T(r), the buffered traffic is directed to
that ASP, and the timer is cancelled. If T(r) expires, the AS is
moved to the AS-INACTIVE state.
4.3.4.4.1. IPSP Considerations (ASP Inactive)
An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP
after an ASP Inactive or ASP Inactive Ack message has been received
from it.
Alternatively, when using IPSP DE model, an interchange of ASP
Inactive messages from each end MUST be performed. Four messages are
needed for completion.
4.3.4.5. Notify Procedures
A Notify message reflecting a change in the AS state MUST be sent to
all ASPs in the AS, except those in the ASP-DOWN state, with
appropriate Status Information and any ASP Identifier of the failed
ASP. At the ASP, Layer Management is informed with an M-NOTIFY
indication primitive. The Notify message must be sent whether the AS
state change was a result of an ASP failure or receipt of an ASP
State management (ASPSM) / ASP Traffic Management (ASPTM) message.
In the second case, the Notify message MUST be sent after any related
acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active
Ack, or ASP Inactive Ack).
When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular
AS, a Notify message SHOULD be sent, by the ASP-UP receptor, after
sending the ASP-UP-ACK, in order to inform the ASP of the current AS
state.
In the case where a Notify message ("AS-PENDING") message is sent by
an SGP that now has no ASPs active to service the traffic, or where a
Notify ("Insufficient ASP resources active in AS") message is sent in
the Loadshare or Broadcast mode, the Notify message does not
explicitly compel the ASP(s) receiving the message to become active.
The ASPs remain in control of what (and when) traffic action is
taken.
In the case where a Notify message does not contain a Routing Context
parameter, the receiver must know, via configuration data, of which
Application Servers the ASP is a member and take the appropriate
action in each AS.
4.3.4.5.1. IPSP Considerations (NTFY)
Notify works in the same manner as in the SG-AS case. One of the
IPSPs can send this message to any remote IPSP that is not in the
ASP-DOWN state.
4.3.4.6. Heartbeat Procedures
The optional Heartbeat procedures MAY be used when operating over
transport layers that do not have their own heartbeat mechanism for
detecting loss of the transport association (i.e., other than SCTP).
Either M3UA peer may optionally send Heartbeat messages periodically,
subject to a provisionable timer, T(beat). Upon receiving a
Heartbeat message, the M3UA peer MUST respond with a Heartbeat Ack
message.
If no Heartbeat Ack message (or any other M3UA message) is received
from the M3UA peer within 2*T(beat), the remote M3UA peer is
considered unavailable. Transmission of Heartbeat messages is
stopped, and the signalling process SHOULD attempt to re-establish
communication if it is configured as the client for the disconnected
M3UA peer.
The Heartbeat message may optionally contain an opaque Heartbeat Data
parameter that MUST be echoed back unchanged in the related Heartbeat
Ack message. The sender, upon examining the contents of the returned
Heartbeat Ack message, MAY choose to consider the remote M3UA peer as
unavailable. The contents/format of the Heartbeat Data parameter is
implementation-dependent and only of local interest to the original
sender. The contents may be used, for example, to support a
Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a
timestamp mechanism (to evaluate delays).
Note: Heartbeat-related events are not shown in Figure 3 "ASP state transition diagram".4.4. Routing Key Management Procedures [Optional]
4.4.1. Registration
An ASP MAY dynamically register with an SGP as an ASP within an Application Server using the REG REQ message. A Routing Key parameter in the REG REQ message specifies the parameters associated with the Routing Key. The SGP examines the contents of the received Routing Key parameter and compares it with the currently provisioned Routing Keys. If the received Routing Key matches an existing SGP Routing Key entry and the ASP is not currently included in the list of ASPs for the related Application Server, the SGP MAY authorize the ASP to be added to the AS. Or, if the Routing Key does not currently exist and the received Routing Key data is valid and unique, an SGP supporting dynamic configuration MAY authorize the creation of a new Routing Key and related Application Server and add the ASP to the new AS. In either case, the SGP returns a Registration Response message to the ASP, containing the same Local-RK-Identifier as provided in the initial request, and a Registration Result "Successfully Registered". A unique Routing Context value assigned to the SGP Routing Key is included. The method of Routing Context value assignment at the SGP is implementation dependent but must be guaranteed to be unique for each Application Server or Routing Key supported by the SGP. If the SGP does not support the registration procedure, the SGP returns an Error message to the ASP, with an error code of "Unsupported Message Class". If the SGP determines that the received Routing Key data is invalid, or contains invalid parameter values, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error Invalid Routing Key", "Error - Invalid DPC", or "Error - Invalid Network Appearance", as appropriate. If the SGP determines that the requested RK partially, but not exactly, matches an existing RK, and that an incoming signalling message received at an SGP could possibly match both the requested and the existing RK, the SGP returns a Registration Response message to the ASP, with a Registration Status of "Error - "Cannot Support Unique Routing". An incoming signalling message received at an SGP should not match against more than one Routing Key.
If the SGP determines that the received RK was already registered, fully and exactly, either statically or dynamically, by the sending ASP, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Routing Key Already Registered". This error applies whether the sending ASP/IPSP is in ASP-ACTIVE or ASP-INACTIVE for the corresponding AS. For this error code, the RC field in the Registration Response message MUST be populated with the actual value of RC in SGP corresponding to the specified RK in the Registration Request message. An ASP MAY request modification of an existing Routing Key by including a Routing Context parameter in a Registration Request message. Upon receipt of a Registration Request message containing a Routing Context, if the SGP determines that the Routing Context applies to an existing Routing Key, the SGP MAY adjust the existing Routing Key to match the new information provided in the Routing Key parameter. A Registration Response "ERR Routing Key Change Refused" is returned if the SGP does not support this re-registration procedure or RC does not exist. Otherwise, a Registration Response "Successfully Registered" is returned. If the SGP does not authorize an otherwise valid registration request, the SGP returns a REG RSP message to the ASP containing the Registration Result "Error - Permission Denied". If an SGP determines that a received Routing Key does not currently exist, and that the SGP does not support dynamic configuration, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Routing Key not Currently Provisioned". If an SGP determines that a received Routing Key does not currently exist and that the SGP supports dynamic configuration but does not have the capacity to add new Routing Key and Application Server entries, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Insufficient Resources". If an SGP determines that a received Routing Key does not currently exist, and the SGP supports dynamic configuration but requires that the Routing Key first be manually provisioned at the SGP, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Routing Key not Currently Provisioned". If an SGP determines that one or more of the Routing Key parameters are not supported for the purpose of creating new Routing Key entries, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Unsupported RK parameter field".
A Registration Response "Error - Unsupported Traffic Handling Mode" is returned if the Routing Key in the REG REQ contains an Traffic Handling Mode that is inconsistent with the presently configured mode for the matching Application Server. An ASP MAY register multiple Routing Keys at once by including a number of Routing Key parameters in a single REG REQ message. The SGP MAY respond to each registration request in a single REG RSP message, indicating the success or failure result for each Routing Key in a separate Registration Result parameter. Alternatively the SGP MAY respond with multiple REG RSP messages, each with one or more Registration Result parameters. The ASP uses the Local-RK-Identifier parameter to correlate the requests with the responses. Upon successful registration of an ASP in an AS, the SGP can now send related SS7 Signalling Network Management messaging, if this did not previously start upon the ASP transitioning to state ASP-INACTIVE4.4.2. Deregistration
An ASP MAY dynamically deregister with an SGP as an ASP within an Application Server using the DEREG REQ message. A Routing Context parameter in the DEREG REQ message specifies which Routing Keys to deregister. An ASP SHOULD move to the ASP-INACTIVE state for an Application Server before attempting to deregister the Routing Key (i.e., deregister after receiving an ASP Inactive Ack). Also, an ASP SHOULD deregister from all Application Servers of which it is a member before attempting to move to the ASP-Down state. The SGP examines the contents of the received Routing Context parameter and validates that the ASP is currently registered in the Application Server(s) related to the included Routing Context(s). If validated, the ASP is deregistered as an ASP in the related Application Server. The deregistration procedure does not necessarily imply the deletion of Routing Key and Application Server configuration data at the SG. Other ASPs may continue to be associated with the Application Server, in which case the Routing Key data SHOULD NOT be deleted. If a Deregistration results in no more ASPs in an Application Server, an SG MAY delete the Routing Key data. The SGP acknowledges the deregistration request by returning a DEREG RSP message to the requesting ASP. The result of the deregistration is found in the Deregistration Result parameter, indicating success or failure with cause.
An ASP MAY deregister multiple Routing Contexts at once by including a number of Routing Contexts in a single DEREG REQ message. The SGP MAY respond to each deregistration request in a single DEREG RSP message, indicating the success or failure result for each Routing Context in a separate Deregistration Result parameter.4.4.3. IPSP Considerations (REG/DEREG)
The Registration/Deregistration procedures work in the IPSP cases in the same way as in AS-SG cases. An IPSP may register an RK in the remote IPSP. An IPSP is responsible for deregistering the RKs that it has registered.4.5. Procedures to Support the Availability or Congestion Status of SS7 Destination
4.5.1. At an SGP
On receiving an MTP-PAUSE, MTP-RESUME or MTP-STATUS indication primitive from the nodal interworking function at an SGP, the SGP M3UA layer will send a corresponding SS7 Signalling Network Management (SSNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the M3UA peers at concerned ASPs. The M3UA layer must fill in various fields of the SSNM messages consistently with the information received in the primitives. The SGP M3UA layer determines the set of concerned ASPs to be informed based on the specific SS7 network for which the primitive indication is relevant. In this way, all ASPs configured to send/receive traffic within a particular Network Appearance are informed. If the SGP operates within a single SS7 Network Appearance, then all ASPs are informed. For the particular case that an ASP becomes active for an AS and destinations normally accessible to the AS are inaccessible, restricted, or congested, the SG MAY send DUNA, DRST, or SCON messages for the inaccessible, restricted, or congested destinations to the ASP newly active for the AS to prevent the ASP from sending traffic for destinations that it might not otherwise know that are inaccessible, restricted, or congested. For the newly activating ASP from which the SGP has received an ASP Active message, these DUNA, DRST, and SCON messages MAY be sent before sending the ASP Active Ack that completes the activation procedure. DUNA, DAVA, SCON, and DRST messages may be sent sequentially and processed at the receiver in the order sent.
Sequencing is not required for the DUPU or DAUD messages, which MAY be sent unsequenced.4.5.2. At an ASP
4.5.2.1. Single SG Configurations
At an ASP, upon receiving an SS7 Signalling Network Management (SSNM) message from the remote M3UA Peer, the M3UA layer invokes the appropriate primitive indications to the resident M3UA-Users. Local management is informed. In the case where a local event has caused the unavailability or congestion status of SS7 destinations, the M3UA layer at the ASP SHOULD pass up appropriate indications in the primitives to the M3UA User, as though equivalent SSNM messages were received. For example, the loss of an SCTP association to an SGP may cause the unavailability of a set of SS7 destinations. MTP-PAUSE indication primitives to the M3UA User are appropriate.4.5.2.2. Multiple SG Configurations
At an ASP, upon receiving a Signalling Network Management message from the remote M3UA Peer, the M3UA layer updates the status of the affected route(s) via the originating SG and determines whether or not the overall availability or congestion status of the affected destination(s) has changed. If so, the M3UA layer invokes the appropriate primitive indications to the resident M3UA-Users. Local management is informed. Implementation Note: To accomplish this, the M3UA layer at an ASP maintains the status of routes via the SG, much like an MTP3 layer maintains route-set status.4.5.3. ASP Auditing
An ASP may optionally initiate an audit procedure to enquire of an SGP the availability and (if the national congestion method with multiple congestion levels and message priorities is used) congestion status of an SS7 destination or set of destinations. A Destination Audit (DAUD) message is sent from the ASP to the SGP, requesting the current availability and congestion status of one or more SS7 Destination Point Codes.
The DAUD message MAY be sent unsequenced. The DAUD MAY be sent by
the ASP in the following cases:
- Periodic. A Timer originally set upon receipt of a DUNA, SCON,
or DRST message has expired without a subsequent DAVA, DUNA,
SCON, or DRST message updating the availability/congestion
status of the affected Destination Point Codes. The Timer is
reset upon issuing a DAUD. In this case, the DAUD is sent to
the SGP that originally sent the SSNM message.
- Isolation. The ASP is newly ASP-ACTIVE or has been isolated
from an SGP for an extended period. The ASP MAY request the
availability/congestion status of one or more SS7 destinations
to which it expects to communicate.
Implementation Note: In the first of the cases above, the auditing
procedure must not be invoked for the case of a received SCON
message containing a congestion level value of "no congestion" or
"undefined" (i.e., congestion Level = "0").
The SGP SHOULD respond to a DAUD message with the MTP3
availability/congestion status of the routeset associated with each
Destination Point Codes in the DAUD message. The status of each SS7
destination requested is indicated in a DUNA message (if
unavailable), a DAVA message (if available), or a DRST (if restricted
and the SGP supports this feature in national networks). For
national networks, the SGP SHOULD additionally respond with a SCON
message (if the destination is congested) before the DAVA or DRST.
Where the SGP does not maintain the congestion status of the SS7
destination, the response to a DAUD message should always only be a
DAVA, DRST, or DUNA message, as appropriate.
Any DUNA or DAVA message in response to a DAUD message MAY contain a
list of Affected Point Codes.
An SG MAY refuse to provide the availability or congestion status of
a destination if, for example, the ASP is not authorized to know the
status of the destination. The SG MAY respond with an Error Message
(Error Code = "Destination Status Unknown").
An SG SHOULD respond with a DUNA message when DAUD was received with
an unknown Signalling Point Code.
(next page on part 5)
