tech-invite   World Map     

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

RFC 3332

 
 
 

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

Part 4 of 4, p. 87 to 120
Prev RFC Part

 


prevText      Top      Up      ToC       Page 87 
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 Type".

   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", "Error - Invalid Network
   Appearance" as appropriate.

   If the SGP determines that a unique Routing Key cannot be created,
   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 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".

Top      Up      ToC       Page 88 
   If an SGP determines that a received Routing Key does not currently
   exist and 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 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 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".  This result MAY be used if, for example, the SGP does not
   support RK Circuit Range Lists in a Routing Key because the SGP does
   not support ISUP traffic, or does not provide CIC range granularity.

   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 that it is a member
   before attempting to move to the ASP-Down state.

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

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

   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 effected
   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

Top      Up      ToC       Page 91 
   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 reception 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").  This is because the value indicates
   either congestion abatement or that the ITU MTP3 international
   congestion method is being used.  In the international congestion
   method, the MTP3 layer at the SGP does not maintain the congestion
   status of any destinations and therefore the SGP cannot provide any
   congestion information in response to the DAUD.  For the same reason,
   in the second of the cases above a DAUD message cannot reveal any
   congested destination(s).

   The SGP SHOULD respond to a DAUD message with the MTP3
   availability/congested status of the routeset associated with each
   Destination Point Code(s) 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).  Where the SGP maintains the
   congestion status of the SS7 destination, and the SS7 destination is
   congested, the SGP MUST additionally respond with an SCON message
   before the DAVA or DRST message.  If the SS7 destination is available
   and congested, the SGP MUST respond with an SCON message and then a
   DAVA message.  If the SS7 destination is restricted and congested,
   the SGP MUST respond with an SCON message immediately followed by a
   DRST message.  If the SGP has no information on the availability

Top      Up      ToC       Page 92 
   status of the SS7 destination, the SGP responds with a DUNA message,
   as it has no routing information to allow it to route traffic to this
   destination.

   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")

4.6 MTP3 Restart

   In the case where the MTP3 in the SG undergoes an MTP restart, event
   communication SHOULD be handled as follows:

   When the SG discovers SS7 network isolation, the SGPs send an
   indication to all concerned available ASPs (i.e., ASPs in the ASP-
   ACTIVE state) using DUNA messages for the concerned destinations.

   When the SG has completed the MTP Restart procedure, the M3UA layers
   at the SGPs inform all concerned ASPs in the ASP-ACTIVE state of any
   available/restricted SS7 destinations using the DAVA/DRST messages.
   No message is necessary for those destinations still unavailable
   after the restart procedure.

   When the M3UA layer at an ASP receives a DUNA message indicating SS7
   destination unavailability at an SG, MTP Users will receive an MTP-
   PAUSE indication and will stop any affected traffic to this
   destination.   When the M3UA receives a DAVA/DRST message, MTP Users
   will receive an MTP-RESUME indication and can resume traffic to the
   newly available SS7 destination, provided the ASP is in the ASP-
   ACTIVE state towards this SGP.

   The ASP MAY choose to audit the availability of unavailable
   destinations by sending DAUD messages.  This would be for example the
   case when an AS becomes active at an ASP and does not have current
   destination statuses.  If MTP restart is in progress at the SG, the
   SGP returns a DUNA message for that destination, even if it received
   an indication that the destination became available or restricted.

   In the IPSP case, MTP restart could be considered if the IPSP also
   has connection to an SS7 network. In that case, the same behavior as
   described above for the SGP would apply to the restarting IPSP.  This
   would also be the case if the IPSPs were perceived as exchanging MTP
   Peer PDUs, instead of MTP primitives between MTP User and MTP
   Provider.  In other words, M3UA does not provide the equivalent to

Top      Up      ToC       Page 93 
   Traffic Restart Allowed messages indicating the end of the restart
   procedure between peer IPSPs that would also be connected to an SS7
   network.

5. Examples of M3UA Procedures

   NOTE: Not all the Notify messages that are appropriate per the Notify
   procedures are shown in these examples.

5.1 Establishment of Association and Traffic between SGPs and ASPs

   These scenarios show the example M3UA message flows for the
   establishment of traffic between an SGP and an ASP or between two
   IPSPs.  In all cases it is assumed that the SCTP association is
   already set up.

5.1.1 Single ASP in an Application Server ("1+0" sparing),

   These scenarios show the example M3UA message flows for the
   establishment of traffic between an SGP and an ASP where only one ASP
   is configured within an AS (no backup).

5.1.1.1 Single ASP in an Application Server ("1+0" sparing),
        No Registration

               SGP                             ASP1
                |                               |
                |<-------------ASP Up-----------|
                |-----------ASP Up Ack--------->|
                |                               |
                |<------- ASP Active(RCn)-------|  RC: Routing Context
                |-----ASP Active Ack (RCn)----->|      (optional)
                |                               |
                |-----NTFY(AS-ACTIVE)(RCn)----->|
                |                               |

   Note: If the ASP Active message contains an optional Routing Context
   parameter, the ASP Active message only applies for the specified RC
   value(s). For an unknown RC value, the SGP responds with an Error
   message.

