Network Working Group               G. Sidebottom, L. Ong, Guy Mousseau
INTERNET-DRAFT                                          Nortel Networks
                                                             Ian Rytina
                                                               Ericsson
                                             Hanns-Juergen Schwarzbauer
                                                                Siemens
                                                          Ken Morneault
                                                                  Cisco
                                                          Mallesh Kalla
                                                              Telcordia

Expires in six months                                    8 October 1999                                  15 February 2000

                SS7 MTP3-User Adaptation Layer (M3UA)
                  <draft-ietf-sigtran-m3ua-00.txt>
                  <draft-ietf-sigtran-m3ua-01.txt>

Status of This Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as 'work in progress.'

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

This Internet Draft defines a protocol for the transport of any SS7
MTP3-User signaling (e.g., ISUP and SCCP messages) over IP using the
Simple Control Transport Protocol.  Also, provision is made for
protocol elements that enable a seamless, or as seamless as possible, operation of the MTP3-User
peers in the SS7 and IP domains. This protocol would be used between a
Signaling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident database but could also be used between two SGs
if desired. IP-
resident Database.  It is assumed that the SG receives SS7 signaling
over a standard SS7 interface using the SS7 Message Transfer Part (MTP)
to provide transport.

NOTE: THIS DRAFT REPLACES <draft-ietf-sigtran-itun-00.txt>

                                                                     1

                        TABLE OF CONTENTS

1.  Introduction..............................................3
2.  Protocol Elements........................................11
3.  Procedures...............................................21
4.  Examples.................................................26
5.  Security.................................................27
6.  Acknowledgements.........................................27
7.  References...............................................27
8.  Author's Addresses.......................................28

                                                                     2

1.  Introduction

1.1 Scope

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

*  Support for transfer of all SS7 MTP3-User Part messages (e.g., ISUP,
   SCCP, TUP, 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 an one or more MGCs or IP-resident Databases
*  Support for MGC or IP Database) IP-resident Database failover and loadsharing
*  Support for the asynchronous reporting of status changes to
   management

In other words, simplistic terms, the SG will terminate SS7 MTP2 and MTP3 protocols
and deliver ISUP, SCCP and/or any other MTP3-User protocols to IP-resident
Application Server Processes protocol messages
over an SCTP transport association associations to MTP3-User peers in MGCs or IP-
resident Databases.

1.2 Terminology

Application Node (AN) - A physical node in an IP network (i.e., an MGCU
or Database node), with one or more unique IP network addresses.  An AN
supports one or more SCTP end-points and one or more Application Server
Processes.

Application Server (AS) - A logical entity serving a specific
application instance. An example of an Application Server is a virtual
switch element handling all call processing for a particular unique range of PSTN
trunks, identified by an SS7
OPC/DPC/CIC_range. DPC/OPC/CIC_range.  Practically speaking,
an AS is modeled at the SG as an ordered list of one or more related unique
Application Server Processes
(e.g., primary, secondary, tertiary, ...). Processes, of which one or more is normally actively
processing traffic.

Application Server Process (ASP) - A process instance of an Application
Server. Examples of Application Server Processes are primary or backup
MGC instances.

Application Server Process Path (ASP Path or just Path) - A Path to a
remote An Application Server Process instance.  A Path maps 1:1 to serves as an SCTP
association

Application Server Cluster (ASC) - A group of one active or more Application
Servers represented to the SS7 network by the same SS7 Point Code. An
SG cannot send MTP Level 3 management messages relating to the
availability/congestion status standby
process of an SS7 destination in the IP domain
unless the status is true across all members of the Application Server
Cluster. (e.g., part of a distributed virtual
switch or database element).

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

Fail-over - The capability to re-route signaling traffic as required to
a next-preferred
an alternate Application Server Process Process, or group of ASPs, within an

Application Server in the event of failure or unavailability of the a
currently used

                                                                     3 Application Server Process (e.g., from primary MGC to back-up MGC).
Fail-over Process.  Fail-back may also apply upon
the return to service of a previously unavailable Application Server
Process.

MTP3-User

IP Database - Any protocol normally using the services The IP-resident analogue of the SS7 a PSTN Service Control Point
(SCP) or wireless Home Location Register (HLR).

MTP3
(e.g., ISUP, SCCP, TUP, etc.). Management Cluster (MMC) - A group of one or more Application
Servers represented to the SS7 network under the same SS7 Destination
Point Code.  MMCs are used to sum the availability/congestion status of
an SS7 destination that is distributed in the IP domain, for the
purpose of supporting MTP Level 3 management procedures.

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

Network Appearance - The Network Appearance identifies the SS7 network
context for the purposes of logically separating the signaling traffic
between the SG and the Application Server Processes over common SCTP
Associations.  An example is where an SG is logically partitioned to
appear as an element in four separate SS7 national networks.  A Network
Appearance uniquely defines the SS7 Destination Point Code, Network
Indicator and MTP3 protocol type/variant/version used within each
network.  An SS7 route-set or link-set at an SG can appear in only one
network appearance.

Network Byte Order: Most significant byte first, a.k.a Big Endian.

Routing Context - An Application Server Process may be configured to
process traffic within more than one Application Server.  From the
perspective of an ASP, a Routing Context defines a range of signaling
traffic that the ASP is currently configured to receive from the SG.
For example, an ASP could be configured to support call processing for
multiple ranges of PSTN trunks and therefore receive related signaling
traffic, identified by separate SS7 DPC/OPC/CIC_ranges.

Stream - A stream refers to an SCTP stream.

1.3 Signaling Transport Architecture

1.3.1 Protocol Architecture.

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

In reference to

Within the SIGTRAN framework architecture [xx], This architecture, this document defines an MTP3-User

adaptation module that is suitable for the transport of SS7 ISDN User
Part (ISUP) [2,3,4] and Signalling Connection Control Part (SCCP)
[5,6,7] messages but could be used equally used to transport other SS7 MTP3-User MTP3-
User Part messages such as, for example, TUP.  Note:
SCCP-Users (e.g., INAP/TC the Telephone User Part (TUP)
[8].  TCAP [9,10,11] or ISUP) RANAP [12] messages are supported implicitly transported
transparently by the M3UA as SCCP
payload. payload, as they are SCCP-User
protocols.  The M3UA uses the services of the Simple Common Transport
protocol [13] as the underlying reliable signaling common transport
protocol.

In a Signaling Gateway, it is expected that the SS7 ISUP/SCCP signaling
is transmitted and received from the PSTN over a standard SS7 network
interface, using the SS7 Message Transfer Part (MTP) [14,15,16] to
provide reliable transport of the ISUP/SCCP signaling messages to and
from an SS7 Signaling End Point (SEP) or Signaling Transfer Point
(STP).  The SG then provides
interworking a functional inter-working of transport
functions with the IP Signaling Transport, transport, in order to transfer the ISUP/SCCP
signaling messages to and from the ASP an Application Server Process where the
peer ISUP/SCCP protocol layer exists.  Three general cases
are shown below to cover the routing options in the event of ISUP or
SCCP transport across the SG as shown below:

1.3.1  Case 1: ISUP transport

  ******    SS7    ******     IP    ******
  *SEP *-----------* SG *-----------*ASP *
  ******           ******           ******

  +----+                            +----+
  |ISUP|                            |ISUP|
  +----+         +---------+        +----+
  |MTP |         |MTP |M3UA|        |M3UA|
  |L3  |         |L3  +----+        +----+
  |L2  |         |L2  |SCTP|        |SCTP|
  |L1  |         |L1  +----+        +----+
  |    |         |    |UDP |        |UDP |
  +----+         +---------+        +----+

SEP - SS7 Signaling End Point
SCTP - Simple Control Transport Protocol [5]

                                                                     4

Note:

The use of standard MTP Level 2 signaling links in the SS7 network
interface is
shown as an example. not the only possibility.  ATM-based High Speed Links
could also be used, using MTP3/SSCF/SSCOP [3,4]. the services of the Signaling ATM Adaptation
Layer (SAAL) [17,18].  For that matter, it is possible that IP-
based IP-based
links could be present, using MTP3/M2UA/SCTP.  Also, the services of the MTP2-User Adaptation
Layer (M2UA) [19].  Also note that STPs may be present in the SS7 path
between the SS7 SEP and the SG.

To enable a seamless, or as seamless as possible, operation of the
MTP3-User peers

Where ATM-base High Speed Links are used in the SS7 and IP domains, network, it is
possible for the SG implements to use the services of the MTP-3b [20] for
modeling purposes a nodal interworking function. reliable
transport to and from an SS7 SEP or STP. The interworking
function purpose maximum Service Data Unit
(SDU) supported by the MTP-3b is 4096 octets compared to deliver the 272 octet
maximum of the MTP.  However, for MTP3-Users to take advantage of the
larger SDU between MTP3-User peers, network architects should ensure
that MTP3-b is used end-to-end between the SG and the SS7-resident
peer.

Three example cases are shown below:

1.3.1.1 Example 1: ISUP transport
  ********   SS7   *****************   IP   ********
  * SEP  *---------*      SG       *--------* ASP  *
  ********         *****************        ********

  +------+                                  +------+
  | ISUP |                                  | ISUP |
  +------+         +------+-+------+        +------+
  | MTP3 |         | MTP3 | | M3UA |        | M3UA |
  +------|         +------+ +------+        +------+
  | MTP2 |         | MTP2 | | SCTP |        | SCTP |
  +------+         +------+ +------+        +------+
  |  L1  |         |  L1  | | UDP  |        | UDP  |
  +------+         +------+ +------+        +------+
      |_______________|         |______________|

    SEP - SS7 Signaling End Point
    SCTP - Simple Control Transport Protocol

Within the SG, MTP-TRANSFER indication primitives received from the MTP
Level 3 upper layer interface are sent to an the local M3UA-resident
network address translation and mapping function for ongoing routing to
the final IP destination.  This internal SG function also delivers MTP-
TRANSFER request  MTP-TRANSFER primitives to the MTP Level 3 upper layer interface
from received from the
local M3UA network address translation and mapping function are sent to
the MTP Level 3 upper layer interface as MTP-TRANSFER request
primitives for
ongoing on-going MTP Level 3 routing to the an SS7 node.  This SEP.

For internal SG modelling purposes, this may be accomplished with the
use of an implementation-dependent nodal interworking inter-working function is described for modeling purposes only - it is within
the SG that serves as a local user of the MTP3 and M3UA.  This nodal
implementation-dependent
inter-working function that does not affect the has no visible peer protocol exchanges.

1.3.2  Case with either the ASP
or SEP.

1.3.1.2  Example 2: SCCP transport where an SCCP function at the SG is
invoked:

  ******

  ********   SS7    ******   *****************   IP     *******
  *SEP *-----------* SG *------------* ASP   ********
  * SEP  *---------*               *--------*      *
  *  or  *         *      SG       *        * ASP  *
  *
  *STP STP  *         *               *        *      *
  ******           ******            *******

  +----+         +---------+         +-----+
  |SCCP|
  ********         *****************        ********

  +------+         +---------------+        +------+
  | SCCP |         |     SCCP      |         |SCCP        |
  +----+         +---------+         +-----+
  |MTP SCCP |
  +------+         +------+-+------+        +------+
  | MTP3 |         | MTP3 | | M3UA |        | M3UA |
  +------|         +------+ +------+        +------+
  | MTP2 |         |MTP |M3UA|         |M3UA         |
  |L3 MTP2 | |         |L3  +----+         +-----+
  |L2 SCTP |         |L2  |SCTP|         |SCTP        |
  |L1 SCTP |         |L1  +----+         +-----+
  +------+         +------+ +------+        +------+
  |  L1  |         |    |UDP  L1  | | UDP  |
  +----+         +---------+         +-----+

Note: An SEP can be an SCP or SSP        | UDP  |
  +------+         +------+ +------+        +------+
      |_______________|         |______________|

    STP - SS7 Signaling Transfer Point

In this case, example, the SG contains an instance of the SS7 SCCP at protocol
layer that may, for example, perform the SG performs SCCP Global Title Translation
(GTT) function for messages in either direction that do not yet have logically addressed to the SG SCCP.  If the
result of a final GTT for an SCCP message yields an SS7
MTP Destination Point Code DPC or DPC/SSN
address (and possibly SCCP Subsystem).  Use result of the an SCCP at peer located in the SG will avoid a requirement for a GTT function
within IP domain, the M3UA protocol.  The SG nodal interworking function delivers
an resulting
MTP-TRANSFER indication request primitive incoming from the SS7 network is sent to

                                                                     5

an the local M3UA-resident
network address translation and mapping function for ongoing routing to
the final IP destination, but only after destination.

