tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4666

 Errata 
Proposed STD
Pages: 124
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SIGTRAN

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

Part 1 of 5, p. 1 to 12
None       Next RFC Part

Obsoletes:    3332


Top       ToC       Page 1 
Network Working Group                                  K. Morneault, Ed.
Request for Comments: 4666                                 Cisco Systems
Obsoletes: 3332                                    J. Pastor-Balbas, Ed.
Category: Standards Track                                       Ericsson
                                                          September 2006


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

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo defines a protocol for supporting the transport of any SS7
   MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
   services of the Stream Control Transmission Protocol.  Also,
   provision is made for protocol elements that enable a seamless
   operation of the MTP3-User peers in the SS7 and IP domains.  This
   protocol would be used between a Signalling Gateway (SG) and a Media
   Gateway Controller (MGC) or IP-resident Database, or between two IP-
   based applications.  It is assumed that the SG receives SS7
   signalling over a standard SS7 interface using the SS7 Message
   Transfer Part (MTP) to provide transport.  This document obsoletes
   RFC 3332.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................6
      1.1. Scope ......................................................6
      1.2. Terminology ................................................6
      1.3. M3UA Overview ..............................................9
           1.3.1. Protocol Architecture ...............................9
           1.3.2. Services Provided by the M3UA Layer ................10
                  1.3.2.1. Support for the Transport of
                           MTP3-User Messages ........................10
                  1.3.2.2. Native Management Functions ...............11
                  1.3.2.3. Interworking with MTP3 Network
                           Management Functions ......................11
                  1.3.2.4. Support for the Management of SCTP
                           Associations between the ..................11
                  1.3.2.5. Support for the Management of
                           Connections to Multiple SGPs ..............12
      1.4. Functional Areas ..........................................12
           1.4.1. Signalling Point Code Representation ...............12
           1.4.2. Routing Contexts and Routing Keys ..................14
                  1.4.2.1. Overview ..................................14
                  1.4.2.2. Routing Key Limitations ...................15
                  1.4.2.3. Managing Routing Contexts and
                           Routing Keys ..............................15
                  1.4.2.4. Message Distribution at the SGP ...........15
                  1.4.2.5. Message Distribution at the ASP ...........16
           1.4.3. SS7 and M3UA Interworking ..........................16
                  1.4.3.1. Signalling Gateway SS7 Layers .............16
                  1.4.3.2. SS7 and M3UA Interworking at the SG .......17
                  1.4.3.3. Application Server ........................17
                  1.4.3.4. IPSP Considerations .......................18
           1.4.4. Redundancy Models ..................................18
                  1.4.4.1. Application Server Redundancy .............18
           1.4.5. Flow Control .......................................18
           1.4.6. Congestion Management ..............................19
           1.4.7. SCTP Stream Mapping ................................19
           1.4.8. SCTP Client/Server Model ...........................19
      1.5. Sample Configuration ......................................20
           1.5.1. Example 1: ISUP Message Transport ..................20
           1.5.2. Example 2: SCCP Transport between IPSPs ............21
           1.5.3. Example 3: SGP Resident SCCP Layer, with
                  Remote ASP .........................................22
      1.6. Definition of M3UA Boundaries .............................23
           1.6.1. Definition of the Boundary between M3UA and
                  an MTP3-User .......................................23
           1.6.2. Definition of the Boundary between M3UA and SCTP ...23
           1.6.3. Definition of the Boundary between M3UA and
                  Layer Management ...................................24

