Network Working Group G. Sidebottom Request for Comments: 3332 Signatus Technologies Category: Standards Track K. Morneault 

                                                                 Cisco
                                                      J. Pastor-Balbas
                                                              Ericsson
                                                               Editors
                                                        September 2002
     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 (2002).  All Rights Reserved.

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.

Table of Contents 

 1.  Introduction..................................................3
 1.1 Scope.........................................................3
 1.2 Terminology...................................................4
 1.3 M3UA Overview.................................................6
 1.4 Functional Areas.............................................10
 1.5 Sample Configurations........................................18
 1.6 Definition of M3UA Boundaries................................21
 2.  Conventions..................................................25

Sidebottom, et. al. Standards Track [Page 1] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 

 3.  M3UA Protocol Elements.......................................25
 3.1 Common Message Header........................................26
 3.2 Variable Length Parameter....................................29
 3.3 Transfer Messages............................................31
 3.4 SS7 Signalling Network Management (SSNM) Messages............35
 3.5 ASP State Maintenance (ASPSM) Messages.......................45
 3.6 Routing Key Management (RKM) Messages........................48
 3.7 ASP Traffic Maintenance (ASPTM) Messages.....................59
 3.8 Management (MGMT) Messages...................................63
 4.  Procedures...................................................69
 4.1 Procedures to Support the M3UA-User .........................69
 4.2 Procedures to Support the Management of SCTP Associations ...70
 4.3 AS and ASP State Maintenance.................................72
 4.4 Routing Key Management Procedures............................87
 4.5 Procedures to Support the Availability or Congestion Status
     of SS7 Destination...........................................89
 4.6 MTP3 Restart.................................................92
 5.  Examples of M3UA Procedures..................................93
 5.1 Establishment of Association and Traffic
     Between SGs and ASPs.........................................93
 5.2 ASP traffic Failover Examples................................99
 5.3 Normal Withdrawal of an ASP from an Application Server
     and Teardown of an Association..............................100
 5.4 M3UA/MTP3-User Boundary Examples............................101
 5.5 Examples of IPSP communication..............................105
 6.  Security Considerations.....................................108
 6.1 Introduction................................................108
 6.2 Threats.....................................................108
 6.3 Protecting Confidentiality..................................108
 7.  IANA Considerations.........................................109
 7.1 SCTP Payload Protocol Identifier............................109
 7.2 M3UA Port Number............................................109
 7.3 M3UA Protocol Extensions....................................109
 8. References...................................................111
 8.1 Normative References........................................111
 8.2 Informative References......................................111
 9. Acknowledgements.............................................113
 10. Document Contributors.......................................113
 Appendix A......................................................114
 A.1 Signalling Network Architecture.............................114
 A.2 Redundancy Models...........................................117
 Editors' Addresses..............................................119
 Full Copyright Statement........................................120

Sidebottom, et. al. Standards Track [Page 2] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002

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 [17]. 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
 Gaway Controller (MGC) or  IP-resident Database [11], 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 [11].  The delivery
 mechanism should meet the following criteria:

ISUP [1,2,3], SCCP [4,5,6], TUP [12], etc.)

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.

Sidebottom, et. al. Standards Track [Page 3] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002

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 unique range of PSTN trunks,
 identified by an SS7 SIO/DPC/OPC/CIC_range.  Another example is a
 virtual database element, handling all HLR transactions for a
 particular SS7 DPC/OPC/SCCP_SSN 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.
 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.

Sidebottom, et. al. Standards Track [Page 4] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 

 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 it belongs to. 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 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 either configured using a configuration
 management interface, or by using the routing key management
 procedures defined in this document.
 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 - An SG is a signaling agent that receives/sends
 SCN native signaling at the edge of the IP network [11].  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.

Sidebottom, et. al. Standards Track [Page 5] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 

 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.
 Stream - A stream refers to 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 [11] 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) [12].  TCAP [13,14,15]
 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) [17] as the underlying reliable common
 signalling transport protocol. This is to take advantage of various
 SCTP features such as:

