[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-loughney-sigtran-sua) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 3868

INTERNET-DRAFT                                             J. Loughney
Internet Engineering Task Force                                  Nokia
                                           G. Sidebottom, Guy Mousseau
Issued:  1 February 2001                               Nortel Networks
Expires: 1 August 2001                                      S. Lorusso
                                                   Unisphere Solutions
                                                  L. Coene, G. Verwimp
                                                               Siemens
                                                             J. Keller
                                                               Tekelec
                                                            F. Escobar
                                                              Ericsson
                                                  W. Sully, S. Furniss
                                                               Marconi

                  SS7 SCCP-User Adaptation Layer (SUA)
                    <draft-ietf-sigtran-sua-05.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                                                                                                    .

   This draft expires on 1 August 2001

Abstract

   This Internet Draft defines a protocol for the transport of any SS7
   SCCP-User signaling (e.g., TCAP, RANAP, etc.) over IP using the
   Stream Control Transport Protocol.  The protocol should be modular
   and symmetric, to allow it to work in diverse architectures, such as
   a Signaling Gateway to IP Signaling Endpoint architecture as well as
   a peer-to-peer IP Signaling Endpoint architecture.  Protocol
   elements are added to allow seamless operation between peers in the
   SS7 and IP domains.

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


Abstract..............................................................1
1. Introduction.......................................................3
 1.1 Scope ...........................................................3
 1.2 Terminology .....................................................3
 1.3 Signaling Transport Architecture ................................5
 1.4 Services Provided by the SUA Layer .............................11
 1.5 Internal Functions Provided in the SUA Layer ...................13
 1.6 Definition of SUA Boundaries ...................................15
2 Conventions........................................................16
3 Protocol Elements..................................................16
 3.1 Common Message Header ..........................................16
 3.2 SUA Connectionless Messages ....................................19
 3.3 Connection Oriented Messages ...................................21
 3.4 SS7 Signaling Network Management Messages ......................29
 3.5 Application Server Process Maintenance Messages ................34
 3.6 ASP Traffic Maintenance Messages ...............................36
 3.7 Management Messages ............................................39
 3.8 Common Parameters ..............................................40
 3.9 SUA-Specific parameters ........................................49
4 Procedures.........................................................62
 4.1 SCCP _ SUA Interworking at the SG ..............................62
 4.2 Primitives received from the local SUA-user ....................63
 4.3 Layer Management Procedures ....................................64
 4.4 SUA Management Procedures ......................................65
5 Examples of SUA Procedures.........................................71
 5.1 SG Architecture ................................................71
 5.2 IP-IP Architecture .............................................74
6 Message Routing Scenarios..........................................76
 6.1 Basic case with single SG acting as end- or relay-point ........76
 6.2 Replicated SG acting as end-point ..............................77
 6.3 Replicated SG acting as relay-point ............................78
7 Security...........................................................79
 7.1 Introduction ...................................................79
 7.2 Threats ........................................................79
 7.3 Protecting Confidentiality .....................................79
8 IANA Considerations................................................80
 8.1 SCTP Payload Protocol ID .......................................80
 8.2 Port Number ....................................................80
 8.3 Protocol Extensions ............................................80
9 Timer Values.......................................................81
10 Acknowledgements..................................................81
10 Authors' Addresses................................................81
11 References........................................................83
Appendix A: Message mapping between SCCP and SUA.....................84
Copyright Statement..................................................85







Loughney, et al.                                            [Page 2]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


1. Introduction

1.1 Scope

   There is on-going integration of SCN networks and IP networks.
   Network service providers are designing all IP architectures which
   include support for SS7 and SS7-like signaling protocols. IP
   provides an effective way to transport user data and for operators
   to expand their networks and build new services. In these networks,
   there may be some need for interworking between the SS7 and IP
   domains.

   This document details the delivery of SCCP-user messages (MAP & CAP
   over TCAP, RANAP, etc.) and new third generation network protocol
   messages over IP between two signaling endpoints.  Consideration is
   given for the transport from an SS7 Signaling Gateway (SG) to an IP
   signaling node (such as an IP-resident Database) as described in the
   Framework Architecture for Signaling Transport [2719]. This protocol
   can also support transport of SCCP-user messages between two
   endpoints wholly contained within an IP network.

   The delivery mechanism SHOULD meet the following criteria:

   *  Support for transfer of SS7 SCCP-User Part messages (e.g., TCAP,
      RANAP, etc.)
   *  Support for SCCP connectionless service.
   *  Support for SCCP connection oriented service.
   *  Support for the seamless operation of SCCP-User protocol peers
   *  Support for the management of SCTP transport associations between
      a SG and one or more IP-based signaling nodes).
   *  Support for distributed IP-based signaling nodes.
   *  Support for the asynchronous reporting of status changes to
      management

   The protocol is modular in design, allowing different
   implementations to be made, based upon the environment that needs to
   be supported. Depending upon the upper layer protocol supported, the
   SUA will need to support SCCP connectionless service, SCCP connect-
   orient service or both services.

1.2 Terminology

   Signaling Gateway (SG) - Network element that terminates SCN
   signaling and transports SCCP-User signaling over IP to an IP
   signaling endpoint.  A Signaling Gateway could be modeled as one or
   more Signaling Gateway Processes, which are located at the border of
   the SS7 and IP networks.

   Application Server (AS) - A logical entity serving a specific
   Routing Key.  An example of an Application Server is a virtual IP
   database element handling all request for a SCCP-user.  The AS

Loughney, et al.                                            [Page 3]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   contains a set of one or more unique Application Server Processes,
   of which one or more is normally actively processing traffic.

   Application Server Process (ASP) - An Application Server Process
   serves as an active or standby process of an Application Server
   (e.g., part of a distributed signaling node or database element).
   Examples of ASPs are MGCs, IP SCPs, or IP-based HLRs.  An ASP
   contains an SCTP end-point and may be configured to process traffic
   within more than one Application Server.

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

   Routing Key - The Routing Key describes a set of SS7 parameter and
   /or parameter-ranges that uniquely defines the range of signaling
   traffic configured to be handled by a particular Application Server.
   An  example would be where a Routing Key consists of a particular
   SS7 network ID and SCCP SSN for which all traffic would be directed
   to a particular Application Server.  Routing Keys are mutually
   exclusive in the sense that a received SS7 signaling message cannot
   be directed to more than one Routing Key. In the case of SUA, the
   Routing Key should be limited to a combination of SS7 network ID and
   SCCP SSN to identify an AS, in order to more easily support SCCP
   management procedures.

   Routing Context - An Application Server Process may be configured to
   process traffic within more than one Application Server.  In this
   case, the Routing Context parameter is exchanged between two ASPs,
   identifying the relevant Application Server.  From the perspective
   of an ASP, the Routing Context uniquely identifies the range of
   traffic associated with a particular Application Server, which the
   ASP is configured to receive. There is a 1:1 relationship between a
   Routing Context value and a Routing Key within an AS.  Therefore the
   Routing Context can be viewed as an index into an AS Table
   containing the AS Routing Keys.

   Fail-over - The capability to re-route signaling traffic as required
   to an alternate Application Server Process, or group of ASPs, within
   an Application Server in the event of failure or unavailability of a
   currently used Application Server Process.  Fail-back may apply upon
   the return to service of a previously unavailable Application Server
   Process.

   Network Appearance - The Network Appearance identifies an SS7
   network context (network ID) for the purposes of logically
   separating the signaling traffic between the SG and the Application
   Server Processes over a common SCTP Association.  This partitioning
   is necessary where an SG is logically partitioned to appear as an
   end-node elements in multiple separate national SS7 networks, in
   which case there is a separate network appearance for each SS7

Loughney, et al.                                            [Page 4]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   network. It is also necessary when an SG is configured as an STP and
   hosts multiple point codes within the same network, in which case
   each point code is a separate network appearance.

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

   Layer Management - Layer Management is a nodal function in an SG or
   ASP that handles the inputs and outputs between the SUA layer and a
   local management entity.

   Host - The computing platform that the ASP process is running on.

   Stream - A stream refers to an SCTP stream; a uni-directional
   logical channel established from one SCTP endpoint to another
   associated SCTP endpoint, within which all user messages are
   delivered in-sequence except for those submitted to the un-ordered
   delivery service.

   Transport address - an address which serves as a source or
   destination for the unreliable packet transport service used by
   SCTP. In IP networks, a transport address is defined by the
   combination of an IP address and an SCTP port number.  Note, only
   one SCTP port may be defined for each endpoint, but each SCTP
   endpoint may have multiple IP addresses.

1.3 Signaling Transport Architecture

   The framework architecture that has been defined for SCN signaling
   transport over IP [2719] 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 general terms, the SUA architecture can be modeled as a peer-to-
   peer architecture. The first section considers the SS7-IP
   interworking architectures for connectionless and connection-
   oriented transport.  For this case, it is assumed that the ASP
   initiates the establishment of the SCTP association with SG.

1.3.1 Protocol Architecture for Connectionless Transport

   In this architecture, the SCCP and SUA layers interface in the SG.
   There needs to be interworking between the SCCP and SUA layers to
   provide for the seamless transfer of the user messages as well as
   the management messages.  For messages destined for an ASP, there
   are two scenarios.


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

Loughney, et al.                                            [Page 5]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


        * STP  *         *             *        *      *
        ********         ***************        ********

        +------+                                +------+
        | TCAP |                                | TCAP |
        +------+         +------+------+        +------+
        | SCCP |         | SCCP | SUA  |        | SUA  |
        +------+         +------+------+        +------+
        | MTP3 |         | MTP3 |      |        |      |
        +------|         +------+ SCTP |        | SCTP |
        | MTP2 |         | MTP2 |      |        |      |
        +------+         +------+------+        +------+
        |  L1  |         |  L1  |  IP  |        |  IP  |
        +------+         +------+------+        +------+
            |               |         |            |
            +---------------+         +------------+

          TCAP - Transaction Capability Application Protocol
          STP  - SS7 Signaling Transfer Point

1.3.1.1 SG as endpoint

   In this case, the connectionless SCCP messages are routed on PC and
   SSN.  The subsystem identified by SSN and SS7 network appearance is
   regarded as local to the SG.  This means from SS7 point of view, the
   SCCP-user is located at the SG.

   By means of configuration, the SG knows the local SCCP-user is
   actually representing an AS, serviced by a set of ASPs working in
   n+k redundancy mode.  An ASP is selected and a CLDT message is sent
   on the appropriate SCTP association/stream.

   Actually, the primitive interface between SCCP and SCCP-user is
   transported here over SUA.  An example for a INAP/TCAP message
   exchange between SEP and ASP is given below.

   Address information in CLDT message (TC_Query) from SG to ASP :

     -  Association ID : SG-ASP,
     -  Stream ID : based on SLS (and possibly OPC, SS7 network ID),
     -  Network appearance : based on SS7 network ID,
     -  Source address : valid combination of SSN, PC and GT, as
        needed for back-routing,
     -  Destination address : at least SSN, to select the SCCP-user
        at the ASP.

   The Network Appearance is needed if the SG operates in more than one
   SS7 network, since PC and SSN only have meaning within a specific
   SS7 network.  In the response, the ASP should pass a unique,
   unambiguous source address.


Loughney, et al.                                            [Page 6]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



   Address information in CLDT message (TC_Response) from ASP to SG :

     - Association ID : ASP-SG,
     - Stream ID : implementation dependent, but in-sequence-
       delivery must be taken care of,
     - Network appearance : as received in previous message,
     - Source address : unique ASP address that when used as
       SCCP called party address in the SEP, MUST yield the
       same ASP again; the SSN could be sufficient,
     - Destination address : copied from source address in received
       CLDT message.

   Further messages from the SEP belonging to the same TCAP transaction
   will now reach the same ASP.

1.3.1.2 SG as relay-point

   A Global Title translation must be executed at the SG, before the
   destination of the message can be determined.  The actual location
   of the SCCP-user is irrelevant to the SS7 network.  GT Translation
   yields an "SCCP entity set", which now may contain one or more AS.
   Selection of the AS is thus based on the SCCP called party address
   (and possibly other SS7 parameters depending on the implementation).
   Basically this means splitting the SS7 traffic over different AS's
   based on GT information.  After this, the same as in 1.3.1.1
   applies.

1.3.2 Protocol Architecture for Connection-Oriented Transport

   In this architecture, the SCCP and SUA layers interface in the SG to
   associate the two connection sections needed for the connection-
   oriented data transfer between SEP and ASP.  Both connection
   sections are setup when routing the Connect Request messages from
   SEP via SG to ASP.  The routing of the Connect Request message is
   done in the same wavy as described in 1.3.1.

   Further messages for this connection are routed on DPC in the SS7
   connection section (MTP routing label), and on IP address in the IP
   connection section (SCTP header).  No other routing information is
   present in the SCCP or SUA messages themselves. Resources are kept
   within the SG to forward messages from one section to another and to
   populate the MTP routing label or SCTP header, based on the
   destination local reference of these messages (Connect Confirm, Data
   Transfer, ...)


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


Loughney, et al.                                            [Page 7]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


        * STP  *         *             *        *      *
        ********         ***************        ********

        +------+                                +------+
        | S7AP |                                | S7AP |
        +------+         +------+------+        +------+
        | SCCP |         | SCCP | SUA  |        | SUA  |
        +------+         +------+------+        +------+
        | MTP3 |         | MTP3 |      |        |      |
        +------|         +------+ SCTP |        | SCTP |
        | MTP2 |         | MTP2 |      |        |      |
        +------+         +------+------+        +------+
        |  L1  |         |  L1  |  IP  |        |  IP  |
        +------+         +------+------+        +------+
            |               |         |            |
            +---------------+         +------------+

          S7AP - SS7 Application Protocol (e.g. - RANAP/RNSAP)
          STP  - SS7 Signaling Transfer Point

   The above architecture may simplify, in some cases, to carrying SS7
   application protocols between two IP based endpoints.  In this
   scenario, full SG functionality may not be needed.  This
   architecture is considered in the next section.

1.3.3 All IP Architecture

   This architecture can be used to carry a protocol which uses the
   transport services of SCCP, but is contained with an IP network.
   This allows extra flexibility in developing networks, especially
   when interaction between legacy signaling is not needed.  The
   architecture removes the need for signaling gateway functionality.

          ********   IP   ********
          *      *--------*      *
          *  AS  *        *  AS  *
          *      *        *      *
          ********        ********

          +------+        +------+
          |  AP  |        |  AP  |
          +------+        +------+
          | SUA  |        | SUA  |
          +------+        +------+
          | SCTP |        | SCTP |
          +------+        +------+
          |  IP  |        |  IP  |
          +------+        +------+
             |                |
             +----------------+


