Internet Draft
 INTERNET-DRAFT                                             J. Loughney
 Internet Engineering Task Force                                  Nokia
                                            G. Sidebottom, Guy Mousseau
 Issued:  2 July 2000                                   Nortel Networks
 Expires: 2 January 2001                                     S. Lorusso
                                                    Unisphere Solutions


                  SS7 SCCP-User Adaptation Layer (SUA)
                     <draft-ietf-sigtran-sua-01.txt>


 Status of This Memo

 This document is an Internet-Draft and is in full conformance with all
 provisions of Section 10 of RFC 2026.

 Internet-Drafts are working documents of the Internet Engineering Task
 Force (IETF), its areas, and its working groups.  Note that other
 groups may also distribute  working documents as Internet-Drafts.

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

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

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

 This draft expires on 2 January 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 an
 IP Signaling Endpoint to IP Signaling Endpoint.  Protocol elements are
 added allow seamless operation peers in the SS7 and IP domains. 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 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 .............................9
   1.5 Internal Functions Provided in the SUA Layer ..................10
   1.6 Definition of SUA Boundaries ..................................11
 2 Protocol Elements .................................................11
   2.1 Common Message Header .........................................11
   2.2 SUA Connectionless Messages ...................................13
   2.3 Connection Oriented Messages ..................................15
   2.4 SS7 Signaling Network Management Messages .....................19
   2.5 Application Server Process Maintenance Messages ...............23
   2.6 Management Messages ...........................................27
   2.7 Vendor Specific Message .......................................29
   2.8 Fixed Length Parameters .......................................30
   2.9 Variable Length Paramters .....................................34
 3 Procedures ........................................................36
   3.1 Peer Message Procedures .......................................36
   3.2 Signaling Gateway Related Procedures ..........................36
   3.3 Layer Management Procedures ...................................36
   3.4 SCTP Management Procedures ....................................36
 4 Examples of SUA Procedures ........................................41
   4.1 Establishment of Association ..................................41
   4.2 ASP fail-over Procedures ......................................41
   4.3 SUA/SCCP-User Boundary Examples ...............................42
 5 Security ..........................................................42
   5.1 Introduction ..................................................42
   5.2 Threats .......................................................42
   5.3 Protecting Confidentiality ....................................43
 6 IANA Considerations ...............................................43
   6.1 SCTP Protocol ID ..............................................43
   6.2 Port Number ...................................................43
 7 Timer Values ......................................................43
 8 Acknowledgements ..................................................43
 9 Authors' Addresses ................................................43
 10 References .......................................................44
 Appendix A: Message mapping between SCCP and SUA. ...................45
 Copyright Statement .................................................45



















 Loughney, et al.                                            [Page 2] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 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.  In these
 networks, they may be some need for interworking between the SS7 and
 IP domains.  IP provides an effective way to transport user data and
 for operators to expand their networks and build new services.

 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 a virtual switch element
 handling all call processing for a unique set of SCCP-users.  The AS
 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.

 Loughney, et al.                                            [Page 3] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000



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

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

 Loughney, et al.                                            [Page 4] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000



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




 Loughney, et al.                                            [Page 5] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


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

    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

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

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

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



 Loughney, et al.                                            [Page 6] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


 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.

 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.

 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.


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

                   Figure 1: Generalized Architecture

 Loughney, et al.                                            [Page 7] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000



1.3.5 Generalized Signaling Gateway Network Architecture

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

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

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


   Signaling Gateway
   ****************
   * +----------+ *                                      **************
   * | AS1      | *                                      *  AS3       *
   * | ******** | *                                      *  ********  *
   * | * 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.



 Loughney, et al.                                            [Page 8] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


 An Application Server can be considered as a list of all ASPs
 configured/registered to handle SCCP-user messages within a certain
 range of routing information, known as a Routing Key.  One or more
 ASPs in the list may normally be active to handle traffic, while
 others may  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

 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.


 Loughney, et al.                                            [Page 9] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000