Top      ToC       Page 3 
   2. Conventions ....................................................27
   3. M3UA Protocol Elements .........................................28
      3.1. Common Message Header .....................................28
           3.1.1. M3UA Protocol Version: 8 bits (unsigned integer) ...28
           3.1.2. Message Classes and Types ..........................28
           3.1.3. Reserved: 8 Bits ...................................30
           3.1.4. Message Length: 32-Bits (Unsigned Integer) .........30
      3.2. Variable-Length Parameter Format ..........................30
      3.3. Transfer Messages .........................................33
           3.3.1. Payload Data Message (DATA) ........................33
      3.4. SS7 Signalling Network Management (SSNM) Messages .........36
           3.4.1. Destination Unavailable (DUNA) .....................36
           3.4.2. Destination Available (DAVA) .......................39
           3.4.3. Destination State Audit (DAUD) .....................40
           3.4.4. Signalling Congestion (SCON) .......................40
           3.4.5. Destination User Part Unavailable (DUPU) ...........43
           3.4.6. Destination Restricted (DRST) ......................45
      3.5. ASP State Maintenance (ASPSM) Messages ....................45
           3.5.1. ASP Up .............................................45
           3.5.2. ASP Up Acknowledgement (ASP Up Ack) ................46
           3.5.3. ASP Down ...........................................47
           3.5.4. ASP Down Acknowledgement (ASP Down Ack) ............48
           3.5.5. Heartbeat (BEAT) ...................................48
           3.5.6. Heartbeat Acknowledgement (BEAT Ack) ...............49
      3.6. Routing Key Management (RKM) Messages [Optional] ..........49
           3.6.1. Registration Request (REG REQ) .....................49
           3.6.2. Registration Response (REG RSP) ....................54
           3.6.3. Deregistration Request (DEREG REQ) .................56
           3.6.4. Deregistration Response (DEREG RSP) ................57
      3.7. ASP Traffic Maintenance (ASPTM) Messages ..................59
           3.7.1. ASP Active .........................................59
           3.7.2. ASP Active Acknowledgement (ASP Active Ack) ........60
           3.7.3. ASP Inactive .......................................61
           3.7.4. ASP Inactive Acknowledgement (ASP Inactive Ack) ....62
      3.8. Management (MGMT) Messages ................................63
           3.8.1. Error ..............................................63
           3.8.2. Notify .............................................67
   4. Procedures .....................................................70
      4.1. Procedures to Support the M3UA-User .......................70
           4.1.1. Receipt of Primitives from the M3UA-User ...........70
      4.2. Receipt of Primitives from the Layer Management ...........71
           4.2.1. Receipt of M3UA Peer Management Messages ...........72
      4.3. AS and ASP/IPSP State Maintenance .........................73
           4.3.1. ASP/IPSP States ....................................74
           4.3.2. AS States ..........................................76
           4.3.3. M3UA Management Procedures for Primitives ..........78
           4.3.4. ASPM Procedures for Peer-to-Peer Messages ..........79
                  4.3.4.1. ASP Up Procedures .........................79

Top      ToC       Page 4 
                  4.3.4.2. ASP-Down Procedures .......................81
                  4.3.4.3. ASP Active Procedures .....................82
                  4.3.4.4. ASP Inactive Procedures ...................86
                  4.3.4.5. Notify Procedures .........................88
                  4.3.4.6. Heartbeat Procedures ......................89
      4.4. Routing Key Management Procedures [Optional] ..............90
           4.4.1. Registration .......................................90
           4.4.2. Deregistration .....................................92
           4.4.3. IPSP Considerations (REG/DEREG) ....................93
      4.5. Procedures to Support the Availability or
           Congestion Status of SS7 Destination ......................93
           4.5.1. At an SGP ..........................................93
           4.5.2. At an ASP ..........................................94
                  4.5.2.1. Single SG Configurations ..................94
                  4.5.2.2. Multiple SG Configurations ................94
           4.5.3. ASP Auditing .......................................94
      4.6. MTP3 Restart ..............................................96
      4.7. NIF Not Available .........................................97
      4.8. M3UA Version Control ......................................97
      4.9. M3UA Termination ..........................................97
   5. Examples of M3UA Procedures ....................................98
      5.1. Establishment of Association and Traffic between
           SGPs and ASPs .............................................98
           5.1.1. Single ASP in an Application Server ("1+0"
                  sparing), No Registration ..........................98
                  5.1.1.1. Single ASP in an Application
                           Server ("1+0" Sparing), No Registration ...98
                  5.1.1.2. Single ASP in Application Server
                           ("1+0" Sparing), Dynamic Registration .....99
                  5.1.1.3. Single ASP in Multiple
                           Application Servers (Each with "1+0"
                           Sparing), Dynamic Registration (Case 1
                           - Multiple Registration Requests) ........100
                  5.1.1.4. Single ASP in Multiple
                           Application Servers (each with "1+0"
                           sparing), Dynamic Registration (Case 2
                           - Single Registration Request) ...........101
           5.1.2. Two ASPs in Application Server ("1+1" Sparing) ....102
           5.1.3. Two ASPs in an Application Server ("1+1"
                  Sparing, Loadsharing Case) ........................103
           5.1.4. Three ASPs in an Application Server ("n+k"
                  Sparing, Loadsharing Case) ........................104
      5.2. ASP Traffic Failover Examples ............................105
           5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override ...105
           5.2.2. 1+1 Sparing, Backup Override ......................105
           5.2.3. n+k Sparing, Loadsharing Case, Withdrawal of ASP ..106
      5.3. Normal Withdrawal of an ASP from an Application Server ...106
      5.4. Auditing Examples ........................................107