Loughney, et al.                                            [Page 8]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


       AP - Application Protocol (e.g. - RANAP/RNSAP)

   In the case where a collision occurs during initiation, there exist
   two possible solutions: 1) if there are sufficient resources, both
   initiations could be accepted; 2) both ASPs should back-off and
   after some amount of time, later re-establish an initiation.

1.3.4 Generalized Point-to-Point Network Architecture

   Figure 1 shows an example network architecture which can support
   robust operation and failover support.  There needs to be some
   management resources at the AS to manage traffic.


         ***********
         *   AS1   *
         * +-----+ * SCTP Associations
         * |ASP1 +-------------------+
         * +-----+ *                 |                   ***********
         *         *                 |                   *   AS3   *
         * +-----+ *                 |                   * +-----+ *
         * |ASP2 +-----------------------------------------+ASP1 | *
         * +-----+ *                 |                   * +-----+ *
         *         *                 |                   *         *
         * +-----+ *                 |                   * +-----+ *
         * |ASP3 | *            +--------------------------+ASP2 | *
         * +-----+ *            |    |                   * +-----+ *
         ***********            |    |                   ***********
                                |    |
         ***********            |    |                   ***********
         *   AS2   *            |    |                   *   AS4   *
         * +-----+ *            |    |                   * +-----+ *
         * |ASP1 +--------------+    +---------------------+ASP1 | *
         * +-----+ *                                     * +-----+ *
         *         *                                     *         *
         * +-----+ *                                     * +-----+ *
         * |ASP2 +-----------------------------------------+ASP1 | *
         * +-----+ *                                     * +-----+ *
         *         *                                     ***********
         * +-----+ *
         * |ASP3 | *
         * +-----+ *
         *         *
         ***********

                    Figure 1: Generalized Architecture

   In this example, the Application Servers are shown residing within
   one logical box, with ASPs located inside.  In fact, an AS could be
   distributed among several hosts.  In such a scenario, the host
   should share state as protection in the case of a failure.

Loughney, et al.                                            [Page 9]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   Additionally, in a distributed system, one ASP could be registered
   to more than one AS.  This draft should not restrict such systems -
   though such a case in not specified.

1.3.5 Generalized Signaling Gateway Network Architecture

   When interworking between SS7 and IP domains is needed, the SG acts
   as the gateway node between the SS7 network and the IP network.  The
   SG will transport SCCP-user signaling traffic from the SS7 network
   to the IP-based signaling nodes (for example  IP-resident
   Databases). The Signaling Gateway can be considered as a group of
   Application Servers with additional functionality to interface
   towards an SS7 network.

   The SUA protocol should be flexible enough to allow different
   configurations and transport technology to allow the network
   operators to meet their operation, management and performance
   requirements.

   Figure 2 shows a possible realization of this architecture, with
   Signaling Gateway functionality.

  Signaling Gateway
  ****************
  * +----------+ *                                      **************
  * | AS1      | *                                      *  AS3       *
  * | ******** | *                                      *  ********  *
  * | * SGP1 +---------------------------------------------+ ASP1 *  *
  * | ******** | *                                      *  ********  *
  * | ******** | *                                      *  ********  *
  * | * SGP2 +--------------------------+       +----------+ ASP2 *  *
  * | ******** | *                      |       |       *  ********  *
  * +----------+ *                      |       |       *      .     *
  * +----------+ *                      |       |       *      .     *
  * | AS2      | *                      |       |       *      .     *
  * | ******** | *                      |       |       *  ********  *
  * | * SGP1 +----------------------------------+       *  * ASPN *  *
  * | ******** | *   SCTP Associations  |               *  ********  *
  * | ******** | *                      |               **************
  * | * SGP2 +----------------          |
  * | ******** | *           |          |               **************
  * +----------+ *           |          |               *  AS4       *
  ****************           |          |               *  ********  *
                             |          +------------------+ ASP1 *  *
                             |                          *  ********  *
                             |                          *      .     *
                             |                          *      .     *
                             |                          *            *
                             |                          *  ********  *
                             +-----------------------------+ ASPn *  *
                                                        *  ********  *

Loughney, et al.                                            [Page 10]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


                                                        **************

                Figure 2: Signaling Gateway Architecture

   The pair of SGs can either operate as replicated endpoints or as
   replicated relay points from the SS7 network point of view.

   Replicated endpoints : only for the first message in a transaction
   or connection one of the SGs is chosen, depending on the traffic
   mode (primary/backup or loadsharing) and overload conditions.  Once
   selected, the same SG is used for the subsequent messages.

   Replicated relay points : in normal circumstances, the path from SEP
   to ASP will always go via the same SG when in-sequence-delivery is
   requested.  However, linkset failures may cause MTP to re-route to
   the other SG.

1.3.6 ASP Fail-over Model and Terminology

   The SUA protocol supports ASP fail-over functions in order to
   support a high availability of transaction processing capability.

   An Application Server can be considered as a list of all ASPs
   configured/registered to handle SCCP-user messages within a certain
   range of routing information, known as a Routing Key.  One or more
   ASPs in the list may normally be active to handle traffic, while
   others may be inactive but available in the event of failure or
   unavailability of the active ASP(s).

1.4 Services Provided by the SUA Layer

1.4.1 Support for the transport of SCCP-User Messages

   The SUA needs to support the transfer of SCCP-user messages. The SUA
   layer at the SG needs to seamlessly transport the user messages.

1.4.2 SCCP Protocol Class Support

   Depending upon the SCCP-users supported, the SUA shall support the 4
   possible SCCP protocol classes transparently.  The SCCP protocol
   classes are defined as follows:

   * Protocol class 0 provides unordered transfer of SCCP-user
     messages in a connectionless manner.

   * Protocol class 1 allows the SCCP-user to select the in-sequence
     delivery of SCCP-user messages in a connectionless manner.

   * Protocol class 2 allows the bi-directional transfer of SCCP-user
     messages by setting up a temporary or permanent signaling
     connection.

Loughney, et al.                                            [Page 11]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



   * Protocol class 3 allows the features of protocol class 2 with
     the inclusion of flow control.  Detection of message loss or
     mis-sequencing is included.

   Protocol classes 0 and 1 make up the SCCP connectionless service.
   Protocol classes 2 and 3 make up the SCCP connection-oriented
   service.

1.4.3 Native Management Functions

   The SUA layer may provide management of the underlying SCTP layer to
   ensure that transport is available according to the degree specified
   by the SCCP-user application.

   The SUA layer provides the capability to indicate errors associated
   with the SUA-protocol messages and to provide notification to local
   management and the remote peer as is necessary.

1.4.4 Interworking with SCCP Network Management Functions

   The SUA layer needs to support the following SCCP network management
   primitives (a reference to ITU and ANSI sections where these
   primitives and corresponding parameters are described, is also
   given):

   Generic   |Specific   |
   Name      |Name       |ANSI/ITU Reference
   ----------+-----------+---------------------------------------------
   N-Coord   |Request    |ITU-Q.711   Chap 6.3.2.3.1 (Tab 13/Q.711)
             |Indication |ANSI-T1.112 Chap 2.3.2.3.1 (Tab 8D/T1.112.1)
             |Response   |
             |Confirm    |
   ----------+-----------+---------------------------------------------
   N-State   |Request    |ITU-Q.711   Chap 6.3.2.3.2 (Tab 14/Q.711)
             |Indication |ANSI-T1.112 Chap 2.3.2.3.2 (Tab 8E/T1.112.1)
   ----------+-----------+---------------------------------------------
   N-Pcstate |Indication |ITU-Q.711   Chap 6.3.2.3.3 (Tab 15/Q.711)
             |           |ANSI-T1.112 Chap 2.3.2.3.4 (Tab 8G/T1.112.1)

1.4.5 Support for the management between the SG and ASP.

   The SUA layer should provide interworking with SCCP management
   functions at the SG for seamless inter-operation between the SCN
   network and the IP network.  It should:

     *    Provide an indication to the SCCP-user at an ASP
          that a remote SS7 endpoint/peer is unreachable.
     *    Provide an indication to the SCCP-user at an ASP
          that a remote SS7 endpoint/peer is reachable.
     *    Provide congestion indication to SCCP-user at an ASP.

Loughney, et al.                                            [Page 12]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


     *    Provide the initiation of an audit of remote SS7
          endpoints at the SG.

1.4.6 Relay function

   An SCTP association exists between two SUA endpoints. For network
   scalability purposes, the SUA may be enhanced with a relay
   functionality to determine the next hop SCTP association towards the
   destination SUA endpoint.

   The determination of the next hop may be based on Global Title
   information (e.g. E.164 number), in analogy with SCCP GTT in SS7
   networks, modelled in [ITU-T Q.714]. It may also be based on
   Hostname information.

   The relay function is invoked when :

   - routing is on Global Title,
   - routing is on Hostname.

   Translation/resolution of the above address information must yield
   either of the following :

   - Route on SSN : SCTP association ID towards the destination node +
     SSN + Network Appearance (optional)
   - Route on GT : SCTP association ID towards next relay node + (new)
     GT + SSN (optional) + Network Appearance (optional)
   - Routing on Hostname : SCTP association ID towards next relay node
     + (new) Hostname + SSN (optional) + Network Appearance (optional)
   - A local SUA-user (combined relay/end node)

   To prevent endless hopping, the hop counter is used. The originating
   end node (be it an SS7 or an IP node) sets the value of the hop
   counter to the maximum value (15). Each time the relay function is
   invoked within an intermediate (relay) node, the hop counter must be
   decremented. When the value reaches zero, and the translation result
   is still _Route on GT_ or _Route on Hostname_, the return or refusal
   procedures are invoked with reason _Hop counter violation_.

1.5 Internal Functions Provided in the SUA Layer

1.5.1 Address Translation and Mapping at the SG

   The SG MUST provide address translation and mapping functions to
   direct messages received from the SS7 network to the appropriate IP
   destination.

   In order to support message distribution, the SG maintains an
   address translation table, which maps the incoming SS7 messages to
   the appropriate AS.  The relevant fields of the incoming SS7 message
   is compared to the existing Routing Keys.  The Routing Keys

Loughney, et al.                                            [Page 13]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   reference an Application Server, which will have one or more ASPs
   processing traffic for the AS.  The availability and status of the
   ASPs is handled by SUA ASP management messages.

   Possible SS7 address/routing information that comprise
   a Routing Key entry includes, for example, OPC, DPC, SIO found in
   the MTP3 routing label, or other specific fields such as the
   SCCP subsystem number, or TCAP transaction ID. Some possibilities
   include:

     Global Title (+ SSN optionally)
     PC (+ SSN optionally)
     Host Name (+ SSN optionally)
     IP Address(es) (+ SSN optionally)

   An Application Server maintains a list of ASPs that are available to
   process the traffic.  The list is dynamic, based upon the
   availability of the individual ASPs in the list.  SUA ASP management
   messages are used to convey the status of these ASPs and their
   availability in failover situations.

   Normally, one or more ASPs is active in the ASP (i.e., currently
   processing traffic) but in certain failure and transition cases it
   is possible that there may not be an active ASP available.  Both
   load-sharing and backup scenarios are supported.

   If there is no Routing Key match for an incoming SS7 message, a
   default treatment MUST be specified.  Possible solutions are to
   provide a default Application Server to direct all unallocated
   traffic to a (set of) default ASP(s), or to drop the messages and
   provide a notification to management.  The treatment of unallocated
   traffic is implementation dependent.

1.5.2 Address Translation and Mapping at the ASP

   In order to direct messages to the SS7 network, the ASP must also
   perform an address translation and mapping function in order to
   choose the proper SG or SGP for a given message.  This is
   accomplished by observing the Destination Point Code and other
   elements of the outgoing message, SS7 network status, SG and SGP
   availability, and network appearance configuration tables.

   A remote Signaling Gateway may be composed of one or more SGPs that
   are capable of routing SS7 traffic.  As is the case with ASPs, a
   dynamic list of SGPs in an SG can be maintained, taking into account
   the availability status of the individual SGPs, configuration
   changes and fail-over mechanisms. There is, however, no SUA
   messaging to manage the status of an SGP. Whenever an SCTP
   association to an SGP exists, it is assumed to be available.  Also,
   every SGP of one SG communicating with one ASP regarding one AS
   provides identical SS7 connectivity to this ASP.

Loughney, et al.                                            [Page 14]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



1.5.3 SCTP Stream Mapping

   The SUA supports SCTP streams. The SG/AS needs to maintain a list of
   SCTP and SUA-users for mapping purposes.  SCCP-users requiring
   sequenced message transfer need to be sent over a stream supporting
   sequenced delivery.

   SUA MUST use stream 0 for SUA management messages. It is recommended
   that sequenced delivery be in order to preserve the order of
   management message delivery.

1.6 Definition of SUA Boundaries

