[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:  15 November 2000                              Nortel Networks
Expires: 15 May 2001                                        S. Lorusso
                                                   Unisphere Solutions
                                                  L. Coede, G. Verwimp
                                                               Siemens
                                                             J. Keller
                                                               Tekelec
                                                            F. Escobar
                                                              Ericsson

                  SS7 SCCP-User Adaptation Layer (SUA)
                    <draft-ietf-sigtran-sua-03.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 15 May 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    November 15, 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 .............................10
 1.5 Internal Functions Provided in the SUA Layer ...................11
 1.6 Definition of SUA Boundaries ...................................12
2 Protocol Elements..................................................13
 2.1 Common Message Header ..........................................13
 2.2 SUA Connectionless Messages ....................................17
 2.3 Connection Oriented Messages ...................................18
 2.4 SS7 Signaling Network Management Messages ......................25
 2.5 Application Server Process Maintenance Messages ................29
 2.6 ASP Traffic Maintenance Messages ...............................32
 2.7 Management Messages ............................................36
 2.8 Common Parameters ..............................................37
 2.9 SUA-Specific parameters ........................................44
3 Procedures.........................................................54
 3.1 Peer Message Procedures ........................................54
 3.2 Signaling Gateway Related Procedures ...........................54
 3.3 Layer Management Procedures ....................................56
 3.4 SCTP Management Procedures .....................................56
4 Examples of SUA Procedures.........................................63
 4.1 SG Architecture ................................................63
 4.2 IP-IP Architecture .............................................65
5 Security...........................................................67
 5.1 Introduction ...................................................67
 5.2 Threats ........................................................67
 5.3 Protecting Confidentiality .....................................68
6 IANA Considerations................................................68
 6.1 SCTP Payload Protocol ID .......................................68
 6.2 Port Number ....................................................68
 6.3 IETF Defined Message Classes ...................................69
 6.3.1 IETF Defined Message Types ...................................69
7 Timer Values.......................................................70
8 Acknowledgements...................................................70
9 Authors' Addresses.................................................70
10 References........................................................71
Appendix A: Message mapping between SCCP and SUA.....................72
Appendix B: Message Mapping Examples.................................73
 1 SUA->SCCP ........................................................73
 2 SCCP->SUA ........................................................73
Copyright Statement..................................................74







Loughney, et al.                                            [Page 2]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 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 Application Servers, which is 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 an IP database
   handling all request for a unique set of SCCP-users.  The AS

Loughney, et al.                                            [Page 3]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 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 PC
   and SSN to 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.   A Routing Key cannot extend across more
   than a single SS7 PC, in order to more easily support SS7 Management
   procedures. It is not necessary for the parameter ranges within a
   particular Routing Key to be contiguous.

   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.

   Signaling Point Management Cluster (SPMC) - A complete set of
   Application Servers represented to the SS7 network under the same
   SS7 Point Code.  SPMCs are used to sum the availability / congestion
   / User_Part status of an SS7 destination point code that is
   distributed in the IP domain, for the purpose of supporting
   management procedures at an SG.


Loughney, et al.                                            [Page 4]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   Network Appearance - The Network Appearance identifies an SS7
   network
   context for the purposes of logically separating the signaling
   traffic between the SG and the Application Server Processes over a
   common SCTP Association.  An example is where an SG is logically
   partitioned to appear as an element in four separate national SS7
   networks.  A Network Appearance implicitly defines the SS7 Point
   Code(s), Network Indicator and SCCP protocol type/variant/version
   used within a specific SS7 network partition. An physical SS7 route-
   set or link-set at an SG can appear in only one network appearance.
   The Network Appearance is not globally significant and requires
   coordination only between the SG and the ASP.

   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.

1.3.1 Protocol Architecture for TCAP 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


Loughney, et al.                                            [Page 5]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   the management messages.  The SUA handles the SS7 address to IP
   address mapping.

     ********   SS7   ***************   IP   ********
     * SEP  *---------*             *--------*      *
     *  or  *         *      SG     *        * ASP  *
     * 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.2 Protocol Architecture for RANAP Transport

   In this architecture, the SS7 application protocol is invoked at the
   SG.  For messages destined for an ASP, the SUA handles address
   translation, for example by way of Global Title Translation or via
   mapping table, resolving the destination specified by SS7
   Application to a SCTP association / IP address.

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

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

Loughney, et al.                                            [Page 6]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


     +------+         +------+------+        +------+
         |               |         |            |
         +---------------+         +------------+

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

   This architecture may simplify, in some cases, to carrying an SS7
   application protocol 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  |
          +------+        +------+
             |                |
             +----------------+

       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.


Loughney, et al.                                            [Page 7]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000



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


Loughney, et al.                                            [Page 8]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   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       *
  * | ******** | *                                      *  ********  *
  * | * ASP1 +---------------------------------------------+ ASP1 *  *
  * | ******** | *                                      *  ********  *
  * | ******** | *                                      *  ********  *
  * | * ASP2 +--------------------------+       +----------+ ASP2 *  *
  * | ******** | *                      |       |       *  ********  *
  * +----------+ *                      |       |       *      .     *
  * +----------+ *                      |       |       *      .     *
  * | AS2      | *                      |       |       *      .     *
  * | ******** | *                      |       |       *  ********  *
  * | * ASP1 +----------------------------------+       *  * ASPN *  *
  * | ******** | *   SCTP Associations  |               *  ********  *
  * | ******** | *                      |               **************
  * | * ASP2 +----------------          |
  * | ******** | *           |          |               **************
  * +----------+ *           |          |               *  AS4       *
  ****************           |          |               *  ********  *
                             |          +------------------+ ASP1 *  *
                             |                          *  ********  *
                             |                          *      .     *
                             |                          *      .     *
                             |                          *            *
                             |                          *  ********  *
                             +-----------------------------+ ASPn *  *
                                                        *  ********  *
                                                        **************

                Figure 2: Signaling Gateway Architecture

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

Loughney, et al.                                            [Page 9]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   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  while any others are inactive but available in the event
   of failure or unavailability of the active ASP(s).

   The fail-over model supports an "n+k" redundancy model, where "n"
   ASPs is the minimum number of redundant ASPs required to handle
   traffic and "k" ASPs are available to take over for a failed or
   unavailable ASP.  Note that "1+1" active/standby redundancy is a
   subset of this model. A simplex "1+0" model is also supported as a
   subset, with no ASP redundancy.

   To avoid a single point of failure, it is recommended that a minimum
   of two ASPs be resident in the list, resident in separate physical
   hosts and therefore available over different SCTP Associations.

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.

   * 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




Loughney, et al.                                            [Page 10]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   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.
     *    Provide the initiation of an audit of remote SS7
          endpoints at the SG.

1.5 Internal Functions Provided in the SUA Layer

1.5.1 Address Translation and Mapping at the SG

   SCCP users may present the following options to address their peer
   endpoints:

     Global Title

Loughney, et al.                                            [Page 11]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


     PC + SSN
     Host Name
     IP Address(es)

   The SG MUST translate the SS7 address presented at the SG (PC + SSN
   or GT) to an SCTP-based ASP final destination, and not to another
   SS7 MTP destination.

   Global Titles are an interesting option for addressing.  Currently,
   the ITU does not support translation of Global Titles to IP
   addresses.  However, IP addresses are global in scope.  There exist
   many proprietary schemes for managing SS7 Address Translation to IP
   addresses, and is considered outside of the scope of this document
   to specify how this is done.

   Some discussion of address translation should be made to insure
   interoperability between implementations of the SUA.  For further
   instruction in the use of Global Titles the rules detailed in Annex
   B of ITU Q.713 [ITU SCCP] or [ANSI SCCP] should be consulted.

   That being said, currently, there is some work within the IETF
   studying translation of E.164 numbers to Host Names [ENUMS], [E.164-
   DNS].

   In many cases, the network operator may have some control over the
   SCCP-user protocols being transported by SUA.  If possible, the
   Upper Layer can present a Host Name or IP Address, which then can be
   directly passed to SCTP.

   An example of address translation at the SG would be that the CDPA
   is extracted from the SCCP Header, processed by the SUA routing
   function which yields a SA.  The SA is fed back into extended SUA
   routing analysis which yields the ASP to route the message to.  This
   is why the Source Address and Destination address-routing should be
   performed based on the CDPA.

1.5.2 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


Loughney, et al.                                            [Page 12]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   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)