Top      ToC       Page 5 
           5.4.1. SG State: Uncongested/Available ...................107
           5.4.2. SG State: Congested (Congestion Level=2) /
                  Available .........................................107
           5.4.3. SG State: Unknown/Available .......................107
           5.4.4. SG State: Unavailable .............................108
      5.5. M3UA/MTP3-User Boundary Examples .........................108
           5.5.1. At an ASP .........................................108
                  5.5.1.1. Support for MTP-TRANSFER
                           Primitives at the ASP ....................108
           5.5.2. At an SGP .........................................109
                  5.5.2.1. Support for MTP-TRANSFER Request
                           Primitive at the SGP .....................109
                  5.5.2.2. Support for MTP-TRANSFER
                           Indication Primitive at the SGP ..........110
                  5.5.2.3. Support for MTP-PAUSE,
                           MTP-RESUME, MTP-STATUS Indication
                           Primitives ...............................110
      5.6. Examples for IPSP Communication ..........................112
           5.6.1. Single Exchange ...................................112
           5.6.2. Double Exchange ...................................113
   6. Security Considerations .......................................113
   7. IANA Considerations ...........................................114
      7.1. SCTP Payload Protocol Identifier .........................114
      7.2. M3UA Port Number .........................................114
      7.3. M3UA Protocol Extensions .................................114
           7.3.1. IETF-Defined Message Classes ......................115
           7.3.2. IETF Defined Message Types ........................115
           7.3.3. IETF-Defined Parameter Extension ..................115
   8. Acknowledgements ..............................................115
   9. Document Contributors .........................................116
   10. References ...................................................116
      10.1. Normative References ....................................116
      10.2. Informative References ..................................117
   Appendix A .......................................................119
   A.1. Signalling Network Architecture .............................119
   A.2. Redundancy Models ...........................................121
        A.2.1. Application Server Redundancy ........................121
        A.2.2. Signalling Gateway Redundancy ........................122

Top      ToC       Page 6 
1.  Introduction

   This memo defines a protocol for supporting the transport of any SS7
   MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
   services of the Stream Control Transmission Protocol [18].  Also,
   provision is made for protocol elements that enable a seamless
   operation of the MTP3-User peers in the SS7 and IP domains.  This
   protocol would be used between a Signalling Gateway (SG) and a Media
   Gateway Controller (MGC) or IP-resident Database [12], or between two
   IP-based applications.

1.1.  Scope

   There is a need for Switched Circuit Network (SCN) signalling
   protocol delivery from an SS7 Signalling Gateway (SG) to a Media
   Gateway Controller (MGC) or IP-resident Database as described in the
   Framework Architecture for Signalling Transport [12].  The delivery
   mechanism should meet the following criteria:

   *  Support for the transfer of all SS7 MTP3-User Part messages (e.g.,
      ISUP [1,2,3], SCCP [4,5,6], TUP [13], etc.)
   *  Support for the seamless operation of MTP3-User protocol peers
   *  Support for the management of SCTP transport associations and
      traffic between an SG and one or more MGCs or IP-resident
      Databases
   *  Support for MGC or IP-resident database process failover and load
      sharing
   *  Support for the asynchronous reporting of status changes to
      management

   In simplistic transport terms, the SG will terminate SS7 MTP2 and
   MTP3 protocol layers [7,8,9] and deliver ISUP, SCCP, and/or any other
   MTP3-User protocol messages, as well as certain MTP network
   management events, over SCTP transport associations to MTP3-User
   peers in MGCs or IP-resident databases.