1.4.4 Interworking with SCCP Network Management Functions

 The SUA layer needs to support the following SCCP network management
 functions:

      Coord Request
      Coord Indication
      Coord Response
      Coord Confirm
      State Request
      State Indication
      Pcstate Indication

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
     DPC + SSN
     Host Name
     IP Address(es)

 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.

 That being said, currently, there is some work within the IETF
 studying translation of E.164 numbers to Host Names [ENUMS], [E.164-
 DNS]. 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.

 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.


 Loughney, et al.                                            [Page 10] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


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

 The following primitives are supported between the SUA and an SCCP-
 user.

      Connect Request
      Connect Indication
      Connect Responding
      Connect Confirm
      Data Request
      Data Indication
      Expedited Data Request
      Expedited Data Indication
      Disconnect Request
      Disconnect Indication
      Reset Request
      Reset Indication
      Reset Response
      Reset Confirm

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

 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Ver      |     Spare     |         Message Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Message Length          |A| B |  C  |D|X|  Hop Counter  |

 Loughney, et al.                                            [Page 11] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Source Address Ptr      |    Destination Address Ptr    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Mandatory Parameters Ptr   |    Optional Parameters Ptr    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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 Types

     Connectionless Messages

        Connectionless Data Transfer (CLDT)         0x0501
        Connectionless Data Acknowledge (CLDA)      0x0502

     Connection-Oriented Messages

        Connection Request (CORE)                   0x0701
        Connection Acknowledge (COAK)               0x0702
        Release Request (RELRE)                     0x0703
        Release Complete (RELCO)                    0x0704
        Reset Confirm (RESCO)                       0x0705
        Reset Request (RESRE)                       0x0706
        Connection Oriented Data Transfer (CODT)    0x0707
        Connection Oriented Data Acknowledge (CODA) 0x0708

     Application Server Process Maintenance (ASPM) Messages

        ASP Up (ASPUP)                              0x0301
        ASP Down (ASPDN)                            0x0302
        Heartbeat(BEAT)                             0x0303
        ASP Active (ASPAC)                          0x0401
        ASP Inactive (ASPIA)                        0x0402
        Notify (NTFY)                               0x0404

     SUA Management Messages

        Error (ERR)                                 0x0000
        Audit (AUD)                                 0x0001

     SS7 Signaling Network Management (SSNM) Messages

        Destination Unavailable (DUNA)              0x0201
        Destination Available (DAVA)                0x0202
        Destination State Audit (DAUD)              0x0203
        SS7 Network Congestion State (SCON)         0x0204
        Vendor-Specific Message (VEN)               0xFFFE

2.1.3 Message Length

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


 Loughney, et al.                                            [Page 12] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


2.1.4 Flags

 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    priority
      Value      Description
      0x0        Least important
       :
      0x7        Highest importance

 D    segmentation
      Value      Description
      0x0        No segmentation
      0x1        Segmentation

 E    Hop Counter
      Value      Description
      0x0
       :
      0x15       Maximum number of GTT
      0x16
       :         Spare
      0x255

2.1.5 Pointer Usage

 The pointer will point to the byte at the start of the parameter.  If
 the pointer value is 0, then the parameter is not present in the
 message.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +---------------+---------------+
     |  Pointer MSB  |  Pointer LSB  |
     +---------------+---------------+
     /             . . .             /
     \                               \
     +---------------+---------------+
     |  X + Pointer  |               |
     +---------------+---------------+


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.

 Loughney, et al.                                            [Page 13] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000



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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  /                             data                              /
  \                                                               \
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Variable Length Parameters
     Originating Address           Mandatory
     Destination Address           Mandatory
     Data                          Mandatory

 Implementation note:

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

2.2.2 Connectionless Data Acknowledge

 This message is used to acknowledge receipt of data 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Cause                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                             data                              /

 Loughney, et al.                                            [Page 14] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


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

 Variable Length Parameters
     Originating Address           Mandatory
     Destination Address           Mandatory
     Data                          Optional

 Fixed Length Parameters
     Cause                         Mandatory

 Implementation note:

 This message covers the following SCCP messages: protocol data unit
 error (ERR), long unitdata service (LUDTS), unitdata service (UDTS),
 extended unitdata service (XUDTS).

2.3 Connection Oriented Messages

2.3.1 Connection Oriented Data Transfer

 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 destination reference number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                             data                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     Sequence number               Optional
      Destination Reference Number Mandatory

 Variable Length Parameters
     Data                          Mandatory

 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 and/or
 report errors.

    0                   1                   2                   3

 Loughney, et al.                                            [Page 15] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 destination reference number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     Sequence number               Optional
     Destination Reference Number  Mandatory

 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   source reference number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                             data                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     Source Reference Number       Mandatory

 Variable Length Parameters
     Data                          Optional