Similarly, the SCCP instance in an SG can perform the SCCP GTT has been performed and a new Destination Point Code (and possibly
Subsystem) have been determined.  The M3UA service
for messages logically addressed to it from SCCP peers in the IP
domain.  In this case, MTP-TRANSFER messages are sent from the local
M3UA-resident network address translation and mapping function then determines the final IP destination.  It is
possible that to the
SCCP GTT for GTT.  If the result could be a non-final of the GTT result and
M3UA would then actually be determining an IP destination that will
perform yields the next GTT.

Similarly messages from address of an SCCP
peer in the IP SS7 network can be addressed to then the SG for
SCCP GTT.  The SG nodal interworking function would deliver these MTP-
TRANSFER resulting MTP-TRANSFER request primitives is
given to the SCCP from M3UA. The SCCP GTT will
then  determine an SS7 Destination Point Code (and possibly Subsystem)
before MTP3 for delivery into the SS7 network. to an SS7-resident node.

It is possible that after the above SCCP GTT at the DPC (and possibly Subsystem) result SG could represent yield the
address of an IP-based
ASP SCCP peer in the IP domain and the resulting MTP-TRANSFER
primitive would be sent by the nodal interworking function back to the M3UA-
resident network address translation and mapping function M3UA for ongoing
routing delivery to an IP
destination.

1.3.3  Case 3: SCCP transport where

For internal SG modelling purposes, this may be accomplished with the
use of an SCCP implementation-dependent nodal inter-working function at within
the SG is that effectively sits below the SCCP and routes MTP-TRANSFER
messages to/from both the MTP3 and the M3UA, based on the SS7 DPC or
DPC/SSN address information.  This nodal inter-working function has no
visible peer protocol with either the ASP or SEP.

Note that the services and interface provided by M3UA are the same as
in Example 1 and the functions taking place in the SCCP entity are
transparent to M3UA.  The SCCP protocol functions are not
invoked:

  ****** reproduced in
the M3UA protocol.

1.3.1.3 Example 3 - Seamless Handling of MTP3 Management

  ********   SS7    ******   *****************   IP     *******
  *SEP *-----------* SG *------------* ASP   ********
  * SEP  *---------*               *--------*      *
  *  or  *         *      SG       *        * ASP  *
  *
  *STP STP  *         *               *        *      *
  ******           ******            *******

  +----+                             +-----+
  |SCCP|                             |SCCP
  ********         *****************        ********

  +------+         +------+-+------+        +------+
  | MTP3 |         | MTP3 | | M3UA |        | M3UA |
  +------|         +------+ +------+        +------+
  | MTP2 |
  +----+         +---------+         +-----+
  |MTP         |         |MTP |M3UA|         |M3UA MTP2 |
  |L3 |         |L3  +----+         +-----+
  |L2 SCTP |         |L2  |SCTP|         |SCTP        |
  |L1 SCTP |         |L1  +----+         +-----+
  +------+         +------+ +------+        +------+
  |  L1  |         |    |UDP  L1  | | UDP  |
  +----+         +---------+         +-----+

For this case, the SG nodal interworking function operates as in Case
1.

1.3.4        | UDP Port

A request will be made to IANA to assign a UDP port for M3UA.

1.4 Services Provided by the M3UA Layer

1.4.1 Support for  |
  +------+         +------+ +------+        +------+
      |_______________|         |______________|

In the transport case of MTP3-User/MTP boundary primitives

                                                                     6

The SS7 MTP Level 3 upper layer interface is retained at the ASP, so
the M3UA protocol layer MTP3 network management, it is required to provide that the equivalent set
MTP3-User protocols at ASPs receive indications of
services to its users SS7 signaling point
availability, SS7 network congestion and User Part availability as provided by
would be expected an SS7 SEP node.  To accomplish this, the MTP Level 3.

This includes MTP-PAUSE,
MTP-RESUME and MTP-STATUS indication primitives received at the following services:

M3UA provides MTP3
upper layer interface at the ability SG need to transfer MTP3-User messages (in this
Case, ISUP/SCCP PDUs) across SCTP associations.  Note that M3UA does
not itself impose a 256 octet user information block limit as specified
by the MTP Level 3.  Larger blocks can be accommodated directly by
M3UA/SCTP without made available to the need for an upper remote
MTP3-User lower layer segmentation/re-assembly
procedure interface at the AN.  Note: These indication
primitives are also made available to any existing local MTP3-Users at
the SG, such as in the ITU White Book SCCP [6] or ISUP segmentation
procedures. However, in the context of an previous example.

For internal SG the maximum 256 octet
block size must modelling purposes, this may be followed when interworking to an SS7 network that
does not support accomplished with the transfer
use of larger blocks to the final
destination.  This will avoid ISUP or SCCP fragmentation at an implementation-dependent nodal inter-working function within
the SG.
However,if SG that effectively sits above the SS7 network supports MTP3 and delivers MTP-PAUSE,
MTP-RESUME and MTP-STATUS indication primitives received from the Broadband MTP [7]
Level 3 upper layer interface to the
block size limit can be increased past 256 octets.  In the future,
M3UA/SCTP could be specified for use between two IP Nodes directly to
carry larger ISUP+ (BICC) [8] or MAP/TCAP [9] messages.

Provision is made for a seamless, or as seamless as possible, operation
of the MTP3-User peers in the SS7 and IP domains. local M3UA-resident management
function.  This includes:

   - Providing an indication to MTP3-Users at an ASP that a remote
MTP3-User nodal inter-working function has no visible peer in
protocol with either the SS7 network is not
reachable, as expected by all MTP3-User protocols.

  - Providing an indication to MTP-Users at an ASP that a remote MTP3-
User peer in the SS7 network or SEP.

It is now reachable, as expected by all MTP3-
User protocols.

  - Providing an indication important to MTP3-Users at an ASP clarify that MTP3 management messages to a
remote MTP3-
User peer in such as TFPs
or TFAs received from the SS7 network are experiencing SS7 congestion or the
remote MTP3-User peer is unavailable, as expected by all MTP3-User
protocols.

1.4.2 Support for communication between Layer Management Modules on the
SG not "encapsulated" and ASP

An M-ERROR primitive is used sent
blindly to indicate an error with a received M3UA
message (e.g., unknown parameter value).

*********
Ed Note:  This section is ffs
*********

1.4.3 Support for the ASPs.  Rather, the existing MTP3 management of SCTP associations and ASP Paths between procedures
are followed within the SG and ASP

The M3UA layer at MTP3 function of the SG keeps to re-calculate the state of all configured ASPs.  A
MTP3 route set

                                                                     7

of primitives between the Layer Management status and initiate any signaling-route-set-test
procedures into the M3UA layer SS7 network.  Only when a route set status changes
are
defined below for the layer Management MTP-PAUSE or MTP-RESUME primitives invoked.  These primitives can
also be invoked due to manage the ASP Paths and local SS7 link set conditions as per existing
MTP3 procedures.

1.3.2 Signaling Network Architecture

A Signaling Gateway is used to support the transport of ISUP/SCCP
signaling traffic between received from the SG SS7 network to multiple distributed
Application Nodes (e.g., MGCUs and IP Databases).  Clearly, an SG-ASP
protocol description cannot in itself meet any performance and
reliability requirements for such transport.  A physical network
architecture is required, with data on the availability and transfer
performance of the ASPs. physical nodes involved in any particular exchange
of information.  The M3UA layer can protocol used must simply be instructed by the Layer Management to establish
an SCTP association to flexible enough allow
its operation and management in a peer M3UA node.  This can be achieved using
the M-SCTP ESTABLISH primitive variety of physical configurations
that will enable Network Operators to request, indicate meet their performance and confirm
reliability requirements.

To meet the
establishment stringent SS7 signaling reliability and performance
requirements for carrier grade networks, these Network Operators should
ensure that there is no single point of failure provisioned in the end-
to-end network architecture between an SCTP association to a peer M3UA node.

The M3UA layer may also need to inform Layer Management SS7 SEP and an IP Application
Node.  Depending of course on the status reliability of the underlying SCTP associations using the M-SCTP STATUS request SG and
indication primitive. For example, AN
functional elements, this can typically be met by the M3UA may inform Layer Management use of redundant
SGs, the reason for the release provision of an redundant QOS-bounded IP network paths for SCTP association, determined either
locally
Associations between SCTP End Points, and redundant Application Nodes.
The distribution of ASPs within the M3UA layer or by available Application Nodes is also

important.  For a primitive from the SCTP.

Layer Management may inform particular Application Server, the M3UA layer of a change related ASPs
should be distributed over at least two physical Application Nodes.

An example physical network architecture relevant to carrier-grade
operation in the local
M3UA User status (e.g., failure, available).  Also the M3UA layer may
need to inform the Layer Management of the change IP network domain is shown in status Figure 1 below:

  ********                                          **************
  *      *__________________________________________*  ********  * AN1
  *      *                                          *  * ASP1 *  *
  *  SG1 *   SCTP Associations                      *  ********  *
  *      *_______________________                   *  ********  *
  *      *                       |                  *  * ASP2 *  *
  *      *                       |                  *  ********  *
  *      *                       |                  *  ********  *
  *      *                       |                  *  * ASP3 *  *
  ********                       |                  *  ********  *
                                 |                  *      .     *
  ********                       |                  *      .     *
  *      *------------------------------------------*            *
  *      *                       |                  *  ********  *
  *  SG2 *    SCTP Associations  |                  *  * ASPn *  *
  *      *____________           |                  *  ********  *
  *      *            |          |                  **************
  *      *            |          |                  **************
  *      *            |          |__________________*  ********  * AN2
  *      *            |                             *  * ASP1 *  *
  ********            |                             *  ********  *
                      |_____________________________*  ********  *
                                                    *  * ASP2 *  *
                                                    *  ********  *
                                                    *  ********  *
                                                    *  * ASP3 *  *
                                                    *  ********  *
                                                    *      .     *
                                                    *      .     *
                                                    *            *
                                                    *  ********  *
                                                    *  * ASPn *  *
                                                    *  ********  *
                                                    **************
                                                           .
                                                           .
                                                           .

                    Figure 1 - Physical Model

For carrier grade networks, Operators should ensure that under failure
or isolation of an ASP a particular AN, stable calls or ASP Path. transactions are not
lost.  This can be achieved using the M-ASP STATUS primitive implies that Application Nodes need, in some cases, to
change and indicate

share the status of an ASP.

*** Ed Note: This will call/transaction state or be moved able to a procedures section*****
The M3UA layer pass the
call/transaction state between each other.  Also, in the case of MGC
Application Nodes, coordination may be informed of a local M3UA-User failure by means of
an indication from local Layer Management.  In response, a peer
protocol is invoked required with the remote M3UA layer related Media
Gateway to stop traffic over the
SCTP association until recovery of transfer the local M3UA-Users.  When the
M3UA-User layer recovers, local Layer Management informs the M3UA layer
and MGC control for a message particular trunk termination.
However, this sharing or communication is sent to the remote M3UA layer indicating traffic can
be restarted over outside the SCTP association.  The M3UA layer maintains
status scope of this
document.

1.3.3 SS7 Point Code Representation

A Signaling Gateway is charged with representing the local M3UA-User availability.
***********************************************

1.5 Internal Functions Provided in IP network nodes
into the M3UA Layer

1.5.1 Address Translation and Mapping SS7 network for routing purposes.  The M3UA layer maps primitives received from the ASP-User lower layer
boundary, or SG nodal interworking function, to the SCTP reliable
transport upper layer boundary and maps signals received from the SCTP
to the ASP MTP3-User lower layer boundary, or SG nodal interworking
function.  For example, itself, as a
physical node in the MTP-TRANSFER request primitive received
from SS7 network, must be addressable with an MTP3-User is mapped SS7
Destination Point Code for MTP3 Management purposes.  This DPC will
also be used to address any local MTP3-Users such as an SCTP Send primitive and SG-resident
SCCP function.  An SG may also be addressable with multiple DPCs where
the SCTP
Receive primitive SG is mapped logically partitioned to operate in multiple SS7 network
appearances.  Alias DPCs may also be used within an MTP-TRANSFER indication primitive
to SG or an SG network
appearance, but SG MTP3 management messages to/from the MTP3-User.

To support this mapping, SS7 network
will not use the alias DPCs.

The M3UA layer at places no restrictions on the SG must additionally
maintain a network address translation table of incoming SS7
address/routing information keys to Application Servers.  The
Application Server represents an ordered list Destination Point Code (DPC)
representation of one or more possible
Application Server Processes.  Normally, one any of the ASPs.  ASPs in the ordered
list will can be represented under the active ASP
same DPC of the SG, their own individual Destination Point Codes (DPCs)
or grouped with other ASPs for a particular routing key entry.  Note
that in certain failure and transition cases it is possible that there Point Code preservation purposes.  A
single DPC may not be used for the SG and all the ASPs together, if
desired.  Note: there are potential SS7 traffic engineering
restrictions in some arrangements as there is a maximum number of SS7
links within a unique link-set to an active ASP.

                                                                     8