1.6.1 Definition of the upper boundary

   The following primitives are supported between the SUA and an SCCP-
   user (a reference to ITU and ANSI sections where these primitives
   and corresponding parameters are described, is also given):

   Generic     |Specific  |
   Name        |Name      |ANSI/ITU Reference
   ------------+----------+-------------------------------------------
   N-Connect   |Request   |ITU-Q.711   Chap 6.1.1.2.2 (Tab 2/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.2 (Tab 2/T1.112.1)
               |Response  |
               |Confirm   |
   ------------+----------+-------------------------------------------
   N-Data      |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 3/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 3/T1.112.1)
   ------------+----------+-------------------------------------------
   N-Expedited |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 4/Q.711)
   Data        |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 4/T1.112.1)
   ------------+----------+-------------------------------------------
   N-Reset     |Request   |ITU-Q.711   Chap 6.1.1.2.3 (Tab 5/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 5/T1.112.1)
               |Response  |
               |Confirm   |
   ------------+----------+-------------------------------------------
   N-Disconnect|Request   |ITU-Q.711   Chap 6.1.1.2.4 (Tab 6/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.4 (Tab 6/T1.112.1)
   ------------+----------+-------------------------------------------
   N-Inform    |Request   |ITU-Q.711   Chap 6.1.1.3.1 (Tab 7/Q.711)
               |Indication|ANSI-T1.112 Chap 2.1.1.2.5 (Tab 6A/T1.112.1)
   ------------+----------+-------------------------------------------
   N-Unit Data |Request   |ITU-Q.711   Chap 6.2.2.3.1 (Tab 10/Q.711)
               |Indication|ANSI-T1.112 Chap 2.2.2.3.1 (Tab 8A/T1.112.1)
   ------------+----------+-------------------------------------------
   N-Notice    |Indication|ITU-Q.711   Chap 6.2.2.3.2 (Tab 11/Q.711)
               |          |ANSI-T1.112 Chap 2.2.2.3.2 (Tab 8B/T1.112.1)


Loughney, et al.                                            [Page 15]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


1.6.2 Definition of the lower boundary

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

2 Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   [RFC2119].

3 Protocol Elements

   The general message format includes a Common Message Header together
   with a list of 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.

3.1 Common Message Header

   The protocol messages for the SCCP-User Adaptation Protocol requires
   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    |   Reserved    | Message Class | Message Type  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Message Length                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           msg data                            |

   Note that the 'data' portion of SUA messages SHALL contain SCCP-User
   data, not the encapsulated SCCP message.

   Optional parameters can only occur at most once in an SUA message.

3.1.1 SUA Protocol Version

   The version field (ver) contains the version of the SUA adaptation
   layer.  The supported versions are:

         01   SUA version 1.0

3.1.2 Message Classes


Loughney, et al.                                            [Page 16]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   Message Classes

     0         Management (MGMT) Message
     1         Reserved
     2         SS7 Signaling Network Management (SSNM) Messages
     3         ASP State Maintenance (ASPSM) Messages
     4         ASP Traffic Maintenance (ASPTM) Messages
     5         Reserved
     6         Reserved
     7         Connectionless Messages
     8         Connection-Oriented Messages
     9 - 127   Reserved by the IETF
     128 - 255 Reserved for IETF-Defined Message Class Extensions

3.1.3 Message Types

   SUA Management Messages

     0         Error (ERR)
     1         Notify (NTFY)
     2 - 127   Reserved by the IETF
     128- 255  Reserved for IETF-Defined Message Class Extensions

   SS7 Signaling Network Management (SSNM) Messages

     0         Reserved
     1         Destination Unavailable (DUNA)
     2         Destination Available (DAVA)
     3         Destination State Audit (DAUD)
     4         SS7 Network Congestion (SCON)
     5         Destination User Part Unavailable (DUPU)
     6         SCCP Management (SCMG)
     7 - 127   Reserved by the IETF
     128 - 255 Reserved for IETF-Defined Message Class Extensions

   Application Server Process Maintenance (ASPM) Messages

     0         Reserved
     1         ASP Up (UP)
     2         ASP Down (DOWN)
     3         Heartbeat (BEAT)
     4         ASP Up Ack (UP ACK)
     5         ASP Down Ack (Down ACK)
     6         Heartbeat Ack (BEAT ACK)
     7 - 127   Reserved by the IETF
     128 - 255 Reserved for IETF-Defined Message Class Extensions

   ASP Traffic Maintenance (ASPTM) Messages

     0         Reserved
     1         ASP Active (ACTIVE)

Loughney, et al.                                            [Page 17]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


     2         ASP Inactive (INACTIVE)
     3         ASP Active Ack (ACTIVE ACK)
     4         ASP Inactive Ack (INACTIVE ACK)
     5 - 127   Reserved by the IETF
     128 - 255 Reserved for IETF-Defined Message Class Extensions

   Connectionless Messages

     0         Reserved
     1         Connectionless Data Transfer (CLDT)
     2         Connectionless Data Response (CLDR)
     3 - 127   Reserved by the IETF
     128 - 255 Reserved for IETF-Defined Message Class Extensions

   Connection-Oriented Messages

     0         Reserved
     1         Connection Request (CORE)
     2         Connection Acknowledge (COAK)
     3         Connection Refused (COREF)
     4         Release Request (RELRE)
     5         Release Complete (RELCO)
     6         Reset Confirm (RESCO)
     7         Reset Request (RESRE)
     8         Connection Oriented Data Transfer (CODT)
     9         Connection Oriented Data Acknowledge (CODA)
     10        Connection Oriented Error (COERR)
     11        Inactivity Test (COIT)
     12 - 127  Reserved by the IETF
     128 - 255 Reserved for IETF-Defined Message Class Extensions

3.1.4 Message Length

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

3.1.5 Tag-Length-Value Format

   SUA messages consist of a Common Header followed by zero or more
   parameters, as defined by the message type.  The Tag-Length-Value
   (TLV)  parameters contained in a message are defined in a Tag-
   Length-Value format as shown below.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Parameter Tag        |       Parameter Length        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /                       Parameter Value                         /
     \                                                               \

Loughney, et al.                                            [Page 18]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


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

   Parameter Tag: 16 bits (unsigned integer)

      Tag field is a 16-bit identifier of the type of parameter. It
      takes a value of 0 to 65534.

   Parameter Length: 16 bits (unsigned integer)

      The Parameter Length field contains the size of the parameter in
      bytes, including the Parameter Tag, Parameter Length, and
      Parameter Value fields. The Parameter Length does not include any
      padding bytes.

   Parameter Value: variable-length.

      The Parameter Value field contains the actual information to be
      transferred in the parameter.

      The total length of a parameter (including Tag, Parameter Length
      and Value fields) MUST be a multiple of 4 bytes. If the length of
      the parameter is not a multiple of 4 bytes, the sender pads the
      Parameter at the end (i.e., after the Parameter Value field) with
      all zero bytes. The length of the padding is NOT included in the
      parameter length field. A sender should NEVER pad with more than
      3 bytes. The receiver MUST ignore the padding bytes.

   Implementation note : the use of TLV in principle allows the
   parameters to be placed in a random order in the message. However,
   some guidelines should be considered for easy processing in the
   following order :

   - parameters needed to correctly process other message parameters,
     preferably should precede these parameters (such as Network
     Appearance), mandatory parameters preferably should precede any
     optional parameters,
   - the data parameter will normally be the final one in the message.

3.2 SUA Connectionless Messages

   The following section describes the SUA Connectionless 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.

3.2.1 Connectionless Data Transfer (CLDT)

   This message transfers data between one SUA to another.

       0                   1                   2                   3

Loughney, et al.                                            [Page 19]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


       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 = 0x0001          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Network Appearance                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0101          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0102          |      Parameter Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                        Source Address                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0103          |      Parameter Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Destination Address                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0003          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             Data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Parameters
     Network Appearance            Optional
     Flags                         Mandatory
     Source Address                Mandatory
     Destination Address           Mandatory
     Data                          Mandatory

   Implementation Note:

   This message covers the following SCCP messages: unitdata (UDT),
   extended unitdata (XUDT), long unitdata (LUDT).

3.2.2 Connectionless Data Response (CLDR)

   This message is used as a response message by the peer to report
   errors in the received CLDT message, when the return on error option
   is set.

       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 = 0x0001          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Network Appearance                     |

Loughney, et al.                                            [Page 20]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0101          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0106          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           SCCP Cause                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0102          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                        Source Address                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0103          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Destination Address                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0003          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             Data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Network Appearance            Optional
     Flags                         Mandatory
     SCCP Cause                    Mandatory
     Source Address                Mandatory
     Destination Address           Mandatory
     Data                          Optional

   Implementation note:

   This message covers the following SCCP messages: unitdata service
   (UDTS), extended unitdata service (XUDTS) and long unitdata service
   (LUDTS).

3.3 Connection Oriented Messages

3.3.1 Connection Oriented Data Transfer (CODT)

   This message transfers data between one SUA to another for
   connection oriented service.

       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 = 0x0107          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Loughney, et al.                                            [Page 21]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


      |                        Sequence number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0105          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Reference Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0003          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             Data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Sequence number               Mandatory *1
     Destination Reference Number  Mandatory
     Data                          Mandatory

   NOTE *1:    Mandatory when CODT message maps a DT2 message.
               Otherwise, the parameter is not be present.

   Implementation note:

   This message covers the following SCCP messages: data form 1 (DT1),
   data form 2 (DT2), expedited data (ED).

3.3.2 Connection Oriented Data Acknowledge (CODA)

   This message is used to acknowledge receipt of data by the peer.
   This message is used only with protocol class 3.

       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 = 0x0001          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Network Appearance                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0105          |              Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Reference Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0108          |              Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Receive Sequence Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x010A          |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Credit                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters

Loughney, et al.                                            [Page 22]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


     Network Appearance            Optional
     Destination Reference Number  Mandatory
     Receive Sequence number       Mandatory *1
     Credit                        Mandatory *1

   NOTE *1:    Mandatory when representing Data Acknowledgement (AK).

   Implementation note:

   This message covers the following SCCP messages: Data
   Acknowledgement (AK), Expedited Data Acknowledgement (EA).

3.3.3 Connection Request (CORE)

   This message is used for establishing a signaling connection between
   two peer endpoints.  This is used for connection oriented service.

        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 = 0x0001          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Network Appearance                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0101          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0104          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Source Reference Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0103          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Destination Address                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0102          |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                        Source Address                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x010A          |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Credit                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0003          |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             Data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Loughney, et al.                                            [Page 23]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



   Parameters
     Flags                         Mandatory
     Source Reference Number       Mandatory
     Destination Address           Mandatory
     Source Address                Optional
     Credit                        Optional
     Data                          Optional

3.3.4 Connection Acknowledge (COAK)

   This message is used to acknowledge a connection request between two
   peer endpoints.

       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 = 0x0101          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0105          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Reference Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0104          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Source Reference Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x010A          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Credit                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0103          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Destination Address                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0003          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             Data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Flags                         Mandatory
     Destination Reference Number  Mandatory
     Source Reference Number       Mandatory
     Credit                        Optional *2
     Destination Address           Optional *1
     Data                          Optional

Loughney, et al.                                            [Page 24]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



   NOTE *1:    Destination Address parameter will be present in case
               that the received CORE message conveys the Source
               Address parameter.
   Note *2:    Used for protocol class 3.

   Implementation note:

   This message covers the following SCCP message: Connection Confirm
   (CC).

3.3.5 Connection Refused (COREF)

   This message is used to refuse a connection request between two peer
   endpoints.

       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 = 0x0001          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Network Appearance                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0105          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Reference Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0106          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           SCCP Cause                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0103          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Destination Address                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0001          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             Data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
        Destination Reference Number    Mandatory
        SCCP Cause                      Mandatory
        Destination Address             Optional *1
        Data                            Optional

   Note *1:    Destination Address parameter will be present in case
               that the received CORE message conveys the Source
               Address parameter.

Loughney, et al.                                            [Page 25]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



3.3.6 Release Request (RELRE)

   This message is used to request a signaling connection between two
   peer endpoints be released.  All associated resources can then be
   released.

       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 = 0x0105          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Reference Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0104          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Source Reference Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0106          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          SCCP Cause                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0101          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0003          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             Data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Destination Reference Number  Mandatory
     Source Reference Number       Mandatory
     SCCP Cause                    Mandatory
     Flags                         Optional
     Data                          Optional

   Implementation Note:

   This message covers the following SCCP message: Connection Refused
   (RLSD).

3.3.7 Release Complete (RELCO)

   This message is used to acknowledge the release of a signaling
   connection between two peer endpoints.  All associated resources
   should be released.

       0                   1                   2                   3

Loughney, et al.                                            [Page 26]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


       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 = 0x0105          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Reference Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0104          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Source Reference Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Destination Reference Number  Mandatory
     Source Reference Number       Mandatory

   Implementation Note:

   This message covers the following SCCP message: Release Complete
   (RLC).

3.3.8 Reset Request (RESRE)

   This message is used to indicate that the sending SCCP/SUA wants to
   initiate a reset procedure (re-initialization of sequence numbers)
   the peer endpoint.

       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 = 0x0105          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Reference Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0104          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Source Reference Number                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0106          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           SCCP Cause                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Destination Reference Number  Mandatory
     Source Reference Number       Mandatory
     SCCP Cause                    Mandatory

   Implementation note:

   This message covers the following SCCP message: reset request (RSR).


Loughney, et al.                                            [Page 27]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


3.3.9 Reset Confirm (RESCO)

   This message is used to confirm the Reset Request.

       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 = 0x0105          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Reference Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0104          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Source Reference Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Destination Reference Number  Mandatory
     Source Reference Number       Mandatory

   Implementation note:

   This message covers the following SCCP message: Reset Confirmation
   (RSC).

3.3.10 Connection Oriented Error (COERR)

   The COERR message is sent to indicate a protocol data unit error.

       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 = 0x0105          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Reference Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0106          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          SCCP Cause                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Destination Reference Number  Mandatory
     SCCP Cause                    Mandatory

   Implementation Note:

   This message covers the following SCCP message: Protocol Data Unit
   Error (ERR)



Loughney, et al.                                            [Page 28]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


3.3.11 Connection Oriented Inactivity Test (COIT)

   This message is used for auditing the signaling connection state and
   the consistency of connection data at both ends of the signaling
   connection.

       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 = 0x0101          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0104          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Source Reference Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0105          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Reference number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0107          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x010A          |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Credit                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Flags                         Mandatory
     Source Reference Number       Mandatory
     Destination Reference number  Mandatory
     Sequence number               Mandatory *1
     Credit                        Mandatory *1

   NOTE *1:    Information in these parameter fields reflect those
               values sent in the last data form 2 or data
               acknowledgement message. They are ignored if the
               protocol class indicates class 2.

   Implementation note:

   This message covers the following SCCP message: Inactivity Test
   (IT).

3.4 SS7 Signaling Network Management Messages

3.4.1 Destination Unavailable (DUNA)


Loughney, et al.                                            [Page 29]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   In the scope of SUA, this message is covered by the PC state
   indication passed between SCCP and local SCCP-user. The DUNA message
   is sent from the SG to all concerned ASPs (servicing SCCP-users
   considered local to the SG, see chapter 1.3.1.1), when an SS7
   destination has become unreachable.  The SUA-User at the ASP is
   expected to stop traffic to the affected destination through the SG
   initiating the DUNA.

   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 = 0x0001          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Network Appearance                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0005          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Affected Point Code                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0004          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          Info String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Network Appearance            Optional
     Affected Point Code           Mandatory
     Info String                   Optional

3.4.2 Destination Available (DAVA)

   In the scope of SUA, this message is covered by the PC state
   indication passed between SCCP and local SCCP-user. The DAVA message
   is sent from the SG to all concerned ASPs (servicing SCCP-users
   considered local to the SG, see chapter 1.3.1.1) to indicate that an
   SS7 destination is now reachable. The ASP SUA-User protocol is
   expected to resume traffic to the affected destination through the
   SG initiating the DAVA.

       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 = 0x0001          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Network Appearance                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0005          |             Length            |

Loughney, et al.                                            [Page 30]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Affected Point Code                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0004          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          Info String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Network Appearance            Optional
     Affected Point Code           Mandatory
     Info String                   Optional

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

       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 = 0x0001          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Network Appearance                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0005          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Affected Point Code                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0004          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          Info String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Network Appearance            Optional
     Affected Point Code           Mandatory
     Info String                   Optional

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

Loughney, et al.                                            [Page 31]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



       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 = 0x0001          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Network Appearance                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0010          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Congestion Level                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x000E          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                          Affected PC                          \
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0004          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          info string                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Network Appearance            Optional
     Congestion Level              Mandatory
     Affected PC                   Mandatory
     Info String                   Optional

3.4.5 Destination User Part Unavailable (DUPU)

   The DUPU message is used in local broadcast procedures (SUA for SCCP
   - SCCP user interface). In remote broadcast procedures, use SCMG
   message formatID SSP (peer SUA message)


   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 = 0x0001          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Network Appearance                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0005          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Affected Point Code                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0009          |             Length            |

Loughney, et al.                                            [Page 32]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Cause/User                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0004          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          info string                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Network Appearance            Optional
     Affected Point Code           Mandatory Note *1
     Cause/User                    Mandatory
     Info String                   Optional

3.4.6 SCCP Management Message (SCMG)

   The SCMG message is sent between SUA Peers to indicate status of
   subsystems. Only one SCMG message type can be sent per message.

      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 = 0x0001          |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Network Appearance                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Tag = 0x010B       |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     SCMG Format Identifier                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Tag = 0x010C       |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         SMI/Subsystem                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Tag = 0x0005       |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                          Affected PC                          /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Tag = 0x000E       |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Congestion Level                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Tag = 0x0004       |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                          INFO String                          \
     \                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters

Loughney, et al.                                            [Page 33]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


     Network Appearance            Optional
     SCMG Format Identifier        Mandatory
     Subsystem/SMI                 Mandatory
     Affected Point Code           Mandatory *1
     Congestion Level              Mandatory *2
     Info String                   Optional

   Note *1:    In the SCMG message, the Affected Point Code Parameter
               MUST contain, at most, a single Affected Point Code.

   Note *2:    When the SCMG Message Type is SSC, then the Congestion
               Level parameter is Mandatory, otherwise it is not
               present.

3.5 Application Server Process Maintenance Messages

3.5.1 ASP Up (UP)

   The ASP UP (UP) message is used to indicate to a remote SUA peer
   that the Adaptation layer is up and running.

       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 = 0x0109       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        ASP Capabilities                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Tag = 0x0004       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          Info String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     ASP Capabilities              Optional
     Info String                   Optional

3.5.2 ASP Up Ack (UP ACK)

   The ASP UP Ack message is used to acknowledge an ASP-Up message
   received from a remote SUA peer.

       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 = 0x0109       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        ASP Capabilities                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Tag = 0x0004       |             Length            |

Loughney, et al.                                            [Page 34]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          Info String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     ASP Capabilities              Optional
     Info String                   Optional

3.5.3 ASP Down (DN)

   The ASP Down (DN) message is used to indicate to a remote SUA peer
   that the adaptation layer is not running.

       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 = 0x000A       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Reason                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Tag = 0x0004       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          Info String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Reason              Mandatory
     Info String         Optional

3.5.4 ASP Down Ack (DOWN ACK)

   The ASP DOWN Ack message is used to acknowledge an ASP-Down message
   received from a remote SUA peer.

       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 = 0x000A       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Reason                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Tag = 0x0004       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          Info String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Reason                        Mandatory

Loughney, et al.                                            [Page 35]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


     Info String                   Optional

3.5.5 Heartbeat (BEAT)

   The Heartbeat message is optionally used to ensure that the SUA
   peers are still available to each other.

   The format for the BEAT 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Tag = 0x0008       |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Heartbeat Data                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Heartbeat Data           Optional

3.5.6 Heartbeat Ack (BEAT ACK)

   The Heartbeat ACK message is sent in response to a BEAT message. A
   peer MUST send a BEAT ACK in response to a BEAT message. It includes
   all the parameters of the received Heartbeat message, without any
   change.

   The format for the BEAT ACK 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Tag = 0x0008       |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Heartbeat Data                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Heartbeat Data           Optional

3.6 ASP Traffic Maintenance Messages

3.6.1 ASP Active (ACTIVE)

   The ASPAC message is sent by an ASP to indicate to a remote SUA peer
   that it is Active and ready to process signaling traffic for a
   particular Application Server

   The format for the ACTIVE message is as follows:

Loughney, et al.                                            [Page 36]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



       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 = 0x000B         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Traffic Mode Type                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0006         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Routing Context                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0004         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          Info String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Traffic Mode Type        Mandatory
     Routing Context          Optional
     Info String              Optional

3.6.2 ASP Active Ack (ACTIVE ACK)

   The ASPAC Ack message is used to acknowledge an ASP-Active message
   received from a remote SUA peer.

   The format for the ACTIVE Ack 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x000B         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Traffic Mode Type                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0006         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Routing Context                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0004         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          Info String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
        Traffic Mode Type     Mandatory

Loughney, et al.                                            [Page 37]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


        Routing Context       Optional
        Info String           Optional

   The format of the Traffic Mode Type and Routing Context parameters
   is the same as for the ASP-Active message.

   The format and description of the optional Info String parameter is
   the same as for the ASP-Active message.

3.6.3  ASP Inactive (INACTIVE)

   The INACTIVE message is sent by an ASP to indicate to a remote SUA
   peer that it is no longer processing signaling traffic within a
   particular Application Server.

   The format for 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 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0006         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Routing Context                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0004         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          INFO String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Routing Context          Optional
     INFO String              Optional

3.6.4 ASP Inactive Ack (INACTIVE ACK)

   The INACTIVE Ack message is used to acknowledge an ASP-Inactive
   message received from a remote SUA peer.

   The format for the INACTIVE Ack 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0006         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Routing Context                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0004         |             Length            |

Loughney, et al.                                            [Page 38]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          INFO String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Routing Context     Optional
     INFO String         Optional

   The format of the Traffic Mode Type and Routing Context parameters
   is the same as for the ASP-Active message.

   The format and description of the optional Info String parameter is
   the same as for the ASP-Active message.

3.7 Management Messages

   These messages are used for managing SUA and the representations of
   the SCCP subsystems in the SUA layer.

3.7.1 Error (ERR)

   The ERR message is sent between two SUA peers to indicate an error
   situation.  The Data parameter is optional, possibly used for error
   logging and/or debugging.

       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 = 0x000C         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Error Code                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0007         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                        Diagnostic Info                        /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Error Code                    Mandatory
     Diagnostic Info               Optional

3.7.2 Notify (NTFY)

   The Notify message used to provide an autonomous indication of SUA
   events to an SUA peer.

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

Loughney, et al.                                            [Page 39]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


      |          Tag = 0x000D         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Status Type/ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0006         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Routing Context                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0004         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          Info String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The NTFY message contains the following parameters:

   Parameters
     Status Type/ID                Mandatory
     Routing Context               Optional
     Info String                   Optional

3.8 Common Parameters

   These TLV parameters are common across the different adaptation
   layers.

   Parameter Name                     Parameter ID
   ==============                     ============
   Network Appearance                   0x0001
   Not used in SUA                      0x0002
   Data                                 0x0003
   Info String                          0x0004
   Affected Point Code                  0x0005
   Routing Context                      0x0006
   Diagnostic Info                      0x0007
   Heartbeat Data                       0x0008
   Cause/User                           0x0009
   Reason                               0x000A
   Traffic Mode Type                    0x000B
   Not used                             0x000C
   Status Type                          0x000D
   Congestion Level                     0x000E

3.8.1 Network Appearance

   The Network Appearance parameter identifies the SS7 network context
   for the message, for the purposes of logically separating the
   signaling traffic between the SG and the Application Server Process
   over a common SCTP Association.  An example is where an SG is


Loughney, et al.                                            [Page 40]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   logically partitioned to appear as an element in several different
   national SS7 networks.

       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 = 0x0001         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        network appearance                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Network Appearance implicitly defines the SS7 Point Code format
   used, the SS7 Network Indicator value and SCCP protocol
   type/variant/version used within the SS7 network partition.  Where
   an SG operates in the context of a single SS7 network, or individual
   SCTP associations are dedicated to each SS7 network context, the
   Network Appearance parameter is not required.

   The Network Appearance parameter value is of local significance
   only, coordinated between the SG and ASP.

   Where the optional Network Appearance parameter is present, it must
   be the first parameter in the message as it defines the format of
   the Protocol Data field.

     3.8.2 Not used

     Parameter ID 0x02 is not used in SUA.

3.8.3 Data

       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 = 0x0003         |            length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Data parameter field contains the SS7 SCCP-User application
   message, for example an INAP/TCAP message.

3.8.4 Info String

   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
   for debugging purposes.


Loughney, et al.                                            [Page 41]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


       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 = 0x0004         |            length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          info string                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.8.5 Affected Point Code

   The Affected Point Code parameter contains one or more Affected
   Destination Point Codes, each a three-octet parameter to allow for
   4-, 16- and 24-bit binary formatted SS7 Point Codes.  Affected Point
   codes that are less than 24-bits, are padded on the left to the 24-
   bit boundary.

       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 = 0x0005         |            length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Mask       |                 Affected PC 1                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             . . .                             /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The encoding is shown below for ANSI and ITU Point Code examples.

   ANSI 24-bit Point Code:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Mask      |    Network    |    Cluster    |     Member    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      |MSB-----------------------------------------LSB|

   ITU 14-bit Point Code:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Mask      |0 0 0 0 0 0 0 0 0 0|Zone |     Region    | SP  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                           |MSB--------------------LSB|



Loughney, et al.                                            [Page 42]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   It is optional to send an Affected Pointe Code parameter with more
   than one Affected PC but it is mandatory to receive it.  All the
   Affected PCs included must be within the same Network Appearance.
   Including multiple Affected PCs may be useful when reception of an
   management message or a linkset event simultaneously affects the
   availability status of a list of destinations at an SG.

   Mask: 8-bits

   The Mask parameter can be used to identify a contiguous range of
   Affected Destination Point Codes, independent of the point code
   format.  Identifying a contiguous range of Affected PCs may be
   useful when reception of an MTP3 management message or a linkset
   event simultaneously affects the availability status of a series of
   destinations at an SG.

   The Mask parameter is an integer representing a bit mask that can be
   applied to the related Affected PC field.  The bit mask identifies
   how many bits of the Affected PC field is significant and which are
   effectively "wild-carded".  For example, a mask of "8" indicates
   that the last eight bits of the PC is "wild-carded".  For an ANSI
   24-bit Affected PC, this is equivalent to signaling that all PCs in
   an ANSI Cluster are unavailable.  A mask of "3" indicates that the
   last three bits of the PC is "wild-carded".  For a 14-bit ITU
   Affected PC, this is equivalent to signaling that an ITU Region is
   unavailable.

3.8.6 Routing Context

       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 = 0x0006         |            length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Routing Context                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Routing Context parameter contains (a list of) 4-byte unsigned
   integers indexing the Application Server traffic that the sending
   ASP is configured/registered to receive.  There is one-to-one
   relationship between an index entry and a SG Routing Key or AS Name.
   Since an AS can only appear in one Network Appearance, the Network
   Appearance parameter is not required in the ASP Active message.

   An Application Server Process may be configured to process traffic
   for more than one logical 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.



Loughney, et al.                                            [Page 43]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


3.8.7 Diagnostic Information

   The Diagnostic Information can be used to convey any information
   relevant to an error condition, to assist in the identification of
   the error condition.  In the case of an Invalid Network Appearance,
   Adaptation Layer Identifier or Traffic Handling Mode, the Diagnostic
   information includes the received parameter.  In the other cases,
   the Diagnostic information may be the first 40 bytes of the
   offending message.

       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 = 0x0007          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Diagnostic Information*                   /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.8.8 Heartbeat Data

   The Heartbeat Data field contents are defined by the sending node.
   It may include a Heartbeat Sequence Number and/or Timestamp, other
   implementation specific details.

   The receiver of a Heartbeat message does not process this field as
   it is only of significance to the sender.  The receiver echoes the
   content of the Heartbeat Data in a BEAT-Ack message.

       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 = 0x0008          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Heartbeat Data                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The data field can be used to store information in the heartbeat
   message useful to the sending node (e.g. the data field can contain
   a time stamp, a sequence number, etc.).

3.8.9 Cause/User

       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 = 0x0009          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Cause              |             User              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Loughney, et al.                                            [Page 44]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



   Unavailability Cause field: 16-bits (unsigned integer)

   The Unavailability Cause parameter provides the reason for the
   unavailability of the SUA-User.  The valid values for the
   Unavailability Cause parameter are shown in the following table.

            0         Unknown
            1         Unequipped Remote User
            2         Inaccessible Remote User

   User Identity field: 16-bits (unsigned integer)

   The User Identity describes the specific SUA-User that is
   unavailable.  Some of the valid values for the User Identity are
   shown below.

          0 - 2          Reserved by M3UA
          3              SCCP/SUA
          4 - 10         Reserved by M3UA

3.8.10 Reason

   The Reason parameter indicates the reason that the remote SUA
   adaptation layer is unavailable.

       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 = 0x0009          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Cause              |             User              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reason: 32-bit (unsigned integer)

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

          0         Unspecified
          1         User Unavailable
          2         Management Blocking
          3         ASP Fault

3.8.11 Traffic Mode Type

   The Traffic Mode Type parameter identifies the traffic mode of
   operation of the ASP within an AS.

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

Loughney, et al.                                            [Page 45]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


      |          Tag = 0x000B         |             length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Traffic Mode Type                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

               1         Over-ride
               2         Load-share
               3         Over-ride (Standby)
               4         Loadshare (Standby)

   Within a Routing Context, Over-ride and Loadshare Types cannot be
   mixed.  The Over-ride value indicates that the ASP is operating in
   Over-ride mode, and the ASP wishes to take over all traffic for an
   Application Server (i.e., primary/back-up operation), over-riding
   any currently active ASP in the AS.  In Load-share mode, the ASP
   wishes to share in the traffic distribution with any other currently
   active ASPs.  The Standby versions of the Over-ride and Loadshare
   Types indicate that the ASP is declaring itself ready to accept
   traffic but leaves it up to the sender as to when the traffic is
   started. Over-ride (Standby) indicates that the traffic sender
   continues to use the currently active ASP until it can no longer
   send/receive traffic (i.e., the currently active ASP transitions to
   Down or Inactive).  At this point the sender may immediately move
   the ASP to Active and commence traffic.  Loadshare (Standby) is
   similar - the sender continues to loadshare to the current ASPs
   until there it is determined that there is insufficient resources in
   the Loadshare group.  When there is insufficient ASPs, the sender
   may immediately move the ASP to Active.

3.8.12 Error Code

       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 =0x000C            |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Error Code                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Error Code parameter indicates the reason for the Error Message.
   The Error parameter value can be one of the following values:

        Invalid Version                                0x01
        Invalid Network Appearance                     0x02
        Unexpected Message Class                       0x03
        Invalid Message Type                           0x04
        Unsupported Traffic Handling Mode              0x05
        Unexpected Message                             0x06
        Protocol Error                                 0x07

Loughney, et al.                                            [Page 46]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


        Invalid Routing Context                        0x08
        Invalid Stream Identifier                      0x09
        Parameter Field Error                          0x0B
        Unexpected Parameter                           0x0C
        Duplicated Parameter                           0x0D

   The "Invalid Version" error would be sent if a message was received
   with an invalid or unsupported version.  The Error message would
   contain the supported version in the Common header.  The Error
   message could optionally provide the supported version in the
   Diagnostic Information area.

   The "Invalid Network Appearance" error would be sent by a SG if an
   ASP sends a message with an invalid (unconfigured) Network
   Appearance value.

   The "Unsupported Traffic Handling Mode" error would be sent by a SG
   if an ASP sends an ASP Active with an unsupported Traffic Handling
   Mode.  An example would be a case in which the SG did not support
   load-sharing.

   The "Unexpected Message" error would be sent by an ASP if it
   received a message while it was in the Inactive state.

   The "Protocol Error" error would be sent for any protocol anomaly
   (i.e. a bogus message).

   The "Invalid Routing Context" error would be sent by a SG if the
   routing context cannot be supported, e.g. not unique.

   The "Invalid Stream Identifier" error would be sent if a message
   was received on an unexpected SCTP stream (i.e.  a stream that did
   not have an Interface Identifier associated with it).

   The "Unexpected Message Class" error would be sent if a message with
   an unexpected or unsupported Message Class is received.

   The "Parameter Field Error" would be sent if a message with a
   parameter having a wrong length field.

   The "Unexpected Parameter" error would be sent if a message contains
   an invalid parameter.

   The "Duplicated Parameter" error would be sent if a message contains
   a parameter more than once.

   The Cause parameter can be one of the following values:

          Invalid Version                         0x1
          Invalid Network Appearance              0x2
          Invalid Adaptation Layer Identifier     0x3

Loughney, et al.                                            [Page 47]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


          Invalid Message Type                    0x4
          Invalid Traffic Handling Mode           0x5
          Unexpected Message Type                 0x6
          Protocol Error                          0x7
          Invalid Routing Context                 0x8
          Unsupported Message Type                0x9

3.8.13 Status Type

   The Status Type parameter identifies the type of the status that is
   being notified.

       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 = 0x000D         |             length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Status Type           |            Status ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The valid values for Status Type (16 bit unsigned integer) are:

          1     Application Server state change (AS_State_Change)
          2     Other

   The Status ID parameter contains more detailed information    for
   the notification, based on the value of the Status Type.

   If the Status Type is AS_STATE_CHANGE, then the Status ID (16 bit
   unsigned integer) values are:

          1    reserved
          2    Application Server Inactive (AS-Inactive)
          3    Application Server Active (AS-Active)
          4    Application Server Pending (AS-Pending)

   These notifications are sent from an SG to an ASP upon a change in
   status of a particular Application Server. The value reflects the
   new state of the Application Server.

   If the Status Type is Other, then the following Status Information
   values are defined:

             1    Insufficient ASP resources active in AS
             2    Alternate ASP Active

   These notifications are not based on the SG reporting the state
   change of an ASP or AS.  In the Insufficient ASP Resources case, the
   SG is indicating to an "Inactive" ASP(s) in the AS that another ASP
   is required in order to handle the load of the AS (Load-sharing
   mode).  For the Alternate ASP Active case, an ASP is informed when

Loughney, et al.                                            [Page 48]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   an alternate ASP transitions to the ASP-Active state in Over-ride
   mode.

3.8.14 Congestion Level

       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 = 0x000E          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Congestion Level                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Congestion Level field: 8-bits (unsigned integer)

   The Congestion Level will have two different meanings, depending
   upon the message it is received with.

   For the SCON message, the Congestion Level field, contains one of
   the following values, which are associated with a destination point
   code:

            0     No Congestion or Undefined
            1     Congestion Level 1
            2     Congestion Level 2
            3     Congestion Level 3

   The congestion levels are as defined in the national congestion
   method in the appropriate MTP recommendation [ITU-MTP], [ANSI-MTP].
   For MTP  congestion methods that do not employ congestion levels
   (e.g., the ITU international method, the parameter is always
   "Undefined"). When an SCON is received at the SG, a TFC message is
   generated into the SS7 network.

   For the SCMG message, the valid values for the Congestion Level
   parameter range from 0 to 7, where 0 indicates least congested and 7
   indicates most congested.

3.9 SUA-Specific parameters

   These TLV parameters are specific to the SUA protocol.

   Parameter Name                     Parameter ID
   ==============                     ============
   Flags                                0x0101
   Source Address                       0x0102
   Destination Address                  0x0103
   Source Reference Number              0x0104
   Destination Reference Number         0x0105
   SCCP Cause                           0x0106
   Sequence Number                      0x0107

Loughney, et al.                                            [Page 49]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   Receive Sequence Number              0x0108
   ASP Capabilities                     0x0109
   Credit                               0x010A
   SCMG Format Identifier               0x010B
   SMI / Subsystem                      0x010C

   Destination/Souce Address Sub Parameters
   ========================================
   Global Title                         0x0801
   Point Code                           0x0802
   Subsystem Number                     0x0803
   IPv4 Address                         0x0804
   Hostname                             0x0805
   IPv6 Addresses                       0x0806

3.9.1  Flags

   The Flags parameter is a conglomerate of following parameters,
   described in ITU-T Recommendation Q.713 :


      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 = 0x0101          |             Length (= 4)      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    spare      |  Importance   |  Hop Counter  |  Protocol Cl. |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   - Protocol class (3.6/Q.713)

          Bits 1-2 indicate the protocol class
          Value      Description
          0x0        Class 0 (connectionless service)
          0x1        Class 1 (connectionless service)
          0x2        Class 2 (connection-oriented service)
          0x3        Class 3 (connection-oriented service)

          Bit 8 indicates the use of the return on error procedure
          Value      Description
          0x0        No special options
          0x1        Return message on error

          Bits 3-7 are spare and should be coded zero.

   - Hop Counter (3.18/Q.713)

   The value of the hop counter is decremented with each global title
   translation, and should be in the range 15 to 1.

   - Importance (3.19/Q.713)

Loughney, et al.                                            [Page 50]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



   Bits 1-3 are coded to indicate the importance of the messages. The
   values are between 0 and 7, where the value of 0 indicates the least
   important and 7 indicates the most important.
   Bits 4-8 are spare bits.

3.9.2 Source Address

       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 = 0x0102         |      Parameter Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Routing Indicator        |       Address Indicator       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Address parameter(s)                    /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Source Address field may contain the SCCP Calling Party Address.
   See chapters 3.4 and 3.5 of ITU-T Recommendation Q.713.

   The following combinations of address parameters are valid :

   - Global Title (e.g. E.164 number) + optional PC and/or SSN, SSN may
     be zero, when routing is done on Global Title
   - PC and SSN (non-zero) + optional Global Title, when routing is
     done on PC + SSN
   - Hostname + optional SSN, when routing is done by Hostname
   - IPv4 or IPv6 address + optional SSN, when routing is done by IP
     address

3.9.2.1 Routing Indicator

   The following values are valid for the routing indicator :

     Reserved                      0
     Route on Global Title         1
   2 Route on SSN + PC             2
     Route on SSN + IP Address     3
     Route on Hostname             43

   The routing indicator determines which address parameters need to be
   present in the address parameters field.

3.9.2.2 Address Indicator

   This parameter is needed for interworking with SS7 networks. The
   address indicator specifies what address parameters are actually
   received in the SCCP address from the SS7 network, or are to be


Loughney, et al.                                            [Page 51]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   populated in the SCCP address when the message is sent into the SS7
   network. The value of the routing indicator needs to be taken into
   account.

   The address indicator is coded as follows:

     Bit 1 is used to indicate inclusion of the SSN

     0         do not include SSN when optional (routing indicator /= 2)
     1         include SSN

     Bit 2 is used to indicate inclusion of the PC

     0         do not include PC, regardless of the routing indicator
               value
     1         include PC

     Bit 3 is used to indicate inclusion of the Global Title

     0         do not include GT when optional (routing indicator /= 1)
     1         include GT


   In the next chapters, the layout of the address parameters is given.
   The following tags are used to identify the address parameters:

     0x00           Reserved
     0x01           Global Title
     0x02           Point Code
     0x03           Subsystem Number
     0x04           IPv4
     0x05           Hostname
     0x06           IPv6

3.9.2.3 Global Title

     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 = 0x0801          |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     spare     | Trans. type   |E|  Num. Plan  | Nature of Add |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Global Title Digits                   |
     /                                                               /
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Translation type:



Loughney, et al.                                            [Page 52]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   0               Unknown
   1 - 63          international services
   64 - 127        spare
   128 - 254       national network specific
   255             reserved

   Odd/even Indicator:

     0         Even number of address signals
     1         Odd number of address signals

   Numbering Plan:

     0         unknown
     1         ISDN/telephony numbering plan (Recommendations E.163 and
               E.164)
     2         generic numbering plan
     3         data numbering plan (Recommendation X.121)
     4         telex numbering plan (Recommendation F.69)
     5         maritime mobile numbering plan (Recommendations E.210,
               E.211)
     6         land mobile numbering plan (Recommendation E.212)
     7         ISDN/mobile numbering plan (Recommendation E.214)
     8 - 13    spare
     14        private network or network-specific numbering plan
     15 - 126  spare
     127       reserved.

   Nature of Address:

     0         unknown
     1         subscriber number
     2         reserved for national use
     3         national significant number
     4         international number
     5 - 255   Spare

   Global Title:

   Octets contain a number of address signals and possibly a filler as
   shown:











Loughney, et al.                                            [Page 53]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


           0   1   2   3   4   5   6   7
         +---+---+---+---+---+---+---+---+
         | 2nd addr.sig. | 1st addr.sig. |
         +---+---+---+---+---+---+---+---+
         | 4th addr.sig. | 3rd addr.sig. |
         +---+---+---+---+---+---+---+---+
         |              ...              |
         +---+---+---+---+---+---+---+---+
         | filler(if req)| nth addr.sig. |
         +---+---+---+---+---+---+---+---+

   Address signals to be coded as defined in ITU-T Q.713 Section
   3.4.2.3.1.

   The actual Global Title format to be used for interworking with the
   SS7 network is defined by the network appearance, or is implicitly
   understood if the SG only operates in one SS7 network partition.
   The formats are defined in chapter 3.4.2.3 of Q.713. The following
   conversions of the Translation Type, Numbering Plan Odd/Even
   indicator and Nature of Address elements apply :

   1) SS7 network uses GTI = 0001

   Odd/Even indicator and Nature of Address are taken over. It is
   implicitly assumed that Translation Type = Unknown and Numbering
   Plan = E.164 (value 1).

   2) SS7 network uses GTI = 0010

   This is most commonly used in North American networks. The
   Translation Type implicitly determines Nature of Address and
   Numbering Plan. This data can be configured in the SG.

   3) SS7 network uses GTI = 0011

   Odd/Even indicator, Numbering Plan and Translation Type are taken
   over. It is implicitly assumed that the Nature of Address = Unknown.

   4) SS7 network uses GTI = 0100

   This format is used in international networks and most commonly in
   networks outside North America. All information is present in the
   SS7 SCCP Global Title as well.