Top      Up      ToC       Page 94 
5.1.1.2 Single ASP in Application Server ("1+0" sparing),
        Dynamic Registration

   This scenario is the same as for 5.1.1.1 but with the optional
   exchange of registration information.  In this case the Registration
   is accepted by the SGP.

               SGP                             ASP1
                |                               |
                |<------------ASP Up------------|
                |----------ASP Up Ack---------->|
                |                               |
                |<----REGISTER REQ(LRCn,RKn)----|  LRC: Local Routing
                |                               |       Context
                |----REGISTER RESP(LRCn,RCn)--->|   RK: Routing Key
                |                               |   RC: Routing Context
                |                               |
                |<------- ASP Active(RCn)-------|
                |-----ASP Active Ack (RCn)----->|
                |                               |
                |-----NTFY(AS-ACTIVE)(RCn)----->|
                |                               |

   Note: In the case of an unsuccessful registration attempt (e.g.,
   invalid RKn), the Register Response message will contain an
   unsuccessful indication and the ASP will not subsequently send an ASP
   Active message.

Top      Up      ToC       Page 95 
5.1.1.3 Single ASP in Multiple Application Servers (each
        with "1+0" sparing), Dynamic Registration (Case 1 - Multiple
        Registration Requests)

               SGP                             ASP1
                |                               |
                |<------------ASP Up------------|
                |----------ASP Up Ack---------->|
                |                               |
                |<----REGISTER REQ(LRC1,RK1)----|  LRC: Local Routing
                |                               |       Context
                |----REGISTER RESP(LRC1,RC1)--->|   RK: Routing Key
                |                               |   RC: Routing Context
                |                               |
                |<------- ASP Active(RC1)-------|
                |-----ASP Active Ack (RC1)----->|
                |                               |
                |                               |
                |<----REGISTER REQ(LRCn,RKn)----|
                |                               |
                |----REGISTER RESP(LRCn,RCn)--->|
                |                               |
                |                               |
                |<------- ASP Active(RCn)-------|
                |-----ASP Active Ack (RCn)----->|
                |                               |

   Note: In the case of an unsuccessful registration attempt (e.g.,
   invalid RKn), the Register Response message will contain an
   unsuccessful indication and the ASP will not subsequently send an ASP
   Active message. Each LRC/RK pair registration is considered
   independently.

   It is not necessary to follow a Registration Request/Response message
   pair with an ASP Active message before sending the next Registration
   Request. The ASP Active message can be sent at any time after the
   related successful registration.

Top      Up      ToC       Page 96 
5.1.1.4 Single ASP in Multiple Application Servers (each
        with "1+0" sparing), Dynamic Registration (Case 2 - Single
        Registration Request)

               SGP                             ASP1
                |                               |
                |<------------ASP Up------------|
                |----------ASP Up Ack---------->|
                |                               |
                |<---REGISTER REQ({LRC1,RK1},---|
                |                   ...,        |
                |                 {LRCn,RKn}),--|
                |                               |
                |---REGISTER RESP({LRC1,RC1},-->|
                |                  ...,         |
                |                 (LRCn,RCn})   |
                |                               |
                |<------- ASP Active(RC1)-------|
                |-----ASP Active Ack (RC1)----->|
                |                               |
                :                               :
                :                               :
                |                               |
                |<------- ASP Active(RCn)-------|
                |-----ASP Active Ack (RCn)----->|
                |                               |

   Note: In the case of an unsuccessful registration attempt (e.g.,
   Invalid RKn), the Register Response message will contain an
   unsuccessful indication and the ASP will not subsequently send an ASP
   Active message.  Each LRC/RK pair registration is considered
   independently.

   The ASP Active message can be sent at any time after the related
   successful registration, and may have more than one RC.

5.1.2 Two ASPs in Application Server ("1+1" sparing)

   This scenario shows the example M3UA message flows for the
   establishment of traffic between an SGP and two ASPs in the same
   Application Server, where ASP1 is configured to be in the ASP-ACTIVE
   state and ASP2 is to be a "backup" in the event of communication
   failure or the withdrawal from service of ASP1.  ASP2 may act as a
   hot, warm, or cold backup depending on the extent to which ASP1 and
   ASP2 share call/transaction state or can communicate call state under
   failure/withdrawal events.  The example message flow is the same

Top      Up      ToC       Page 97 
   whether the ASP Active messages indicate "Override", "Loadshare" or
   "Broadcast" mode, although typically this example would use an
   Override mode.

      SGP                      ASP1                       ASP2
       |                        |                          |
       |<--------ASP Up---------|                          |
       |-------ASP Up Ack------>|                          |
       |                        |                          |
       |<----------------------------ASP Up----------------|
       |----------------------------ASP Up Ack------------>|
       |                        |                          |
       |                        |                          |
       |<-------ASP Active------|                          |
       |------ASP Active Ack--->|                          |
       |                        |                          |