This table adjacent SS7 node.

If an ASP or group of ASPs is required in order available to route the SS7 ISUP/SCCP messages
incoming network via more
than one SG, it is recommended that the ASP(s) be represented by a
Destination Point Code that is separate from any SG DPC.  This allows
some SGs to be viewed from the SS7 network domain as "STPs", each having a
"route" to the appropriate same ASP.  Under failure conditions where an ASP in the IP
network domain.  This mapping is dynamic, taking into account the
availability status becomes
unavailable from one of the individual ASP Paths in SGs, this approach enables MTP3 route
management messaging between the list,
configuration changes, SG and possible fail-over mechanisms.

Possible SS7 address/routing information to be considered as a routing
key entry includes, for example, the OPC, DPC, SIO, ISUP CIC range or
SCCP Called Party Address. network, allowing simple
re-routing through an alternate SG.

1.3.4 ASP Fail-over Model and Terminology

The network address translation and mapping function in
effect defines the SS7 address representation of the Application
Servers within the IP domain.  As such, the implementation M3UA
supports ASP fail-over functions in order to support a high
availability of this
function must be flexible enough call and transaction processing capability.  All
ISUP/SCCP messages incoming to handle an SG from the SS7 address vision of
network operator(s).  For example, some network operators may choose are assigned
to
represent the SG and Application Servers with a single SS7 point code.
Other operators may choose to represent each SG and unique Application Server
with individual SS7 point codes, or may group logical groups Server, based on the information in the
message.  The information examined may be one or more of
Application Servers under the MTP DPC,
OPC, SLS, or any MTP3-User specific fields such as, for example, the
ISUP CIC, SCCP SSN, or TCAP TRID.  Some example possibilities are the
DPC alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the
DPC/SSN combination.  The information used to point codes.

From to an AS is not
limited by the perspective M3UA and none of the M3UA instance at an examples are mandated.

The Application Server
Process, it is possible that the ASP could route signaling messages
destined in practical terms an ordered list of all
ASPs configured/registered to the SS7 network through more than one SG.  A primary/back-
up case is possible where the unavailability process ISUP/SCCP messages within a
certain range of routing information, known as a Routing Key.  One or
more ASPs in the ASP Path to a
primary SG,or list are normally handling traffic while any others
are inactive but available in the event of failure or unavailability of
the SS7 destination node from active ASP(s).

The fail-over model supports an "n+k" redundancy model, where "n" ASPs
is the
primary SG, could be used minimum number of redundant ASPs required to reroute handle traffic and
"k" ASPs are available to take over for a next-preferred SG.  Also, failed or unavailable ASP.
Note that "1+1" active/standby redundancy is a
loadsharing case subset of this model. A
simplex "1+0" model is possible where the signaling messages are load-
shared across two (or more) SGs.

1.5.2 SCTP Stream Mapping.  M3UA also supports the assignment supported as a subset, with no ASP
redundancy.

To avoid a single point of
traffic into streams within an SCTP association.  Traffic failure, it is recommended that requires
sequencing should a minimum of
two ASPs be assigned to resident in the same stream. list, resident in separate physical
Application Nodes and therefore available over different SCTP
Associations.  For example, SS7
traffic may be assigned to individual streams based on in the SLS value network shown in
the MTP3 Routing Label Figure 1, all
messages to DPC x could be sent to ASP1 in AN1 or the ISUP CIC assignment, subject of course ASP1 in AN2.  The AS
ordered list at SG1 would look like this:

    Application Server 1 - Routing Key {DPC=x)
        ASP1/AN1 - Up, Active
        ASP1/AN2 - Up, Inactive

In this "1+1" redundancy case, ASP1 in AN1 would be sent any incoming
message with DPC=x.  ASP1 in AN2 could be brought to the maximum number active state
upon failure of, or loss of streams supported by connectivity to, ASP1/AN1. Both ASPs are
Up, meaning that the underlying related SCTP
association.  Traffic association and far-end M3UA peer is
ready.

In the process of fail-over or fail-back, it is recommended that does in the
case of MGCs, stable calls do not require sequencing can fail.  It is possible that calls in
"transition" may fail, although measures of communication between the
MGCs involved may mitigate this.  For example, the two MGCs may share
call state via shared memory, or may use an MGC-MGC protocol to pass
call state information.

1.3.5 UDP Port

A request will be assigned made to an unsequenced stream.

1.5.3 Congestion Control. IANA to assign a well-known UDP port for
M3UA.

1.4 Services Provided by the M3UA Layer

The M3UA Layer is informed at the ASP provides the equivalent set of local and IP network congestion primitives at
its upper layer to the MTP3-Users as provided by means
of an implementation-dependent function (e.g., an implementation-
dependent indication from the SCTP of IP network congestion). When MTP Level 3 to its
local users at an
SG determines that the transport of SS7 messages to SEP.  In this way, the ISUP and/or SCCP layer at
an Application
Server Cluster ASP is encountering congestion, unaware that the SG may optionally
trigger SS7 MTP3 Transfer Controlled management messages to originating
SS7 nodes. The triggering of SS7 expected MTP3 Management messages services are offered remotely
from an MTP3 Layer at an SG is
an implementation-dependent function.  At an ASP, congestion is
indicated to local MTP3-Users and not by means of an MTP-Status primitive
indicating congestion, a local MTP3 layer.  In effect,

the M3UA extends access to invoke appropriate upper the MTP3 layer responses, as
per current services to a remote ASP -
the M3UA does not itself provide the MTP3 services so does not
duplicate MTP3 procedures.  Congestion Control mechanisms are

1.4.1 Support for
further study.

                                                                     9

1.5.4 Seamless Network Management Interworking.

(Ed. Note: It is ffs if this function is modeled in the transport of MTP3-User Messages

The M3UA layer at
an SG or is part provides the transport of MTP-TRANSFER primitives across SCTP
associations between an independent relay function at the SG that is a
user of the M3UA layer and MTP-3 layer.) an ASP. The SG must maintain knowledge of SS7 node and Application Server
Cluster status in their respective domains in order to perform MTP-TRANSFER primitives are
encoded as
seamless ISUP/SCCP messages with attached MTP3 Routing Labels as possible interworking of
described in the two domains.  For example, SG
knowledge message format sections of the availability and/or congestion status of Application
Server Clusters SCCP and SS7 nodes must be maintained ISUP
recommendations.  In this way, the SCCP and disseminated in ISUP messages received from
the respective networks so that end-to-end operation is transparent to SS7 network are not re-encoded into a different format for
transport to/from the communicating SCN protocol peers ASP. As well, all the required MTP3 Routing Label
information (OPC, DPC, SIO) is available at the SS7 node and ASP.

When an SG determines that ASP as is expected by
the transport of SS7 ISUP/SCCP layer.  For ISUP messages to an
Application Server Cluster the CIC is encountering congestion, available, in its
native format.  The CIC together with the SG may
optionally issue OPC and DPC uniquely identify
all PSTN trunk circuits within a given MTP Transfer Controlled (TFC) messages to network instance.

Note that M3UA does not itself impose a 272-octet user information
block limit as specified by the SS7 SEPs
which are generating signalling traffic to MTP Level 3.  Larger information blocks
can be accommodated directly by M3UA/SCTP without the affected Application
Server Cluster, need for an upper
layer segmentation/re-assembly procedure such as per current MTP procedures [2].

When specified in recent
SCCP or ISUP versions. However, in the context of an SG determines SG, the maximum
272-octet block size must be followed when inter-working to a SS7
network that does not support the transport transfer of SS7 messages larger information blocks
to an
Application Server Cluster the final destination, as is interrupted, possible in the SG may optionally issue Broadband MTP Transfer Prohibited (TFP) messages to [20].
This will avoid ISUP or SCCP fragmentation requirements at the SG.
However, if the adjacent SS7 nodes which
are generating signalling traffic network is provisioned to support the affected Application Server
Clusters per current MTP procedures [2].

When an SG determines that Broadband
MTP, the transport of SS7 messages to an
Application Server Cluster can now information block size limit may be resumed, the SG increased past 272 octets.

1.4.2 Native Management Functions

The M3UA may optionally
issue MTP Transfer Allowed (TFA) messages to provide management of the adjacent SS7 nodes underlying SCTP transport
protocol to
resume signalling traffic ensure that SG-ASP transport is available to the affected Application Server Clusters
per current MTP procedures [2].

Triggering of degree
called for by the MTP-3 management messages is an implementation
dependent function.

1.5.5 Management Inhibit/Uninhibit

Local Management may wish MTP3-User signaling applications.

The M3UA provides the capability to stop traffic across an SCTP association in
order indicate errors associated with
received M3UA messages and to temporarily remove notify, as appropriate, local management
and/or the remote peer M3UA.

1.4.3 Inter-working with MTP3 Network Management Functions

At the SG, the M3UA must also provide inter-working with MTP3
management functions to support seamless operation of the user SCN
signaling applications in the SS7 and IP domains.  This includes:

  - Providing an indication to MTP3-Users at an ASP that a remote
destination in the SS7 network is not reachable.

  - Providing an indication to MTP3-Users at an ASP that a remote
destination in the SS7 network is now reachable.

  - Providing an indication to MTP3-Users at an ASP that messages to a
remote MTP3-User peer in the SS7 network are experiencing SS7
congestion

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

The M3UA layer at an ASP may initiate an audit of the availability of
remote SS7 destinations.  This information is requested from the M3UA
at the SG.

1.4.4 Support for the management of SCTP associations between the SG
and AN.

The M3UA layer at the SG maintains the availability state of all
configured remote ASPs, in order to manage the SCTP Associations and
the traffic between the SG and ASPs.  As well, the active/inactive
state of remote ASPs is also maintained - Active ASPs are those
currently receiving traffic from the SG.

The M3UA layer at either the SG or ASP can be instructed by local
management to establish an SCTP association to a peer M3UA node.  This
can be achieved using the M-SCTP ESTABLISH primitive to request,
indicate and confirm the establishment of an SCTP association with a
peer M3UA node.

The M3UA layer may also need to inform local management of the status
of the underlying SCTP associations using the M-SCTP STATUS request and
indication primitive. For example, the M3UA may 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 need to inform the local management of the
change in availability status of an ASP.  This can be achieved using
the M-ASP STATUS primitive to change and indicate the status of an ASP.

1.5 Internal Functions Provided in the M3UA Layer

1.5.1 Address Translation and Mapping at the SG M3UA

In order to direct messages received from the MTP3 network to the
desired IP destination, the SG M3UA must perform address translation
and mapping functions using information from the received ISUP/SCCP
message.

To support this mapping, the SG must maintain a network address
translation table, mapping incoming SS7 information to an ordered list
of an Application Server Processes.  Note that in certain failure and
transition cases it is possible that there may not be an active ASP
available.

This table is assumed to be dynamic, taking into account the
availability status of the individual ASPs in the list, configuration
changes, and possible fail-over mechanisms.  The M3UA protocol includes
messages to convey the availability status of the individual ASPs as
input to a fail-over mechanism.

Possible SS7 address/routing information that may comprise a routing
key entry includes, for example, the OPC, DPC, SIO, ISUP CIC range or
SCCP Called Party Address.  The particular information used in an SG
M3UA is implementation dependent.

1.5.2 SG Redundancy

It is possible that the ASP could route signaling messages destined to
the SS7 network through more than one SG.  A primary/back-up case is
possible where the unavailability of the ASP Path to a primary SG, or
the unavailability of the SS7 destination node from the primary SG,
could be used to reroute to a next-preferred SG.  Also, a load-sharing
case is possible where the signaling messages are load-shared across
two (or more) SGs.

1.5.3 SCTP Stream Mapping.  The M3UA at both the SG and ASP also
supports the assignment of signaling traffic into streams within an
SCTP association.  Traffic that requires sequencing must be assigned to
the same stream.  To accomplish this, ISUP/SCCP traffic may be assigned
to individual streams based on 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.5.4 Congestion Control.

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). When an
SG determines that the transport of SS7 messages to an MTP3 Management
Cluster is encountering congestion, the SG may optionally trigger SS7
MTP3 Transfer Controlled management messages to originating SS7 nodes.
The triggering of SS7 MTP3 Management messages from an SG is an
implementation-dependent function.  At an ASP, congestion is indicated
to local MTP3-Users by means of an MTP-Status primitive indicating
congestion, to invoke appropriate upper layer responses, as per current
MTP3 procedures.

1.5.5 Seamless Network Management Inter-working.