Sidebottom, et. al. Standards Track [Page 6] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002

  1. Explicit packet-oriented delivery (not stream-oriented),
  2. 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, and
    - 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.

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.

Sidebottom, et. al. Standards Track [Page 7] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002

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, 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
 size.  Some configurations (e.g., Broadband MTP [21]) 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:
  1. Providing an indication to MTP3-Users at an ASP that a destination

in the SS7 network is not reachable.

  1. Providing an indication to MTP3-Users at an ASP that a destination

in the SS7 network is now reachable.

  1. Providing an indication to MTP3-Users at an ASP that messages to a

destination in the SS7 network are experiencing SS7 congestion.

Sidebottom, et. al. Standards Track [Page 8] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002

  1. Providing an indication to the M3UA layer at an ASP that the routes

to a destination in the SS7 network are restricted.

  1. 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, 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.  As well, 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
 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.

Sidebottom, et. al. Standards Track [Page 9] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002

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.

1.4 Functional Areas

1.4.1 Signalling Point Code Representation 

 For example, within an SS7 network, a Signalling Gateway might be
 charged with representing a set of nodes in the IP domain into the
 SS7 network for routing purposes.  The SG itself, as a signalling
 point in the SS7 network, might also be addressable with an SS7 Point
 Code for MTP3 Management purposes. The SG Point Code might also be
 used for addressing any local MTP3-Users at the SG such as a local
 SCCP layer.
 An SG may be logically partitioned to operate in multiple SS7 network
 appearances.  In such a case, the SG could be addressable with a
 Point Code in each network appearance, and represents a set of nodes
 in the IP domain into each SS7 network.  Alias Point Codes [8] may
 also be used within an SG network appearance.
 Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
 remote AS/ASP states of each SGP SHOULD be coordinated across all the
 SGPs.  Rerouting of traffic between the SGPs MAY also be supported.
 Application Servers can be represented under the same Point Code of
 the SG, their own individual Point Codes or grouped with other
 Application Servers for Point Code preservation purposes.  A single
 Point Code may be used to represent the SG and all the Application
 Servers together, if desired.
 If an ASP or group of ASPs is available to the SS7 network via more
 than one SG, each with its own Point Code, the ASP(s) will typically
 be represented by a Point Code that is separate from any SG Point
 Code. This allows, for example, these SGs to be viewed from the SS7
 network as "STPs", each having an ongoing "route" to the same ASP(s).
 Under failure conditions where the ASP(s) become(s) unavailable from
 one of the SGs, this approach enables MTP3 route management messaging
 between the SG and SS7 network, allowing simple SS7 rerouting through

Sidebottom, et. al. Standards Track [Page 10] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 

 an alternate SG without changing the Destination Point Code Address
 of SS7 traffic to the ASP(s).
 Where a particular AS can be reached via more than one SGP, the
 corresponding Routing Keys in the SGPs should be identical.  (Note:
 It is possible for the SGP Routing Key configuration data to be
 temporarily out-of-sync during configuration updates).
                            +--------+
                            |        |
               +------------+  SG 1  +--------------+
   +-------+   |  SS7 links | "STP"  |  IP network  |     ----
   |  SEP  +---+            +--------+              +---/      \
   |   or  |                    |*                      | ASPs  |
   |  STP  +---+            +--------+              +---\      /
   +-------+   |            |        |              |     ----
               +------------+  SG 2  +--------------+
                            | "STP"  |
                            +--------+
                  Figure 1  Example with mated SGs

carrier grade networks, using an MTP3 linkset or an equivalent, to 

 allow rerouting between the SGs in the event of route failures. Where
 SGPs are used, inter-SGP communication might be used.  Inter-SGP
 protocol is outside of the scope of this document.
 The following example shows a signalling gateway partitioned into two
 network appearances.
                                SG
   +-------+              +---------------+
   |  SEP  +--------------| SS7 Ntwk |M3UA|              ----
   +-------+   SS7 links  |   "A"    |    |            /      \
                          |__________|    +-----------+  ASPs  |
                          |          |    |            \      /
   +-------+              | SS7 Ntwk |    |              ----
   |  SEP  +--------------+   "B"    |    |
   +-------+              +---------------+
                  Figure 2  Example with multiple Network