1.6.2 Definition of the lower boundary

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

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

2.1 Common Message Header


Loughney, et al.                                            [Page 13]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   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.

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

2.1.2 Message Classes

   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

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

Loughney, et al.                                            [Page 14]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000



   SS7 Signaling Network Management (SSNM) Messages

     0         Reserved
     1         Destination Unavailable (DUNA)
     2         Destination Available (DAVA)
     3         Destination State Audit (DAUD)
     4         SCCP Management (SCMG)
     5         Destination User Part Unavailable (DUPU)
     6 - 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)
     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)

Loughney, et al.                                            [Page 15]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


     7         Reset Request (RESRE)
     8         Connection Oriented Data Transfer (CODT)
     9         Connection Oriented Data Acknowledge (CODA)
     10        Connection Oriented Error (COERR)
     11 - 127  Reserved by the IETF
     128 - 255 Reserved for IETF-Defined Message Class Extensions

2.1.4 Message Length

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

2.1.4 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                         /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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

Loughney, et al.                                            [Page 16]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


      parameter length field. A sender should NEVER pad with more than
      3 bytes. The receiver MUST ignore the padding bytes.

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

2.2.1 Connectionless Data Transfer

   This message transfers data between one SUA to another.

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0102          |      Parameter Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                        Source Address                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0103          |      Parameter Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     destination address                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0003          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Parameters
     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).



Loughney, et al.                                            [Page 17]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000



2.2.2 Connectionless Data Response

   This message is used as a response message by the peer and/or report
   errors.

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0109          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       SCCP Error Cause                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0102          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                        Source Address                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0103          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     destination address                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0003          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fixed Lengths Parameters
     Flags                         Mandatory
     Return Cause                  Mandatory
     SCCP Error Cause              Mandatory
     Source Address                Mandatory
     Destination Address           Mandatory
     Data                          Optional

   Implementation note:

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

2.3 Connection Oriented Messages

2.3.1 Connection Oriented Data Transfer


Loughney, et al.                                            [Page 18]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 destination reference number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0003          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0105          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0101          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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


   NOTE *1:    Mandatory for representing DT1 message.
   NOTE *2:    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).

2.3.2 Connection Oriented Data Acknowledge

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

Loughney, et al.                                            [Page 19]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x010F          |              Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Receive Sequence Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x010C          |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Credit                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     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).

2.3.3 Connect Request

   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 = 0x0105          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0106          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Source Reference Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0103          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Destination Address                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0102          |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                        Source Address                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x010C          |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Credit                             |

Loughney, et al.                                            [Page 20]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0003          |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             Data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

2.3.4 Connection Acknowledge

   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 = 0x0107          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Reference Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0106          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Source Reference Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0105          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x010C          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Credit                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0103          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Destination Address                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0003          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             Data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters

