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

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

INTERNET-DRAFT                                              J. Loughney
Internet Engineering Task Force                                   Nokia
                                            G. Sidebottom, Guy Mousseau
Issued:  12 May 2000                                    Nortel Networks
Expires: 12 November 2000                                    S. Lorusso
                                                    Unisphere Solutions


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


Status of This Memo

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

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

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

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


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

Abstract

This Internet Draft defines a protocol for the transport of any SS7
SCCP-User signaling (e.g., TCAP, RANAP, etc.) over IP using the Simple
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       May 12, 2000



1.  Introduction.......................................................4
 1.1 Scope ............................................................4
 1.2 Terminology ......................................................4
 1.3 Signaling Transport Architecture .................................6
  1.3.1 Protocol Architecture for TCAP Transport ......................6
  1.3.2 Protocol Architecture for RANAP Transport .....................6
  1.3.3 All IP Architecture ...........................................7
  1.3.4 Generalized Point-to-Point Network Architecture ...............8
  1.3.5 Generalized Signaling Gateway Network Architecture ............8
  1.3.6 ASP Fail-over Model and Terminology ...........................9
 1.4 Services Provided by the SUA Layer ..............................10
  1.4.1 Support for the transport of SCCP-User Messages ..............10
  1.4.2 SCCP Protocol Class Support ..................................10
  1.4.3 Native Management Functions ..................................10
  1.4.4 Interworking with SCCP Network Management Functions ..........10
  1.4.5 Support for the management between the SG and ASP. ...........11
 1.5 Internal Functions Provided in the SUA Layer ....................11
  1.5.1 Address Translation and Mapping at the SG ....................11
  1.5.2 SCTP Stream Mapping ..........................................11
 1.6 Definition of SUA Boundaries ....................................12
  1.6.1 Definition of the upper boundary .............................12
  1.6.2 Definition of the lower boundary .............................12
2 Protocol Elements...................................................12
 2.1 Common Message Header ...........................................12
  2.1.1 SUA Protocol Version .........................................12
  2.1.2 Message Types ................................................13
  2.1.3 Message Length ...............................................13
  2.1.4 Flags ........................................................13
  2.1.5 Usage Pointers ...............................................14
 2.2 SUA Connectionless Messages .....................................14
  2.2.1 Connectionless Data Transfer .................................14
  2.2.2 Connectionless Data Acknowledge ..............................15
 2.3 Connection Oriented Messages ....................................16
  2.3.1 Connection Oriented Data Transfer ............................16
  2.3.2 Connection Oriented Data Acknowledge .........................17
  2.3.3 Connect Request ..............................................17
  2.3.4 Connection Acknowledge .......................................18
  2.3.5 Release Request ..............................................19
  2.3.6 Release Complete .............................................20
  2.3.7 Reset Request ................................................20
  2.3.8 Reset Confirm ................................................21
 2.4 SS7 Signaling Network Management Messages .......................21
  2.4.1 Destination Unavailable ......................................21
  2.4.2 Destination Available ........................................22
  2.4.3 Destination State Audit ......................................23
  2.4.4 SS7 Network Congestion .......................................24
  2.4.5 Destination User Part Unavailable ............................25
 2.5 Application Server Process Maintenance Messages .................26
  2.5.1 ASP Up (ASPUP) ...............................................26
  2.5.2 ASP Down (ASPDN) .............................................27
  2.5.3 ASP Active (ASPAC) ...........................................28
  2.5.4 ASP Inactive (ASPIA) .........................................29
  2.5.5 ASP Inactive Ack (ASPIAK) ....................................30
  2.5.6 ASP Takeover (ASPTO) .........................................30
  2.5.7 Notify (NTFY) ................................................32
 2.6  Management Messages ............................................33
  2.6.1 Error (ERR) ..................................................33
  2.6.2 Audit ........................................................34