2.3.4 Connection Acknowledge

 This message is used to acknowledge and/or refuse a connection request
 between to peer endpoints.

 Loughney, et al.                                            [Page 16] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 destination reference number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   source reference number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                             data                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     Destination Reference Number  Mandatory *1
     Source Reference Number       Mandatory *1
     Cause                         Mandatory *2

 Variable Length Parameters
     Data                          Optional

 *1  Mandatory for connection confirmation, it is not needed in the case
    that the connection is refused.

 *2  Mandatory in the case that the connection is refused.

 Implementation note:

 This message covers the following SCCP messages: connection confirm
 (CC), connection refused (CREF).

2.3.5 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 destination reference number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Loughney, et al.                                            [Page 17] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   source reference number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Cause                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                             data                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     Destination Reference Number  Mandatory
     Source Reference Number       Mandatory
     Cause                         Mandatory

 Variable Length Parameters
     Data                          Optional

2.3.6 Release Complete

 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 destination reference number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   source reference number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     Destination Reference Number  Mandatory
     Source Reference Number       Mandatory

2.3.7 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 destination reference number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Loughney, et al.                                            [Page 18] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


   |                   source reference number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Cause                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     Destination Reference Number  Mandatory
     Source Reference Number       Mandatory
     Cause                         Mandatory

2.3.8 Reset Confirm

 This message is used to confirm the Reset Request.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 destination reference number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   source reference number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     Destination Reference Number  Mandatory
     Source Reference Number       Mandatory

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.

 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          protocol id                          |

 Loughney, et al.                                            [Page 19] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        network appearance                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          info string                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     Protocol ID                   Optional
     Network Appearance            Optional

 Variable Length Parameters
     Source Address                Mandatory
     Destination Address           Mandatory
     Info String                   Optional

 Note: The Source Address refers to the address of the sender of the
 DUNA.  The Destination Address refers to the address of the
 unreachable destination.

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 MTP3-User protocol is expected to resume traffic to the
 affected destination through the SG initiating the DUNA.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          protocol id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        network appearance                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          info string                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters

 Loughney, et al.                                            [Page 20] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


     Protocol ID                   Optional
     Network Appearance            Optional

 Variable Length Parameters
     Source Address                Mandatory
     Destination Address           Mandatory
     Info String                   Optional

 Note: The Source Address refers to the address of the sender of the
 DAVA.  The Destination Address refers to the address of the
 destination which is now reachable.

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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          protocol id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        network appearance                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          info string                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     Protocol ID                   Optional
     Network Appearance            Optional

 Variable Length Parameters
     Source Address                Mandatory
     Destination Address           Mandatory
     Info String                   Optional

 Note: The Source Address refers to the address of the sender of the
 DAUD.  The Destination Address refers to the address of the
 destination who's state is being audited.

 Loughney, et al.                                            [Page 21] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000



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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          protocol id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       network appearance                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       congestion level                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          info string                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     Protocol ID                   Optional
     Network Appearance            Optional
     Congestion Level              Optional

 Variable Length Parameters
     Source Address                Mandatory
     Destination Address           Mandatory
     Info String                   Optional

 Note: The Source Address refers to the address of the sender of the
 SCON.  The Destination Address refers to the address of the
 unreachable destination.

 Implementation note:

 This message covers the following SCCP message: subsystem congested
 (SSC).



 Loughney, et al.                                            [Page 22] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


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 ready to receive traffic or maintenance
messages.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        ASP Capabilities                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ALI                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          info string                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     ASP Capabilities              Manditory (see section 2.8.10)
     Adaptation Layer Identifier   Optional

 Variable Length Parameters
     Info String                   Optional


2.5.2 ASP Down (ASPDN)

The ASP Down (ASPDN) message is used to indicate to a remote SUA peer
that the adaptation layer is not ready to receive traffic or maintenance
messages.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Loughney, et al.                                            [Page 23] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          reason code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          info string                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     Reason Code                   Mandatory

 Variable Length Parameters
     Info String                   Optional

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

 Implementation note:

 This message covers the following SCCP message: subsystem-prohibited
 (SSP).