Loughney, et al.                                            [Page 21]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


     Destination Reference Number  Mandatory
     Source Reference Number       Mandatory
     Flags                         Mandatory
     Credit                        Optional
     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.

   Implementation note:

   This message covers the following SCCP message: connection confirm
   (CC).

2.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 = 0x0107          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Reference Number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0109          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        SCCP Error Cause                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0103          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Destination Address                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0001          |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             Data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Note *1:    Destination Address parameter will be present in case


Loughney, et al.                                            [Page 22]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


               that the received CORE message conveys the Source
             Address
               parameter.


2.3.6 Release Request

   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 = 0x0107          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 destination reference number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0106          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   source reference number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0104          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Return Cause                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0105          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0003          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Implementation Note:

   This message covers the following SCCP message: connection refused
   (CREF).

2.3.7 Release Complete



Loughney, et al.                                            [Page 23]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   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
       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 destination reference number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0106          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   source reference number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Destination Reference Number  Mandatory
     Source Reference Number       Mandatory

2.3.8 Reset Request

   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 = 0x0107          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 destination reference number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0106          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   source reference number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0109          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        SCCP Error Cause                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

2.3.9 Reset Confirm

   This message is used to confirm the Reset Request.


Loughney, et al.                                            [Page 24]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 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 = 0x0107          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 destination reference number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0106          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   source reference number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Destination Reference Number  Mandatory
     Source Reference Number       Mandatory

2.3.10 Connection Oriented Error (COERR)

   The COERR message is sent when an invalid value is found in an
   incoming 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 = 0x0107          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 destination reference number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0109          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      SCCP Error Cause                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Destination Reference Number  Mandatory
     SCCP Error Cause              Mandatory

   Implementation Note:

   This message covers the following SCCP message: Protocol data unit
   error (ERR)

2.4 SS7 Signaling Network Management Messages

2.4.1 Destination Unavailable

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


Loughney, et al.                                            [Page 25]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


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

   Parameters
     Affected Point Code           Mandatory
     Network Appearance            Optional
     Info String                   Optional

2.4.2 Destination Available

   The DAVA message is sent from the SG to all concerned ASPs to
   indicate that the SG has determined that an SS7 destination is now
   reachable. The ASP 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 = 0x0005          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     Affected Point Code                       /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0001          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Network Appearance                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0004          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          info string                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters

Loughney, et al.                                            [Page 26]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


     Affected Point Code           Mandatory
     Network Appearance            Optional
     Info String                   Optional

2.4.3 Destination State Audit

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

   Parameters
     Affected Point Code           Mandatory
     Network Appearance            Optional
     Info String                   Optional

2.4.4 SS7 Network Congestion

   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.


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

Loughney, et al.                                            [Page 27]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


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

   Parameters
     Network Appearance            Optional
     Congestion                    Mandatory
     Info String                   Optional

2.4.5 Destination User Part Unavailable

   The DUPU message is used by an SG to inform an ASP that a remote
   peer SUA-User User Part at an SS7 node is unavailable.

   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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Cause             |            User               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Tag = 0x0004          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          info string                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

2.4.6 SCCP Management Message



Loughney, et al.                                            [Page 28]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   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 = 0x010D       |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      SCMG  Message Type                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Tag = 0x010E       |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             SMI               |           Subsystem           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Tag = 0x0005       |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                          Affected PC                          /
     \                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Tag = 0x0108       |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       congestion level                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Tag = 0x0004       |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                          INFO String                          \
     \                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     SCMG Message Type             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 optional.

2.5 Application Server Process Maintenance Messages

2.5.1 ASP Up (ASPUP)

   The ASP UP (ASPUP) 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

Loughney, et al.                                            [Page 29]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Tag = 0x010A       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        ASP Capabilities                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Tag = 0x0004       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          info string                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     ASP Capabilities              Optional
     Info String                   Optional

2.5.2 ASP Up Ack (UPACK)

   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 = 0x010A       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        ASP Capabilities                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Tag = 0x0004       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          info string                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     ASP Capabilities              Optional
     Info String                   Optional

2.5.3 ASP Down (ASPDN)

   The ASP Down (ASPDN) 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 = 0x0002       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Cause Code                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Tag = 0x0004       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Loughney, et al.                                            [Page 30]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


      /                          info string                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Cause Code          Mandatory
     Info String         Optional

2.5.4 ASP Down Ack (DNACK)

   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 = 0x0002       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Cause Code                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Tag = 0x0004       |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          info string                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Reason                        Mandatory
     Info String                   Optional

2.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 = 8            |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Heartbeat Data                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Heartbeat Data           Optional

2.5.6 Heartbeat Ack (BEAT ACK)


Loughney, et al.                                            [Page 31]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


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

   Parameters
     Heartbeat Data           Optional

2.6 ASP Traffic Maintenance Messages

2.6.1 ASP Active (ASPAC)

   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 ASPAC 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Type                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0006         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Routing Context                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0004         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          INFO String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
        Type               Mandatory
        Routing Context    Optional
        INFO String        Optional

   Type: 32-bit (unsigned integer)

Loughney, et al.                                            [Page 32]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000



   The Type parameter identifies the traffic mode of operation of the
   ASP within an AS. 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.

2.6.2 ASP Active Ack

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

   The format for the ASPAC 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Type                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0006         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Routing Context                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0004         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          INFO String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Loughney, et al.                                            [Page 33]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000



   The ASPAC Ack message contains the following parameters:

        Type               Mandatory
        Routing Context    Optional
        INFO String        Optional

   Type: 32-bit (unsigned integer)

   The Type parameter identifies the traffic mode of operation of the
   ASP within an AS. The valid values for Type are shown in the
   following table.

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

   The type field in the ASPAC Ack message should contain the type as
   the ASPAC message to which the message is acknowledging.