Loughney, et al.                                            [Page 54]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


3.9.2.4 Point Code

     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 = 0x0802          |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Point Code                         |
     /                                                               /
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   See chapter 3.2.5 Affected Point Code for the layout of the Point
   Code field.


3.9.2.5 Subsystem Number

     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 = 0x0803          |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            SSN value                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The internationally standardized SSN values are described in chapter
   3.4.2.2 of Q.713.



3.9.2.6 IP Addresses

   The IP address formats can use different tags. It should be noted
   that if the source address is in a certain IP version, the
   destination address should also be in the same IP version.

     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 = 0x10040x0804/0x1006   0x0806   |            Length
   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        IPv4 or IPv6 Address                   |
     /                                                               /
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Loughney, et al.                                            [Page 55]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


3.9.2.7 Hostname

     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 = 0x0805          |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Host Name                          |
     /                                                               /
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If the type of address is Host Name, then the labels in the host
   name have to be reversed to obtain an efficient Host Name encoding
   form for the Global title translation function.

   hostname: zzzz.yyy....edc.ab
   should be transformed to
   HTname : ab.edc....yyy.zzzz

   The labels of the Host Name are then encoded using the encoding
   rules of the labels described in [IDNS]. The end of the Host name is
   indicated by 0x00.

   Example :
   hostname = www.reindael.security.org
   First the name has to be reverse to have the gTLD on the left side.
   Global Title name: org.security.reindael.www

   Then the result of applying the rules of the iDNS is:






