Loughney, et al.                                              [Page 2]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


 2.7 Vendor Specific Message .........................................34
 2.8 Fixed Length Paramters ..........................................36
  2.8.1 Sequence Number ..............................................36
  2.8.2 Source Reference Number ......................................36
  2.8.3 Destination Reference Number .................................36
  2.8.4 Cause ........................................................37
  2.8.5 Protocol Identifier ..........................................37
  2.8.6 Network Appearance ...........................................37
  2.8.7 Congestion Level .............................................38
  2.8.8 Adaptation Layer Identifier ..................................38
  2.8.9 ASP ID .......................................................38
 2.9 Variable Length Paramters .......................................39
  2.9.1 Data .........................................................40
  2.9.2 Source Address (=CLG) ........................................40
  2.9.3 Destination Address (=CLD) ...................................40
  2.9.4 Info String ..................................................41
  2.9.5 Routing Context ..............................................41
3 Procedures..........................................................42
 3.1 Procedures to support the SUA Services ..........................42
  3.1.1 Receipt of Local primitives ..................................42
 3.2 Procedures to support the SUA Layer Management Services .........42
  3.2.1 Layer Management primitives procedures .......................42
  3.2.2 Receipt of Peer Management messages ..........................42
 3.3 Procedures to support the SUA SCTP Management Services ..........42
  3.3.1 State Maintenance ............................................42
  3.3.2 ASPM procedures for primitives ...............................44
  3.3.3 ASPM procedures for peer-to-peer messages ....................45
 3.4 Procedures to support the SUA Services ..........................46
  3.4.1 At an SG .....................................................46
  3.4.2 At an ASP ....................................................46
4 Examples of SUA Procedures..........................................46
 4.1 Establishment of Association ....................................46
 4.2 ASP fail-over Procedures ........................................47
  4.2.1 For Primary/Backup model .....................................47
 4.3 SUA/SCCP-User Boundary Examples .................................48
  4.3.1 Data Tranfer .................................................48
5 Security............................................................48
 5.1 Introduction ....................................................48
 5.2 Threats .........................................................48
 5.3 Protecting Confidentiality ......................................48
6 IANA Considerations.................................................49
 6.1 SCTP Protocol ID ................................................49
 6.2 Port Number .....................................................49
7 Timer Values........................................................49
8 Acknowledgements....................................................49
9 Author's Addresses..................................................49
9 References..........................................................50
Appendix A Message mapping between SCCP and SUA.......................50












Loughney, et al.                                              [Page 3]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 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 an
   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 4]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 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.

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



Loughney, et al.                                              [Page 5]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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


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,

Loughney, et al.                                              [Page 6]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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)

This architecture can be used to carrying an protocol which use 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 removes the
need for signaling gateway functionality.


Loughney, et al.                                              [Page 7]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

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

Loughney, et al.                                              [Page 8]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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.

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


Loughney, et al.                                              [Page 9]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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.

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

Loughney, et al.                                              [Page 10]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


     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.

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.



Loughney, et al.                                              [Page 11]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

Loughney, et al.                                              [Page 12]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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)                   0x0601
        Connection Acknowledge (COAK)               0x0602
        Release Request (RELRE)                     0x0603
        Release Complete (RELCO)                    0x0604
        Reset Confirm (RESCO)                       0x0605
        Reset Request (RESRE)                       0x0606
        Connection Oriented Data Transfer (CODT)    0x0607
        Connection Oriented Data Acknowledge (CODA) 0x0608

     Application Server Process Maintenance (ASPM) Messages

        ASP Up (ASPUP)                           0x0301
        ASP Down (ASPDN)                         0x0302
        ASP Active (ASPAC)                       0x0401
        ASP Inactive (ASPIA)                     0x0402
        ASP Takeover (ASPTO)                     0x0403
        Notify (NTFY)                            0x0404
        No Active ASP (NAASP)                    0x0405

     SUA Management Messages

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

     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
        Destination User Part Unavailable (DUPU) 0x0205
        Vendor-Specific Message (VEN)            0xFFFE

2.1.3 Message Length

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

2.1.4 Flags

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

 B    Protocol class

Loughney, et al.                                              [Page 13]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

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.

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

Loughney, et al.                                              [Page 14]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

Loughney, et al.                                              [Page 15]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 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 0 0 1|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                             data                              /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Loughney, et al.                                              [Page 16]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

Loughney, et al.                                              [Page 17]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

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

Loughney, et al.                                              [Page 18]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

Loughney, et al.                                              [Page 19]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

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