2.6.3  ASP Inactive (ASPIA)

   The ASPIA 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Type                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0006         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Routing Context                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0004         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          INFO String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The ASPIA message contains the following parameters:

        Type                 Mandatory
        Routing Context      Optional
        INFO String          Optional


Loughney, et al.                                            [Page 34]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   The Type parameter identifies the traffic mode of operation of the
   ASP within an AS. The valid values for Type are shown in the
   following table.

       Value        Description
        0x1         Over-ride
        0x2         Load-share
        0x3         Over-ride (Standby)
        0x4         Loadshare (Standby)

   Within a particular Routing Context, only one Type can be used.  The
   Override value indicates that the ASP is operating in Over-ride
   mode, and will no longer handle traffic within an Application Server
   (i.e., it is now a backup in a primary/back-up arrangement).  The
   Load-share value indicates that the ASP is operating in Load-share
   mode and will no longer share in the traffic distribution with any
   other currently active ASPs.

   A node that receives an ASPIA with an incorrect Type for a
   particular Routing Context will respond with an Error Message
   (Cause: Invalid Traffic Handling Mode.

2.6.4 ASP Inactive Ack

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

   The format for the ASPIA 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Type                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0006         |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Routing Context                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0004         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          INFO String                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters

     Type               Mandatory
     Routing Context    Optional
     INFO String        Optional


Loughney, et al.                                            [Page 35]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   The Type parameter identifies the traffic mode of operation of the
   ASP within an AS. The valid values for Type are shown in the
   following table.

            1         Over-ride
            2         Load-share

   The type field in the Ack message should contain the type as the
   ASPIA message to which the message is acknowledging.

2.7 Management Messages

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

2.7.1 Error (ERR)

   The ERR message is sent between two SUA peers to indicate an error
   situation.  The Data parameter is option, 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Cause                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0007         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                        Diagnostic Info                        /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameters
     Cause                         Mandatory
     Diagnostic Info               Optional

   The Cause parameter can be one of the following values:

          Invalid Version                         0x1
          Invalid Network Appearance              0x2
          Invalid Adaptation Layer Identifier     0x3
          Invalid Message Type                    0x4
          Invalid Traffic Handling Mode           0x5
          Unexpected Message Type                 0x6
          Protocol Error                          0x7
          Invalid Routing Context                 0x8
          Unsupported Message Type                0x9

2.7.2 Notify (NTFY)



Loughney, et al.                                            [Page 36]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x010B         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Status                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0006         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Routing Context                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x0004         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                          info string                          /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The NTFY message contains the following parameters:

   Parameters
     Status Type                   Mandatory
     Routing Context               Optional
     Info String                   Optional

2.8 Common Parameters

   These TLV parameters are common across the different adaptation
   layers.

   Parameter Name                     Parameter ID
   ==============                     ============
   Network Appearance                   0x0001
   Cause Code                           0x0002
   Data                                 0x0003
   Info String                          0x0004
   Affected Point Code                  0x0005
   Routing Context                      0x0006
   Diagnostic Info                      0x0007
   Heartbeat Data                       0x0008
   Cause/User                           0x0009
   Congestion                           0x000A

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

Loughney, et al.                                            [Page 37]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   Processes over common SCTP Associations.  An example is where an SG
   is logically partitioned to appear as an element in four different
   national SS7 networks.  A Network Appearance implicitly defines the
   SS7 Destination Point Code used, the SS7 Network Indicator value and
   SCCP/SCCP-User 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 appearance, the Network Appearance parameter is not
   required.

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

   In an SSNM message, the Network Appearance parameter defines the
   format of the Affected PC(s) in the Affected Destination parameter.
   The PC point code length (e.g., 14-, 16-, or 24-bit) and sub-field
   definitions (e.g., ANSI 24-bit network/cluster/member, ITU-
   international 14-bit zone/region/signal_point, many national field
   variants, ...) are fixed within a particular Network Appearance.
   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 and the
   format of the Affected PC(s) is understood implicitly.

   The format of the Network Appearance parameter is an integer, the
   values of which are assigned according to network operator policy.
   The values used are 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
   Affected PCs in the Affected Destination parameter.

2.8.2 Cause Code

   The Cause Code parameter indicates the reason that the remote SUA
   adaptation layer is unavailable.  The valid values for Reason are
   shown in the following table.

          Value               Description
          0x1                 Processor Outage
          0x2                 Management Inhibit

2.8.3 Data


Loughney, et al.                                            [Page 38]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 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 = 0x0003         |            length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                             data                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

Loughney, et al.                                            [Page 39]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


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

   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 is 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 "wildcarded".  For example, a mask of "8" indicates that
   the last eight bits of the PC is "wildcarded".  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 "wildcarded".  For a 14-bit ITU Affected PC,
   this is equivalent to signaling that an ITU Region is unavailable.

2.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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Type                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       Routing Context                         /

Loughney, et al.                                            [Page 40]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type parameter identifies the message as an Over-ride or Load-
   share Active message.  The valid values for Type are shown in the
   following table.

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

   Within a particular Routing Context, only one Type can be used.

   The optional Routing Context parameter contains (a list of) integers
   indexing the Application Server traffic that the sending ASP is
   configured to receive.  There is one-to-one relationship between an
   index entry and an AS Name.  Because an AS can only appear in one
   Network Appearance, the Network Appearance parameter is not required
   in the ASPAC 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.

2.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*                   /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.8.8 Heartbeat 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 = 8            |            Length             |

Loughney, et al.                                            [Page 41]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       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.).