1.2.  Terminology

   Application Server (AS) - A logical entity serving a specific Routing
   Key.  An example of an Application Server is a virtual switch element
   handling all call processing for a signalling relation, identified by
   an SS7 DPC/OPC.  Another example is a virtual database element,
   handling all HLR transactions for a particular SS7 SIO/DPC/OPC
   combination.  The AS contains a set of one or more unique Application
   Server Processes, of which one or more is normally actively
   processing traffic.  Note that there is a 1:1 relationship between an
   AS and a Routing Key.

Top      ToC       Page 7 
   Application Server Process (ASP) - A process instance of an
   Application Server.  An Application Server Process serves as an
   active or backup process of an Application Server (e.g., part of a
   distributed virtual switch or database).  Examples of ASPs are
   processes (or process instances) of MGCs, IP SCPs, or IP HLRs.  An
   ASP contains an SCTP endpoint and may be configured to process
   signalling traffic within more than one Application Server.

   Association - An association refers to an SCTP association.  The
   association provides the transport for the delivery of MTP3-User
   protocol data units and M3UA adaptation layer peer messages.

   IP Server Process (IPSP) - A process instance of an IP-based
   application.  An IPSP is essentially the same as an ASP, except that
   it uses M3UA in a point-to-point fashion.  Conceptually, an IPSP does
   not use the services of a Signalling Gateway node.

   Failover - The capability to reroute signalling traffic as required
   to an alternate Application Server Process, or group of ASPs, within
   an Application Server in the event of failure or unavailability of a
   currently used Application Server Process.  Failover also applies
   upon the return to service of a previously unavailable Application
   Server Process.

   Host - The computing platform that the process (SGP, ASP or IPSP) is
   running on.

   Layer Management - Layer Management is a nodal function that handles
   the inputs and outputs between the M3UA layer and a local management
   entity.

   Linkset - A number of signalling links that directly interconnect two
   signalling points, which are used as a module.

   MTP - The Message Transfer Part of the SS7 protocol.

   MTP3 - MTP Level 3, the signalling network layer of SS7.

   MTP3-User - Any protocol normally using the services of the SS7 MTP3
   (e.g., ISUP, SCCP, TUP, etc.).

   Network Appearance - The Network Appearance is a M3UA local reference
   shared by SG and AS (typically an integer) that, together with an
   Signaling Point Code, uniquely identifies an SS7 node by indicating
   the specific SS7 network to which it belongs.  It can be used to
   distinguish between signalling traffic associated with different
   networks being sent between the SG and the ASP over a common SCTP
   association.  An example scenario is where an SG appears as an

Top      ToC       Page 8 
   element in multiple separate national SS7 networks and the same
   Signaling Point Code value may be reused in different networks.

   Network Byte Order - Most significant byte first, a.k.a Big Endian.
   Routing Key - A Routing Key describes a set of SS7 parameters and
   parameter values that uniquely define the range of signalling traffic
   to be handled by a particular Application Server.  Parameters within
   the Routing Key cannot extend across more than a single Signalling
   Point Management Cluster.

   Routing Context - A value that uniquely identifies a Routing Key.
   Routing Context values are configured either using a configuration
   management interface, or by using the routing key management
   procedures defined in this document.

   Signaling End Point (SEP) - A node in the SS7 network associated with
   an originating or terminating local exchange (switch) or a gateway
   exchange.

   Signalling Gateway Process (SGP) - A process instance of a Signalling
   Gateway.  It serves as an active, backup, load-sharing, or broadcast
   process of a Signalling Gateway.

   Signalling Gateway (SG) - An SG is a signaling agent that
   receives/sends SCN native signaling at the edge of the IP network
   [12].  An SG appears to the SS7 network as an SS7 Signalling Point.
   An SG contains a set of one or more unique Signalling Gateway
   Processes, of which one or more is normally actively processing
   traffic.  Where an SG contains more than one SGP, the SG is a logical
   entity, and the contained SGPs are assumed to be coordinated into a
   single management view to the SS7 network and to the supported
   Application Servers.

   Signalling Process - A process instance that uses M3UA to communicate
   with other signalling processes.  An ASP, an SGP, and an IPSP are all
   signalling processes.

   Signalling Point Management Cluster (SPMC) - The complete set of
   Application Servers represented to the SS7 network under a single MTP
   entity (Signalling Point) in one specific Network Appearance.  SPMCs
   are used to aggregate the availability, congestion, and user part
   status of an MTP entity (Signalling Point) that is distributed in the
   IP domain, for the purpose of supporting MTP3 management procedures
   towards the SS7 network.  In some cases, the SG itself may also be a
   member of the SPMC.  In this case, the SG
   availability/congestion/User_Part status should also be taken into
   account when considering any supporting MTP3 management actions.