Loughney, et al.                                              [Page 20]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


   |                 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 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      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 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Ver        |   Spare     |         Message Type          |

Loughney, et al.                                              [Page 21]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       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                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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
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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Ver        |   Spare     |         Message Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Message Length          |A| B |  C  |D|X|  Hop Counter  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Source Address Ptr      |    Destination Address Ptr    |

Loughney, et al.                                              [Page 22]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

Loughney, et al.                                              [Page 23]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

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

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 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 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).

2.4.5 Destination User Part Unavailable

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

    0                     1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      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    |

Loughney, et al.                                              [Page 25]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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 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 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
     Reason                        Mandatory
     Protocol ID                   Optional
     Network Appearance            Optional
     Congestion Level              Optional

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

2.5 Application Server Process Maintenance Messages

2.5.1 ASP Up (ASPUP)

The ASP UP (ASPUP) message is used to indicate to a remote SUA peer that
the Adaptation layer is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Loughney, et al.                                              [Page 26]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

Loughney, et al.                                              [Page 27]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

Loughney, et al.                                              [Page 28]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

Loughney, et al.                                              [Page 29]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


     Routing Context               Optional
     Info String                   Optional

Implementation note:

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

2.5.5 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      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                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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.6 ASP Takeover (ASPTO)


Loughney, et al.                                              [Page 30]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


The ASPTO message is sent by an ASP to indicate to an SG/AS that it will
be replacing an active ASP, in a controlled manner.

    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                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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 1 0 1|            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            ASP ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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
     ASP ID                        Optional
     Info String                   Optional

The optional ASP ID parameter identifies an ASP, that will be taken over
by the ASP that is sending this message. SG/AS would keep sending
traffic to both the ASPs for some time. Either because of a timer or an
explicit ASPIA message from the taken over ASP, the controling entity
would remove that ASP from the active ASPs list. During the time when
both ASPs receive traffic, all messages/traffic corresponding to new
transactions/calls will be sent to the new ASP and traffic corresponding
to the continued work would be sent to the old ASP.

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

Loughney, et al.                                              [Page 31]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

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

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


Loughney, et al.                                              [Page 32]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


Fixed Length Parameters
     Status Type                   Manditory

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


Loughney, et al.                                              [Page 33]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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


Loughney, et al.                                              [Page 34]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

Loughney, et al.                                              [Page 35]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

   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 Paramters

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

Loughney, et al.                                              [Page 36]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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


Loughney, et al.                                              [Page 37]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

Loughney, et al.                                              [Page 38]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

Loughney, et al.                                              [Page 39]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

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




Loughney, et al.                                              [Page 40]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

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

Loughney, et al.                                              [Page 41]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000



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 Procedures to support the SUA Services

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

3.1.1 Receipt of Local primitives

3.2 Procedures to support the SUA Layer Management Services

3.2.1 Layer Management primitives procedures

3.2.2 Receipt of Peer Management messages

3.3 Procedures to support the SUA SCTP Management Services

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

3.3.1 State Maintenance

The SUA layer on at each AS needs to maintain the state of each ASP as
connected as a way to manage the connections between it's ASPs.  Also,
in an SG, the state of each ASP is needed as input to the SGs address
translation and mapping function.

3.3.1.1  ASP States

The state of each ASP is maintained in the SUA layer at the controling
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


Loughney, et al.                                              [Page 42]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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

                 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.3.1.2  AS States

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

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

   * ASP state transitions
   * Recovery timer triggers

The possible states of an AS are:

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

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


Loughney, et al.                                              [Page 43]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000



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

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

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


      +----------+  one ASP trans ACTIVE   +-------------+
      |          |------------------------>|             |
      |  AS-UP   |                         |  AS-ACTIVE  |
      |          |                         |             |
      |          |<                       -|             |
      +----------+ \                     / +-------------+
         ^   |      \ Tr Trigger        /       ^    |
         |   |       \ at least one    /        |    |
         |   |        \ ASP in UP     /         |    |
         |   |         \             /          |    |
         |   |          \           /           |    |
         |   |           \     /---/            |    |
 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  |
      |          |                         |  (queueing) |
      |          |<------------------------|             |
      +----------+    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.3.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