Sidebottom, et. al. Standards Track [Page 11] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002

1.4.2 Routing Contexts and Routing Keys

1.4.2.1 Overview 

 The distribution of SS7 messages between the SGP and the Application
 Servers is determined by the Routing Keys and their associated
 Routing Contexts.  A Routing Key is essentially a set of SS7
 parameters used to filter SS7 messages, whereas the Routing Context
 parameter is a 4-byte value (integer) that is associated to that
 Routing Key in a 1:1 relationship.  The Routing Context therefore can
 be viewed as an index into a sending node's Message Distribution
 Table containing the Routing Key entries.
 Possible SS7 address/routing information that comprise a Routing Key
 entry includes, for example, the OPC, DPC, SIO found in the MTP3
 routing label, or MTP3-User specific fields (such as the ISUP CIC,
 SCCP subsystem number).  Some example Routing Keys are: the DPC
 alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the
 DPC/SSN combination.  The particular information used to define an
 M3UA Routing Key is application and network dependent, and none of
 the above examples are mandated.
 An Application Server Process may be configured to process signalling
 traffic related to more than one Application Server, over a single
 SCTP Association.  In ASP Active and ASP Inactive management
 messages, the signalling traffic to be started or stopped is
 discriminated by the Routing Context parameter.  At an ASP, the
 Routing Context parameter uniquely identifies the range of signalling
 traffic associated with each Application Server that the ASP is
 configured to receive.

1.4.2.2 Routing Key Limitations 

 Routing Keys SHOULD be unique in the sense that each received SS7
 signalling message SHOULD have a full or partial match to a single
 routing result. It is not necessary for the parameter range values
 within a particular Routing Key to be contiguous.  For example, an AS
 could be configured to support call processing for multiple ranges of
 PSTN trunks that are not represented by contiguous CIC values.

1.4.2.3 Managing Routing Contexts and Routing Keys 

 There are two ways to provision a Routing Key at an SGP.  A Routing
 Key may be configured statically using an implementation dependent
 management interface, or dynamically using the M3UA Routing Key
 registration procedure.

Sidebottom, et. al. Standards Track [Page 12] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 

 When using a management interface to configure Routing Keys, the
 message distribution function within the SGP is not limited to the
 set of parameters defined in this document.  Other implementation
 dependent distribution algorithms may be used.

1.4.2.4 Message Distribution at the SGP 

 To direct messages received from the SS7 MTP3 network to the
 appropriate IP destination, the SGP must perform a message
 distribution function using information from the received MTP3-User
 message.
 To support this message distribution, the SGP might, for example,
 maintain the equivalent of a network address translation table,
 mapping incoming SS7 message information to an Application Server for
 a particular application and range of traffic.  This could be
 accomplished by comparing elements of the incoming SS7 message to
 currently defined Routing Keys in the SGP.
 These Routing Keys could in turn map directly to an Application
 Server that is enabled by one or more ASPs.  These ASPs provide
 dynamic status information regarding their availability, traffic
 handling capability and congestion to the SGP using various
 management messages defined in the M3UA protocol.
 The list of ASPs in an AS is assumed to be dynamic, taking into
 account the availability, traffic handling capability and congestion
 status of the individual ASPs in the list, as well as configuration
 changes and possible failover mechanisms.
 Normally, one or more ASPs are active (i.e., currently processing
 traffic) in the AS but in certain failure and transition cases it is
 possible that there may be no active ASP available.  Broadcast,
 loadsharing and backup scenarios are supported.
 When there is no matching Routing Key entry for an incoming SS7
 message, a default treatment MAY be specified.  Possible solutions
 are to provide a default Application Server at the SGP that directs
 all unallocated traffic to a (set of) default ASP(s), or to drop the
 message and provide a notification to layer management.  The
 treatment of unallocated traffic is implementation dependent.

Sidebottom, et. al. Standards Track [Page 13] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002