Top      ToC       Page 9 
   Signaling Transfer Point (STP) - A node in the SS7 network that
   provides network access and performs message routing, screening and
   transfer of signaling messages.

   Stream - An SCTP stream; a unidirectional logical channel established
   from one SCTP endpoint to another associated SCTP endpoint, within
   which all user messages are delivered in-sequence except for those
   submitted to the unordered delivery service.

1.3.  M3UA Overview

1.3.1.  Protocol Architecture

   The framework architecture that has been defined for SCN signalling
   transport over IP [12] uses multiple components, including a common
   signalling transport protocol and an adaptation module to support the
   services expected by a particular SCN signalling protocol from its
   underlying protocol layer.

   Within the framework architecture, this document defines an MTP3-User
   adaptation module suitable for supporting the transfer of messages of
   any protocol layer that is identified to the MTP Level 3 as an MTP
   User.  The list of these protocol layers includes but is not limited
   to ISDN User Part (ISUP) [1,2,3], Signalling Connection Control Part
   (SCCP) [4,5,6], and Telephone User Part (TUP) [13].  TCAP [14,15,16]
   or RANAP [16] messages are transferred transparently by the M3UA
   protocol as SCCP payload, as they are SCCP-User protocols.

   It is recommended that M3UA use the services of the Stream Control
   Transmission Protocol (SCTP) [18] as the underlying reliable common
   signalling transport protocol.  This is to take advantage of various
   SCTP features, such as:

      - Explicit packet-oriented delivery (not stream-oriented)
      - Sequenced delivery of user messages within multiple streams,
        with an option for order-of-arrival delivery of individual
        user messages
      - Optional multiplexing of user messages into SCTP datagrams
      - Network-level fault tolerance through support of multi-homing
        at either or both ends of an association
      - Resistance to flooding and masquerade attacks
      - Data segmentation to conform to discovered path MTU size

   Under certain scenarios, such as back-to-back connections without
   redundancy requirements, the SCTP functions above might not be a
   requirement, and TCP MAY be used as the underlying common transport
   protocol.

Top      ToC       Page 10 
1.3.2.  Services Provided by the M3UA Layer

   The M3UA Layer at an ASP or IPSP provides the equivalent set of
   primitives at its upper layer to the MTP3-Users as provided by the
   MTP Level 3 to its local MTP3-Users at an SS7 SEP.  In this way, the
   ISUP and/or SCCP layer at an ASP or IPSP is unaware that the expected
   MTP3 services are offered remotely from an MTP3 Layer at an SGP, and
   not by a local MTP3 layer.  The MTP3 layer at an SGP may also be
   unaware that its local users are actually remote user parts over
   M3UA.  In effect, the M3UA extends access to the MTP3 layer services
   to a remote IP-based application.  The M3UA layer does not itself
   provide the MTP3 services.  However, in the case where an ASP is
   connected to more than one SG, the M3UA layer at an ASP should
   maintain the status of configured SS7 destinations and route messages
   according to the availability and congestion status of the routes to
   these destinations via each SG.

   The M3UA layer may also be used for point-to-point signalling between
   two IP Server Processes (IPSPs).  In this case, the M3UA layer
   provides the same set of primitives and services at its upper layer
   as the MTP3.  However, in this case the expected MTP3 services are
   not offered remotely from an SGP.  The MTP3 services are provided,
   but the procedures to support these services are a subset of the MTP3
   procedures, due to the simplified point-to-point nature of the IPSP-
   to-IPSP relationship.