5.1.3 Two ASPs in an Application Server ("1+1" sparing,
      loadsharing case)

   This scenario shows a similar case to Section 5.1.2 but where the two
   ASPs are brought to the state ASP-ACTIVE and subsequently loadshare
   the traffic.  In this case, one ASP is sufficient to handle the total
   traffic load.

      SGP                      ASP1                       ASP2
       |                        |                          |
       |<---------ASP Up--------|                          |
       |--------ASP Up Ack----->|                          |
       |                        |                          |
       |<-----------------------------ASP Up---------------|
       |----------------------------ASP Up Ack------------>|
       |                        |                          |
       |                        |                          |
       |<--ASP Active (Ldshr)---|                          |
       |-----ASP-Active Ack---->|                          |
       |                        |                          |
       |---NOTIFY (AS-ACTIVE)-->|                          |
       |---------------------------NOTIFY (AS-ACTIVE------>|
       |                        |                          |
       |<---------------------------ASP Active (Ldshr)-----|
       |------------------------------ASP Active Ack------>|
       |                        |                          |

Top      Up      ToC       Page 98 
5.1.4 Three ASPs in an Application Server ("n+k" sparing,
      loadsharing case)

   This scenario shows the example M3UA message flows for the
   establishment of traffic between an SGP and three ASPs in the same
   Application Server, where two of the ASPs are brought to the state
   ASP-ACTIVE and subsequently share the load.  In this case, a minimum
   of two ASPs are required to handle the total traffic load (2+1
   sparing).

      SGP                 ASP1                ASP2                ASP3
       |                   |                   |                   |
       |<------ASP Up------|                   |                   |
       |-----ASP Up Ack--->|                   |                   |
       |                   |                   |                   |
       |<-------------------------ASP Up-------|                   |
       |------------------------ASP Up Ack---->|                   |
       |                   |                   |                   |
       |<--------------------------------------------ASP Up--------|
       |--------------------------------------------ASP Up Ack---->|
       |                   |                   |                   |
       |                   |                   |                   |
       |<--ASP Act (Ldshr)-|                   |                   |
       |----ASP Act Ack--->|                   |                   |
       |                   |                   |                   |
       |                   |                   |                   |
       |<-------------------ASP Act. (Ldshr)---|                   |
       |----------------------ASP Act Ack----->|                   |
       |                   |                   |                   |
       |---------Notify (AS-ACTIVE)----------->|                   |
       |----------------------Notify (AS-ACTIVE)------------------>|

Top      Up      ToC       Page 99 
5.2 ASP Traffic Failover Examples

5.2.1 (1+1 Sparing, Withdrawal of ASP, Backup Override)

   Following on from the example in Section 5.1.2, and ASP1 withdraws
   from service:

            SGP                      ASP1                       ASP2
             |                        |                          |
             |<-----ASP Inactive------|                          |
             |----ASP Inactive Ack--->|                          |
             |                        |                          |
             |----NTFY(AS-PENDING)--->|                          |
             |-----------------------NTFY(AS-PENDING)----------->|
             |                        |                          |
             |<----------------------------- ASP Active----------|
             |-----------------------------ASP Active Ack------->|
             |                        |                          |
             |----NTFY(AS-ACTIVE)---->|                          |
             |-----------------------NTFY(AS-ACTIVE)------------>|

   Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g.,
   M3UA heartbeat loss or detection of SCTP failure), the initial ASP
   Inactive message exchange (i.e., SGP to ASP1) would not occur.

5.2.2 (1+1 Sparing, Backup Override)

   Following on from the example in Section 5.1.2, ASP2 wishes to
   Override ASP1 and take over the traffic:

            SGP                      ASP1                       ASP2
             |                        |                          |
             |<----------------------------- ASP Active----------|
             |------------------------------ASP Active Ack------>|
             |----NTFY(Alt ASP-Act)-->|
             |                        |                          |

Top      Up      ToC       Page 100 
5.2.3 (n+k Sparing, Loadsharing case, Withdrawal of ASP)

   Following on from the example in Section 5.1.4, and ASP1 withdraws
   from service:

      SGP                 ASP1                ASP2                ASP3
       |                   |                   |                   |
       |<----ASP Inact.----|                   |                   |
       |---ASP Inact Ack-->|                   |                   |
       |                   |                   |                   |
       |--------------------------------NTFY(Ins. ASPs)----------->|
       |                   |                   |                   |
       |<----------------------------------------ASP Act (Ldshr)---|
       |------------------------------------------ASP Act (Ack)--->|
       |                   |                   |                   |

   For the Notify message to be sent, the SG maintains knowledge of the
   minimum ASP resources required (e.g., if the SG knows that "n+k" =
   "2+1" for a Loadshare AS and "n" currently equals "1").

   Note: If the SGP detects loss of the ASP1 M3UA peer (e.g., M3UA
   heartbeat loss or detection of SCTP failure), the initial ASP
   Inactive message exchange (i.e., SGP-ASP1) would not occur.

5.3 Normal Withdrawal of an ASP from an Application Server
    and Teardown of an Association

   An ASP which is now confirmed in the state ASP-INACTIVE (i.e., the
   ASP has received an ASP Inactive Ack message) may now proceed to the
   ASP-DOWN state, if it is to be removed from service.  Following on
   from Section 5.2.1 or 5.2.3, where ASP1 has moved to the "Inactive"
   state:

Top      Up      ToC       Page 101 
            SGP                            ASP1
             |                              |
             |<-----ASP Inactive (RCn)------|    RC: Routing Context
             |----ASP Inactive Ack (RCn)--->|
             |                              |
             |<-----DEREGISTER REQ(RCn)-----|    See Notes
             |                              |
             |---DEREGISTER RESP(LRCn,RCn)->|
             |                              |
             :                              :
             |                              |
             |<-----------ASP Down----------|
             |---------ASP Down Ack-------->|
             |                              |

   Note: The Deregistration procedure will typically be used if the ASP
   previously used the Registration procedures for configuration within
   the Application Server.  ASP Inactive and Deregister messages
   exchanges may contain multiple Routing Contexts.

   The ASP should be in the ASP-INACTIVE state and should have
   deregistered in all its Routing Contexts before attempting to move to
   the ASP-DOWN state.

5.4  M3UA/MTP3-User Boundary Examples

5.4.1 At an ASP

   This section describes the primitive mapping between the MTP3 User
   and the M3UA layer at an ASP.

5.4.1.1 Support for MTP-TRANSFER Primitives at the ASP