2.5.3 Heartbeat (BEAT)

 The Heartbeat message is optionally used to ensure that the SUA peers
 are still available to each other.  It is recommended for use when the
 SUA runs over a transport layer other than the SCTP, which has its own
 heartbeat.

 The BEAT message contains no parameters.

2.5.4 ASP Active (ASPAC)

 The ASPAC message is sent by an ASP to indicate to an SG/AS that it is
 Active and ready to be used.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Loughney, et al.                                            [Page 24] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


   |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Type                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Routing Context                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          info string                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Variable Length Parameters
      Routing Context              Mandatory
      Info String                  Optional

 Implementation note:

 This message covers the following SCCP message: subsystem-allowed
 (SSA).

2.5.5 ASP Inactive (ASPIA)

 The ASPIA message is sent by an ASP to indicate to an SG/AS that it is
 no longer an active ASP to be used from within a list of ASPs.  The
 SG/AS will respond with an ASPIA message and either discard incoming
 messages or buffer for a timed period and then discard.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Type                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Routing Context                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          info string                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Variable Length Parameters
      Routing Context              Optional
      Info String                  Optional


 Loughney, et al.                                            [Page 25] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


 Implementation note:

 This message covers the following SCCP message: subsystem-out-of-
 service-request (SOR).

2.5.6 ASP Inactive Ack (ASPIAK)

 The ASPIAK message is sent by the SG/AS in response to an ASPIA to the
 sending ASP that it acknowledges the ASPIA.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Type                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Routing Context                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          info string                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Variable Length Parameters
     Routing Context               Optional
     Info String                   Optional


 Implementation note:

 This message covers the following SCCP message: subsystem-out-of-
 service-grant (SOG).

2.5.7 Notify (NTFY)

 The NTFY message is sent by an AS to indicate any change of status in
 the AS or ASP to an ASP. AS sends this message to all concerned
 endpoints.

 The format for the NTFY 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Loughney, et al.                                            [Page 26] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Status                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Type                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Routing Context                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          info string                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The NTFY message contains the following parameters:

 Fixed Length Parameters
      Status Type                  Mandatory

 Variable Length Parameters
     Routing Context               Optional
     Info String                   Optional

2.6 Management Messages

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

2.6.1 Error (ERR)

 The ERR 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Ver        |   Spare     |         Message Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Message Length          |A| B |  C  |D|X|  Hop Counter  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Source Address Ptr      |    Destination Address Ptr    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Mandatory Parameters Ptr   |    Optional Parameters Ptr    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \

 Loughney, et al.                                            [Page 27] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Cause                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                             data                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Fixed Length Parameters
     Cause                         Mandatory

 Variable Length Parameters
     Source Address                Mandatory
     Destination Address           Mandatory
     Data                          Optional

The Error Code can be one of the following values:

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

2.6.2 Audit

 This message is used to audit the current state of 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                        Source Address                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     destination address                       /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                             data                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


 Variable Length Parameters
     Source Address                Mandatory

 Loughney, et al.                                            [Page 28] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


     Destination Address           Mandatory
     Data                          Optional

 Implementation note:

 This message covers the following SCCP messages: inactivity test (IT),
 subsystem-status-test (SST).


2.7 Vendor Specific Message

 This is to allow vendors to support their own extended message not
 defined by the IETF. It MUST not affect the operation of the SUA.

 Endpoints not equipped to interpret the vendor-specific messages sent
 by a remote endpoint MUST ignore it (although it may be reported).
 Endpoints that do not receive desired vendor-specific information
 SHOULD make an attempt to operate without it, although they may do so
 (and report they are doing so) in a degraded mode.

 A summary of the Vendor-specific extension format is shown below. The
 fields are transmitted from left to right.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Message Type = 0xFFFE     |      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor-Id                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                        Parameter Value                        /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type: 16 bit u_int

      0xFFFE for all Vendor-Specific parameters.

   Length: 16 bit u_int

      Indicate the size of the parameter in octets, including the
      Type, Length, Vendor-Id, and Value fields.

   Vendor-Id: 32 bit u_int

      The high-order octet is 0 and the low-order 3 octets are the
      SMI Network Management Private Enterprise Code of the Vendor
      in network byte order, as defined in the Assigned Numbers (RFC
      1700).

   Value: variable length

      The Value field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished
      octets.

      The codification of the range of allowed usage of this field is

 Loughney, et al.                                            [Page 29] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


      outside the scope of this specification.

      It SHOULD be encoded as a sequence of vendor type / vendor length
      / value fields, as follows.  The parameter field is dependent on
      the vendor's definition of that attribute.  An example encoding
      of the Vendor-Specific attribute using this method 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Parameter Type = 0xFFFE    |      Parameter Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Vendor-Id                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          VS-Type              |             VS-Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                          VS-Value                             /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    VS-Type: 16 bit u_int

      This field identifies the parameter included in the VS-Value
      field. It is assigned by the vendor.

    VS-Length: 16 bit u_int

      This field is the length of the vendor-specific parameter and
      includes the VS-Type, VS-Length and VS-Value (if included)
      fields.

    VS-Value:  Variable Length

      This field contains the parameter identified by the VS-Type
      field. It's meaning is identified by the vendor.