Loughney, et al.                                            [Page 56]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        x |           3           |           O           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+2 |           R           |           G           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+4 |           7           |           S           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+6 |           E           |           C           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+8 |           U           |           R           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+10|           I           |           T           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+12|           Y           |           8           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+14|           R           |           E           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+16|           I           |           N           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+18|           D           |           A           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+20|           E           |           L           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+22|           3           |           W           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+24|           W           |           W           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |           00          |                       |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

3.9.3 Destination Address

     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 = 0x0103         |      Parameter Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Routing Indicator        |       Address Indicator       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                       address parameter(s)                    /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of this parameter is identical to the Source Address
   parameter.







Loughney, et al.                                            [Page 57]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


3.9.4 Source Reference Number

       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 = 0x0104         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Source Reference Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The source reference number is a 4 octet long integer. This is
   allocated by the source SUA instance.

3.9.5 Destination Reference Number

       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 = 0x0105         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Reference Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The destination reference number is a 4 octet long integer. This is
   allocated by the destination SUA instance.

3.9.6 SCCP Cause

       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 = 0x0106          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           spare               |   Cause Type  |  Cause Value  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This parameter bundles the SCCP parameters Release cause, Return
   cause, Reset cause, Error cause and Refusal cause.

   Cause Type can have the following values:

        Return Cause          0x1
        Refusal Cause         0x2
        Release Cause         0x3
        Reset Cause           0x4
        Error Cause           0x5

   Cause Value contains the specific cause value.  Below gives examples
   for ITU SCCP values.  ANSI references can be found in ANSI T1.112.3

   Cause value in        Correspondence with Reference

Loughney, et al.                                            [Page 58]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   SUA message           SCCP parameter
   ------------------    -----------------   ---------
   CLDR                  Return Cause        ITU-T Q.713 Chap 3.12
   COREF                 Refusal Cause       ITU-T Q.713 Chap 3.15
   RELRE                 Release Cause       ITU-T Q.713 Chap 3.11
   RESRE                 Reset Cause         ITU-T Q.713 Chap 3.13
   ERR                   Error Cause         ITU-T Q.713 Chap 3.14