5.4.1.1.1 Support for MTP-TRANSFER Request Primitive

   When the MTP3-User on the ASP has data to send to a remote MTP3-User,
   it uses the MTP-TRANSFER request primitive.  The M3UA layer at the
   ASP will do the following when it receives an MTP-TRANSFER request
   primitive from the M3UA user:

      - Determine the correct SGP;

      - Determine the correct association to the chosen SGP;

      - Determine the correct stream in the association (e.g.,
        based on SLS);

Top      Up      ToC       Page 102 
      - Determine whether to complete the optional fields of the DATA
        message;

      - Map the MTP-TRANSFER request primitive into the Protocol Data
        field of a DATA message;

      - Send the DATA message to the remote M3UA peer at the SGP,
        over the SCTP association.

         SGP                       ASP
          |                         |
          |<-----DATA Message-------|<--MTP-TRANSFER req.
          |                         |

5.4.1.1.2 Support for the MTP-TRANSFER Indication Primitive

   When the M3UA layer on the ASP receives a DATA message from the M3UA
   peer at the remote SGP, it will do the following:

      - Evaluate the optional fields of the DATA message, if present;

      - Map the Protocol Data field of a DATA message into the
        MTP-TRANSFER indication primitive;

      - Pass the MTP-TRANSFER indication primitive to the user part. In
        case of multiple user parts, the optional fields of the Data
        message are used to determine the concerned user part.

         SGP                       ASP
          |                         |
          |------Data Message------>|-->MTP-Transfer ind.
          |                         |

5.4.1.1.3 Support for ASP Querying of SS7 Destination States

   There are situations such as temporary loss of connectivity to the
   SGP that may cause the M3UA layer at the ASP to audit SS7 destination
   availability/congestion states.  Note: there is no primitive for the
   MTP3-User to request this audit from the M3UA layer as this is
   initiated by an internal M3UA management function.

Top      Up      ToC       Page 103 
         SGP                        ASP
          |                          |
          |<----------DAUD-----------|
          |<----------DAUD-----------|
          |<----------DAUD-----------|
          |                          |
          |                          |

5.4.2 At an SGP

   This section describes the primitive mapping between the MTP3-User
   and the M3UA layer at an SGP.

5.4.2.1 Support for MTP-TRANSFER Request Primitive at the SGP

   When the M3UA layer at the SGP has received DATA messages from its
   peer destined to the SS7 network it will do the following:

      - Evaluate the optional fields of the DATA message, if present, to
        determine the Network Appearance;

      - Map the Protocol data field of the DATA message into an
        MTP-TRANSFER request primitive;

      - Pass the MTP-TRANSFER request primitive to the MTP3 of the
        concerned Network Appearance.

                            SGP                        ASP
                             |                          |
        <---MTP-TRANSFER req.|<---------DATA -----------|
                             |                          |

5.4.2.2 Support for MTP-TRANSFER Indication Primitive at the SGP

   When the MTP3 layer at the SGP has data to pass its user parts, it
   will use the MTP-TRANSFER indication primitive.  The M3UA layer at
   the SGP will do the following when it receives an MTP-TRANSFER
   indication primitive:

      - Determine the correct AS using the distribution function;

      - Select an ASP in the ASP-ACTIVE state

      - Determine the correct association to the chosen ASP;

      - Determine the correct stream in the SCTP association (e.g.,
        based on SLS);

Top      Up      ToC       Page 104 
      - Determine whether to complete the optional fields of the DATA
        message;

      - Map the MTP-TRANSFER indication primitive into the Protocol Data
        field of a DATA message;

      - Send the DATA message to the remote M3UA peer in the ASP, over
        the SCTP association

                           SGP                        ASP
                            |                          |
       --MTP-TRANSFER ind.->|-----------DATA --------->|
                            |                          |

5.4.2.3 Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS Indication
        Primitives

   The MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from
   the MTP3 upper layer interface at the SGP need to be made available
   to the remote MTP3 User Part lower layer interface at the concerned
   ASP(s).

5.4.2.3.1 Destination Unavailable

   The MTP3 layer at the SGP will generate an MTP-PAUSE indication
   primitive when it determines locally that an SS7 destination is
   unreachable.  The M3UA layer will map this primitive to a DUNA
   message. The SGP M3UA layer determines the set of concerned ASPs to
   be informed based on internal SS7 network information associated with
   the MTP-PAUSE indication primitive indication.

                   SGP                       ASP
                    |                         |
 --MTP-PAUSE ind.-->|---------DUNA----------->|--MTP-PAUSE ind.-->
                    |                         |

5.4.2.3.2 Destination Available

   The MTP3 at the SGP will generate an MTP-RESUME indication primitive
   when it determines locally that an SS7 destination that was
   previously unreachable is now reachable.  The M3UA layer will map
   this primitive to a DAVA message.  The SGP M3UA determines the set of
   concerned ASPs to be informed based on internal SS7 network
   information associated with the MTP-RESUME indication primitive.

Top      Up      ToC       Page 105 
                   SGP                       ASP
                    |                         |
--MTP-RESUME ind.-->|-----------DAVA--------->|--MTP-RESUME ind.-->
                    |                         |

5.4.2.3.3 SS7 Network Congestion

   The MTP3 layer at the SGP will generate an MTP-STATUS indication
   primitive when it determines locally that the route to an SS7
   destination is congested.  The M3UA layer will map this primitive to
   a SCON message.  It will determine which ASP(s) to send the SCON
   message to, based on the intended Application Server.

                     SGP                       ASP
                      |                         |
  --MTP-STATUS ind.-->|-----------SCON--------->|--MTP-STATUS ind.-->
                      |                         |