2.8 Fixed Length Parameters

     Parameter Name                     Parameter ID
     ==============                     ============
     Sequence Number                    0x0002
     Source Reference Number            0x0003
     Destination Reference Number       0x0004
     Cause                              0x0007
     Protocol Identifier                0x0008
     Network Appearance                 0x0009
     Congestion Level                   0x000C
     Adaptation Layer Identifier        0x000D
     ASP ID                             0x000E
     ASP Capabilities                   0x000F
     Status                             0x0010

2.8.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Loughney, et al.                                            [Page 30] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


   |                        Sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.8.2 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   source reference number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.8.3 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 destination reference number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.8.4 Cause

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          reason code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Reason code may be one of the following reasons:

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

2.8.5 Protocol Identifier

 The Protocol Identifier parameter identifies the SCCP version/variant.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          protocol id                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

 Loughney, et al.                                            [Page 31] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        network appearance                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.8.7 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       congestion level                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

2.8.8 Adaptation Layer Identifier

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

The optional Adaptation Layer Identifier (ALI) is a string that
identifies the adaptation layer.  This string MUST be set to "SUA" which
results in a length of 3.  The ALI would normally only be used in the
initial ASP Up message across a new SCTP association to ensure both
peers are assuming the same adaptation layer protocol.

2.8.9 ASP ID

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Loughney, et al.                                            [Page 32] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


   |                            ASP ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 2.8.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            reserved           |0 0 0 0|a|b|c|d| interworking  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
     0x0 indicates no interworking with SS7 Networks.
     0x1 indicates IP Signaling Endpoint.
     0x2 indicates Signaling Gateway.

 2.8.11 Status

 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Status Type           |         Status Id             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

      Value         Description
      0x1           AS_STATE_CHANGE
      0x2           ASP_STATE_CHANGE

 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

      Value         Description
      0x1           AS_DOWN
      0x2           AS_UP

 Loughney, et al.                                            [Page 33] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


      0x3           AS_PART_ACTIVE
      0x4           AS_ACTIVE
      0x5           AS_PENDING

 If the Status Type is ASP_STATE_CHANGE

      Value         Description
      0x1           ASP_DOWN
      0x2           ASP_UP
      0x3           ASP_ACT_NEW
      0x4           ASP_ACT_OLD
      0x5           AS_ACTIVE

2.9 Variable Length Paramters

     Parameter Name                     Parameter ID
     ==============                     ============
      Data                              0x0001
      Source Address                    0x0005
      Destination Address               0x0006
      Info String                       0x000A
      Routing Context                   0x000B

2.9.1 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                             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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1|      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 analized.

 Type of Address

     Unknown/Undeterminable        0x00000000
     SS7 Point Code                0x00000001
     Global Title                  0x00000002
     Host Name                     0x00000003
     IPv4 Address                  0x00000004
     IPv6 Address                  0x00000005

 Loughney, et al.                                            [Page 34] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000



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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0|      Parameter Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         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 analized.

 Type of Address

     Unknown/Undeterminable        0x00000000
     SS7 Point Code                0x00000001
     Global Title                  0x00000002
     Host Name                     0x00000003
     IPv4 Address                  0x00000004
     IPv6 Address                  0x00000005

2.9.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                          info string                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.9.5 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Type                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Routing Context                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




 Loughney, et al.                                            [Page 35] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 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.

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 performs address translation and
 mapping (if needed), 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.