The M3UA at an SG must maintain knowledge of SS7 node and MTP3
Management Cluster status in their respective domains in order to
perform as seamless as possible inter-working of the two domains.  For
example, SG M3UA knowledge of the availability and/or congestion status
of MTP3 Management Cluster and SS7 nodes must be maintained and
disseminated in the respective networks so that end-to-end operation is

transparent to the communicating SCN protocol peers at the SS7 node and
ASP.

When an SG M3UA determines that the transport of SS7 messages to an
MTP3 Management Cluster is encountering congestion, the SG may
optionally inform the MTP3 route management function (by an
implementation-dependent mechanism).  This information is used by the
MTP3 to mark the route to the affected destination as congested and to
trigger MTP Transfer Controlled (TFC) messages to any SS7 SEPs
generating traffic to the congested DPC, as per current MTP3
procedures.

When an SG M3UA determines that the transport of SS7 messages to all
ASPs in a particular MTP3 Management Cluster is interrupted, the SG
M3UA may similarly optionally inform the MTP3 route management
function. This information is used by the MTP3 to mark the route to the
affected destination as unavailable and to trigger MTP Transfer
Prohibited (TFP) messages to the adjacent SS7 nodes which are
generating traffic to the unavailable DPC as per current MTP
procedures.

When an SG M3UA determines that the transport of SS7 messages to an ASP
in a particular MTP3 Management Cluster can be resumed, the SG M3UA may
similarly optionally inform the MTP3 route management function. This
information is used by the MTP3 to mark the route to the affected
destination as available and to trigger MTP Transfer Allowed (TFA)
messages to the adjacent SS7 nodes as per current MTP3 procedures.

Note: In some SS7 network architectures, the sending of TFP and TFA
messages from the SG into the SS7 network should be suppressed.  For
example, in the case where an SG seen by the adjacent SS7 node as an
SEP (i.e., in ANSI MTP terms they are connected via A-links or F-
links), TFP or TFA messages would not normally be expected by the
adjacent SS7 node.

1.5.6 Management Inhibit/Uninhibit

Local Management at an ASP or SG may wish to stop traffic across an
SCTP association in order 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.5.7 Active Association Control

At an SG, an Application Server list may contain active and inactive
ASPs to support ASP loads-haring and fail-over procedures. When, for
example, both a primary and a back-up ASP are available, M3UA peer
protocol is required to control which ASP is currently active.  The
ordered list of ASPs within a logical Application Server is kept
updated in the SG to reflect the active Application Server Process(es).

1.6 Definition of M3UA Boundaries

1.6.1 Definition of the boundary between M3UA and an MTP3-User.

>From ITU Q.701 [2]:

MTP-TRANSFER request
MTP-TRANSFER indication
MTP-PAUSE indication
MTP-RESUME indication
MTP-STATUS indication

1.6.2 Definition of the boundary between M3UA and SCTP

The upper layer primitives provided by the SCTP are provided in [13]

2.0 M3UA Protocol Elements

The general M3UA message format includes a Common Message Header
followed by zero or more parameters as defined by the Message Type.
For forward compatibility, all Message Types may have attached
parameters even if none are specified in this version.

2.1 Common Message Header

The protocol messages for MTP3-User Adaptation require a message
structure which contains a version, message type, message length, and
message contents.   This message header is common among all signaling
protocol adaptation layers:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |     Spare     |         Message Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Message Length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |

All fields in an M3UA message MUST be transmitted in the network byte order,
unless otherwise stated.

2.1.1 M3UA Protocol Version

The version field (Vers.) contains the version of the M3UA adaptation
layer.  The supported versions are:

      0000 0001   Release 1.0 protocol

2.1.2  Message Types

The following list contains the message types for the defined messages.

     Transfer Messages

        Data                                       0101

     SS7 Signaling Network Management (SSNM) Messages

        Destination Unavailable (DUNA)             0201
        Destination Available (DAVA)               0202
        Destination State Audit (DAUD)             0203
        SS7 Network Congestion State (SCON)        0204
        Destination User Part Unavailable (DUPU)   0205

     Application Server Process Maintenance (ASPM) messages

        ASP Up                                     0301
        ASP Down                                   0302
        ASP Active                                 0401
        ASP Inactive                               0402

     Management (MGMT) Messages

         Error                                     0000

2.1.3 Message Length

The Message Length defines the length of the message in octets, not
including the header.

2.2 ISUP/SCCP Transfer Messages

The following section describes the ISUP/SCCP Transfer messages and
parameter contents.  The general message format includes a Common
Message Header together with a list of zero or more parameters as
defined by the Message Type.  All Message Types can have attached
parameters.

2.2.1 Data Message

The Data message contains SS7 MTP3-User protocol data, which is an MTP-
TRANSFER primitive, including the complete MTP3 Routing Label. The Data
message contains the following parameters:

     PROTOCOL IDENTIFIER (Optional)
     NETWORK APPEARANCE (Optional)
     PROTOCOL DATA

The format for the Data Message parameters is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Tag (0xx)          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                       Protocol Identifier*                    |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Tag (0xx)          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                       Network Appearance*                     |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Tag (0xx)   |     Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                         Protocol Data                         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Protocol Identifier parameter identifies explicitly the MTP3-User
Part being transported, where the SCN protocol carried is
not known implicitly in the context of a particular SCTP
association/stream or Network Appearance/SIO.  The Protocol Id defines
the protocol type, variant, and version, and thereby specifies the
components and encoding of the Protocol Data parameter. Protocol Ids
will be maintained by IANA outside of this document and may be
registered on an "as needed" basis.  The Protocol Id is not required in
Data messages if the Protocol Id information is pre-configured or
identified at Association or Path establishment.

Ed Note: The Protocol Id format is an OID as defined in .....

The Network Appearance identifies the SS7 network context for the
message, for the purposes of logically separating the signaling traffic
between the SG and the Application Server Processes over common SCTP
Associations.  An example is where an SG is logically partitioned to
appear as an element in four different national networks.  A Network
Appearance implicitly defines the SS7 Destination Point Code, Network
Indicator and MTP3 protocol type/variant/version used within each
network.

The format is an ASCII string, the values of which are assigned

according to network operator policy. The Network Appearance string
should be padded to 32-bit boundaries.

The Protocol Data field contains the MTP3-User application message,
which is in effect an MTP-TRANSFER primitive.  As defined for a
specific value of the Protocol Identifier, this will include the MTP-
User Data and includes the MTP Routing Label (SS7 OPC, DPC, SLS), and
the SIO (Service Indicator, Network Indicator & optional Message
Priority codes). In the case of ISUP messages, the Circuit
Identification Code is also included.

2.3.2  SS7 Signaling Network Management (SSNM) Messages
2.3.2.1 Destination Unavailable (DUNA)

The DUNA message is sent from the SG to all concerned ASPs to indicate
that the SG has determined that an SS7 destination is unreachable.  The
MTP3-User at the ASP is expected to stop traffic to the affected
destination through the SG initiating the DUNA.

The DUNA message contains the following parameters:

     Protocol Identifier (Optional)
     Network Appearance (Optional)
     Affected Destination Point Code
     Info String (Optional)

The format for DUNA Message parameters is as follows:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xx)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                  (MTP) Protocol Identifier*                   |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xx)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                      Network Appearance*                      |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xx)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Spare      |                 Affected DPC                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xx)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                          INFO String*                         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Protocol Identifier parameter is defined similarly to Section 2.2.1
but in this case defines the MTP3 version/variant.  In this context it
defines the format of the Affected DPC parameter.  By identifying the
MTP variant and version, the point code length (e.g., 14-, 16-, or 24-
bit) and sub-field definitions (e.g., ANSI network/cluster/member, ITU-
international zone/region/signal_point, many national field variants,
...) can be determined.

The Network Appearance is defined as in Section 2.2.1

The INFO String parameter can carry any meaningful 8-BIT ASCII
character string along with the message.  Length of the INFO String
parameter is from 0 to 255 characters.  No procedures are presently
identified for its use but the INFO String may be used by Operators to
identify in text form the location reflected by the Affected DPC for
debugging purposes.

The Affected DPC is provisionally a three-octet parameter to allow 14-,
16- and 24-bit binary formatted SS7 Point Codes.

2.3.2.2 Destination Available (DAVA)

The DAVA message is sent from the SG to all concerned ASPs to indicate
that the SG has determined that an SS7 destination is now reachable.
The ASP MTP3-User protocol is expected to resume traffic to the
affected destination through the SG initiating the DUNA.

The DAVA message contains the following parameters:

     Protocol Identifier (Optional)
     Network Appearance (Optional)
     Affected Destination Point Code
     Info String (Optional)

The format and description of DAVA Message parameters is the same as
for the DUNA message (See Section 2.3.2.1.)

2.3.2.3 Destination State Audit (DAUD)

The DAUD message can be sent from the ASP to the SG to query the
availability state of the SS7 routes to an affected destination.  A
DAUD may be  sent periodically after the ASP has received a DUNA, until
a DAVA is received.   The DAUD can also be sent when an ASP recovers
from isolation from the SG.

The DAUD message contains the following parameters:

     Protocol Identifier (Optional)
     Network Appearance (Optional)
     Affected Destination Point Code
     Info String (Optional)

The format and description of DAUD Message parameters is the same as
for the DUNA message (See Section 2.3.2.1.)

2.3.2.4 SS7 Network Congestion (SCON)

The SCON message can be sent from the SG to all concerned ASPs to
indicate that the congestion level in the SS7 network to a specified
destination has changed.

The SCON message contains the following parameters:

     Protocol Identifier (Optional)
     Network Appearance (Optional)
     Affected Destination Point Code
     Info String (Optional)
     Congestion Level (Optional)

The format for SCON Message parameters is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xx)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                       Protocol Identifier*                    |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xx)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                        Network Appearance                     |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xx)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cong. Level   |                 Affected DPC                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xx)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                         INFO String*                          |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The format and description of the Protocol Identifier, Network
Appearance, Affected DPC and Info String parameters is the same as for
the DUNA message (See Section 2.3.2.1.)

The valid values for the optional Congestion Level parameter are shown
in the following table.

                Value       Description
                 00     No Congestion or Undefined
                 01     Congestion Level 1
                 02     Congestion Level 2
                 03     Congestion Level 3

The congestion levels are as defined in the national congestion method
in the ITU MTP recommendation [14] or in the ANSI MTP standard [15].
For MTP versions/variants without congestion levels, for example the
ITU international method, the parameter is always Undefined.

2.3.2.5 Destination User Part Unavailable (DUPU)

The DUPU message is used by a SG to inform an ASP that a remote peer
MTP3-User User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable.

The DUPU message contains the following parameters:

     Protocol Identifier (Optional)
     Network Appearance (Optional)
     Affected Destination Point Code
     Info String (Optional)
     Reason

The format for DUPU Message parameters is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xx)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                       Protocol Identifier*                    |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xx)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                      Network Appearance*                      |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xx)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Reason     |                 Affected DPC                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xx)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                          INFO String*                         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The format and description of the association from service or to perform
testing Protocol Identifier, Network
Appearance, Affected DPC and maintenance activity. Info String parameters is the same as for
the DUNA message (See Section 2.3.2.1.)

The function could optionally be
used to manage valid values for Reason are shown in the start of traffic on to a newly-available SCTP
association.

1.5.6 Active Association Control

An following table.

     Define           Value       Description
     UPU-Unknown        01   MTP User Part Unavailable, No Reason Given
     UPU-Unequipped     02   MTP User Part Unavailable, Unequipped
     UPU-Inaccessible   03   MTP User Part Unavailable, Inaccessible

2.3.3 Application Server Process can have associated back-up process.
When, for example, both a primary and a back-up Maintenance (ASPM) Messages

2.3.3.1 ASP are available, then
peer protocol is required to control which ASP,
and hence Up (ASPUP)

The ASP Path, UP (ASPUP) message is currently active.  The ordered list of ASPs
related used to an Application Server is kept updated indicate to reflect the active
Application Server Process instance.

                                                                    10

1.6 Definition of a remote M3UA Boundaries

1.6.1 Definition of peer
that the boundary between M3UA Adaptation layer is ready to receive traffic or maintenance
messages.

The ASPUP message contains the following parameters:

     Adaptation Layer Identifer (optional)
     Protocol Identifier (optional)
     INFO String (optional)

The format for ASPUP Message parameters is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x2)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                 Adaptation Layer Identifier*                  |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x3)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                      Protocol Identifier*                     |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x4)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                          INFO String*                         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The format and an MTP3-User.

From ITU Q.701 [2]:

MTP-TRANSFER request
MTP-TRANSFER indication
MTP-PAUSE indication
MTP-RESUME indication
MTP-STATUS indication

1.6.2 Definition description of the boundary between M3UA optional Protocol Identifier and SCTP Info
String parameters is the same as for the DUNA message (See Section
2.3.2.1.)