5.4.2.3.4 Destination User Part Unavailable

   The MTP3 layer at the SGP will generate an MTP-STATUS indication
   primitive when it receives an UPU message from the SS7 network.  The
   M3UA layer will map this primitive to a DUPU message.  It will
   determine which ASP(s) to send the DUPU based on the intended
   Application Server.

                      SGP                       ASP
                       |                         |
   --MTP-STATUS ind.-->|----------DUPU---------->|--MTP-STATUS ind.-->
                       |                         |

5.5 Examples for IPSP communication.

   These scenarios show a basic example for IPSP communication for the
   three phases of the connection (establishment, data exchange,
   disconnection).  It is assumed that the SCTP association is already
   set up.  Both single exchange and double exchange behavior are
   included for illustrative purposes.

Top      Up      ToC       Page 106 
5.5.1 Single exchange:

               IPSP-A                           IPSP-B
                 |                                |
                 |-------------ASP Up------------>|
                 |<----------ASP Up Ack-----------|
                 |                                |
                 |<------- ASP Active(RCb)--------|  RC: Routing Context
                 |-----ASP Active Ack (RCb)------>|      (optional)
                 |                                |
                 |                                |
                 |<=========  DATA (RCb) ========>|
                 |                                |
                 |<-----ASP Inactive (RCb)--------|  RC: Routing Context
                 |----ASP Inactive Ack (RCb)----->|      (optional)
                 |                                |
                 |<-----------ASP Down------------|
                 |---------ASP Down Ack---------->|
                 |                                |

   Routing Context are previously agreed to be the same in both
   directions.

Top      Up      ToC       Page 107 
5.5.2 Double exchange:

               IPSP-A                           IPSP-B
                 |                                |
                 |<-------------ASP Up------------|
                 |-----------ASP Up Ack---------->|
                 |                                |
                 |-------------ASP Up------------>|  (optional)
                 |<----------ASP Up Ack-----------|  (optional)
                 |                                |
                 |<------- ASP Active(RCb)--------|  RC: Routing Context
                 |-----ASP Active Ack (RCb)------>|      (optional)
                 |                                |
                 |------- ASP Active(RCa)-------->|  RC: Routing Context
                 |<-----ASP Active Ack (RCa)------|      (optional)
                 |                                |
                 |<=========  DATA (RCa) =========|
                 |==========  DATA (RCb) ========>|
                 |                                |
                 |<-----ASP Inactive (RCb)--------|  RC: Routing Context
                 |----ASP Inactive Ack (RCb)----->|
                 |                                |
                 |------ASP Inactive (RCa)------->|  RC: Routing Context
                 |<----ASP Inactive Ack (RCa)-----|
                 |                                |
                 |<-----------ASP Down------------|
                 |---------ASP Down Ack---------->|
                 |                                |
                 |------------ASP Down----------->|  (optional)
                 |<--------ASP Down Ack-----------|  (optional)
                 |                                |

   In this approach, only one single exchange of ASP Up message can be
   considered as enough since the response by the other peer can be
   considered as a notice that it is in ASP_UP state.

   For the same reason, only one ASP Down message is needed since once
   that an IPSP receives ASP_Down ack message it is itself considered as
   being in the ASP_Down state and not allowed to receive ASPSM
   messages.

Top      Up      ToC       Page 108 
6. Security Considerations

6.1 Introduction

   M3UA is designed to carry signalling messages for telephony services.
   As such, M3UA must involve the security needs of several parties: the
   end users of the services; the network providers and the applications
   involved.  Additional requirements may come from local regulation.
   While having some overlapping security needs, any security solution
   should fulfill all of the different parties' needs.

6.2 Threats

   There is no quick fix, one-size-fits-all solution for security.  As a
   transport protocol, M3UA has the following security objectives:

      * Availability of reliable and timely user data transport.
      * Integrity of user data transport.
      * Confidentiality of user data.

   M3UA is recommended to be transported on SCTP.  SCTP [17] provides
   certain transport related security features, such as some protection
   against:

      * Blind Denial of Service Attacks
      * Flooding
      * Masquerade
      * Improper Monopolization of Services

   When M3UA is running in professionally managed corporate or service
   provider network, it is reasonable to expect that this network
   includes an appropriate security policy framework.  The "Site
   Security Handbook" [22] should be consulted for guidance.

   When the network in which M3UA runs in involves more than one party,
   it may not be reasonable to expect that all parties have implemented
   security in a sufficient manner.  In such a case, it is recommended
   that IPSEC is used to ensure confidentiality of user payload.
   Consult [23] for more information on configuring IPSEC services.

6.3 Protecting Confidentiality

   Particularly for mobile users, the requirement for confidentiality
   may include the masking of IP addresses and ports.  In this case
   application level encryption is not sufficient; IPSEC ESP [24] SHOULD
   be used instead.  Regardless of which level performs the encryption,
   the IPSEC ISAKMP [25] service SHOULD be used for key management.

Top      Up      ToC       Page 109 
7. IANA Considerations

7.1 SCTP Payload Protocol Identifier

   IANA has assigned an M3UA value for the Payload Protocol Identifier
   in the SCTP DATA chunk.  The following SCTP Payload Protocol
   Identifier is registered:

         M3UA    "3"

   The SCTP Payload Protocol Identifier value "3" SHOULD be included in
   each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA
   protocol.  The value "0" (unspecified) is also allowed but any other
   values MUST not be used.  This Payload Protocol Identifier is not
   directly used by SCTP but MAY be used by certain network entities to
   identify the type of information being carried in a DATA chunk.

   The User Adaptation peer MAY use the Payload Protocol Identifier as a
   way of determining additional information about the data being
   presented to it by SCTP.