3.2 Signaling Gateway Related Procedures

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

 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.3 Layer Management Procedures

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

3.4 SCTP Management Procedures



 Loughney, et al.                                            [Page 36] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


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

3.4.1 State Maintenance

 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.

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


 Loughney, et al.                                            [Page 37] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


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

                 Figure 4: ASP State Transition Diagram


 SCTP CDI: The local SCTP layer's Communication Down Indication to the
 Upper Layer Protocol. The local SCTP will send this indication when it
 detects the loss of connectivity to the ASP's SCTP  layer.

 Ts: Switch over Timer Triggers

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

 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 ACTIVE   +-------------+
       |          |------------------------>|             |
       |  AS-UP   |                         |  AS-ACTIVE  |
       |          |                         |             |
       |          |<                       -|             |
       +----------+ \                     / +-------------+
          ^   |      \ Tr Trigger        /       ^    |
          |   |       \ at least one    /        |    |
          |   |        \ ASP in UP     /         |    |


 Loughney, et al.                                            [Page 38] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


          |   |         \             /          |    |
          |   |          \           /           |    |
          |   |           \     /---/            |    |
  one ASP |   |            \   /         one ASP |    | ACTIVE ASP
  trans   |   | all ASP     \-/----\     trans   |    | trans to UP or
  to UP   |   | trans to     /      \    ACTIVE  |    | ACTIVE ASP
          |   | DOWN        /        \           |    | SCTP CDI
          |   |            /          \          |    |
          |   |           /            \         |    |
          |   |          /all ASP       \        |    |
          |   v         / trans to       \       |    v
       +----------+    /  DOWN            \ +-------------+
       |          |<--/                    -|             |
       | AS-DOWN  |                         | AS-PENDING  |
       |          |                         |  (queuing)  |
       |          |<------------------------|             |
       +----------+    Tr Trigger no ASP    +-------------+
                        in UP state or
                      prev ACTIVE ASP trans
                         to DOWN state

       Tr = Recovery Timer

                  Figure 5: AS State Transition Diagram


3.4.2 ASPM procedures for primitives

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

 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.


 Loughney, et al.                                            [Page 39] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


3.4.3 ASPM procedures for peer-to-peer messages

3.4.3.1 ASP-Up

 The AS will mark the path as up if an explicit ASP UP (ASPUP) message
 is received and internally the path is allowed to come up (i.e., not
 in a locked local maintenance state). An ASP UP (ASPUP) message will
 be sent to acknowledge the received ASPUP. The SG will respond to a
 ASPUP with a ASPDN message if the path is in a locked maintenance
 state.

 The receiving ASP will send a ASPUP message in response to a received
 ASPUP message from the ASP even if that path was already marked as UP.
 The paths are controlled by the ASP.

 The ASP will send ASPUP messages every t(a) seconds until the path
 comes up (i.e. until it receives a ASPUP message from the remote peer
 for that path).  The ASP may decide to reduce the frequency (say to
 every 5 seconds) if the an acknowledgement is not received after a few
 tries.

 The ASP should wait for the ASPUP message from the remote peer before
 transmitting ASP maintenance messages (ASPIA or ASPAC) or SUA messages
 or it will risk message loss.

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 AS will also send a ASPDN message when the ASP is already down and
 a ASPDN) message is received from the ASP.

 The ASP will send ASPDN whenever it wants to take down a ASP.  Since
 it is possible for ASPDN messages and responses can 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



 Loughney, et al.                                            [Page 40] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


 When an ASP Active (ASPAC) message is received, the ASP will start
 traffic routing to that ASP.  Reception of a ASPAC message overrides
 any previous ASPAC messages and results in the ASP associated with the
 ASPAC message to become the newly active ASP.

3.4.3.5 ASP Inactive

 When a ASPIA message is received, message transmission to that ASP
 ceases.  The ASP will either discard all incoming messages or start
 buffering the incoming messages for T(r)seconds after which messages
 will be discarded.

 If the ASP is down, all of the Paths that were supported by that ASP
 are, by default, down.

4 Examples of SUA Procedures

4.1 Establishment of Association