2.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 = 9            |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Cause              |             User              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   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

2.8.10 Congestion

       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 = 0x0010          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Mask        |                 Affected PC 1                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Congestion Level 1                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Loughney, et al.                                            [Page 42]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


      \                                                               \
      /                              ...                              /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Mask      |                 Affected PC n                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Congestion Level n                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Congestion Level field: 8-bits (unsigned integer)

   The Congestion Level field, associated with each Affected PC in the
   Affected Destinations parameter, contains one of the following
   values:

            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.

   Mask: 8-bit unsigned integer

   The Mask field associated with each Affected PC in the Affected
   Destinations parameter, 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.  For example, if all PCs in an ANSI cluster
   are determined to be unavailable due to local linkset
   unavailability, the DUNA could identify potentially 256 Affected
   PCs in a single Affected PC field.

   The Mask parameter represents 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 are significant and which are effectively
   "wildcarded".  For example, a mask of "8" indicates that the last
   eight bits of the PC is "wildcarded".  For an ANSI 24-bit Affected
   PC, this is equivalent to signalling that all PCs in an ANSI
   Cluster are unavailable.  A mask of "3" indicates that the last
   three bits of the PC is "wildcarded".  For a 14-bit ITU Affected
   PC, this is equivalent to signaling that an ITU Region is

Loughney, et al.                                            [Page 43]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   unavailable. A mask value equal to the number of bits in the PC
   indicates that the entire network appearance is affected - this is
   used to indicate network isolation to the ASP.


2.9 SUA-Specific parameters

   These TLV parameters are specific to the SUA protocol.

   Parameter Name                     Parameter ID
   ==============                     ============
   Sequence Number                      0x0101
   Source Address                       0x0102
   Destination Address                  0x0103
   Return Cause                         0x0104
   Flags                                0x0105
   Source Reference Number              0x0106
   Destination Reference Number         0x0107
   Congestion Level                     0x0108
   SCCP Error                           0x0109
   ASP Capabilities                     0x010A
   Status                               0x010B
   Credit                               0x010C
   SCMG Message Type                    0x010D
   SMI / Subsystem                      0x010E

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

   It is used exclusively for protocol class 3 to number each DT
   message   sequentially for the purpose of flow control, sequence
   numbering and segmenting and reassembly.

   It is used to number each DT message sequentially for the purpose of
   flow control. It contains the received as well as the sent sequence
   number, P(R) and P(S) in Q.713.

   As such it can 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 8-2 are used to indicate the Send Sequence Number P(S).
          Bit 1 of octet 1 is spare.

Loughney, et al.                                            [Page 44]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000




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

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

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

          0         no more data
          1         more data.

2.9.2 Source Address (=CLG)

       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         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Type of Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                        Source Address                         /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type of Address field is used to aid in the identification of
   the type of address.  If this field is set to 0, then the address
   field needs to be analyzed.

   Type of Address

     Unknown/Undeterminable        0x00000000
     SS7 SCCP CLG                  0x00000001
     Host Name                     0x00000002
     IPv4 Address                  0x00000003
     IPv6 Address                  0x00000004

   The combinations of SS7 addressing schemes (ITU, ANSI, etc).
   supported is implementation dependant.

   The Source Address field can contain the SCCP Calling Party Address.
   It is possible to simply encapsulate the information, as presented
   by the upper layer.

2.9.3 Destination Address (=CLD)

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

Loughney, et al.                                            [Page 45]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


      |                         Type of Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       destination address                     /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type of Address field is used to aid in the identification of
   the type of address.  If this field is set to 0, then the address
   field needs to be analyzed.

   Type of Address

     Unknown/Undeterminable        0x00000000
     SS7 SCCP CLD                  0x00000001
     Host Name                     0x00000002
     IPv4 Address                  0x00000003
     IPv6 Address                  0x00000004

   Note: the combinations of SS7 addressing schemes(ITU, ANSI, etc).
   supported is implementation dependant.

   The Destination Address field can contain the SCCP Called Party
   Address.  It is possible to simply encapsulate the information, as
   presented by the upper layer.

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

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

   The labels are then encoded using the encoding rules of the labels
   described in [IDNS]. The end of the hostname 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.
   org.security.reindael.www  Then applying the rules of the iDNS we
   get a nice encoding as follows:

          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        x |           3           |           O           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+2 |           R           |           G           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+4 |           7           |           S           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+6 |           E           |           C           |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      x+8 |           U           |           R           |

Loughney, et al.                                            [Page 46]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


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

2.9.4 Return Cause

   The Return Cause corresponds to the return cause of the SCCP
   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 = 0x0104         |             length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Cause Code                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length is a one octet unsigned integer.

   Possible values for the Return Cause are:

   0x00        no translation for an address of such nature
   0x01        no translation for this specific address
   0x02        subsystem congestion
   0x03        subsystem failure
   0x04        unequipped user
   0x05        MTP failure
   0x06        network congestion
   0x07        unqualified
   0x08        error in message transport (Note)
   0x09        error in local processing (Note)
   0x0A        destination cannot perform reassembly (Note)
   0x0B        SCCP failure
   0x0C        hop counter violation
   0x0D        segmentation not supported

Loughney, et al.                                            [Page 47]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   0x0E        segmentation failure
   0xFA        Invalid ISNI routing request (Note)
   0xFB        Unauthorized message
   0xFC        Message Incompatibility
   0xFD        Cannot perform ISNI Constrained routing (Note)
   0xFE        Redundant ISNI constrained routing information (Note)
   0xFF        Unable to perform ISNI identification (Note)

   NOTE: Only applicable to XUDT(S) message.