7.2 M3UA Port Number

   IANA has registered SCTP (and UDP/TCP) Port Number 2905 for M3UA.  It
   is recommended that SGPs use this SCTP port number for listening for
   new connections.  SGPs MAY also use statically configured SCTP port
   numbers instead.

7.3 M3UA Protocol Extensions

   This protocol may also be extended through IANA in three ways:

      -- through definition of additional message classes,
      -- through definition of additional message types, and
      -- through definition of additional message parameters

   The definition and use of new message classes, types and parameters
   is an integral part of SIGTRAN adaptation layers.  Thus these
   extensions are assigned by IANA through an IETF Consensus action as
   defined in Guidelines for Writing an IANA Considerations Section in
   RFCs (25]

   The proposed extension must in no way adversely affect the general
   working of the protocol.

Top      Up      ToC       Page 110 
7.3.1 IETF Defined Message Classes

   The documentation for a new message class MUST include the following
   information:

      (a) A long and short name for the new message class;
      (b) A detailed description of the purpose of the message class.

7.3.2 IETF Defined Message Types

   The documentation for a new message type MUST include the following
   information:

      (a) A long and short name for the new message type;
      (b) A detailed description of the structure of the message;.
      (c) A detailed definition and description of intended use for each
          field within the message;
      (d) A detailed procedural description of the use of the new
          message type within the operation of the protocol;
      (e) A detailed description of error conditions when receiving this
          message type.

   When an implementation receives a message type which it does not
   support, it MUST respond with an Error (ERR) message ("Unsupported
   Message Type").

7.3.3 IETF Defined Parameter Extension

   Documentation of the message parameter MUST contain the following
   information:

      (a) Name of the parameter type;
      (b) Detailed description of the structure of the parameter field.
          This structure MUST conform to the general type-length-value
          format described in Section 3.2;
      (c) Detailed definition of each component of the parameter value;
      (d) Detailed description of the intended use of this parameter
          type, and an indication of whether and under what
          circumstances multiple instances of this parameter type may be
          found within the same message.

Top      Up      ToC       Page 111 
8. References

8.1 Normative References

   [1]  ITU-T Recommendations Q.761 to Q.767, "Signalling System No.7
        (SS7) - ISDN User Part (ISUP)"

   [2]  ANSI T1.113 - "Signaling System Number 7 - ISDN User Part"

   [3]  ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN);
        Signalling System No.7; ISDN User Part (ISUP) version 2 for the
        international interface; Part 1: Basic services"

   [4]  ITU-T Recommendations Q.711 to Q.715, "Signalling System No. 7
        (SS7) - Signalling Connection Control Part (SCCP)"

   [5]  ANSI T1.112 "Signaling System Number 7 - Signaling Connection
        Control Part"

   [6]  ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN);
        Signalling System No.7; Signalling Connection Control Part
        (SCCP) (connectionless and connection-oriented class 2) to
        support international interconnection; Part 1: Protocol
        specification"

   [7]  ITU-T Recommendations Q.701 to Q.705, "Signalling System No. 7
        (SS7) - Message Transfer Part (MTP)"

   [8] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part"

   [9]  ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN);
        Signalling System No.7; Message Transfer Part (MTP) to support
        international interconnection; Part 1: Protocol specification"

   [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.

8.2 Informative References

   [11] Ong, L., Rytina, M., Garcia, H., Schwarzbauer, L., Coene, H.,
        Lin, I., Juhasz, M. and C. Holdrege, "Framework Architecture for
        Signaling Transport", RFC 2719, October 1999.

   [12] ITU-T Recommendation Q.720, "Telephone User Part"

Top      Up      ToC       Page 112 
   [13] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7
        (SS7) - Transaction Capabilities (TCAP)"

   [14] ANSI T1.114 "Signaling System Number 7 - Transaction
        Capabilities Application Part"

   [15] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN);
        Signalling System No.7; Transaction Capabilities (TC) version 2;
        Part 1: Protocol specification"

   [16] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd
        Generation partnership Project; Technical Specification Group
        Radio Access Network; UTRAN Iu Interface: General Aspects and
        Principles"

   [17] Stewart, R., Xie, Q., Mornmeault, K., Sharp, H., Taylor, T.,
        Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control
        Transport Protocol", RFC 2960, October 2000.

   [18] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer -
        Service Specific Coordination Function for signalling at the
        Network Node Interface (SSCF at NNI)"

   [19] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer -
        Service Specific Connection Oriented Protocol (SSCOP)"

   [20] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [21] ITU-T Recommendation Q.2210 "Message Transfer Part Level 3
        functions and messages using the services of ITU Recommendation
        Q.2140"

   [22] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September
        1997.

   [23] Ramakrishnan, S., Floyd, S. and D. Black, "Security Architecture
        for the Internet Protocol", RFC 3168, November 1998.

   [24] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
        (ESP)", RFC 2406, November 1998.

   [25] Maughan, D., Schertler, M., Schneider, M. and J. Turner,
        "Internet Security Association and Key Management Protocol", RFC
        2408, November 1998.

   [26] Narten, T. and H. Alverstrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