The upper layer primitives provided by optional Adaptation Layer Identifier (ALI) is a string that
identifies the SCTP are provided adaptation layer.  This string must be set to "M3UA"
which results in [5]

1.6.3 Definition a length of 4.  The ALI would normally only be used in
the Boundary between M3UA and initial ASP Up message across a new SCTP association to ensure both
peers are assuming the Layer Management

M-SCTP ESTABLISH
M-SCTP RELEASE
M-SCTP STATUS
M-ASP STATUS
M-ERROR

(Ed same adaptation layer protocol.

Note: more text Strings are padded to be added)

2.0 Protocol Elements 32-bit boundaries.  The general message format includes a Common Message Header together
with a list length field
indicates the end of zero or more parameters as defined by the Message Type.
For forward compatability, all Message Types may have attached
parameters even if none are specified in this version.

2.1 Common Message Header string.

2.3.3.2 ASP Down (ASPDN)

The protocol messages for MTP3-User Adaptation require a ASP Down (ASPDN) message
structure which contains is used to indicate to a version, message type, message length, and remote M3UA peer
that the adaptation layer is not ready to receive traffic or
maintenance messages.

The ASPDN message contents.   This contains the following parameters:

     Reason
     INFO String (Optional)

The format for the ASPDN message header parameters is common among all signaling
protocol adaptation layers: as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8    15 16           31
   +-------+-------+---------------+
   | Vers 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Spare                              Reason                           |   Msg Type
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
   +-------+-------+---------------+           Tag (0x4)           |        Message            Length             |
   +---------------+---------------+

2.1.1 M3UA Protocol Version
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                         INFO String*                          |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The version field (vers) contains the version format and description of the M3UA adaptation

                                                                    11

layer.  The supported versions are:

      01   Release 1.0 protocol

2.1.2  Message Types

The following list contains optional Info String parameter is the message types
same as for the defined messages.

     ISUP/SCCP Tunneling (ITUN) Messages

        Data Message                               0101

     SS7 Signalling Network Management (SSNM) Messages

        Destination Unavailable (DUNA)             0201
        Destination Available (DAVA)               0202
        Destination State Audit (DAUD)             0203
        SS7 Network Congestion State (SCON)        0204
        Destination User Part Unavailable (DUPU)   0205

     Application Server Process Maintenance (ASPM) messages

        ASP Up                                     0301
        ASP Down                                   0302
        ASP Active                                 0401
        ASP Inactive                               0402

     Management (MGMT) Messages

         Error                                     0000

2.1.3 Message Length DUNA message (See Section 2.3.2.1.)

The Message Length defines Reason parameter indicates the length of reason that the message remote M3UA
adaptation layer is unavailable.  The valid values for Reason are shown
in octets, not
including the header.

2.2 ITUN Messages

The following section describes the ITUN messages and parameter
contents.  The general ITUN message format includes a Common Message
Header together with a list of zero or more parameters as defined by
the Message Type.  All Message Types can have attached parameters.

2.2.1 Data Message table.

     Value         Description
     0x1        Processor Outage
     0x2        Management Inhibit

2.3.3.3 ASP Active (ASPAC)

The Data ASPAC message contains SS7 MTP3-User protocol data, which is sent by an MTP-
TRANSFER primitive, normally including the complete MTP3 Routing Label. ASP to indicate to an SG that it is
Active and ready to be used.

The Data ASPAC message contains the following parameters:

     SCN PROTOCOL IDENTIFIER

     Routing Context (Optional)
     INTERFACE IDENTIFIER
     INFO String (Optional)
     PROTOCOL DATA

                                                                     12

The format for the Data Message parameters ASPAC message is as follows:

    0            15 16           31
   +---------------+---------------+                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0xx)             |             Length            |
   +---------------+---------------+

   |   SCN Protocol Identifier*    |

   +---------------+---------------+
   |   Tag (0xx)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Length                             Type                              |
   +---------------+---------------+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |    Interface Identifier*                       Routing Context*                        |

   +-------------------------------+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag (0xx) (0x4)             |             Length            |
   +---------------+---------------+
                  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |        Protocol Data                          INFO String*                         |
                  ...
   +---------------+---------------+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The SCN Protocol Identifier Type parameter identifies explicitly the SCN
signaling protocol being transported, where the SCN protocol carried is
not known implicitly in the context of a particular association or
stream.  The SCN Protocol Id defines the protocol type, variant, and
version, and thereby specifies the components and encoding of the
Protocol Data parameter.  The SCN Protocol Id may also define what SCN
Protocol Data components are omitted in the Protocol Data (e.g.,
whether or not the Protocol Data contains an MTP routing label).  SCN
Protocol Ids will be maintained by IANA outside of this document and
may be registered on ASPAC as an "as needed" basis.  The SCN Protocol ID is not
required in Data messages if the Protocol Id information is pre-
configured or identified at Association Over-ride or Path establishment.

***********
ED Note: The SCN Protocol Identifier parameter format is for further
study. Load-share
Active message.  The protocol identifier values should be maintained outside of
this document by IANA to allow registration of valid values without re-
issuing the adaptation layer protocol document. We need decision on
encoding of mime-type value or fixed string/integer.  If mime-type need
to refer to "draft-ietf-sigtran-mime-isup.txt" for Type are shown in the following
table.

     Value         Description
     0x1            Over-ride
     0x2            Load-share

Within a particular Routing Context, only one Type can be used.  An SG
that receives an example of ASPAC with an
application/ISUP media incorrect type defined according to the rules defined in
RFC 2048.
************ for a particular Routing
Context will respond with an Error Message.

The Interface Identifier optionally identifies the physical interface,
or network, at optional Routing Context parameter contains (a list of) integers
indexing the SG for which Application Server traffic that the signaling messages are
sent/received.  The format sending ASP is
conigured to receive.  There is one-to-one relationship between an ASCII string,
index entry and an AS Name.  Because an AS can only appear in one
Network Appearance, the values of which are
assigned according to network operator policy. The interface Identifier
string should be padded to 32-bit boundaries.

                                                                     13

**************
Ed Note: The identification of Network Appearance parameter is not required in
the interface can ASPAC message

An Application Server Process may be very useful at MGCs
that are receiving signaling from multiple national networks and cannot
rely on the SS7 NI value configured to tell their signalling process traffic apart.
However, no procedures are specified.
**************

The Protocol Data field contains for
more than one logical Application Server.  From the MTP3-User application message,
which is perspective of an MTP-TRANSFER primitive.  As defined for
ASP, a specific value Routing Context defines a range of signaling traffic that the Protocol Identifier, this will include
ASP is currently configured to receive from the MTP-User Data SG.  For example, an
ASP could be configured to support call processing for multiple ranges
of PSTN trunks and
normally includes the MTP Routing Label (SS7 OPC, DPC, SLS), therefore receive related signaling traffic,
identified by separate SS7 DPC/OPC/CIC_ranges.

The format and description of the
SIO (Network Indicator & optional Message Priority codes).

2.3.2  SS7 Signaling Network Management (SSNM) Messages

2.3.2.1 Destination Unavailable (DUNA) Info String parameter is the
same as for the DUNA message (See Section 2.3.2.1.)

2.3.3.4  ASP Inactive (ASPIA)

The DUNA ASPIA message is sent from the SG to the by an ASP to indicate that
the to an SG has determined that an SS7 destination it is unreachable.  The MTP-
User at the no
longer an active ASP is expected to stop traffic to the affected destination
through the SG initiating the DUNA. be used from within a list of ASPs.  The DUNA SG
will respond with an ASPIA message and either discard incoming messages
or buffer for a timed period and then discard.

The contains the following parameters:

     Protocol Identifier

     Routing Context (Optional)
     Affected Destination Point Code
     Info
     INFO String (Optional)

The format for DUNA parameter the ASPIA message parameters is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8    15 16           31
   +---------------+---------------+
   |   Tag (0xx)   |     Length    |
   +---------------+---------------+

   |     Protocol Identifier*      |

   +---------------+---------------+ 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0xx)           |            Length             |
   +---------------+---------------+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |         Affected DPC                        Routing Context                        |
   +---------------+---------------+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Tag (0xx) (0x4)   |    Length     |
   +---------------+---------------+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                          INFO String*                         |

   +-------------------------------+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Protocol format and description of the optional Routing Context and Info
String parameters is the same as for the ASPAC message (See Section
2.3.3.3.)

2.3.4  Management Messages

2.3.4.1  Error (ERR)

The ERR message is sent when an invalid value is found in an incoming
message.

The ERR message contains the following parameters:

     Error Code

The format for the ERR message is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Error Code                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Error Code can be one of the following values:

     Invalid Version                        0x1
     Invalid Network Appearance             0x2
     Invalid SCN Version                    0x3
     Invalid Adaptation Layer Identifier parameter is defined similarly    0x4
     Invalid Stream Identifier              0x5
     Invalid Message Type                   0x6

3.0 Procedures

The M3UA layer needs to respond to various local primitives it receives
from other layers as well as the SCN

                                                                     14

Protocol Id but in this case defines the MTP3 version/variant.  In this
context messages that it defines receives from the format of
peer M3UA layers.  This section describes the Affected DPC parameter.  By
identifying M3UA procedures in
response to these events.

3.1 Procedures to support the MTP variant and version, services of the point code size (e.g., 14-
, 16-, or 24-bit) and sub-field definitions (e.g., ANSI
network/cluster/member, ITU-international zone/region/signal_point,
many national field variants, ...) can be determined. M3UA layer

The INFO String parameter can carry any meaningful 8-BIT ASCII
character string along with the message.  Length services of the INFO String
parameter is M3UA layer are described in Section 1.4.1.  These
procedures support the M3UA transport of MTP3-User/MTP3 boundary
primitives.

3.1.1 Receipt of Local primitives

On receiving an MTP-Transfer primitive from 0 an upper layer, or the
nodal inter-working function at an SG, the M3UA layer will send a
corresponding Data message (see Section 2) to 255 characters.  No procedures are presently
identified for its use but M3UA peer.  The M3UA
layer must fill in various fields of the INFO String can be used by Operators to
identify common and specific headers
correctly.

At an SG, the M3UA address translation and mapping function determines
the logical Application Server based on the information in text form the location reflected by incoming
message.  From an ordered list of ASPs within the Affected DPC for
debugging purposes.

The Affected DPC AS table, the Active
ASP is provisionally a three-octet parameter to allow 14-,
16- selected and 24-bit binary formatted SS7 Point Codes.

2.3.2.2 Destination Available (DAVA)

The DAVA the Data message is sent from the SG to constructed and issued on the
corresponding SCTP Association.  If more than one ASP is active (i.e.,
traffic is to indicate that be load-shared across all the SG
has determined that an SS7 destination active ASPs), one of the
active ASPs from the list is now reachable. selected.  The ASP MTP3-
User protocol selection algorithm is expected
implementation dependent but could be based on, for example, the SLS or
ISUP CIC.

In addition, the message needs to resume traffic be sent on the appropriate SCTP
stream, taking care to conserve the affected destination
through message sequencing needs of the SG initiating
signaling application.

Ed Note: Further description of stream assignment and/or examples are
required

3.2 Procedures to support the DUNA.

The DAVA message contains M3UA services in Section 1.4.2

3.2.1 Layer Management primitives procedures

On receiving these primitives from the following parameters:

     Protocol Identifier (Optional)
     Affected Destination Point Code
     Info String (Optional) local layer management, the M3UA
layer will send the corresponding management message (Error) to its
peer.  The parameter format M3UA layer must fill in the various fields of the common and definitions for
specific headers correctly.

3.2.2 Receipt of Peer Management messages

Upon receipt of Management messages, the DAVA message is M3UA layer must invoke the same
as for
corresponding Layer Management primitive indications (M-ERROR ind.) to

the DUNA message (See local layer management.

3.3 Procedures to support the M3UA services in Section 2.3.2.2).

2.3.2.3 Destination State Audit (DAUD)

The DAUD message can be sent from 1.4.4

These procedures support the M3UA management of SCTP Associations and
ASP to Paths between SGs and ASPs

3.3.1 State Maintenance

The M3UA layer on the SG needs to query maintain the
availability state of the SS7 routes each ASP as
input to an affected destination.  A
DAUD is sent periodically after the SGs address translation and mapping function.

3.3.1.1  ASP has received a DUNA, until a
DAVA is received. States

The DAUD can also be sent when an ASP recovers from
interruption state of each ASP is maintained in the transport path to M3UA layer in the SG.

     Protocol Identifier (Optional)
     Affected Destination Point Code
     Info String (Optional) The format and description
state of DAUD parameters is the same as for an ASP changes due to events. The events include:

   * Reception of messages from peer M3UA layer
   * Reception of indications from the
DUVA message (See Section 2.3.2.1.)