2.9.5  Flags

      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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | trans. type   |  Hop Counter  |  segmenting   |D| B |A|   C   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A      Error Return option
          Value      Description
          0x0        No error message
          0x1        Return message on error

   B      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

   C      Importance
          Value      Description
          0x0        Least important
               :
          0x7        Highest importance

   D      Segmentation
          Value      Description
          0x0        No segmentation
          0x1        Segmentation

   Transfer Type has the following values:

          0       reserved
          1       unitdata
          2       long unitdata
          3       extended unitdata

   Hop Counter

Loughney, et al.                                            [Page 48]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000



          Value          Description
          0x0
          :
          0x15           Maximum number of GTT


   Segmenting field corresponds to the SCCP Segmenting parameter.

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |  segmenting   |
      +-+-+-+-+-+-+-+-+

   Bit 7 is coded as the following:

   _ 0:   in all segments but the first;
   _ 1:   first segment.

   Bit 6 is used to keep in the message in sequence delivery option
   required by the SCCP user and is coded as follows:

   _ 0:   Class 0 selected;
   _ 1:   Class 1 selected.

   Bits 4 and 5 are spare bits.

   Bits 0-3 of octet 1 are used to indicate the number of remaining
   segments. The values 0000 to 1111 are possible; the value 0000
   indicates the last segment.

   An SUA-layer MUST support receiving segmented messages & MUST be
   able to re-assembled segmented messages.  An SUA-layer at an SG MUST
   be able to segment SCCP messages destined for the SS7 network. An
   SUA-layer at an IPSP MAY support sending segmented messages.

2.9.6 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 = 0x0106         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   source reference number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The source reference number is a 3 octet long integer, which is
   generated by the local source to identify a connection.

   Valid values are from 0x0 to 0xFFFFFE, while 0xFFFFFF is reserved
   for future use.

Loughney, et al.                                            [Page 49]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000



2.9.7 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 = 0x0107         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 destination reference number                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Destination Reference Number is a 3 octet long integer, which is
   generated by the destination node to identify a connection.

   Valid values are from 0x0 to 0xFFFFFE, while 0xFFFFFF is reserved
   for future use.

2.9.8 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 = 0x0108         |             length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       congestion level                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length is one octet.

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

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

   Cause Type can have the following values:

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



Loughney, et al.                                            [Page 50]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


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

   Cause value in        Correspondence with Reference
   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

2.9.10 ASP Capabilities

   This parameter is used so that the ASP can report it's capabilities
   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 = 0x010A         |             length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          SCCP Variant         |0 0 0 0|a|b|c|d| interworking  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length is two octets.

   SCCP Variant field can contain the following values:

     Unidentified/unknown               0x0
     ITU-I SCCP                         0x1
     ITU-N SCCP                         0x2
     ANSI SCCP                          0x3
     Japanese SCCP                      0x4
     Chinese SCCP                       0x5
     Other                              0x6

   Flags

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

     0 indicates no support for the Protocol Class.

   Interworking

   Values


Loughney, et al.                                            [Page 51]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


     0x0 indicates no interworking with SS7 Networks.
     0x1 indicates IP Signaling Endpoint.
     0x2 indicates Signaling Gateway.

2.9.11 Status

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

   The valid values are shown in the following table.

          1     Application Server state change (AS_State_Change)
          2     Other

   The Status Id parameter identifies the status that is being
   notified. The valid values are shown in the following table.

   If the Status Type is AS_STATE_CHANGE

   If the Status Type is AS_State_Change the following Status
   Information values are used:

            1    Application Server Down (AS_Down)
            2    Application Server Up (AS_Up)
            3    Application Server Active (AS_Active)
            4    Application Server Pending (AS_Pending)
            5    Alternate ASP Active
            6    Insufficient ASPs

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

            1    Insufficient ASP resources active in AS

   This notification is not based on the SG reporting the state change
   of an ASP or AS.  For the value defined the SG is indicating to an
   ASP(s) in the AS that another ASP is required in order to handle the
   load of the AS.

2.9.12 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

Loughney, et al.                                            [Page 52]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Tag = 0x010C         |             length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Credit                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length is one octet.

2.9.13 SCMG Message Type

      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 = 0x010D       |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      SCMG  Message Type                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The SCMG Message Type 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
     254       SBR
     255       SRT

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

   Subsystem Number (SSN) is one octet.

   Subsystem multiplicity indicator (SMI) can have the following
   values:

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

Loughney, et al.                                            [Page 53]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000



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

   It is used exclusively for protocol class 3 in the data
   acknowledgment message to indicate the lower edge of the receiving
   window.

   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 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 SCU procedures
   in response to these events.

3.1 Peer Message Procedures

   On receiving a message, the SUA layer at the SG performs address
   translation and mapping (if needed), to determine the appropriate
   Application Server Process (ASP).  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.

3.1.1 Connection Oriented Timers

   The SUA layer needs to start a timer after sending a CR, RLSD or RSR
   message.

   Add more text.

3.2 Signaling Gateway Related Procedures

   These support the SUA transport of SCCP-User/SCCP boundary
   primitives.



Loughney, et al.                                            [Page 54]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000



   On receiving a SCCP message at the SG, the SUA layer performs
   address translation and mapping, to determine the appropriate
   Application Server Process (ASP).  The appropriate ASP can be
   determined based on the 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.

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

3.2.1 ASP Down

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

   ASPDN or even an ASPIA may not correlate to a SCCP SSP, as it
   depends upon the ASP load configuration (primary/backup or
   loadsharing specified in the routing context 'type' field) and also
   upon the ASP routing configuration.

   Where traffic for a single SSN is routed to just one ASP then the
   withdrawal of that ASP will result in a SSP being issued. By
   contrast, where a SSN is associated with more than one ASP and
   routing to the different ASPs is achieved using the routing context
   (e.g. TCAP TIDs) then the withdrawal of just one ASP will not yield
   a SSP message.