Loughney, et al.                                              [Page 44]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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.

3.3.3 ASPM procedures for peer-to-peer messages

3.3.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 peeer before
transmitting ASP maintenance messages (ASPIA or ASPAC) or SUA messages
or it will risk message loss.

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




Loughney, et al.                                              [Page 45]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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.3.3.3 ASP Version Control

If a ASP Up message with an unknown version is received, the receiving
end will respond with an Error message.  This will indicate to the
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.3.3.4 ASP Active

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

3.4 Procedures to support the SUA Services

3.4.1 At an SG

Details to be provided.

3.4.2 At an ASP

Details to be provided.

4 Examples of SUA Procedures

4.1 Establishment of Association

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

Loughney, et al.                                              [Page 46]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


      |                  |                   |
      <-----------------------ASP Up---------+
      +-----------------------ASP Up (Ack)--->
      |                  |                   |
      <----ASP Active----+                   |
      +-ASP Active Ack--->                   |
      |                  |                   |

4.2 ASP fail-over Procedures

4.2.1 For Primary/Backup model

      SG               ASP1                ASP2
                      (Primary)           (Backup)
      |                  |                   |
      <----ASP Up--------+                   |
      +----ASP Up (Ack)-->                   |
      |                  |                   |
      <-----------------------ASP Up---------+
      +-----------------------ASP Up (Ack)--->
      |                  |                   |
      <----ASP Active----+                   |
      +-ASP Active Ack--->                   |
      |                  |                   |
      +-Stream1 Proceed-->                   |
      +-Stream2 Proceed-->                   |
      |       ...        |                   |
      +-StreamN Proceed-->                   |
      |                  |                   |
      |   Backhaul       |                   |
      <===  Flow   ======>                   |
      |    Begins        |                   |
      |                  |                   |
      |               *********              |
      |               *Failure*              |
      |               *Occurs *              |
      |  SCTP         *********   ASP1       |
      <--Communication   |        Failure --->
      |  Down            |        Detection  |
      |                  |                   |
   SG locally            |                   |
   changes ASP1          |                   |
   to Inactive/Down      |                   |
      |                  |                   |
      +----+      ***************            |
      | Queue     *Backhaul Flow*            |
      | Msgs      *Suspended    *            |
      <----+      ***************            |
      |                  |                   |
      +--No Active ASP--->                   |
      +--------------------No Active ASP----->
      |                  |                   |
      <---------------------ASP Active-------+
      +---------------------ASP Active (Ack)->
      |                  |                   |
      +-Stream1 Proceed---------------------->
      +-Stream2 Proceed---------------------->
      |       ...        |                   |
      +-StreamN Proceed---------------------->

Loughney, et al.                                              [Page 47]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


      |                  |                   |
      <=====================Backhaul Flow====>
      |                  |     Resumes       |

4.3 SUA/SCCP-User Boundary Examples

4.3.1 Data Tranfer

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

     SEP                SG                  ASP
      |                  |                   |
      +--------UDT------->                   |
      |                  +-------CLDT-------->
      |                  |                   |


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 [RANAP] provides certain transport
related security features, such as:

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

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

When the network in which SUA runs in involves more than one party, it
may not be reasonable to expect that all parties have implemented
security in a sufficient manner.  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


Loughney, et al.                                              [Page 48]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


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.

9 Author's 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
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
SLorusso@UnisphereSolutions.com

Loughney, et al.                                              [Page 49]

Internet Draft        SS7 SCCP-User Adaptation Layer       May 12, 2000


email: SLorusso@UnisphereSolutions.com

9 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]         Simple Control Transport Protocol <draft-ietf-sigtran-
               sctp-08.txt>, April 2000, Work in Progress.

[M3UA]         MTP3-User Adaptation Layer <draft-ietf-sigtran-m3ua-
               02.txt>, 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" <draft-ietf-enum-rqmts-01.txt>,
               December 1999, Work in Progress.

[E.164-DNS]    "E.164 number and DNS" , <draft-faltstrom-e164-05.txt>,
               January 2000, Work in Progress.


Appendix A Message mapping between SCCP and SUA.

This is for illustrative purposes only.  To Be Added latter









Loughney, et al.                                              [Page 50]


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