***********
Ed Note: It SCTP layer

The ASP state transition diagram is for further study whether multiple Affected
Destination Point Codes can be included as a list in one DAUD message
and shown in responding DUVA messages.
***********

                                                                     15 Figure 4.  The SG receiving the DAUD should reply with the availability state possible
states of
the queried destination in a DUNA or DAVA message.

2.3.2.4 SS7 Network Congestion (SCON) an ASP are:

ASP-DOWN: The SCON message can Application Server Process is unavailable.  Initially all
ASPs will be sent from the SG to the ASP to indicate that
the congestion level in the SS7 network to a specified destination has
changed. this state.

ASP-UP: The SCON message contains the following parameters:

     Protocol Identifier (Optional)
     Affected Destination Point Code
     Info String (Optional)
     Congestion Level (Optional)

    0     7 8    15 16           31
   +---------------+---------------+ Application Server Process is available but application
traffic is stopped.

ASP-ACTIVE: The Application Server Process is available and application
traffic is active (for a particular Routing Context or set of Routing
Contexts).

                 Figure 4: ASP State Transition Diagram

                               +-------------+
                     |-------->|             |   Tag (0xx)
                     |     Length         |
   +---------------+---------------+  ASP-ACTIVE |
                     |     Protocol Identifier*         +-------------+
                     |

   +---------------+---------------+             ^     |   Tag (0xx)
                     |     Length      ASP    |
   +---------------+---------------+     |         Affected DPC ASP
                     |
   +---------------+---------------+      Active |   Tag (0xx)     |     Length Inactive
                     |
   +---------------+---------------+             |         INFO String*     v
                     |         +-------------+
         ASP Down /  |

   +-------------------------------+         |   Tag (0xx)             |     Length
          SCTP CDI   |
   +---------------+---------------+         |       Congestion Level*  ASP-UP     |
                     |         +-------------+
                     |             ^    |
                     |        ASP  |    | ASP Down /
                     |        Up   |    |
   +-------------------------------+ SCTP CDI
                     |             |    v
                     |         +-------------+
                     |         |             |
                     |-------->|             |
                               |  ASP-DOWN   |
                               +-------------+

SCTP CDI: The format and description of local SCTP layer's Communication Down Indication to the
Upper Layer Protocol Identifier, Affected DPC and
Info String parameters is (M3UA) on an SG. The local SCTP will send this
indication when it detects the same as for loss of connectivity to the DUVA message (See Section
2.3.2.1.) ASP's SCTP
layer.

3.3.1.2  AS States

The valid values for state of the optional Congestion Level are shown AS is maintained in the
following table.

                                                                     16
     Define           Value       Description
     Level 0          0000     No Congestion or Undefined
     Level 1          0001     Congestion Level 1
     Level 2          0002     Congestion Level 2
     Level 3          0003     Congestion Level 3 M3UA layer on the SG.

The congestion levels state of an AS changes due to events. These events include:

   * ASP state transitions
   * Recovery timer triggers

The possible states of an AS are:

AS-DOWN: The Application Server is unavailable.  This state implies
that all related ASPs are in the ASP-DOWN state for this AS. Initially
the AS will be in this state.

AS-UP: The Application Server is available but no application traffic
is active (i.e., one or more related ASPs are as defined in the national congestion method ASP-UP state, but
none in the ITU MTP recommendation [2] or ASP-Active state).

AS-ACTIVE: The Application Server is available and application traffic
is active.  This state implies that one ASP is in the ANSI MTP standard [10].
For MTPs without congestion levels, for example ASP-ACTIVE state.

AS-PENDING: An active ASP has transitioned from active to inactive or
down and it was the ITU international
method, last remaining active ASP in the parameter is omitted.

The AS. A recovery
timer T(r) will be started and all incoming SCN messages will be queued
by the SG. If an ASP receiving becomes active before T(r) expires, the SCON message is expected AS will
move to follow AS-ACTIVE state and all the currently
defined MTP3-User protocol reaction to an indication of SS7 network
congestion.

2.3.2.5 Destination User Part Unavailable (DUPU)

The DUPU message is used by a SG queued messages will be sent to inform the
active ASP.

If T(r) expires before an ASP that a remote peer
MTP3-User User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable.

The DUPU message contains becomes active, the following parameters:

     Protocol Identifier (Optional)
     Affected Destination Point Code
     Info String (Optional)
     Reason SG stops queuing
messages and  discards all previously queued messages. The format for optional DUPU message AS will move
to AS-UP if at least one ASP is as follows:

0     7 8    15 16           31
   +---------------+---------------+ in ASP-UP state, otherwise it will move
to AS-DOWN state.

                 Figure 5: AS State Transition Diagram

      +----------+  one ASP trans ACTIVE   +-------------+
      |          |------------------------>|             |
      |  AS-UP   |                         |  AS-ACTIVE  |
      |          |                         |             |
      |          |<                       -|             |
      +----------+ \                     / +-------------+
         ^   |      \ Tr Trigger        /       ^    |   Tag (0xx)
         |     Length   |
   +---------------+---------------+       \ at least one    /        |     Protocol Identifier*    |

   +---------------+---------------+
         |   Tag (0xx)   |     Length        \ ASP in UP     /         |
   +---------------+---------------+    |         Affected DPC
         |
   +---------------+---------------+   |   Tag (0xx)         \             /          |     Length    |
   +---------------+---------------+
         |         INFO String*   |

   +-------------------------------+          \           /           |   Tag (0xx)    |     Length
         |
   +---------------+---------------+   |            Reason           \     /---/            |
   +-------------------------------+

                                                                     17

The format and description of the Protocol Identifier, Affected DPC and
Info String parameters is the same as for the DUVA message (See Section
2.3.2.1.)

The valid values for Reason are shown in the following table.

     Define           Value       Description
     UPU-Unknown      0x4    MTP User Part Unavailable, No Reason Given
     UPU-Unequipped   0x5    MTP User Part Unavailable, Unequipped
     UPU-Inaccessible 0x6    MTP User Part Unavailable, Inaccessible

The    |
 one ASP receiving the DUPU message is expected to follow the currently
defined MTP3-User protocol reaction to an indication of remote user
part unavailabilty.

2.3.3 Application Server Process Maintenance (ASPM) Messages

2.3.3.1 |   |            \   /        one ASP Up (ASPUP)

The ASP-UP message is used to indicate  |    | ACTIVE ASP
 trans   |   | all ASP     \-/----\    trans to a remote M3UA peer that the
Adaptation layer is ready |    | trans to receive traffic UP or maintenance messages.

The ASPUP message contains the following parameters:

     Adaptation Layer Identifer (optional)
     SCN Protocol Identifier (optional)
     INFO String (optional)

The format for the ASPUP message is as follows:

    0            15 16           31
   +---------------+---------------+
 to UP   |   Tag (0x2)   |    Length trans to     /      \   ACTIVE   |
   +---------------+---------------+    | Adaptation Layer Identifier* DOWN
         |   | DOWN        /        \           |    |
         |   |            /          \          |    |
         |   |           /            \         |    |
         |   |          /all ASP       \        |    |
         |   v         / trans to       \       |    v
      +----------+    /  DOWN            \ +-------------+
      |          |<--/                    -|             |

   +---------------+---------------+
      |   Tag (0x3) AS-DOWN  |    Length                         |
   +---------------+---------------+ AS-PENDING  |      Protocol Identifier*
      |

   +---------------+---------------+          |   Tag (0x4)                         |    Length  (queueing) |
   +---------------+---------------+
      |         INFO String*          |<------------------------|             |

   +---------------+---------------+

                                                                     18

The format and description
      +----------+    Tr Trigger no ASP    +-------------+
                       in UP state or

    Tr = Recovery Timer

3.3.2 ASPM procedures for primitives

Before the establishment of an SCTP association the optional Protocol Identifier ASP state at both
the SG and Info
String parameters ASP is assumed to be "Down".

When the same as for M3UA layer receives an M-SCTP ESTABLISH request primitive from
the DUVA message (See Section
2.3.2.1.)

The optional Adaptation Layer Identifier is a string that identifies Management, the adaptation layer.  This string must be set M3UA layer will try to "M3UA" which results
in a length of 4.  The ALI would normally only be used in establish an SCTP
association with the initial
ASP remote M3UA peer.  Upon reception of an eventual
SCTP-Communication Up message across a new confirm primitive from the SCTP, the M3UA layer
will invoke the primitive M-SCTP ESTABLISH confirm to the Layer
Management.

Alternatively, if the remote M3UA-peer establishes the SCTP association to ensure both peers are
assuming
first, the same adaptation M3UA layer protocol.

Note: Strings are padded will receive an SCTP Communication Up indication
primitive from the SCTP. The M3UA layer will then invoke the primitive
M-SCTP ESTABLISH indication to 32-bit boundaries. the Layer Management.

Once the SCTP association is established, The length field
indicates M3UA layer at an ASP will
then find out the end state of its local M3UA-user from the Layer
Management using the primitive M-ASP STATUS.  Based on the status of
the local M3UA-User, the local ASP M3UA Application Server Process
Maintenance (ASPM) function will initiate the string.

2.3.3.2 ASP Down (ASPDN)

The ASP-DN message is used ASPM procedures, using
the ASP-Up/-Down/-Active/-Inactive messages to indicate convey the ASP-state to a remote M3UA peer that
the
adaptation SG - see Section 3.3.3.

If the M3UA layer is not ready to receive traffic or maintenance
messages.

The ASPDN message contains subsequently receives an SCTP-Communication Down
indication from the following parameters:

     INFO String (Optional)

The format for underlying SCTP layer, it will inform the ASPDN message is as follows:

    0            15 16           31
   +---------------+---------------+
   |   Tag (0x4)   |    Length     |
   +---------------+---------------+

   |         INFO String*          |

   +---------------+---------------+

****************
Ed Note: Need to add a reason code parameter.  Reasons could be failure
or management inhibit.
****************

2.3.3.3 ASP Active (ASPAC)

The ASPAC message is sent Layer
Management by an invoking the M-SCTP STATUS indication primitive. The
state of the ASP will be moved to indicate to an "Down" at both the SG that it is and ASP.

At an ASP, the active ASP Layer Management may try to be used from within a list of primary and back-up
ASPs for a particular AS.

The ASPAC message contains reestablish the following parameters:

     INFO String (Optional)

The format SCTP
association using M-SCTP ESTABLISH request primitive.

3.3.3 ASPM procedures for peer-to-peer messages

3.3.3.1 ASP-Up

[Ed Note: text required to specify what SG does before first ASP-Up
received]

The SG will mark the ASPAC message is path as follows:

                                                                     19
    0            15 16           31
   +---------------+---------------+
   |   Tag (0x4)   |    Length     |
   +---------------+---------------+

   |         INFO String*          |

   +---------------+---------------+

2.3.3.4  ASP Inactive (ASPIA)

The ASPIA message is sent by up if an explicit ASP to indicate to an SG that it UP (ASPUP) message
is
no longer the received and internally the active ASP path is allowed to be used from within come up (i.e., not in
a list of primary
and back-up locked local maintenance state). An ASP for a particular AS. UP (ASPUP) message will be
sent to acknowledge the received ASPUP. The SG will respond to a ASPUP
with an ASPIA a ASPDN message and either discard incoming messages or buffer for if the path is in a timed
period and then discard. locked maintenance state.

The ASPIA SG will send a ASPUP message contains in response to a received ASPUP
message from the following parameters:

     INFO String (Optional) ASP even if that path was already marked as UP at the
SG.

The format for paths are controlled by the ASPIA message is as follows:

    0            15 16           31
   +---------------+---------------+
   |   Tag (0x4)   |    Length     |
   +---------------+---------------+

   |         INFO String*          |

   +---------------+---------------+

2.3.4  Management Messages

2.3.4.1  Error (ERR) ASP. The ERR message is sent when an invalid value is found SG will only send ASPUP in an incoming
response to the reception of a ASPUP message.

The ERR ASP will send ASPUP messages every 2 seconds until the path comes
up (i.e. until it receives a ASPUP message contains from the following parameters:

     Error Code

The format SG for that path).
The ASP may decide to reduce the ERR message frequency (say to every 5 seconds) if

the an acknowledgement is as follows:

    0     7 8    15 16           31
   +---------------+---------------+
   |           Error Code          |
   +---------------+---------------+

                                                                     20 not received after a few tries.

The Error Code can be one of ASP should wait for the following values:

     Invalid Version                        0x1
     Invalid Interface Identifier           0x2
     Invalid SCN Version                    0x3
     Invalid Adaptation Layer Identifier    0x4
     Invalid Stream Identifier              0x5
     Invalid Message Type                   0x6

3.0 Procedures