Top      Up      ToC       Page 113 
   [27] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J.
        Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)
        - User Adaptation Layer", RFC 3331, August 2002.

   [28] George, T., et. al., "SS7 MTP2-User Peer-to-Peer Adaptation
        Layer", Work in Progress.

   [29] Telecommunication Technology Committee (TTC) Standard JT-Q704,
        "Message Transfer Part Signaling Network Functions", April 28,
        1992.

9. Acknowledgements

   The authors would like to thank Antonio Roque Alvarez, Joyce
   Archibald, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes,
   Antonio Caete, Nikhil Jain, Roland Jesske, Joe Keller, Kurt Kite,
   Ming Lin, Steve Lorusso, Naoto Makinae, Howard May, Francois
   Mouillaud, Barry Nagelberg, Neil Olson, Heinz Prantner, Shyamal
   Prasad, Mukesh Punhani, Selvam Rengasami, John Schantz, Ray Singh,
   Michael Tuexen, Nitin Tomar, Gery Verwimp, Tim Vetter, Kazuo
   Watanabe, Ben Wilson and many others for their valuable comments and
   suggestions.

10. Document Contributors

   Ian Rytina - Ericsson
   Guy Mousseau - Nortel Networks
   Lyndon Ong - Ciena
   Hanns Juergen Schwarzbauer - Siemens
   Klaus Gradischnig - Detecon Inc.
   Mallesh Kalla - Telcordia
   Normand Glaude - Performance Technologies
   Brian Bidulock - OpenSS7
   John Loughney - Nokia

Top      Up      ToC       Page 114 
Appendix A.

A.1 Signalling Network Architecture

   A Signalling Gateway is used to support the transport of MTP3-User
   signalling traffic received from the SS7 network to multiple
   distributed ASPs (e.g., MGCs and IP Databases).  Clearly, the M3UA
   protocol is not designed to meet the performance and reliability
   requirements for such transport by itself.  However, the conjunction
   of distributed architecture and redundant networks provides support
   for reliable transport of signalling traffic over IP.  The M3UA
   protocol is flexible enough to allow its operation and management in
   a variety of physical configurations, enabling Network Operators to
   meet their performance and reliability requirements.

   To meet the stringent SS7 signalling reliability and performance
   requirements for carrier grade networks, Network Operators might
   require that no single point of failure is present in the end-to-end
   network architecture between an SS7 node and an IP-based application.
   This can typically be achieved through the use of redundant SGPs or
   SGs, redundant hosts, and the provision of redundant QOS-bounded IP
   network paths for SCTP Associations between SCTP End Points.
   Obviously, the reliability of the SG, the MGC and other IP-based
   functional elements also needs to be taken into account. The
   distribution of ASPs and SGPs within the available Hosts MAY also be
   considered.  As an example, for a particular Application Server, the
   related ASPs could be distributed over at least two Hosts.

Top      Up      ToC       Page 115 
   One example of a physical network architecture relevant to SS7
   carrier grade operation in the IP network domain is shown in Figure 5
   below:

           SGs                                     MGCs

   Host#1 **************                          ************** Host#3
          *  ********__*__________________________*__********  *   =
          *  *SGP1.1*__*_____      _______________*__* ASP1 *  *  MGC1
          *  ********  *     \    /               *  ********  *
          *  ********__*______\__/________________*__********  *
          *  *SGP2.1*__*_______\/______      _____*__* ASP2 *  *
          *  ********  *       /\      |    |     *  ********  *
          *      :     *      /  \     |    |     *      :     *
          *  ********  *     /    \    |    |     *  ********  *
          *  * SGPn *  *     |    |    |    |     *  * ASPn *  *
          *  ********  *     |    |    |    |     *  ********  *
          **************     |    |    |    |     **************
                             |    |    \    /
   Host#2 **************     |    |     \  /      ************** Host#4
          *  ********__*_____|    |______\/_______*__********  *   =
          *  *SGP1.2*__*_________________/\_______*__* ASP1 *  *  MGC2
          *  ********  *                /  \      *  ********  *
          *  ********__*_______________/    \_____*__********  *
          *  *SGP2.2*__*__________________________*__* ASP2 *  *
          *  ********  *                          *  ********  *
          *      :     *     SCTP Associations    *      :     *
          *  ********  *                          *  ********  *
          *  * SGPn *  *                          *  * ASPn *  *
          *  ********  *                          *  ********  *
          **************                          **************

   SGP1.1 and SGP1.2 are part of SG1
   SGP2.1 and SGP2.2 are part of SG2

                         Figure 5 - Physical Model

   In this model, each host may have many application processes.  In the
   case of the MGC, an ASP may provide service to one or more
   Application Servers, and is identified as an SCTP end point.  One or
   more Signalling Gateway Processes make up a single Signalling
   Gateway.

   This example model can also be applied to IPSP-IPSP signalling.  In
   this case, each IPSP may have its services distributed across 2 hosts
   or more, and may have multiple server processes on each host.

Top      Up      ToC       Page 116 
   In the example above, each signalling process (SGP, ASP or IPSP) is
   the end point to more than one SCTP association, leading to more than
   one other signalling processes.  To support this, a signalling
   process must be able to support distribution of M3UA messages to many
   simultaneous active associations.  This message distribution function
   is based on the status of provisioned Routing Keys, the status of the
   signalling routes to signalling points in the SS7 network, and the
   redundancy model (active-standby, load sharing, broadcast, n+k) of
   the remote signalling processes.

   For carrier grade networks, the failure or isolation of a particular
   signalling process should not cause stable calls or transactions to
   be lost.  This implies that signalling processes need, in some cases,
   to share the call/transaction state or be able to pass the call state
   information between each other.  In the case of ASPs performing call
   processing, coordination may also be required with the related Media
   Gateway to transfer the MGC control for a particular trunk
   termination. However, this sharing or communication of
   call/transaction state information is outside the scope of this
   document.

   This model serves as an example.  M3UA imposes no restrictions as to
   the exact layout of the network elements, the message distribution
   algorithms and the distribution of the signalling processes.
   Instead, it provides a framework and a set of messages that allow for
   a flexible and scalable signalling network architecture, aiming to
   provide reliability and performance.