3.2.2 MTP 3 - SUA interaction

   The Signaling Gateway will need to manage the availability of the
   ASPs within the IP network; while reporting the status of endpoints
   in the SS7 network.  Therefore, there will be interworking between
   the MTP 3 layer and SUA.  MTP 3 indication messages (MTP Pause, MTP
   resume, MPT Status) need to be indicated to the peer SUA layer.

3.2.3 Support of Connectionless Data Transfer

   When SUA operates in an interworking scenario with traditional SS7
   networks, the SG (interworking function between SCCP and SUA) must
   ensure that the selected outgoing connectionless message type
   (UDT/S, XUDT/S or LUDT/S) is correctly understood by the recipient
   SCCP node. The criteria for message type selection shall be handled
   locally; this information can be based on the underlying MTP or
   remote SCCP capabilities, or selected messages types preferred by
   the recipient SCCP node.




Loughney, et al.                                            [Page 55]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


3.3 Layer Management Procedures

   The SUA layer needs to send and receive layer management messages.

3.4 SCTP Management Procedures

   These procedures support the SUA management of SCTP Associations and
   ASP Paths between SGs and ASPs.

3.4.1 State Management

   The SUA layer on at each AS needs to maintain the state of each ASP
   under its control, as a way to manage the state and connections of
   the local ASPs.  At a SG, the state of each ASP is needed as input
   to the SGs address translation and mapping function.

3.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:

      * Reception of messages from that ASP's SUA layer
      * Reception of messages from a different ASP's SUA layer
      * Reception of indications from the SCTP layer
      * Switch over timer triggers

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

   ASP-ACTIVE: The Application Server Process is available and
   application traffic is active.














Loughney, et al.                                            [Page 56]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


                  Figure 4: ASP State Transition Diagram

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

                  Figure 4: ASP State Transition Diagram

   SCTP Down: The local SCTP layer's SHUTDOWN COMPLETE notification or
   COMMUNICATION LOST notification.

3.4.1.2  AS States

   The state of the AS is maintained in the SUA layer.

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

      * ASP state transitions
      * Recovery timer triggers

   The possible states of an AS are:

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

   AS-UP: The Application Server is available but no application
   traffic is active (i.e., one or more related ASPs are in the ASP-UP
   state, but none in the ASP-Active state).




Loughney, et al.                                            [Page 57]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   AS-ACTIVE: The Application Server is available and application
   traffic is active.  This state implies that 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


3.4.2 ASPM procedures for primitives


Loughney, et al.                                            [Page 58]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   Before the establishment of an SCTP association the ASP state at
   both the AS and ASP is assumed to be "Down".

   When the SUA layer receives an M-SCTP ESTABLISH request primitive
   from the Layer Management, the SUA layer will try to establish an
   SCTP association with the remote SUA peer.  Upon reception of an
   eventual SCTP-Communication Up confirm primitive from the SCTP, the
   SUA layer will invoke the primitive M-SCTP ESTABLISH confirm to the
   Layer Management.

   Alternatively, if the remote SUA-peer establishes the SCTP
   association first, the SUA layer will receive an SCTP Communication
   Up indication primitive from the SCTP. The SUA layer will then
   invoke the primitive M-SCTP ESTABLISH indication to the Layer
   Management.

   Once the SCTP association is established, The SUA layer at an ASP
   will then find out the state of its local SUA-user from the Layer
   Management using the primitive M-ASP STATUS.  Based on the status of
   the local SUA-User, the local ASP SUA Application Server Process
   Maintenance (ASPM) function will initiate the ASPM procedures, using
   the ASP-Up/-Down/-Active/-Inactive messages to convey the ASP-state
   to the SG - see Section 2.5.

   If the SUA layer subsequently receives an SCTP-Communication Down
   indication from the underlying SCTP layer, it will inform the Layer
   Management by invoking the M-SCTP STATUS indication primitive. The
   state of the ASP will be moved to "Down."

   At an ASP, the Layer Management may try to reestablish the SCTP
   association using M-SCTP ESTABLISH request primitive.

3.4.3 ASPM procedures for peer-to-peer messages

3.4.3.1 ASP-Up

   An ASP sends an ASPUP to each remote AS to which it is a member of.
   When the ASPUP message is received, the remote AS will mark the
   remote ASP Inactive, as long as the ASP is not considered locked-out
   for local management reasons.  The remote peer replies with an ASP-
   Up Ack message in acknowledgement, to every ASPUP, even if the ASP
   is already marked as Inactive. If for any local reason (e.g.,
   management lock-out) the remote peer cannot respond with an ASP-Up
   Ack, the SG responds to an ASP-Up with an ASP-Down Ack message with
   Reason "Management Blocking".

   If the ASP does not receive a ASPUP ACK, the ASP may resend ASP-Up
   messages until it receives an ASP-Up Ack message.  The ASP must wait
   for the ASP-Up Ack message before sending any other messages. If the



Loughney, et al.                                            [Page 59]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   remote peer receives any other SUA messages from an ASP, before an
   ASP Up is received, the message should be discarded.

3.4.3.2 ASP Down

   The AS will mark the ASP as down and send a ASPDN message to the ASP
   if one of the following events occur:

        - an ASP Down (ASPDN) message is received from the ASP,
        - the ASP is locked by local maintenance.

   The SG 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.

   The ASP will send ASPDN whenever it wants to take down a ASP.  Since
   it is possible for ASPDN and ASPDN ACK messages to be lost (for
   example, during a node failover), the ASP can send ASPDN messages
   every t(a) seconds until the path comes down (i.e. until it receives
   a ASPDN message from the remote peer for that path).