1.3.2.1.  Support for the Transport of MTP3-User Messages

   The M3UA layer provides the transport of MTP-TRANSFER primitives
   across an established SCTP association between an SGP and an ASP or
   between IPSPs.

   At an ASP, in the case where a destination is reachable via multiple
   SGPs, the M3UA layer must also choose via which SGP the message is to
   be routed or support load balancing across the SGPs, thereby
   minimizing missequencing.

   The M3UA layer does not impose a 272-octet signalling information
   field (SIF) length limit as specified by the SS7 MTP Level 2 protocol
   [7,8,9].  Larger information blocks can be accommodated directly by
   M3UA/SCTP, without the need for an upper layer segmentation/
   re-assembly procedure as specified in recent SCCP or ISUP versions.
   However, in the context of an SG, the maximum 272-octet block size
   must be followed when interworking to a SS7 network that does not
   support the transfer of larger information blocks to the final
   destination.  This avoids potential ISUP or SCCP fragmentation
   requirements at the SGPs.  The provisioning and configuration of the
   SS7 network determines the restriction placed on the maximum block

Top      ToC       Page 11 
   size.  Some configurations (e.g., Broadband MTP [19,20,22]) may
   permit larger block sizes.

1.3.2.2.  Native Management Functions

   The M3UA layer provides the capability to indicate errors associated
   with received M3UA messages and to notify, as appropriate, local
   management and/or the peer M3UA.

1.3.2.3.  Interworking with MTP3 Network Management Functions

   At the SGP, the M3UA layer provides interworking with MTP3 management
   functions to support seamless operation of the user SCN signalling
   applications in the SS7 and IP domains.  This includes

   - providing an indication to MTP3-Users at an ASP that a destination
     in the SS7 network is not reachable;

   - providing an indication to MTP3-Users at an ASP that a destination
     in the SS7 network is now reachable;

   - providing an indication to MTP3-Users at an ASP that messages to a
     destination in the SS7 network are experiencing SS7 congestion;

   - providing an indication to the M3UA layer at an ASP that the routes
     to a destination in the SS7 network are restricted; and

   - providing an indication to MTP3-Users at an ASP that a MTP3-User
     peer is unavailable.

   The M3UA layer at an ASP keeps the state of the routes to remote SS7
   destinations and may initiate an audit of the availability and the
   restricted or the congested state of remote SS7 destinations.  This
   information is requested from the M3UA layer at the SGP.

   The M3UA layer at an ASP may also indicate to the SG that the M3UA
   layer itself or the ASP or the ASP's Host is congested.

1.3.2.4.  Support for the Management of SCTP Associations between the
          SGP and ASPs

   The M3UA layer at the SGP maintains the availability state of all
   configured remote ASPs, to manage the SCTP Associations and the
   traffic between the M3UA peers.  Also, the active/inactive and
   congestion state of remote ASPs is maintained.

   The M3UA layer MAY be instructed by local management to establish an
   SCTP association to a peer M3UA node.  This can be achieved using the

Top      ToC       Page 12 
   M-SCTP_ESTABLISH primitives (see Section 1.6.3 for a description of
   management primitives) to request, indicate, and confirm the
   establishment of an SCTP association with a peer M3UA node.  In order
   to avoid redundant SCTP associations between two M3UA peers, one side
   (client) SHOULD be designated to establish the SCTP association, or
   M3UA configuration information maintained to detect redundant
   associations (e.g., via knowledge of the expected local and remote
   SCTP endpoint addresses).

   Local management MAY request from the M3UA layer the status of the
   underlying SCTP associations using the M-SCTP_STATUS request and
   confirm primitives.  Also, the M3UA MAY autonomously inform local
   management of the reason for the release of an SCTP association,
   determined either locally within the M3UA layer or by a primitive
   from the SCTP.

   Also, the M3UA layer MAY inform the local management of the change in
   status of an ASP or AS.  This MAY be achieved using the M-ASP_STATUS
   request or M-AS_STATUS request primitives.

1.3.2.5.  Support for the Management of Connections to Multiple SGPs

   As shown in Figure 1, an ASP may be connected to multiple SGPs.  In
   such a case, a particular SS7 destination may be reachable via more
   than one SGP and/or SG; i.e., via more than one route.  As MTP3 users
   only maintain status on a destination and not on a route basis, the
   M3UA layer must maintain the status (availability, restriction,
   and/or congestion of route to destination) of the individual routes,
   derive the overall availability or congestion status of the
   destination from the status of the individual routes, and inform the
   MTP3 users of this derived status whenever it changes.



(page 12 continued on part 2)

Next RFC Part