Top      Up      ToC       Page 117 
A.2 Redundancy Models

A.2.1 Application Server Redundancy

   At the SGP, an Application Server list contains active and inactive
   ASPs to support ASP broadcast, loadsharing and failover procedures.
   The list of ASPs within a logical Application Server is kept updated
   in the SGP to reflect the active Application Server Process(es).

   For example, in the network shown in Figure 1, all messages to DPC x
   could be sent to ASP1 in Host3 or ASP1 in Host4.  The AS list at SGP1
   in Host 1 might look like the following:

      Routing Key {DPC=x) - "Application Server #1"
         ASP1/Host3  - State = Active
         ASP1/Host4  - State = Inactive

   In this "1+1" redundancy case, ASP1 in Host3 would be sent any
   incoming message with DPC=x.  ASP1 in Host4 would normally be brought
   to the "active" state upon failure of, or loss of connectivity to,
   ASP1/Host1.

   The AS List at SGP1 in Host1 might also be set up in loadshare mode:

      Routing Key {DPC=x) - "Application Server #1"
         ASP1/Host3 - State = Active
         ASP1/Host4 - State = Active

   In this case, both the ASPs would be sent a portion of the traffic.
   For example the two ASPs could together form a database, where
   incoming queries may be sent to any active ASP.

   Care might need to be exercised by a Network Operator in the
   selection of the routing information to be used as the Routing Key
   for a particular AS.

   For example, where Application Servers are defined using ranges of
   ISUP CIC values, the Operator is implicitly splitting up control of
   the related circuit groups.  Some CIC value range assignments may
   interfere with ISUP circuit group management procedures.

   In the process of failover, it is recommended that in the case of
   ASPs supporting call processing, stable calls do not fail.  It is
   possible that calls in "transition" may fail, although measures of
   communication between the ASPs involved can be used to mitigate this.
   For example, the two ASPs may share call state via shared memory, or

Top      Up      ToC       Page 118 
   may use an ASP to ASP protocol to pass call state information.  Any
   ASP-to-ASP protocol to support this function is outside the scope of
   this document.

A.2.2 Signalling Gateway Redundancy

   Signalling Gateways may also be distributed over multiple hosts.
   Much like the AS model, SGs may comprise one or more SG Processes
   (SGPs), distributed over one or more hosts, using an active/backup or
   a loadsharing model.  Should an SGP lose all or partial SS7
   connectivity and other SGPs exist, the SGP may terminate the SCTP
   associations to the concerned ASPs.

   It is therefore possible for an ASP to route signalling messages
   destined to the SS7 network using more than one SGP.  In this model,
   a Signalling Gateway is deployed as a cluster of hosts acting as a
   single SG.  A primary/backup redundancy model is possible, where the
   unavailability of the SCTP association to a primary SGP could be used
   to reroute affected traffic to an alternate SGP.  A loadsharing model
   is possible, where the signalling messages are loadshared between
   multiple SGPs.  A broadcast model is also possible, where signalling
   messages are sent to each active SGP in the SG. The distribution of
   the MTP3-user messages over the SGPs should be done in such a way to
   minimize message missequencing, as required by the SS7 User Parts.

   It may also be possible for an ASP to use more than one SG to access
   a specific SS7 end point, in a model that resembles an SS7 STP mated
   pair.  Typically, SS7 STPs are deployed in mated pairs, with traffic
   loadshared between them.  Other models are also possible, subject to
   the limitations of the local SS7 network provisioning guidelines.

   From the perspective of the M3UA layer at an ASP, a particular SG is
   capable of transferring traffic to a provisioned SS7 destination X if
   an SCTP association with at least one SGP of the SG is established,
   the SGP has returned an acknowledgement to the ASP to indicate that
   the ASP is actively handling traffic for that destination X, the SGP
   has not indicated that the destination X is inaccessible and the SGP
   has not indicated MTP Restart.  When an ASP is configured to use
   multiple SGPs for transferring traffic to the SS7 network, the ASP
   must maintain knowledge of the current capability of the SGPs to

   handle traffic to destinations of interest.  This information is
   crucial to the overall reliability of the service, for active/backup,
   loadsharing and broadcast models, in the event of failures, recovery
   and maintenance activities.  The ASP M3UA may also use this
   information for congestion avoidance purposes.  The distribution of
   the MTP3-user messages over the SGPs should be done in such a way to
   minimize message missequencing, as required by the SS7 User Parts.

Top      Up      ToC       Page 119 
Editors' Addresses

   Greg Sidebottom
   Signatus Technologies
   Kanata, Ontario, Canada

   EMail: greg@signatustechnologies.com


   Ken Morneault
   Cisco Systems Inc.
   13615 Dulles Technology Drive
   Herndon, VA, USA  20171

   EMail: kmorneau@cisco.com


   Javier Pastor-Balbas
   Ericsson Espana S.A.
   C/ Retama 1
   28045 Madrid - Spain

   EMail: j.javier.pastor@ericsson.com

Top      Up      ToC       Page 120 
Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other
   than  English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.