1.4.2.5 Message Distribution at the ASP 

 The ASP must choose an SGP to direct a message to the SS7 network.
 This is accomplished by observing the Destination Point Code (and
 possibly other elements of the outgoing message such as the SLS
 value). The ASP must also take into account whether the related
 Routing Context is active or not (See Section 4.3.4.3).
 Implementation Note: Where more than one route (or SGP) is possible
 for routing to the SS7 network, the ASP could, for example, maintain
 a dynamic table of available SGP routes for the SS7 destinations,
 taking into account the SS7 destination
 availability/restricted/congestion status received from the SGP(s),
 the availability status of the individual SGPs and configuration
 changes and failover mechanisms. There is, however, no M3UA messaging
 to manage the status of an SGP (e.g., SGP-Up/Down/Active/Inactive
 messaging).
 Whenever an SCTP association to an SGP exists, the SGP is assumed to
 be ready for the purposes of responding to M3UA ASPSM messages (Refer
 to Section 3).

1.4.3 SS7 and M3UA Interworking 

 In the case of SS7 and M3UA interworking, the M3UA adaptation layer
 is designed to provide an extension of the MTP3 defined user
 primitives.

1.4.3.1 Signalling Gateway SS7 Layers 

 The SG is responsible for terminating MTP Level 3 of the SS7
 protocol, and offering an IP-based extension to its users.
 From an SS7 perspective, it is expected that the Signalling Gateway
 transmits and receives SS7 Message Signalling Units (MSUs) to and
 from the PSTN over a standard SS7 network interface, using the SS7
 Message Transfer Part (MTP) [7,8,9] to provide reliable transport of
 the messages.
 As a standard SS7 network interface, the use of MTP Level 2
 signalling links is not the only possibility.  ATM-based High Speed
 Links can also be used with the services of the Signalling ATM
 Adaptation Layer (SAAL) [18,19].
 Note: It is also possible for IP-based interfaces to be present,
 using the services of the MTP2-User Adaptation Layer (M2UA) [27] or
 M2PA [28].

Sidebottom, et. al. Standards Track [Page 14] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 

 These could be terminated at a Signalling Transfer Point (STP) or
 Signalling End Point (SEP).  Using the services of MTP3, the SG could
 be capable of communicating with remote SS7 SEPs in a quasi-
 associated fashion, where STPs may be present in the SS7 path between
 the SEP and the SG.

1.4.3.2 SS7 and M3UA Interworking at the SG 

 The SGP provides a functional interworking of transport functions
 between the SS7 network and the IP network by also supporting the
 M3UA adaptation layer.  It allows the transfer of MTP3-User
 signalling messages to and from an IP-based Application Server
 Process where the peer MTP3-User protocol layer exists.
 For SS7 user part management, it is required that the MTP3-User
 protocols at ASPs receive indications of SS7 signalling point
 availability, SS7 network congestion, and remote User Part
 unavailability as would be expected in an SS7 SEP node.  To
 accomplish this, the MTP-PAUSE, MTP-RESUME and MTP-STATUS indication
 primitives received at the MTP3 upper layer interface at the SG need
 to be propagated to the remote MTP3-User lower layer interface at the
 ASP.
 MTP3 management messages (such as TFPs or TFAs received from the SS7
 network) MUST NOT be encapsulated as Data message Payload Data and
 sent either from SG to ASP or from ASP to SG.  The SG MUST terminate
 these messages and generate M3UA messages as appropriate.

1.4.3.3 Application Server 

 A cluster of application servers is responsible for providing the
 overall support for one or more SS7 upper layers.  From an SS7
 standpoint, a Signalling Point Management Cluster (SPMC) provides
 complete support for the upper layer service for a given point code.
 As an example, an SPMC providing MGC capabilities could provide
 complete support for ISUP (and any other MTP3 user located at the
 point code of the SPMC) for a given point code.
 In the case where an ASP is connected to more than one SGP, the M3UA
 layer must maintain the status of configured SS7 destinations and
 route messages according to availability/congestion/restricted status
 of the routes to these SS7 destinations.

1.4.3.4 IPSP Considerations 

 Since IPSPs use M3UA in a point-to-point fashion, there is no concept
 of routing of messages beyond the remote end.  Therefore, SS7 and
 M3UA interworking is not necessary for this model.