4.1.1 SG Architecture

      SG               ASP1                ASP2
                       (Primary)           (Backup)
       |                  |                   |
       <----ASP Up--------+                   |
       +----ASP Up (Ack)-->                   |
       |                  |                   |
       <-----------------------ASP Up---------+
       +-----------------------ASP Up (Ack)--->
       |                  |                   |
       <----ASP Active----+                   |
       +-ASP Active Ack--->                   |
       |                  |                   |

4.1.2 IP to IP Architecture

    ASP1 (AS1)         ASP1 (AS2)         ASP2 (AS2)
                       (Primary)           (Backup)
       |                  |                   |
       <----ASP Up--------+                   |
       +----ASP Up (Ack)-->                   |
       |                  |                   |
       <-----------------------ASP Up---------+
       +-----------------------ASP Up (Ack)--->
       |                  |                   |
       <----ASP Active----+                   |
       +-ASP Active Ack--->                   |
       |                  |                   |

4.2 ASP fail-over Procedures

        SG                       ASP1                       ASP2
         |                         |                          |
         |<-----ASP Inactive-------|                          |
         |---NTFY(ASP Inactive)--->|                          |
         |--------------------NTFY(ASP-Inactive) (Optional)-->|
         |                         |                          |
         |<------------------------------ ASP Active----------|


 Loughney, et al.                                            [Page 41] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


         |-----------------------------NTFY(ASP-Active)------>|
         |                                                    |


4.3 SUA/SCCP-User Boundary Examples

4.3.1 Data Transfer

 This is an example of data transfer, assuming associations are already
 established.

      SEP           SG          SG         ASP         ASP
     SCCP           SUA         SCTP       SCTP         SUA
       |            |           |           |           |
       +----UDT----->           |           |           |          
       |            +---Send---->           |           |
       |            |.. . . . . . . CLDT . . . . . . . .>
       |            |           +---data---->           |
       |            |           |           +-data arr-->
       |            |           |           <-rec data--|
       |            |           <---sack----+           |
       |            <-data arr--+           |           |
       |            +-rec data-->           |           |
       |            < . . . . . . . CLDA . . . . . . . ..
       |            |           |           |           |


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.

 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.

 Loughney, et al.                                            [Page 42] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000



 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.  In such a case, 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 Protocol ID

 A request will be made to IANA to assign protocol IDs.  A protocol ID
 for the SUA will be registered.

 The protocol ID is included in each SCTP data chunk, to indicate which
 protocol SCTP is carrying. This protocol 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.

6.2 Port Number

 A request will be made to IANA to assign an SUA Port Number.  This
 Port Number is the port which the SG listen to when receiving SCTP
 datagrams.

7 Timer Values

     Ta        2 seconds
     Tr        2 seconds

8 Acknowledgements

 The authors would like to thank Lode Coene, 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
 john.loughney@nokia.com

 Greg Sidebottom
 Nortel Networks
 3685 Richmond Rd,
 Nepean, Ontario, Canada  K2H 5B7

 Loughney, et al.                                            [Page 43] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000


 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

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.0.0 (2000-01) 'Technical Specification
                3rd Generation Partnership Project; Technical
                Specification Group Radio Access Network; UTRAN Iu
                Interface RANAP Signalling'

 [SCTP]         Stream Control Transport Protocol , June 2000, Work in Progress.

 [M3UA]         MTP3-User Adaptation Layer , March 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.0.0 (2000-01) "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" ,
                December 1999, Work in Progress.

 [E.164-DNS]    "ENUM Service Specific Provisioning: Principles of
                Operation" , , April
                2000, Work in Progress.

 Loughney, et al.                                            [Page 44] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000




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    -    -    -    -
 CLDA     UDTS      Unitdata service         X    X    -    -    -    -
 CLDA     XUDTS     Extended unitdata serv.  X    X    -    -    -    -
 CLDA     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
 VEN      n/a       n/a                      -    -    -    -    -    X

 SS7 MGT Messages
 DUNA     SSP       subsystem-prohibited     -    -    -    -    X    -
 DAVA     SSA       subsystem-allowed        -    -    -    -    X    -
 DAUD     SST       subsystem-status-test    -    -    -    -    X    -
 SCON     SSC       SCCP/subsystem-congested -    -    -    -    X    -
 SOR                subsystem-oos-req        -    -    -    -    X    -
 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

Copyright Statement

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

 Loughney, et al.                                            [Page 45] 
 Internet Draft       SS7 SCCP-User Adaptation Layer      July 2, 2000



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