The M3UA layer needs to respond to various local primitives it receives ASPUP message from other layers as well as the SG before
transmitting ASP maintenance messages that (ASPIA or ASPAC) or M3UA messages
or it receives will risk message loss.  The ASPUP message received from the
peer M3UA layers.  This section describes SG
is not acknowledged by the M3UA procedures in
response to these events.

3.1 Procedures to support ASP.

3.3.3.2 ASP Down

The SG will mark the M3UA services in Section 1.4.1

These procedures support ASP as down and send an ASPDN message to the M3UA transport of MTP3-User/MTP3 boundary
primitives.

3.1.1 Receipt ASP
if one of Local primitives

On receiving a primitive the following events occur:

     - an ASP Down(ASPDN) message is received from the upper layer, ASP,
     - the M3UA layer ASP is locked by local maintenance at the SG.

The SG will also send the corresponding ITUN or SSNM a ASPDN message (see Section 2) to its
peer.  The M3UA layer must fill in various fields of when the common ASP is already down and
specific headers correctly.  In addition the
a ASPDN) message needs is received from the ASP.

The ASP will send ASPDN whenever it wants to be sent
on take down a ASP.  Since
the appropriate SCTP stream.

3.1.2 Receipt of ITUN ASPDN messages to the SG or SSNM Messages the ASPDN responses from the Peer M3UA

On receiving ITUN or SSNM SG can be
lost (for example, during fail-over), the MGC can send ASPDN messages
every 2 seconds until the path comes down (i.e. until it receives a
ASPDN message from the remote M3UA Peer, SG for that path).

3.3.3.3 ASP Version Control

If a ASP Up message with an unknown version is received, the receiving
end will respond with an Error message.  This will indicate to the M3UA
layer invokes
sender which version the appropriate primitive indications to receiving node supports.

This is useful when protocol version upgrades are being performed.  A
node with the M3UA-User

3.2 Procedures to newer version should support the M3UA services older versions used on
other nodes it is communicating with.

The version field in Section 1.4.2

3.2.1 Layer Management primitives procedures

On receiving these primitives from the local layer management, the M3UA
layer Error message header associated will send indicate
the corresponding management message (Error) to its
peer.  The M3UA layer must fill in version supported by the various fields of node.

3.3.3.4 ASP Active

When an ASP Active (ASPAC) message is received, the common and
specific headers correctly.

3.2.2 Receipt SG will start
routing to that ASP.  Reception of Peer Management a ASPAC message overrides any
previous ASPAC messages

Upon receipt of Management messages, and results in the M3UA layer must invoke ASP associated with the
corresponding Layer Management primitive indications (M-ERROR ind.)
ASPAC message to become the local layer management.

3.3 Procedures newly active ASP.

3.3.3.5 ASP Inactive

When a ASPIA message is received, message transmission to support the M3UA services in Section 1.4.3

                                                                     21

These procedures support the M3UA management of SCTP Associations and that ASP Paths between SGs and ASPs

3.3.1 State Maintenance
ceases.  The M3UA layer on the SG needs to maintain the state of each ASP as
well as will either discard all incoming messages or start
buffering the state of incoming messages for T(r)seconds after which messages
will be discarded.

If the related ASs.

3.3.1.1 ASP States

The state is down, all of each the Paths that were supported by that ASP is maintained in

are, by default, down.

3.4 Procedures to support the M3UA layer services in Section 1.4.3

3.4.1 At an SG

On receiving an MTP-PAUSE, MTP-RESUME, or MTP-STATUS indication
primitive from the SG. The
state of inter-working function at an ASP changes due SG, the M3UA layer will
send a corresponding SSNM DUNA, DAVA, SCON, or DUPU message (see
Section 2) to events. the concerned M3UA peers.  The events include:

   * Reception of messages from peer M3UA layer
   * Reception must fill in
various fields of indications from the SCTP layer

The ASP state transition diagram is shown in Figure 4. common and specific headers correctly.

The possible
states M3UA address translation and mapping function determines the set of an ASP are:

ASP-DOWN: The Application Server Process is unavailable.  Initially all
ASPs will to be in this state.

ASP-UP: The Application Server Process is available but application
traffic is stopped.

ASP-ACTIVE: The Application Server Process informed based on the network appearance for which the
indication is available and application relevant. All ASPs configured to send/receive traffic is active.  At most one ASP per AS can be in
within a particular network appearance are informed.  If the active state.

                 Figure 4: ASP State Transition Diagram

                               +-------------+
                     |-------->|             |
                     |         |  ASP-ACTIVE |
                     |         +-------------+
                     |             ^     |
                     |      ASP    |     | ASP
                     |      Active |     | Inactive
                     |             |     v
                     |         +-------------+
         ASP Down /  |         |             |
          SCTP CDI   |         |  ASP-UP     |
                     |         +-------------+
                     |             ^    |
                     |        ASP  |    | ASP Down /
                     |        Up   |    | SCTP CDI
                     |             |    v
                     |         +-------------+
                     |         |             |
                     |-------->|             |
                               |  ASP-DOWN   |
                               +-------------+

                                                                     22

SCTP CDI: The local SCTP layer's Communication Down Indication SG
operates within a single network appearance, then all ASPs are
informed.  It may be possible to the
Upper Layer Protocol (M3UA) on suppress DUPU messages to ASPs that do
not implement an SG. The local SCTP will send MTP3-User protocol peer for the affected MTP3-User,
but this
indication when it detects is not mandatory.

In addition, the loss of connectivity DUNA, DAVA, SCON messages need to be sent on a
sequenced stream as these primitives should arrive in order.  This is
not required for the ASP's SCTP
layer.

3.3.1.2  AS States

The state of DUPU message, which may optionally be sent un-
sequenced.

3.4.2 At an ASP

At an ASP, upon receiving an SSNM message from the AS is maintained in remote M3UA Peer,
the M3UA layer on invokes the SG.

The state of an AS changes due appropriate primitive indications to events. These events include:

   * ASP state transitions
   * Recovery timer triggers

The possible states of an AS are:

AS-DOWN: The Application Server is unavailable.  This state implies
that all related ASPs are in the ASP-DOWN state for this AS. Initially
the AS will be in this state.

AS-UP: The Application Server
M3UA-User.  Local management is available informed but no application traffic state is active (i.e., one or more related ASPs are maintained in
the ASP-UP state, but
none M3UA layer.

4.0 Examples of M3UA Procedures

4.1 Establishment of Association and Traffic between SGs and ASPs

4.1.1 Single ASP in the ASP-Active state).

AS-ACTIVE: The an Application Server is available ("1+0" sparing)

An example of the message flows for establishing an active association
between an SG and application traffic an ASP is active.  This state implies shown below.  It is assumed that one ASP an SCTP
association is already set-up.

             SG                       ASP1
              |
              |<---------ASP Up---------|
              |-------ASP Up (Ack)----->|
              |                         |
              |<-------ASP Active-------|
              |----ASP Active (Ack)---->|
              |                         |

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

Establishment of Associations between an SG and Multiple ASPs in the ASP-ACTIVE state.

AS-PENDING: The Active ASP has transitioned from active to inactive or
down. A recovery timer T(r) will be started and all incoming SCN
messages
same Application Server (Primary/Back-up case).  In this case ASP1 will
be queued by the SG. If an primary ASP becomes active before T(r)
expires, for the AS will move to AS-ACTIVE state and all the queued
messages ASP2 will be sent to a standby in the active ASP.

If T(r) expires before an ASP becomes active, event
of failure of the SG stops queuing
messages and  discards all previously queued messages. The AS will move
to AS-UP if at least one withdrawal from service of ASP1.  ASP is in ASP-UP state, otherwise it will move could act as a
hot, warm, or cold standby depending on the extent to AS-DOWN state.

                                                                     23
                 Figure 5: AS State Transition Diagram

      +----------+  one ASP trans ACTIVE   +-------------+
      |          |------------------------>| which ASP1 and
ASP2 share call state or can communicate call state under
failure/withdrawal events.

       SG                       ASP1                       ASP2
        |                         |  AS-UP                          |
        |<---------ASP Up---------|                          |  AS-ACTIVE
        |-------ASP Up (Ack)----->|                          |
        |                         |                          |
        |<------------------------------ASP Up---------------|
        |-----------------------------ASP Up (Ack)---------->|
        |                         |          |<                       -|                          |
      +----------+ \                     / +-------------+
         ^

                                 ...

        |      \ Tr Trigger        /       ^                         |                          |
        |<-------ASP Active-------|                          |       \ at least one    /
        |----ASP Active (Ack)---->|                          |
        |                         |                          |        \ ASP

4.1.3 Two ASPs in UP     / an Application Server ("1+1" sparing, load-sharing
case)

       SG                       ASP1                       ASP2
        |                         |                          |
        |<---------ASP Up---------|                          |         \             /
        |-------ASP Up (Ack)----->|                          |
        |                         |                          |          \           /
        |<------------------------------ASP Up---------------|
        |-----------------------------ASP Up (Ack)---------->|
        |                         |                          |

                                 ...

        |           \     /---/                         |                          |
 one ASP
        |<--ASP Active (Ldshr)----|                          |
        |----ASP Active (Ack)---->|                          |            \   /        one ASP
        |                         | ACTIVE ASP
 trans                          |
        |<----------------------------ASP Active (Ldshr)-----|
        |-----------------------------ASP Active (Ack)------>|
        | all ASP     \-/----\    trans to                         |                          | trans to UP or
 to UP

4.1.4 Three ASPs in an Application Server ("n+k" sparing, load-sharing
case)

   SG                  ASP1                 ASP2                 ASP3
    |                    | trans to     /      \   ACTIVE                   |                   | DOWN
    |<------ASP Up-------|                   |                   | DOWN        /        \
    |----ASP Up (Ack)--->|                   |                   |
    |                    |            /          \                   |                   |
    |<--------------------------ASP Up-------|                   |
    |------------------------ASP Up (Ack)--->|                   |           /            \
    |                    |                   |                   |          /all ASP       \
    |<---------------------------------------------ASP Up--------|
    |--------------------------------------------ASP Up (Ack)--->|
    |                    |                   |   v         / trans to       \                   |    v
      +----------+    /  DOWN            \ +-------------+

                             ...

    |                    |                   |                   |          |<--/                    -|
    |<-ASP Act. (Ldshr)--|                   |                   | AS-DOWN
    |---ASP Act. (Ack)-->|                   |                   | AS-PENDING
    |                    |                   |                   |  (queueing)
    |<--------------------ASP Act. (Ldshr)---|                   |
    |----------------------ASP Act. (Ack)--->|                   |          |<------------------------|
    |
      +----------+    Tr Trigger no ASP    +-------------+
                       in UP state or

    Tr = Recovery Timer

3.3.2 ASPM procedures for primitives

Before the establishment of an SCTP association the ASP state at both
the SG and                    |                   |                   |

4.3 ASP is assumed to be "Down".

When the M3UA layer receives an M-SCTP ESTABLISH request primitive from
the Layer Management, the M3UA layer will try to establish an SCTP
association with the remote M3UA peer.  Upon reception Traffic Fail-over Examples

4.3.1 (1+1 Sparing, withdrawal of an eventual
SCTP-Communication Up confirm primitive from the SCTP, the M3UA layer
will invoke the primitive M-SCTP ESTABLISH confirm to the Layer
Management.

Alternatively, if the remote M3UA-peer establishes the SCTP association
first, the M3UA layer will receive an SCTP Communication Up indication
primitive ASP, Back-up Over-ride)

Following on from the SCTP. The M3UA layer will then invoke the primitive
M-SCTP ESTABLISH indication to the Layer Management.

Once the SCTP association is established, The M3UA layer at an example in Section 4.1.2, and ASP will
then find out the state of its local M3UA-user withdraws from the Layer
Management using the primitive M-ASP STATUS.  Based on the status of
the local M3UA-User, the local ASP M3UA Application Server Process

                                                                     24

Maintenance (ASPM) function will initiate the ASPM procedures, using
the ASP-Up/-Down/-Active/-Inactive messages to convey the ASP-state to
the
service:

       SG - see Section 3.3.3.

If the M3UA layer subsequently receives an SCTP-Communication Down
indication from the underlying SCTP layer, it will inform the Layer
Management by invoking the M-SCTP STATUS indication primitive. The
state of the                       ASP1                       ASP2
        |                         |                          |
        |<-----ASP Inactive-------|                          |
        |---ASP Inactive (Ack)--->|                          |
        |----------------------------ASP Active (Optional)-->|
        |                         |                          |
        |<------------------------------ ASP will be moved to "Down" at both Active----------|
        |-----------------------------ASP Active (Ack)------>|
        |                                                    |

Note: If the SG and ASP.

