tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4666

 
 
 

Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)

Part 4 of 5, p. 70 to 95
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 70 
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.

Top      Up      ToC       Page 71 
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

Top      Up      ToC       Page 72 
   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.

Top      Up      ToC       Page 73 
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.

Top      Up      ToC       Page 74 
   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

Top      Up      ToC       Page 75 
   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.

Top      Up      ToC       Page 76 
   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.

Top      Up      ToC       Page 77 
   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

Top      Up      ToC       Page 78 
   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).

Top      Up      ToC       Page 79 
   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.

Top      Up      ToC       Page 80 
   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

Top      Up      ToC       Page 81 
   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.

Top      Up      ToC       Page 82 
   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.

Top      Up      ToC       Page 83 
   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.

Top      Up      ToC       Page 84 
   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

Top      Up      ToC       Page 85 
   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.

Top      Up      ToC       Page 86 
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

Top      Up      ToC       Page 87 
   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

Top      Up      ToC       Page 88 
   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

Top      Up      ToC       Page 89 
   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).

Top      Up      ToC       Page 90 
   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.

Top      Up      ToC       Page 91 
   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".

Top      Up      ToC       Page 92 
   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-INACTIVE

4.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.

Top      Up      ToC       Page 93 
   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.

Top      Up      ToC       Page 94 
   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.

Top      Up      ToC       Page 95 
   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 RFC Part