3.9.7 Sequence Number

       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 = 0x0107         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           spare               | Rec Seq Num |M| Sent Seq Num  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This parameter is used to indicate whether _more_ data will follow
   in subsequent CODT messages, and to number each CODT message
   sequentially for the purpose of flow control. It contains the more
   indicator, and the received as well as the sent sequence number,
   P(R) and P(S) in Q.713, chapters 3.7 and 3.9.

   As such it can also be used to acknowledge the receipt of data
   transfers from the peer in case of protocol class 3.

   Sent Sequence Number is one octet and is coded as follows:

          Bits 2-8 are used to indicate the Send Sequence Number P(S).
          Bit 1 (LSB) of octet 1 is spare.

   Received Sequence Number is one octet, and is coded as follows:

          Bits 2-8 are used to indicate the Received Sequence Number
          P(R).

          Bit 1 (LSB) is used for the more data indication, as follows:

          0         no more data
          1         more data











Loughney, et al.                                            [Page 59]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


3.9.8 Receive Sequence Number

    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 = 0x0108         |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    spare                      |  Rec Seq Num  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This parameter is used exclusively for protocol class 3 in the data
   acknowledgment message to indicate the lower edge of the receiving
   window. See Q.713, chapter 3.8.

   It is a 1 octet long integer coded as follows:

      Bits 8-2 are used to indicate the Receive Sequence Number P(R).

      Bit 1 is spare.

3.9.9 ASP Capabilities

   This parameter is used so that the ASP can report it's capabilities
   regarding SUA for supporting different protocol classes and
   interworking scenarios.

       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 = 0x0109         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            spare              |0 0 0 0|a|b|c|d| Interworking  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length is two octets.

   Flags

     a - Protocol Class 3
     b - Protocol Class 2
     c - Protocol Class 1
     d - Protocol Class 0

     It is mandatory to support at least Protocol Class 0.

   Interworking

   Values

     0x0 indicates no interworking with SS7 Networks.
     0x1 indicates IP Signaling Endpoint (ASP).

Loughney, et al.                                            [Page 60]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


     0x2 indicates Signaling Gateway.

3.9.10 Credit

       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 = 0x010A         |             length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Credit                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length of the credit field is is one octet.  See ITU-T Q.713
   chapter 3.10.

3.9.11 SCMG Format Identifier

      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 = 0x010B       |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       SCMG Format Identifier                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The SCMG Format Identifier field may have the following values:

     0         Reserved
     1         SSA
     2         SSP
     3         SST
     4         SOR
     5         SOG
     6         SSC
     7 - 252   Reserved
     253       SNR (ANSI SCCP Specific)
     254       SBR (ANSI SCCP Specific)
     255       SRT (ANSI SCCP Specific)

3.9.12 SMI / Subsystem

      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 = 0x010C       |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             SMI               |     Spare     |      SSN      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Subsystem Number (SSN) is one octet.


Loughney, et al.                                            [Page 61]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   Subsystem Multiplicity Indicator (SMI) can have the following
   values:

     0x00      Reserved
     0x01      Replicated
     0x02      Solitary
     0x03      Unknown


4 Procedures

   The SUA layer needs to respond to various local primitives it
   receives from other layers as well as the messages that it receives
   from the peer SUA layers.  This section describes the SUA procedures
   in response to these events.

4.1 SCCP _ SUA Interworking at the SG

   On the SG, the SCCP routing or interworking function determines that
   the message must be sent to an AS via the SUA stack, based on
   information in the incoming message. The SUA outgoing mapping
   function identifies the appropriate Application Server (AS) and
   selects an active ASP from the list of ASPs servicing this AS. The
   appropriate ASP can be determined based on the routing information
   in the incoming message, local load sharing information, etc. The
   appropriate SUA message is then constructed and sent to the
   appropriate endpoint, via the correct SCTP association and stream.

4.1.1 Connection Oriented Procedures

   On receipt of a CR message from the SS7 network, a first connection
   section is established between the SG and SS7 originating node. A
   second connection section is to be setup between the SG and the
   appropriate ASP, determined by the SUA outgoing mapping function.

   Local resources and source local reference numbers are allocated to
   keep/retrieve the required address information and the connection
   state in order to format and route subsequent messages for the
   connection based on reference numbers only. The existing SCCP
   procedures can be deployed by SUA to perform this coupling of
   connection sections.

   The same applies for a CORE message received from the IP network,
   destined for an SS7 node. After allocating the necessary resources,
   the SUA incoming mapping function formats the appropriate SCCP
   message and passes it on to SCCP routing for further processing
   (sending into the SS7 network).

4.1.2 Connectionless Procedures



Loughney, et al.                                            [Page 62]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   The existing SCCP routing functions may be enhanced to support
   interworking with the SUA layer. The function of SUA can be limited
   to outgoing mapping (formatting of the CLDT or CLDR message) and
   selection of the correct SCTP association (ASP) and stream. For the
   direction ASP to SG, the SUA incoming mapping formats the
   appropriate SCCP message (UDT(S), XUDT(S) or LUDT(S)) and passes it
   on to SCCP routing for further processing.
   The SG MUST take care of any segmentation / reassembly at the border
   of the SS7 and IP networks.  The IPSP may not have any knowledge
   about the requirements of the SS7 network to which it is sending to.

4.1.3 SS7 Signaling Network Management Procedures

   When an SCCP Subsystem Management (SCMG) message is received from
   the SS7 network, it has to be determined whether there are concerned
   Application Servers, interested in subsystem status changes. The
   normal SCCP management procedures for local and remote broadcast can
   be deployed, but the SUA outgoing mapping function is called upon to
   format and transfer these SCMG messages to the appropriate list of
   concerned ASPs.

   When MTP-3 Management indications are received (MTP-PAUSE, MTP-
   RESUME, MTP-STATUS), SCCP Subsystem Management determines whether
   there are concerned local SCCP-users. When these local SCCP-users
   are in fact Application Servers, serviced by ASPs, SUA outgoing
   mapping is called upon to format the appropriate SUA message (DUNA,
   DAVA or SCON) and forward it on the correct SCTP associations (ASPs)
   on the appropriate stream (streamID _0_ for management messages).

   When the DAUD message is received at the SG from an ASP, the SG
   checks the status of the specified SS7 destination and returns DAVA,
   DUNA or SCON depending on the result of the check. No SS7 procedures
   are triggered.

   SCCP Subsystem Management procedures may also be triggered in case
   of AS state changes, see chapter 4.4.1.2.

4.2 Primitives received from the local SUA-user

   These support the SUA transport of SCCP-User/SCCP boundary
   primitives. The same services as supported by SCCP (connectionless
   and connection-oriented) are to be provided by SUA. The SCCP-users
   at the SG should be able to use the same primitive interface to
   SCCP/SUA without any changes. The SCCP-SUA interworking function
   takes care of selecting the appropriate stack.

   The SUA needs to setup and maintain the appropriate SCTP association
   to the selected endpoint. SUA also manages the usage of SCTP
   streams.



Loughney, et al.                                            [Page 63]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   The address information passed by the SUA-user at an ASP must
   contain either :

   - a valid SS7 address to reach a destination in the SS7 network via
     the appropriate SCTP association to a SG,
   - a valid IP address/hostname to reach another ASP in the IP network
     via the appropriate SCTP association.

4.3 Layer Management Procedures

   On receiving primitives from the local Layer Management, the SUA
   layer will take the requested action and provide a response to Layer
   Management.

   An M-SCTP-ESTABLISH request from Layer Management will initiate the
   establishment of an SCTP association. An M-SCTP-ESTABLISH confirm
   will be sent to Layer Management when the initiated association set-
   up is complete. An M-SCTP-ESTABLISH indication is sent upon
   successful completion of an incoming SCTP association set-up from a
   peer SUA node.

   An M-SCTP-RELEASE request from Layer Management initiates the tear-
   down of an SCTP association. An M-SCTP-RELEASE confirm is sent to
   Layer Management when the association tear-down is complete. An M-
   SCCP-RELEASE indication is sent to Layer Management upon successful
   tear-down of an SCTP association initiated by a peer SUA.

   An M-SCTP-STATUS request supports a Layer Management query of the
   local status of a particular SCTP association. The SUA responds with
   the association status in an M-SCTP-STATUS confirm. No peer SUA
   protocol is invoked.

   An M-ASP-STATUS request supports a Layer Management query of the
   status of a particular local or remote ASP. The SUA responds with an
   M-ASP-STATUS confirm. No peer SUA protocol is invoked.

   An M-AS-STATUS request supports a Layer Management query of the
   status of a particular AS. The SUA responds with an M-AS-STATUS
   confirm. No peer SUA protocol is invoked.

   M-ASP-UP, -DOWN, -ACTIVE and _INACTIVE request primitives allow
   Layer Management at an IPSP to force state changes. Upon successful
   completion, a corresponding confirm primitive is issued by SUA to
   the Layer Management. If the invocation is unsuccessful, an Error
   indication is provided.

   Layer Management is informed by SUA Management about AS/ASP state
   changes with the corresponding indications. It is also informed of
   received NTFY or ERR messages, see chapter 4.4.3.



Loughney, et al.                                            [Page 64]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


4.4 SUA Management Procedures

   This functionality comprises the handling of AS/ASP state and
   traffic management messages, SUA peer management messages, SCTP
   notifications and the interface with local Layer Management.
   These procedures support the SUA management of SCTP Associations and
   ASP paths between SGs and ASPs.

4.4.1 AS and ASP State and Traffic Management

   The SUA layer on each IPSP (e.g. SG) needs to maintain the state of
   each connected IPSP (e.g. ASP), as a way to manage the traffic to
   these IPSPs and the (logical) ASs they service.  In particular at a
   SG, the state of each connected ASP is needed as input to the SGs
   routing function.

4.4.1.1  ASP States

   The state of each ASP is maintained in the SUA layer at the
   controlling AS. The state of an ASP changes due to events. The
   events include:

   - ASP Management messages (ASP-Up, ASP-Down, ASP-Active, ASP-
     Inactive)
   - SCTP Communication Down Notification (SCTP CDI)

   The state of the ASP within each AS is important in particular for
   the routing function at the SG, in order to direct traffic for a
   specific routing key (AS) to the appropriate ASP.

   At an ASP, if it is connected to a set of redundant SGs, this set
   can also be seen as an AS handling all traffic destined for the SS7
   network.

   The ASP state transition diagram is shown in Figure 4. The possible
   states of an ASP are:

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

   ASP-UP: The Application Server Process is available but application
   traffic is not possible. The ASP can only handle management
   messages.

   ASP-ACTIVE: The Application Server Process is available and
   application traffic is possible. Whether traffic will be directed to
   this ASP depends on the Traffic Mode Type (over-ride, loadshare with
   or without Standby option).




Loughney, et al.                                            [Page 65]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


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

                  Figure 4: ASP State Transition Diagram

   SCTP CDI: The local SCTP layer's SHUTDOWN COMPLETE notification or
   COMMUNICATION LOST notification. The shutdown of an SCTP association
   may have been requested by local Layer Management, see chapter 4.3.

   Local Layer Management

4.4.1.2  AS States

   The AS is configured in the IPSP as a logical entity to handle
   traffic for a specific (unique) routing key. The state of the AS is
   maintained in the SUA layer, and can change due to following events:

   - ASP state changes : when the first ASP within an AS goes UP or
     ACTIVE, or when the last ASP within an AS goes DOWN or INACTIVE
   - Recovery Timer expiry

   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 possible (i.e. one or more related ASPs are in the ASP-UP
   state, but none in the ASP-ACTIVE state).


Loughney, et al.                                            [Page 66]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   AS-ACTIVE: The Application Server is available and application
   traffic is possible. This state implies that at least one ASP is in
   the ASP-ACTIVE state.

   AS-PENDING: An active ASP has transitioned from active to inactive
   or down and it was the last remaining active ASP in the AS. A
   recovery timer T(r) will be started and all incoming SCN messages
   will be queued by the SG. If an ASP becomes active before T(r)
   expires, the AS will move to AS-ACTIVE state and all the queued
   messages will be sent to the active ASP.

   If T(r) expires before an ASP becomes active, the SG stops queuing
   messages and discards all previously queued messages. The AS will
   move to AS-UP if at least one ASP is in ASP-UP state, otherwise it
   will move to AS-DOWN state.

         +----------+   one ASP trans to ACTIVE   +-------------+
         |          |---------------------------->|             |
         |  AS-UP   |                             |  AS-ACTIVE  |
         |          |<---                         |             |
         +----------+    \                        +-------------+
            ^   |         \ Tr Expiry,                ^    |
            |   |          \ at least one             |    |
            |   |           \ ASP in UP               |    |
            |   |            \                        |    |
            |   |             \                       |    |
            |   |              \                      |    |
    one ASP |   | all ASP       \            one ASP  |    | Last ACT.
    trans   |   | trans to       \           trans to |    | asp trans
    to UP   |   | DOWN            -------\   ACTIVE   |    | to UP or
            |   |                         \           |    | DOWN
            |   |                          \          |    |
            |   |                           \         |    |
            |   |                            \        |    |
            |   v                             \       |    v
         +----------+                          \  +-------------+
         |          |                           --|             |
         | AS-DOWN  |                             | AS-PENDING  |
         |          |                             |  (queueing) |
         |          |<----------------------------|             |
         +----------+       Tr Expiry no ASP      +-------------+
                            in UP state


         Tr = Recovery Timer

                    Figure 5: AS State Transition Diagram

   The SG maintains the availability of the ASs, and will need to issue
   the correct SCCP management message (where applicable) to the SS7
   node(s).

Loughney, et al.                                            [Page 67]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   When an AS transitions to the UP or DOWN state, and it is the only
   (or last) one handling traffic for a certain SSN, an SSP message
   must be broadcast to the concerned remote SCCP-users in the SS7
   network.
   When an AS transitions to the ACTIVE state, and it is the first one
   handling traffic for a certain SSN, an SSA message must be broadcast
   to the concerned remote SCCP-users in the SS7 network.

4.4.2  AS/ASP Management procedures

   Once an SCTP association is established between two IPSPs, one (or
   both) side(s) might issue an ASP-UP message.