3.4.3.3 ASP Version Control

   If a ASP Up message with an unknown version is received, the
   receiving end will respond with an Error message.  This will
   indicate to the sender which version 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 used
   on other nodes it is communicating with.

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

3.4.3.4 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 (ASPAC)
   message is received, the remote peer responds with an ASPAC ACK.
   The ASP cannot send any other messages until after the ASPAC ACK is
   received.  If the ASPAC ACK is not received within a certain period,
   the ASP may resend the ASPAC message.

   The ASP Active message optionally contains a list of one more
   Routing Contexts, indicating for 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 Type parameter in the ASPAC message indicates the traffic
   handling mode used in a particular Application Server, either Over-

Loughney, et al.                                            [Page 60]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   ride, Over-ride (standby), Load-share or Load-share (standby). If
   the remote peer determines that the mode indicated in an ASPAC 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 ASPAC message at a remote
   peer causes the all traffic for the AS to be sent to the ASP which
   sent the ASPAC.  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 ASPs in the AS, after stopping all
   traffic to that ASP.

   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 "Inactive or "Down" state.  At
   this point the ASP that sent the Over-Ride (Standby) ASPAC is moved
   to the Active state and the traffic is redirected.  No Notify
   messages are needed.

   In the Load-share mode, reception of an ASPAC message causes the
   redistribution of traffic to the ASP sending the ASPAC, 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 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 the AS. When needed, the ASP which sent the
   Loadshare (Standby) ASPAC is moved to the Active state and traffic
   is started. No Notify messages are needed to be sent.

   A node that receives an ASPAC with an incorrect Type for a
   particular Routing Context will respond with an Error Message, Cause
   = Invalid Traffic Handling Mode.  A node that receives an unknown
   Routing Context value responds with an Error message, Cause =
   Invalid Routing Context.

3.4.3.5 ASP Inactive

   When an ASP wishes to withdraw from receiving traffic, it sends an
   ASPIA to the applicable remote ASPs, within the AS from which it is
   withdrawing.  If the ASP is withdrawing from more than one AS, then
   the ASP issues either multiple ASPIA message, if multiple SCTP



Loughney, et al.                                            [Page 61]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   associations exist to the remote ASPs; or a single ASPIA message
   containing multiple Routing Contexts.

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

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

   In the Load-sharing mode, the remote AS 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
   is 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 may not be sent.  An ASPIA 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 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 ASPAC 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.

3.4.3.6 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 Identification.

   In the case where a NTFY (AS-Pending) message is sent by an SG that
   now has no ASPs active 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.3.3.7 Heartbeat





Loughney, et al.                                            [Page 62]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


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

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

4.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
   ASPAC but can only declare unavailability when all ASPs have issued
   ASPIA.

4.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)-+

Loughney, et al.                                            [Page 63]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000



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

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


4.1.2 Failover scenarios

   The following sequences address failover of SEP and ASP

4.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--------+
          <-----------------DUNA-----------------+
          +-----------------DAUD----------------->
                                                 +--------SST-------->

4.1.2.2 Successful ASP Failover scenario


Loughney, et al.                                            [Page 64]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


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

4.1.2.3 Unsuccessful ASP Failover scenario

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

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

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

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

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


Loughney, et al.                                            [Page 65]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   Each node is configured (via MIB or through discovery protocol) 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 Assosciation -|

                         |------- Establish SCTP Assosciation ------|

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


4.2.2 Failover scenarios


Loughney, et al.                                            [Page 66]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   The following sequences address failover of ASP

4.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------------>
              <----------ASP Act Ack--------+


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

5 Security

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

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



Loughney, et al.                                            [Page 67]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   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.

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

6 IANA Considerations

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

6.2 Port Number

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

   Protocol Extensions

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

Loughney, et al.                                            [Page 68]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


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

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

6.3.1 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.
   (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.

   [Editor's note: this Error Code should be added to all of the UAs]

6.3.3 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

Loughney, et al.                                            [Page 69]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


       multiple instances of this parameter type may be found within
   the
       same message type.

7 Timer Values

     Ta        2 seconds
     Tr        2 seconds

8 Acknowledgements

   The authors would like to thank Lode Coene, Joe Keller, Florencio
   Escobar-Gonzalez, Marja-Liisa Hamalainen and Markus Maanoja for
   their insightful comments and suggestions.

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

9 Authors' Addresses

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

   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

Loughney, et al.                                            [Page 70]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   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


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

Loughney, et al.                                            [Page 71]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000



   [M3UA]         MTP3-User Adaptation Layer <draft-ietf-sigtran-m3ua-
                  04.txt>, September 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.

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

Loughney, et al.                                            [Page 72]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


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

   General Protocol Messages
   ERR    ERR       Protocol data unit error -    -    X    X    -    X
   AUD    IT        Inactivity test          -    -    X    X    -    X

   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

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

Appendix B: Message Mapping Examples

1 SUA->SCCP


2 SCCP->SUA

   CLDT


Loughney, et al.                                            [Page 73]

Internet Draft       SS7 SCCP-User Adaptation Layer    November 15, 2000


   - A and B flags are mapped from 'Protocol Class' parameter
     received in XUDT/LUDT/UDT (or from Data Request primitive).

   - C flag is mapped from 'Importance parameter' received in XUDT/LUDT
     (or from Data Request primitive), or if not present a default
     value for the message type shall be used.

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
   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 74]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/