Sidebottom, et. al. Standards Track [Page 15] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002

1.4.4 Redundancy Models

1.4.4.1 Application Server Redundancy 

 All MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned
 Routing Key at an SGP are mapped to an Application Server.
 The Application Server is the set of all ASPs associated with a
 specific Routing Key. Each ASP in this set may be active, inactive or
 unavailable.  Active ASPs handle traffic; inactive ASPs might be used
 when active ASPs become unavailable.
 The failover model supports an "n+k" redundancy model, where "n" ASPs
 is the minimum number of redundant ASPs required to handle traffic
 and "k" ASPs are available to take over for a failed or unavailable
 ASP.  A "1+1" active/backup redundancy is a subset of this model. A
 simplex "1+0" model is also supported as a subset, with no ASP
 redundancy.

1.4.5 Flow Control 

 Local Management at an ASP may wish to stop traffic across an SCTP
 association to temporarily remove the association from service or to
 perform testing and maintenance activity.  The function could
 optionally be used to control the start of traffic on to a newly
 available SCTP association.

1.4.6 Congestion Management 

 The M3UA layer is informed of local and IP network congestion by
 means of an implementation-dependent function (e.g., an
 implementation dependent indication from the SCTP of IP network
 congestion).
 At an ASP or IPSP, the M3UA layer indicates congestion to local
 MTP3-Users by means of an MTP-STATUS primitive, as per current MTP3
 procedures, to invoke appropriate upper layer responses.
 When an SG determines that the transport of SS7 messages to a
 Signalling Point Management Cluster (SPMC) is encountering
 congestion, the SG MAY trigger SS7 MTP3 Transfer Controlled
 management messages to originating SS7 nodes, per the congestion
 procedures of the relevant MTP3 standard. The triggering of SS7 MTP3
 Management messages from an SG is an implementation-dependent
 function.

Sidebottom, et. al. Standards Track [Page 16] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 

 The M3UA layer at an ASP or IPSP MAY indicate local congestion to an
 M3UA peer with an SCON message.  When an SG receives a congestion
 message (SCON) from an ASP, and the SG determines that an SPMC is now
 encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled
 management messages to concerned SS7 destinations according to
 congestion procedures of the relevant MTP3 standard.

1.4.7 SCTP Stream Mapping. 

 The M3UA layer at both the SGP and ASP also supports the assignment
 of signalling traffic into streams within an SCTP association.
 Traffic that requires sequencing SHOULD be assigned to the same
 stream.  To accomplish this, MTP3-User traffic may be assigned to
 individual streams based on, for example, the SLS value in the MTP3
 Routing Label or the ISUP CIC assignment, subject of course to the
 maximum number of streams supported by the underlying SCTP
 association.

1.4.8 Client/Server Model 

 It is recommended that the SGP and ASP be able to support both client
 and server operation. The peer endpoints using M3UA SHOULD be
 configured so that one always takes on the role of client and the
 other the role of server for initiating SCTP associations.  The
 default orientation would be for the SGP to take on the role of
 server while the ASP is the client. In this case, ASPs SHOULD
 initiate the SCTP association to the SGP.
 In the case of IPSP to IPSP communication, the peer endpoints using
 M3UA SHOULD be configured so that one always takes on the role of
 client and the other the role of server for initiating SCTP
 associations.
 The SCTP and TCP Registered User Port Number Assignment for M3UA is
 2905.

Sidebottom, et. al. Standards Track [Page 17] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002

1.5 Sample Configuration

1.5.1 Example 1: ISUP Message Transport 

 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.

Sidebottom, et. al. Standards Track [Page 115] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 

 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.

Sidebottom, et. al. Standards Track [Page 116] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002

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

Sidebottom, et. al. Standards Track [Page 117] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 

 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.

Sidebottom, et. al. Standards Track [Page 118] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002

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

Sidebottom, et. al. Standards Track [Page 119] RFC 3332 SS7 MTP3-User Adaptation Layer September 2002

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.

Sidebottom, et. al. Standards Track [Page 120]