4.4.2.1 ASP-Up

   An ASP sends an ASP-UP to each communication partner.  When the ASP-
   UP message is received, the receiving IPSP can react in three
   different ways:

   - Mark the remote ASP Inactive and reply with an ASP-UP Ack message
     in acknowledgement to every received ASP-UP, even if the ASP is
     already marked as Inactive.
   - If for any local reason (e.g. management lock-out) the IPSP cannot
     respond with an ASP-UP Ack, it responds with an ASP-DOWN Ack
     message with Reason "Management Blocking".
   - If an unknown version is received with the ASP-UP message, the
     receiving end must respond with an Error message with Error Code
     _Invalid Version_. The version field in the common header will
     indicate to the sender which version(s) the receiving node
     supports. This is useful when protocol version upgrades are being
     performed. A node with the newer version should support the older
     versions as well to fallback upon in a subsequent ASP-UP message.

   If the ASP does not receive any of the above reactions, the ASP may
   resend ASP-Up messages until it receives an response. The ASP must
   wait for the ASP-UP Ack message before sending any other messages.
   If the remote peer receives any other SUA messages from an ASP,
   before an ASP-UP is received and acknowledged, the message should be
   discarded.

4.4.2.2 ASP-Down

   The IPSP will mark an ASP as down if one of the following events
   occur:

        - an ASP Down (ASP-DOWN) message is received from the ASP,
        - the ASP is locked by local Layer Management.

   The IPSP sends an ASP-DOWN Ack message in response to a received
   ASP-DOWN message from the ASP even if the ASP is already marked as
   Down.

Loughney, et al.                                            [Page 68]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



   The IPSP will send an ASP-DOWN message whenever it wants to take
   down a ASP. Since it is possible for ASP-DOWN and ASP-DOWN Ack
   messages to be lost (for example, during a node failover), the IPSP
   can send ASP-DOWN messages repeatedly until the path comes down
   (i.e. until it receives a ASP-DOWN message from the remote peer or
   the SCTP association goes down).

4.4.2.3 ASP-Active

   When an ASP is ready to start processing traffic, it sends an ASP-
   ACTIVE message to the remote peer. When an ASP-ACTIVE message is
   received, the remote peer responds with an ASP-ACTIVE Ack. The ASP
   cannot send any other messages until after the ASP-ACTIVE Ack is
   received. If the ASP-ACTIVE Ack is not received within a certain
   time, the ASP may resend the ASP-ACTIVE message.

   The ASP-ACTIVE message optionally contains a list of one or more
   Routing Contexts, indicating which Application Servers the ASP is
   joining. If no Routing Contexts are present, then local
   configuration data is used to determine to which Application
   Server(s) the ASP belongs.

   The Traffic Mode Type parameter in the ASP-ACTIVE message indicates
   the traffic handling mode used in a particular Application Server,
   either Over-ride, Over-ride (Standby), Load-share or Load-share
   (Standby). If the remote peer determines that the mode indicated in
   an ASP-ACTIVE is incompatible with the mode currently used in the
   AS, the remote peer responds with an Error message indicating
   "Invalid Traffic Handling Mode".

   In the Over-ride mode, reception of an ASP-ACTIVE message at a
   remote peer causes the all traffic for the AS to be sent to the ASP
   which sent the ASP-ACTIVE. All previously active ASPs in the AS are
   now considered Inactive and will no longer receive traffic for that
   particular AS.  The remote peer sends a Notify (Alternate ASP-
   Active) to the previously active ASP in the AS, after stopping all
   traffic to that ASP. All existing connections/transactions with the
   previously active ASP should be terminated however.

   In the Over-ride (Standby) mode, the actions are the same with the
   exception that the traffic is not started to the ASP until the
   previously active ASP transitions to the "Inactive or "Down" state.
   At this point the ASP that sent the Over-Ride (Standby) ASP-ACTIVE
   message takes over the traffic. No Notify messages are needed.

   In the Load-share mode, reception of an ASP-ACTIVE message causes
   the redistribution of traffic to the ASP sending the ASP-ACTIVE, in
   addition to all the other ASPs that are currently active in the AS.
   The algorithm at the SG for load-sharing traffic within an AS to all
   the active ASPs is implementation dependent. All ASPs marked for

Loughney, et al.                                            [Page 69]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   load-sharing should be able to handle any traffic within the AS, in
   order to accommodate any potential fail-over or re-balancing of the
   offered load.

   In the Load-share (Standby) mode, the actions are the same as the
   Load-share mode, with the exception that the traffic is not started
   to the ASP until the remote peer determines that additional
   resources are needed to service the AS. When needed, the ASP which
   sent the Loadshare (Standby) ASP-ACTIVE message is taken up in the
   loadsharing scheme and traffic is started. No Notify messages are
   needed to be sent.

   A node that receives an ASP-ACTIVE with an incorrect Traffic Mode
   Type for a particular Routing Context will respond with an Error
   Message with Error Cause _Invalid Traffic Handling Mode_. A node
   that receives an unknown Routing Context value responds with an
   Error message with Error Cause _Invalid Routing Context_.

4.4.2.4 ASP-Inactive

   When an ASP wishes to withdraw from handling traffic, it sends an
   ASP-INACTIVE to the applicable remote IPSPs, specifying the AS
   (Routing Context) from which it is withdrawing. If the ASP is
   withdrawing from more than one AS, then the ASP issues either
   multiple ASP-INACTIVE messages, if multiple SCTP associations exist
   to the remote ASPs; or a single ASP-INACTIVE message containing
   multiple Routing Contexts.

   There are two ASP-INACTIVE modes, Over-ride and load-share.  If the
   remote peer determines that the Traffic Mode Type parameter in the
   ASP-INACTIVE is inconsistent with the mode being used by the
   Application Server, an error is reported to the local layer
   management, indicating _Invalid Traffic Handling Mode_.  However,
   the ASP-INACTIVE is still handled.

   In the Over-ride mode, the ASP which sent the ASP-INACTIVE is marked
   as Inactive. No further traffic is sent from and to the ASP marked
   Inactive.

   In the Load-sharing mode, the IPSP marks the ASP as Inactive and re-
   allocates the traffic to the remaining active ASPs. The load-sharing
   mechanism used is outside of the scope of SUA. If there are
   insufficient resources, a NTFY (Insufficient ASPs) may be sent to
   all inactive ASPs.  If a Loadshare (Standby) ASP is available, it
   may be now immediately included in the loadshare group and a Notify
   message must not be sent.  An ASP-INACTIVE Ack message is sent to
   the ASP after all traffic is halted.

   In the case when no other ASPs are active or standby in the
   Application Server, the remote peer should send a NTFY (AS-Pending)
   to all inactive ASPs of the AS. The remote peer then either discards

Loughney, et al.                                            [Page 70]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   all incoming messages for the AS or starts buffering the incoming
   messages for T(r) seconds, after which messages will be discarded.
   T(r) is configurable by the network operator.

   If the remote peer receives an ASP-ACTIVE from an ASP in the AS
   before expiry of T(r), the buffered traffic is directed to the ASP
   and the timer is cancelled.  If T(r) expires, the AS is moved to the
   "Down" state.

4.4.3 SUA peer management messages

4.4.3.1 Notify

   A NTFY message reflecting a change in the AS state is sent to all
   ASPs in the AS, except those in the "Down" state, with appropriate
   Status Type/ID.

   In the case where a NTFY (AS-Pending) message is sent by an SG that
   now has no active ASPs to service the traffic, or a NTFY
   (Insufficient ASPs) is sent in the Loadshare mode, the NTFY does not
   explicitly force the ASP(s) receiving the message to become active.
   The ASPs remain in control of what (and when) action is taken.

4.4.3.2 Error

   The ERR message is used to signal invalid protocol behaviour.

4.4.4 Heartbeat procedure

   The optional Heartbeat message may be sent in order to query the
   status of the remote peer.  It is optional to send, but mandatory to
   acknowledge.

   The data field can be used to store information in the heartbeat
   message useful to the sending node (e.g. the data field can contain
   a time stamp, a sequence number, etc.).


5 Examples of SUA Procedures

   The following sequence charts overview the procedures of SUA.  These
   are meant as examples, they do not, in and of themselves, impose
   additional requirements upon an instance of SUA.

5.1 SG Architecture

   The sequences below outline logical steps for a variety of scenarios
   within a SG architecture.  Please note that these scenarios cover a
   Primary/Backup configuration.  Where there is a load-sharing
   configuration then the SG can declare availability when 1 ASP issues


Loughney, et al.                                            [Page 71]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   ASPAC but can only declare unavailability when all ASPs have issued
   ASPIA.

5.1.1 Establishment of SUA connectivity

   The following must be established before SUA/SCCP traffic can flow.

   Each node is configured (via MIB or through discovery protocol) with
   the connections that need to be setup


        ASP-a1            ASP-a2                SG                  SEP
       (Primary)           (Backup)
          |------Establish SCTP Association------|
                             |--Estab. SCTP Ass--|
                                                 |--Align SS7 link---|

               Each ASP declares to the SG that it is running.

          +----------------ASP Up---------------->
          <--------------ASP Up Ack--------------+
                             +------ASP Up------->
                             <---ASP Up Ack------+

               The Primary ASP declares to the SG that it is active.
               The SG notifies all ASPs.

          +-------------ASP Active--------------->
          <----------ASP Active Ack--------------+
          <----------NTFY (ASP Active)-----------+
                             <-NTFY (ASP Active)-+

               The SG declares the availability of the signaling
               user on ASP-a1 to the SEP.  The SG has been
               configured (via a MIB) that the SEP is concerned
               about its signaling users.  N.B. The SGs SS7 address
               is presented in the SSA, i.e. the SG represents the
               availability of ASP-a1 to the SEP.

                                                 +--------SSA-------->

               The SEP declares its availability to the SG since
               the SG appears within its concerned list.  Similarly,
               the SG informs the active ASP of the availability of
               the SEP as dictated by SGs concerned list.  N.B.
               The SG maps the SS7 address of the SEP to an
               IP address which the SG knows ASP-a1 will understand.

                                                 <--------SSA--------+
          <-----------------SCMG-----------------+


Loughney, et al.                                            [Page 72]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


               Traffic can now flow.  A connectionless flow is shown
               for simplicity.  Nevertheless, the SG is responsible
               for mapping IP to SS7 addresses and vice-versa.  Only
               the Routing Context for ASP-a1 persists from ASP-a1 to
               SEP.

          +-----------------CLDT----------------->
                                                 +--------UDT-------->


5.1.2 Failover scenarios

   The following sequences address failover of SEP and ASP

5.1.2.1 SEP Failover

   The SEP knows that the SG is 'concerned' about its availability.
   Similarly, the SG knows that ASP-a1 is concerned about the SEPs
   availability, therefore the incoming SSP is translated into DUNA.
   ASP-a1 can then instruct the SG to invoke the SS7 Sub-system Test
   procedure using AUD.

        ASP-a1            ASP-a2                SG                  SEP
      (Primary)           (Backup)
                                                 <--------SSP--------+
          <-----------------SCMG-----------------+
          +-----------------DAUD----------------->
                                                 +--------SST-------->

5.1.2.2 Successful ASP Failover scenario

   The following is an example of a successful failover scenario, where
   there is a failover from ASP-a1 to ASP-a2, i.e. Primary to Backup.
   During the failover, the SG buffers any incoming data messages from
   the SEP, forwarding them when the Backup becomes available.


        ASP-a1            ASP-a2                SG                  SEP
      (Primary)           (Backup)
          +-------------ASP Inactive------------->
          <----------NTFY (ASP Inactive)---------+
                             <-NTFY (ASP Inact.)-+
                             +----ASP Active----->
                             <--ASP Active Ack---+
                             <-NTFY (ASP Active)-+
          <----------NTFY (ASP Active)-----------+

5.1.2.3 Unsuccessful ASP Failover scenario

        ASP-a1            ASP-a2                SG                  SEP
      (Primary)           (Backup)

Loughney, et al.                                            [Page 73]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


          +-------------ASP Inactive------------->
          <----------NTFY (ASP Inactive)---------+
                             <-NTFY (ASP Inact.)-+

                After some time elapses (i.e. timeout).

                                                 +--------SSP-------->
                                                 <--------SST--------+

5.2 IP-IP Architecture

   The sequences below outline logical steps for a variety of scenarios
   within an IP-IP architecture.  Please note that these scenarios
   cover a Primary/Backup configuration.  Where there is a load-sharing
   configuration then the AS can declare availability when 1 ASP issues
   ASPAC but can only declare unavailability when all ASPs have issued
   ASPIA.

5.2.1 Establishment of SUA connectivity

   The following shows an example establishment of SUA connectivity.
   In this example, each IP SP consists of a Management Instance (MI)
   and two ASPs.  The Management Instance handles the address mapping
   mechanisms and monitors the states of the remote peer.  For
   simplicity, the Management Instances and ASPs are considered as a
   separate entity.  This is not a requirement, as they can be co-
   located with an ASP.

   The following must be established before SUA traffic can flow. A
   connectionless flow is shown for simplicity.

   Each node is configured (via MIB, for example) with the connections
   that need to be setup

   IP SEP A                                                  IP SEP B
   ASP-a1     ASP-a2     MI a             MI b       ASP-b2    ASP-b1
   (Primary) (Backup)                               (Backup) (Primary)

               Establish SCTP Connectivity

                         |-- Est. SCTP Ass.--|

   |------ Establish SCTP Association -------|
   |------------- Establish SCTP Association -------------|
   |------------------ Establish SCTP Association ------------------|

              |--- Establish SCTP Assoc. ----|
              |------- Establish SCTP Association --------|
              |------------ Establish SCTP Association -------------|

                         |-- Establish SCTP Association -|

Loughney, et al.                                            [Page 74]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



                         |------- Establish SCTP Association ------|

               Establish SUA Connectivity

   +---------------ASP Up------------------->
   <---------------ASP Up Ack---------------+

              +------------ASP Up----------->
              <------------ASP Up Ack-------+

                        <--------------ASP Up-------------+
                        +--------------ASP Up Ack--------->

                        <----------------ASP Up---------------------+
                        +----------------ASP Up Ack----------------->

   +---------------ASP Act------------------>
   <---------------ASP Act Ack--------------+

                        <----------------ASP Act--------------------+
                        +----------------ASP Act Ack---------------->

   Traffic can now flow directly between ASPs.

   +-------------------------------CLDT------------------------------->


5.2.2 Failover scenarios

   The following sequences address failover of ASP

5.2.2.1 Successful ASP Failover scenario

   The following is an example of a successful failover scenario, where
   there is a failover from ASP-a1 to ASP-a2, i.e. Primary to Backup.
   Since data transfer passes directly between peer ASPs, ASP-b1 is
   notified of the failover of ASP-a1 and must buffer outgoing data
   messages until ASP-a2 becomes available.

   IP SEP A                                                  IP SEP B
   ASP-a1     ASP-a2     MI a             MI b       ASP-b2    ASP-b1
   (Primary) (Backup)                               (Backup) (Primary)

   +--------------ASP Inact----------------->
   <--------------ASP Inact Ack-------------+

              <----NTFY (ASP-a1 Inactive)---+

              +----------ASP Act------------>