At an ASP, the Layer Management may try to reestablish detects loss of the M3UA peer (M3UA heartbeat loss or
detection of SCTP
association using M-SCTP ESTABLISH request primitive.

3.3.3 ASPM procedures for peer-to-peer messages

3.3.3.1 ASP-Up

The SG will mark failure), the path as up if an explicit initial SG-ASP1 ASP UP (ASPUP) Inactive message is
received and internally the path is allowed to come up (i.e.,
exchange would not occur.

4.3.2 (1+1 Sparing, Back-up Over-ride)

Following on from the example in a
locked local maintenance state). An ASP UP (ASPUP) message will be sent Section 4.1.2, and ASP2 wishes to acknowledge
over-ride ASP1 and take over the received ASPUP. The traffic:

       SG will respond to a ASPUP with a
ASPDN message if                       ASP1                       ASP2
        |                         |                          |
        |<------------------------------ ASP Active----------|
        |-----------------------------ASP Active (Ack)------>|
        |                         |                          |
        |------ASP Inactive------>|                          |
        |<--ASP Inactive (Ack)----|                          |
        |                         |                          |

4.3.3 (n+k Sparing, Load-sharing case, withdrawal of ASP)

Following on from the path is example in a locked maintenance state.

The Section 4.1.4, and ASP1 withdraws from
service:

   SG will send a ASPUP message in response to a received ASPUP                  ASP1                 ASP2                 ASP3
    |                    |                   |                   |
    |<----ASP Inact.-----|                   |                   |
    |--ASP Inact. (Ack)->|                   |                   |
    |                    |                   |                   |
    |---------------------------------------ASP Act. (Optional)->|
    |                    |                   |                   |
    |<-----------------------------------------ASP Act. (Ldshr)--|
    |-------------------------------------------ASP Act. (Ack)-->|
    |                    |                   |                   |

Note: If the SG detects loss of the M3UA peer (M3UA heartbeat loss or
detection of SCTP failure), the first SG-ASP1 ASP Inactive message
exchange would not occur.

4.4  M3UA/MTP3-User Boundary Examples

4.4.1 At an ASP

This section describes the primitive mapping from the MGC even if that path was already marked as UP MTP3 User to M3UA
at an ASP.

4.4.1.1 Support for MTP-Transfer

When the SG.

The paths are controlled by the MGC. The SG will only send ASPUP in
response MTP3-User has data to send into the reception of a ASPUP message. SS7 network, it will use
the MTP-Transfer indication primitive.  The MGC M3UA on the ASP will send ASPUP messages every 2 (add text regarding this being
a configurable timer) seconds until do the path comes up (i.e. until
following when it receives a ASPUP message from an MTP-Transfer:

? Determine the correct SG for that path).  The MGC may decide
to reduce

? Determine the frequency (say correct association to every 5 seconds) if the an acknowledge-
ment is not received after a few tries.

The MGC should wait for chosen SG

? Determine the ASPUP message from correct stream in the SG before transmitting
ASP maintenance messages (ASPIA or ASPAC) or M2UA messages or it will
risk association (e.g., based on SLS)

? Map the MTP-Transfer into the Payload of a Data message loss.  The ASPUP

? Send the Data message received from to the SG is not
acknowledged by remote M3UA peer, over the MGC.

3.3.3.2 ASP Down

The SCTP
association

        SG will mark the                       ASP
        |                         |
        |<-----Data Message-------|<--MTP-Transfer req.
        |                         |

                     or

        |                         |
        |------Data Message------>|---MTP-Transfer ind.?
        |                         |

4.4.1.2 Support for ASP Querying of SS7 Destination States

There are situations such as down and send a ASPDN message temporary loss of connectivity to the MGC if
one of SG
that may cause the M3UA on the following events occur:

     - a ASP Down(ASPDN) message to audit SS7 destination
availability states.  Note: there is received from no primitive for the MGC,
     - MTP3-User to
request this audit from the ASP M3UA as this is locked initiated by local maintenance. an internal
M3UA management function.

The SG will also M3UA on the MGC / AN would send a ASPDN message when Destination State Audit (DAUD)
messages for each of the ASP is already down and
a ASPDN) message is received from destinations that the MGC.

The MGC will send ASPDN whenever it wants to take down a ASP.  Since / AN supports.

       SG                        ASP
        |                         |
        |<-----DAUD Message ------|
        |<-----DAUD Message ------|
        |<-----DAUD Message ------|
        |                         |
        |                         |

4.4.2 At an SG

This section describes the
ASPDN messages primitive mapping from the MTP3 Upper layer
boundary to the SG or M3UA at the ASPDN responses SG.

The MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from the
MTP3 upper layer interface at the SG can need to be lost

                                                                     25

(for example, during a MGC node failover), made available to the MGC can send ASPDN messages
every 2 seconds until
remote MTP3-User lower layer interface at the path comes down (i.e. until it receives a ASPDN
message from ASP.

4.4.2.1 Destination Unavailable

The MTP3 on the SG for will generate an MTP-PAUSE primitive when it
determines locally that path).

3.3.3.3 ASP Version Control

If a ASP Up message with an unknown version SS7 destination is received, the receiving
end unreachable.  The M3UA
will respond with an Error map this primitive to a Destination Unavailable (DUNA) message.  This
It will indicate to the
sender determine which version the receiving node supports.

This is useful when protocol version upgrades are being performed.  A
node with the newer version should support ASP(s) to send the older versions used DUNA based on
other nodes it is communicating with.

The version field in the Error message header associated will indicate the
version supported by the node.

3.3.3.4 ASP Active

When a Network
Appearance information.

                     SG                       ASP Active (ASPAC) message is received,
                      |                         |
   --MTP-PAUSE ind.-->|------DUNA Message ----->|--MTP-PAUSE ind.-->
                      |                         |

4.4.2.2 Destination Available

The MTP3 on the SG will start routing
to generate an MTP-RESUME primitive when it
determines locally that ASP.  Reception of a ASPAC message overrides any previous ASPAC
messages and results in the ASP associated with the ASPAC message to
become the newly active ASP.

3.3.3.5 ASP Inactive

When a ASPIA message an SS7 destination that was previously
unreachable is received, message transmission now reachable.  The M3UA will map this primitive to that a
Destination Unavailable (DAVA) message.  It will determine which ASP(s)
to send the DUNA based on the Network Appearance information.

                      SG                       ASP ceases.
                       |                         |
   --MTP-RESUME ind.-->|------DAVA Message ----->|--MTP-RESUME ind.-->
                       |                         |

4.4.2.3 SS7 Network Congestion

The MTP3 on the SG will either discard all incoming messages or start buffering generate an MTP-STATUS primitive when it
determines locally that the
incoming messages for T(r)seconds after which messages route to an SS7 destination is congested.
The M3UA will be discarded.

If map this primitive to a SS7 Network Congestion State
(SCON) message.  It will determine which ASP(s) to send the ASP is down, all of DUPU to
based on the Paths that were supported by that ASP
are, by default, down.

4.0 Examples of M3UA Procedures

4.1 Establishment of associations between an intended Application Server.

                     SG and an                       ASP

An example of
                       |                         |
   --MTP-STATUS ind.-->|------SCON Message ----->|--MTP-STATUS ind.-->
                       |                         |

4.4.2.4 Destination User Part Unavailable

The MTP3 on the message flows for establishing SG will generate an active association
between MTP-STATUS primitive when it
determines locally that an SG and ASP SS7 destination User Part is shown below.

                  SG                  ASP1

                        <----------- ASP Up
                  ASP Up ---------->
                  (ACK)
                        <----------- ASP Active
              ASP Active ---------->
              (ACK)

An example of message flows for establishment of associations with two
ASPs and the message flows for take-over of unavailable.
The M3UA will map this primitive to a Destination User Part Unavailable
(DUPU) message.  It will determine which ASP(s) to send the primary (ASP1) by DUPU to
based on the
secondary (ASP2).

                                                                     26 intended Application Server.

                      SG                    ASP1               ASP2

                        <----------- ASP Up
                  ASP Up ---------->
                  (ACK)
                        <------------------------------ ASP Up
                  ASP Up ------------------------------>
                  (ACK)
                        <----------- ASP Active
              ASP Active ---------->
              (ACK)
                              ...

                        <----------- ASP Inactive
            ASP Inactive ---------->
            (ACK)

                         (this message is optional)
            ASP Inactive ------------------------------>
                        <------------------------------ ASP Active                       ASP Active ------------------------------>
              (ACK)

4.2  M3UA/MTP3-User Boundary Examples

*****************
Ed Note: Text to be added
*****************
                       |                         |
   --MTP-STATUS ind.-->|------DUPU Message ----->|--MTP-STATUS ind.-->
                       |                         |

5.0 Security

M3UA relies upon IPSEC to ensure confidentiality of user payload.
Consult [RFC 2401, "Security Architecture for the Internet Protocol",
S. Kent, R. Atkinson, November 1998] for more information on
configuring IPSEC services.

6.0 Acknowledgements

The authors would like to thank John Loughney Loughney, Neil Olson, Norm Glaude,
and Michael Tuexen for his their valuable comments and suggestions.

7.0  References

[1] RFC 2719, "Framework Architecture for Signaling Transport"

[2] ITU-T Recommendation Q.700, 'Introduction To ITU-T Recommendations Q.761 to Q.767, 'Signalling System No.7 (SS7)
    - ISDN User Part (ISUP)'

[3] ANSI T1.113 - 'Signaling System Number 7 - ISDN User Part

[4] 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"

[5] ITU-T Recommendations Q.711-714, 'Signalling System No. 7 (SS7)'

[2] (SS7) -
    Signalling Connection Control Part (SCCP)'

[6] ANSI T1.112 'Signaling System Number 7 - Signaling Connection
Control Part'

[7] 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"

[8] ITU-T Recommendations Q.720, 'Telephone User Part'

[9] ITU-T Recommendation Q.771-775 'Signalling System No. 7 SS7) -
    Transaction Capabilities (TCAP)

[10] ANSI T1.114 'Signaling System Number 7 - Transaction Capabilities
Application Part'

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

[12] RANAP

[13] Simple Control Transport Protocol <draft-ietf-sigtran-sctp-
     05.txt>, Dec. 1999, Work in Progress

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

[3]

[15] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part'

[16] 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"

[17] ITU-T Recommendation Q.2140 'B-ISDN ATM Adaptation Layer -

                                                                     27 Service
     Specific Coordination Function for signaling at the Network Node
     Interface (SSCF at NNI)

[4]

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

[5] Simple Control Transport Protocol
    draft-ietf-sigtran-sctp-00.txt, Sept.

[19] MTP2-User Adaptation Layer <draft-ietf-sigtran-m2ua-01.txt>, Nov.
     1999, Work in Progress

[6] ITU-T Recommendation Q.711-714 'Signalling System No. 7
(SS7) - Signaling Connection Control Part (SCCP)'

[7]

[20] ITU-T Recommendation Q.2210 'B-ISDN MTP'

[8] ITU-T Recommendation Q.xxxx 'ISUP BICC'

[9] ITU-T Recommendation Q.771-775 'Signalling System No. 7
(SS7) - Transaction Capabilities (TCAP)

[10] ANSI T1.111 'Signaling System Number 7 - Message Transfer Part'

5.0  Author's Addresses

Lyndon Ong                             Guy Mousseau
Nortel Networks                        Nortel Networks
4401 Great America Pkwy                3685 Richmond Rd
Santa Clara, CA, USA  95054
long@nortelnetworks.com

Greg Sidebottom
Nortel Networks
3685 Richmond Rd,            Nepean, Ontario, Canada K2H 5B7
gregside@nortelnetworks.com

Guy Mousseau
long@nortelnetworks.com

Greg Sidebottom                        Ian Rytina
Nortel Networks                        Ericsson Australia
3685 Richmond Rd Rd,                      37/360 Elizabeth Street
Nepean, Ontario, Canada  K2H 5B7

Ian Rytina
Ericsson Australia
37/360 Elizabeth Street       Melbourne, Victoria 3000, Vic 3000  Australia
gregside@nortelnetworks.com            ian.rytina@ericsson.com

Hanns Juergen Schwarzbauer
SIEMENS AG
Hofmannstr. 5181359
Munich, Germany
HannsJuergen.Schwarzbauer@icn.siemens.de

                                                                     28             Ken Morneault
SIEMENS AG                             Cisco Systems Inc.
Hofmannstr. 51                         13615 Dulles Technology Drive Rd
81359 Munich, Germany                  Herndon, VA, USA VA 20171
EMail:  USA
HannsJuergen.Schwarzbauer@icn.siemens.de   kmorneau@cisco.com

Malleswar Kalla
Telcordia Technologies
MCC 1J211R
445 South Street
Morristown, NJ, USA  07960
EMail: kalla@research.telcordia.com

This draft expires April July 2000.

                                                                     29