Loughney, et al.                                            [Page 75]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


              <----------ASP Act Ack--------+

5.2.2.2 Unsuccessful ASP Failover scenario

   The sequence is the same as 4.2.2.1 except that, since the backup
   fails to come in then, the Notify messages declaring the
   availability of the backup are not sent.

6 Message Routing Scenarios

6.1 Basic case with single SG acting as end- or relay-point

    ______            _____            ______
    |     |   SS7     |    |     IP    |     |
    | SEP |-----------| SG |-----------| ASP |
    |_____|           |____|           |_____|


6.1.1 SG as end-point

   Address information in (X)UDT message from SEP to SG :

     - MTP routing label OPC = SEP, DPC = SG
     - SCCP calling party address contains SSN, optionally OPC = SEP
     - SCCP called party address contains SSN

   At the SG, the SCCP subsystem identified by SSN (and for non-
   standardized SSN, also MTP network) is regarded as a local
   subsystem. From SEP point of view, the SCCP-user is located at the
   SG.

   Depending on administration data, the SG knows the SCCP-user is
   serviced by an AS, which means a set of ASPs working in n+k
   redundancy mode. An ASP is selected and the CLDT message is sent on
   the appropriate SCTP association/stream.

   Actually, the primitive interface between SCCP and SCCP-user is
   transported here over SUA.

   Address information in CLDT message from SG to ASP :

       -  Association ID : SG-ASP, Stream ID : based on SLS (and
          possibly OPC, MTP network ID)
       -  Source address contains PC (SEP) + SSN + MTP network ID,
          needed for back routing
       -  Destination address contains SSN, to select the SCCP-user at
          the ASP.





Loughney, et al.                                            [Page 76]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   The MTP network ID is needed if the SG operates in more than 1 MTP
   network. PC and SSN only have meaning within an MTP network. In the
   response, the ASP should pass a unique, unambiguous source address.
   Further messages from SEP belonging to the same transaction /
   connection will then reach the same ASP.

   Address information in CLDT message from ASP to SG :

        - Association ID : ASP-SG, Stream ID : implementation
          dependent, but in-sequence-delivery must be taken care of
        - Source address contains unique ASP address : when used as
          SCCP called party address at the SG, the SG SHOULD select the
          same ASP again.
        - Destination address copied from source address in received
          CLDT message.

6.1.2 SG as relay-point

   Address information in (X)UDT message from SEP to SG :

        - MTP routing label OPC = SEP, DPC = SG
        - SCCP calling party address contains SSN, optionally OPC =
          SEP, and a GT
        - SCCP called party address contains SSN and a GT

   Since routing is done on GT, the actual location of the SCCP-user is
   irrelevant to the SEP. Translation of the GT always leads to a "SCCP
   entity set", which in this case equals an AS. Selection of the AS is
   thus based on the SCCP called party address (and possibly other
   parameters, e.g. OPC, depending on the implementation). Basically
   this means splitting the SS7 traffic over different AS's based on GT
   information After this, the same as in 6.1.1 applies.

   Address information in CLDT message from SG to ASP :

        - Association ID : SG-ASP, Stream ID : based on SLS (and
          possibly OPC, MTP network ID)
        - Source address contains PC (SEP) + SSN + MTP network ID or a
          GT, needed for back routing
        - Destination address contains SSN, to select the SCCP-user at
          the ASP.

6.2 Replicated SG acting as end-point
               ______             _____
               |     |            |    |
               | STP |------------| SG |
               |_____|            |____|
                 /   \           /     \
                /     \         /       \
               /       \       /         \
              /         \     /           \

Loughney, et al.                                            [Page 77]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


    ______   /           \   /             \ ______
    |     | /             \ /               \|     |
    | SEP |/               \                /| ASP |
    |_____|\              / \              / |_____|
            \            /   \            /
             \          /     \          /
              \        /       \        /
               \      /         \      /
               ______/           _____/
               |     |           |    |
               | STP |-----------| SG |
               |_____|           |____|


   This case does not differ much from the basic case 6.1.1. The SCCP-
   user is still considered to be located at the SG. Only for the first
   message of the transaction/connection, a SG selection must be made
   (possibly via GTT at the STPs, or by implementation dependent means
   on the SEP). Once selected, the same SG is used throughout the
   transaction/connection.

6.3 Replicated SG acting as relay-point
              ______             _____
               |     |            |    |
               | STP |------------| SG |
               |_____|            |____|
                 /   \           /     \
                /     \         /       \
               /       \       /         \
              /         \     /           \
    ______   /           \   /             \ ______
    |     | /             \ /               \|     |
    | SEP |/               \                /| ASP |
    |_____|\              / \              / |_____|
            \            /   \            /
             \          /     \          /
              \        /       \        /
               \      /         \      /
               ______/           _____/
               |     |           |    |
               | STP |-----------| SG |
               |_____|           |____|


   The final GTT occurs in one of the mated pair SGs (with identical
   database). The ASP is selected in the same way as in 6.1.2. In
   normal circumstances, the path from SEP to ASP will always go via
   the same SG when in-sequence-delivery is requested. However, linkset
   failures may cause re-routing to the other SG. This should be kept
   in mind when the SG is to reassemble XUDT segments received from SEP
   into a single CLDT before sending to the ASP.

Loughney, et al.                                            [Page 78]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



7 Security

7.1 Introduction

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

7.2 Threats

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

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

   SUA runs on top of SCTP.  SCTP provides certain transport related
   security features, such as:

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

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

   When the network in which SUA runs in involves more than one party,
   it may not be reasonable to expect that all parties have implemented
   security in a sufficient manner. End-to-end security should be the
   goal, therefore, it is recommended that IPSEC is used to ensure
   confidentiality of user payload.  Consult [2409] for more
   information on configuring IPSEC services.

7.3 Protecting Confidentiality

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



Loughney, et al.                                            [Page 79]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


8 IANA Considerations

8.1 SCTP Payload Protocol ID

   A request will be made to IANA to assign SCTP Payload Protocol IDs.
   A Payload ID for the SUA will be registered.

   The Payload ID is included in each SCTP data chunk, to indicate
   which protocol SCTP is carrying. This Payload ID is not directly
   used by SCTP but may be used by certain network entities to identify
   the type of information being carried in this DATA chunk.

   It is assumed that the Payload ID for SUA will be 4.

8.2 Port Number

   SUA will use port number 14001, which is currently registered to
   "ITU-T SCCP".  It will be renamed to "SUA." This Port Number is the
   port which the SG listen to when receiving SCTP datagrams.

8.3 Protocol Extensions

   This protocol may also be extended through IANA in three ways:
    -- through definition of additional message classes,
    -- through definition of additional message types, and
    -- through definition of additional message parameters.

   The definition and use of new message classes, types and parameters
   is an integral part of SIGTRAN adaptation layers.  Thus, these
   extensions are assigned by IANA through an IETF Consensus action as
   defined in [RFC2434].

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

8.3.1 IETF Defined Message Classes

   The documentation for a new message class MUST include the following
   information:
   (a) A long and short name for the message class;
   (b) A detailed description of the purpose of the message class.

8.3.2 IETF Defined Message Types

   Documentation of the message type MUST contain the following
   information:

   (a) A long and short name for the new message type;
   (b) A detailed description of the structure of the message.
   (c) A detailed definition and description of intended use of each
       field within the message.

Loughney, et al.                                            [Page 80]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   (d) A detailed procedural description of the use of the new message
       type within the operation of the protocol.
   (e) A detailed description of error conditions when receiving this
       message type.

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

8.3.4 IETF-defined TLV Parameter Extension

   Documentation of the message parameter MUST contain the following
   information:

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

9 Timer Values

     Ta                                      2 seconds
     Tr                                      2 seconds
     T(ack)                                  2 seconds
     T(ias)    Inactivity Send timer         7 minutes
     T(iar)    Inactivity Receive timer      15 minutes

10 Acknowledgements

   The authors would like to thank Brian Bidulock, Martin Booyens,
   Marja-Liisa Hamalainen, Sherry Karl, Markus Maanoja, Chirayu Patel,
   Michael Purcell, Michael Tuexen, Al Varney and Ben Wilson for their
   insightful comments and suggestions.

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

10 Authors' Addresses

   John Loughney
   Nokia Research Center
   PO Box 407
   FIN-00045 Nokia Group
   Finland
   EMail: john.loughney@nokia.com


Loughney, et al.                                            [Page 81]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


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

   Guy Mousseau
   Nortel Networks
   3685 Richmond Rd
   Nepean, Ontario, Canada  K2H 5B7

   Stephen Lorusso
   Unisphere Solutions
   One Executive Drive
   Chelmsford, MA 01824
   USA
   email:                                                                                                                         SLorusso@UnisphereSolutions.com

   Lode Coene
   Siemens Atea
   Atealaan 34
   B-2200 Herentals
   Belgium
   Phone: +32-14-252081
   EMail: lode.coene@siemens.atea.be

   Gery Verwimp
   Siemens Atea
   34 Atealaan
   PO 2200
   Herentals
   Belgium
   Phone : +32 14 25 3424
   EMail:gery.verwimp@siemens.atea.be

   Joe Keller
   Tekelec
   5200 Paramount Parkway
   Morrisville, NC 27560
   USA
   EMail: joe.keller@tekelec.com

   Florencio Escobar Gonzalez
   Ericsson Spain S.A.
   Retama 7, 2nd floor
   28045, Madrid
   Spain
   EMail: florencio.escobar@ericsson.com

   Steven Furniss
   Marconi

Loughney, et al.                                            [Page 82]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   New Century Park
   Coventry CV3 1HJ
   United Kingdom
   EMail: steven.furniss@marconi.com

   William Sully
   Marconi
   New Century Park
   Coventry CV3 1HJ
   United Kingdom
   EMail: william.sully@marconi.com

11 References

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

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

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

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

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

   [RANAP]        3G TS 25.413 V3.3.0 (2000-09) 'Technical
                  Specification 3rd Generation Partnership Project;
                  Technical Specification Group Radio Access Network;
                  UTRAN Iu Interface RANAP Signalling'

   [SCTP]         RFC 2960 "Stream Control Transport Protocol" R.
                  Stewart, et. Al. November 2000.

   [M3UA]         MTP3-User Adaptation Layer <draft-ietf-sigtran-m3ua-
                  05.txt>, Decemenber 2000, Work in Progress.

   [2401]         RFC 2401, "Security Architecture for the Internet
                  Protocol", S. Kent, R. Atkinson, November 1998.

   [UTRAN IUR]    3G TS 25.420 V3.2.0 (2000-09) "Technical
                  Specification 3rd Generation Partnership Project;
                  Technical Specification Group Radio Access Network;
                  UTRAN Iur Interface General Aspects and Principles"

   [2196]         RFC 2196, "Site Security Handbook", B. Fraser Ed.,
                  September 1997.

Loughney, et al.                                            [Page 83]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000



   [ENUM]         "ENUM Requirements" <draft-ietf-enum-rqmts-01.txt>,
                  June 2000, Work in Progress.

   [E.164-DNS]    RFC 2916 "E.164 number and DNS", P. Faltstrom,
                  September 2000.

   [IDNS]         Blanchet, M., Hoffman, P., "Internationalized domain
                  names using EDNS (IDNE)", <draft-ietf-idn-idne-
                  01.txt>, Work in progress, July 2000

   [RFC2434]      RFC 2434 "Guidelines for Writing an IANA
                  Considerations Section in RFCs", T. Narten, H.
                  Alvestrand, October 1998.

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

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

Appendix A: Message mapping between SCCP and SUA.

   This is for illustrative purposes only.

   SUA    SCCP      SCCP                     Classes          Mgt.  SUA
   Name   Name      Full Name                0    1    2    3 Msg.Usage
   ====================================================================
   Connectionless Messages
   CLDT   UDT       Unitdata                 X    X    -    -    -    -
   CLDT   XUDT      Extended unitdata        X    X    -    -    -    -

   CLDT   LUDT      Long unitdata            X    X    -    -    -    -
   CLDR   UDTS      Unitdata service         X    X    -    -    -    -
   CLDR   XUDTS     Extended unitdata serv.  X    X    -    -    -    -
   CLDR   LUDTS     Long unitdata service    X    X    -    -    -    -

   Connection-Oriented Messages
   CODT   DT1       Data form 1              -    -    X    -    -    -
   CODT   DT2       Data form 2              -    -    -    X    -    -
   CODT   ED        Expedited data           -    -    -    X    -    -
   CODA   AK        Data acknowledgement     -    -    -    X    -    -
   CODA   EA        Expedited data ack.      -    -    -    X    -    -
   CORE   CR        Connection request       -    -    X    X    -    -
   COAK   CC        Connection confirm       -    -    X    X    -    -
   COAK   CREF      Connection refused       -    -    X    X    -    -
   RELRE  RLSD      Released                 -    -    X    X    -    -
   RELCO  RLC       Release complete         -    -    X    X    -    -
   RESRE  RSR       Reset request            -    -    -    X    -    -
   RESCO  RSC       Reset confirm            -    -    -    X    -    -
   COIT   IT        Integrity Test           -    -    X    X    -    -

Loughney, et al.                                            [Page 84]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   COERR  ERR       Protocol Data Unit Error -    -    X    X    -    -

   General Protocol Messages

   SS7 MGT Messages
   DUNA   n/a       n/a                      -    -    -    -    -    X
   DAVA   n/a       n/a                      -    -    -    -    -    X
   DAUD   n/a       n/a                      -    -    -    -    -    X
   SCMG   SSC       SCCP/subsystem-congested -    -    -    -    X    -
   SCMG   SSA       subsystem-allowed        -    -    -    -    X    -
   SCMG   SSP       subsystem-prohibited     -    -    -    -    X    -
   SCMG   SST       subsystem-status-test    -    -    -    -    X    -
   SCMG   SOR       subsystem-oos-req        -    -    -    -    X    -
   SCMG   SOG       subsystem-oos-grant      -    -    -    -    X    -

   SUA MGT Messages
   ASPUP  n/a       n/a                      -    -    -    -    -    X
   ASPDN  n/a       n/a                      -    -    -    -    -    X
   ASPAC  n/a       n/a                      -    -    -    -    -    X
   ASPIA  n/a       n/a                      -    -    -    -    -    X
   NTFY   n/a       n/a                      -    -    -    -    -    X
   ERR    n/a       n/a                      -    -    -    -    -    X

   -      = Message not applicable for this protocol class.
   X      = Message applicable for this protocol class.
   n/a    = not applicable

Copyright Statement

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

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

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

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

Loughney, et al.                                            [Page 85]

Internet Draft       SS7 SCCP-User Adaptation Layer    February 1, 2000


   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

















































Loughney, et al.                                            [Page 86]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/