| draft-ietf-sigtran-sua-04Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-sua-04.txt.
INTERNET-DRAFT J. Loughney
Internet Engineering Task Force Nokia
G. Sidebottom, Guy Mousseau
Issued: 24 November 2000 Nortel Networks
Expires: 24 May 2001 S. Lorusso
Unisphere Solutions
L. Coede, G. Verwimp
Siemens
J. Keller
Tekelec
F. Escobar
Ericsson
W. Sully, S. Furniss
Marconi
SS7 SCCP-User Adaptation Layer (SUA)
<draft-ietf-sigtran-sua-04.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as 'work in progress.'
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html .
This draft expires on 24 May 2001
Abstract
This Internet Draft defines a protocol for the transport of any SS7
SCCP-User signaling (e.g., TCAP, RANAP, etc.) over IP using the
Stream Control Transport Protocol. The protocol should be modular
and symmetric, to allow it to work in diverse architectures, such as
a Signaling Gateway to IP Signaling Endpoint architecture as well as
a peer-to-peer IP Signaling Endpoint architecture. Protocol
elements are added to allow seamless operation between peers in the
SS7 and IP domains.
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Abstract..............................................................1
1. Introduction.......................................................3
1.1 Scope ...........................................................3
1.2 Terminology .....................................................3
1.3 Signaling Transport Architecture ................................5
1.4 Services Provided by the SUA Layer .............................10
1.5 Internal Functions Provided in the SUA Layer ...................11
1.6 Definition of SUA Boundaries ...................................12
2 Conventions........................................................13
3 Protocol Elements..................................................13
3.1 Common Message Header ..........................................14
3.2 SUA Connectionless Messages ....................................17
3.3 Connection Oriented Messages ...................................18
3.4 SS7 Signaling Network Management Messages ......................26
3.5 Application Server Process Maintenance Messages ................31
3.6 ASP Traffic Maintenance Messages ...............................34
3.7 Management Messages ............................................37
3.8 Common Parameters ..............................................38
3.9 SUA-Specific parameters ........................................46
4 Procedures.........................................................59
4.1 Peer Message Procedures ........................................59
4.2 Signaling Gateway Related Procedures ...........................60
4.3 Layer Management Procedures ....................................61
4.4 SCTP Management Procedures .....................................61
5 Examples of SUA Procedures.........................................68
5.1 SG Architecture ................................................68
5.2 IP-IP Architecture .............................................70
6 Message Routing Scenarios..........................................72
6.1 Basic case with single SG acting as end- or relay-point ........72
6.2 Replicated SG acting as end-point ..............................74
6.3 Replicated SG acting as relay-point ............................74
7 Security...........................................................75
7.1 Introduction ...................................................75
7.2 Threats ........................................................75
7.3 Protecting Confidentiality .....................................76
8 IANA Considerations................................................76
8.1 SCTP Payload Protocol ID .......................................76
8.2 Port Number ....................................................76
8.3 IETF Defined Message Classes ...................................77
9 Timer Values.......................................................78
10 Acknowledgements..................................................78
10 Authors' Addresses................................................78
11 References........................................................79
Appendix A: Message mapping between SCCP and SUA.....................80
Appendix B: Message Mapping Examples.................................82
1 SUA->SCCP ........................................................82
2 SCCP->SUA ........................................................82
Copyright Statement..................................................82
Loughney, et al. [Page 2]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
1. Introduction
1.1 Scope
There is on-going integration of SCN networks and IP networks.
Network service providers are designing all IP architectures which
include support for SS7 and SS7-like signaling protocols. IP
provides an effective way to transport user data and for operators
to expand their networks and build new services. In these networks,
there may be some need for interworking between the SS7 and IP
domains.
This document details the delivery of SCCP-user messages (MAP & CAP
over TCAP, RANAP, etc.) and new third generation network protocol
messages over IP between two signaling endpoints. Consideration is
given for the transport from an SS7 Signaling Gateway (SG) to an IP
signaling node (such as an IP-resident Database) as described in the
Framework Architecture for Signaling Transport [2719]. This protocol
can also support transport of SCCP-user messages between two
endpoints wholly contained within an IP network.
The delivery mechanism SHOULD meet the following criteria:
* Support for transfer of SS7 SCCP-User Part messages (e.g., TCAP,
RANAP, etc.)
* Support for SCCP connectionless service.
* Support for SCCP connection oriented service.
* Support for the seamless operation of SCCP-User protocol peers
* Support for the management of SCTP transport associations between
a SG and one or more IP-based signaling nodes).
* Support for distributed IP-based signaling nodes.
* Support for the asynchronous reporting of status changes to
management
The protocol is modular in design, allowing different
implementations to be made, based upon the environment that needs to
be supported. Depending upon the upper layer protocol supported, the
SUA will need to support SCCP connectionless service, SCCP connect-
orient service or both services.
1.2 Terminology
Signaling Gateway (SG) - Network element that terminates SCN
signaling and transports SCCP-User signaling over IP to an IP
signaling endpoint. A Signaling Gateway could be modeled as one or
more Application Servers, which is located at the border of the SS7
and IP networks.
Application Server (AS) - A logical entity serving a specific
Routing Key. An example of an Application Server is an IP database
handling all request for a unique set of SCCP-users. The AS
Loughney, et al. [Page 3]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
contains a set of one or more unique Application Server Processes,
of which one or more is normally actively processing traffic.
Application Server Process (ASP) - An Application Server Process
serves as an active or standby process of an Application Server
(e.g., part of a distributed signaling node or database element).
Examples of ASPs are MGCs, IP SCPs, or IP-based HLRs. An ASP
contains an SCTP end-point and may be configured to process traffic
within more than one Application Server.
Association - An association refers to an SCTP association. The
association provides the transport for the delivery of SCCP-User
protocol data units and SUA adaptation layer peer messages.
Routing Key - The Routing Key describes a set of SS7 parameter and
/or parameter-ranges that uniquely defines the range of signaling
traffic configured to be handled by a particular Application Server.
An example would be where a Routing Key consists of a particular PC
and SSN to which all traffic would be directed to a particular
Application Server. Routing Keys are mutually exclusive in the
sense that a received SS7 signaling message cannot be directed to
more than one Routing Key. A Routing Key cannot extend across more
than a single SS7 PC, in order to more easily support SS7 Management
procedures. It is not necessary for the parameter ranges within a
particular Routing Key to be contiguous.
Routing Context - An Application Server Process may be configured to
process traffic within more than one Application Server. In this
case, the Routing Context parameter is exchanged between two ASPs,
identifying the relevant Application Server. From the perspective
of an ASP, the Routing Context uniquely identifies the range of
traffic associated with a particular Application Server, which the
ASP is configured to receive. There is a 1:1 relationship between a
Routing Context value and a Routing Key within an AS. Therefore the
Routing Context can be viewed as an index into an AS Table
containing the AS Routing Keys.
Fail-over - The capability to re-route signaling traffic as required
to an alternate Application Server Process, or group of ASPs, within
an Application Server in the event of failure or unavailability of a
currently used Application Server Process. Fail-back may apply upon
the return to service of a previously unavailable Application Server
Process.
Signaling Point Management Cluster (SPMC) - A complete set of
Application Servers represented to the SS7 network under the same
SS7 Point Code. SPMCs are used to sum the availability / congestion
/ User_Part status of an SS7 destination point code that is
distributed in the IP domain, for the purpose of supporting
management procedures at an SG.
Loughney, et al. [Page 4]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Network Appearance - The Network Appearance identifies an SS7
network context for the purposes of logically separating the
signaling traffic between the SG and the Application Server
Processes over a common SCTP Association. An example is where an SG
is logically partitioned to appear as an element in four separate
national SS7 networks. A Network Appearance implicitly defines the
SS7 Point Code(s), Network Indicator and SCCP protocol
type/variant/version used within a specific SS7 network partition.
An physical SS7 route-set or link-set at an SG can appear in only
one network appearance. The Network Appearance is not globally
significant and requires coordination only between the SG and the
ASP.
Network Byte Order - Most significant byte first, a.k.a. Big Endian.
Layer Management - Layer Management is a nodal function in an SG or
ASP that handles the inputs and outputs between the SUA layer and a
local management entity.
Host - The computing platform that the ASP process is running on.
Stream - A stream refers to an SCTP stream; a uni-directional
logical channel established from one SCTP endpoint to another
associated SCTP endpoint, within which all user messages are
delivered in-sequence except for those submitted to the un-ordered
delivery service.
Transport address - an address which serves as a source or
destination for the unreliable packet transport service used by
SCTP. In IP networks, a transport address is defined by the
combination of an IP address and an SCTP port number. Note, only
one SCTP port may be defined for each endpoint, but each SCTP
endpoint may have multiple IP addresses.
1.3 Signaling Transport Architecture
The framework architecture that has been defined for SCN signaling
transport over IP [2719] uses multiple components, including an IP
transport protocol, a signaling common transport protocol and an
adaptation module to support the services expected by a particular
SCN signaling protocol from its underlying protocol layer.
In general terms, the SUA architecture can be modeled as a peer-to-
peer architecture.
1.3.1 Protocol Architecture for TCAP Transport
In this architecture, the SCCP and SUA layers interface in the SG.
There needs to be interworking between the SCCP and SUA layers to
provide for the seamless transfer of the user messages as well as
Loughney, et al. [Page 5]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
the management messages. The SUA handles the SS7 address to IP
address mapping.
******** SS7 *************** IP ********
* SEP *---------* *--------* *
* or * * SG * * ASP *
* STP * * * * *
******** *************** ********
+------+ +------+
| TCAP | | TCAP |
+------+ +------+------+ +------+
| SCCP | | SCCP | SUA | | SUA |
+------+ +------+------+ +------+
| MTP3 | | MTP3 | | | |
+------| +------+ SCTP | | SCTP |
| MTP2 | | MTP2 | | | |
+------+ +------+------+ +------+
| L1 | | L1 | IP | | IP |
+------+ +------+------+ +------+
| | | |
+---------------+ +------------+
TCAP - Transaction Capability Application Protocol
STP - SS7 Signaling Transfer Point
1.3.2 Protocol Architecture for RANAP Transport
In this architecture, the SS7 application protocol is invoked at the
SG. For messages destined for an ASP, the SUA handles address
translation, for example by way of Global Title Translation or via
mapping table, resolving the destination specified by SS7
Application to a SCTP association / IP address.
******** SS7 *************** IP ********
* SEP *---------* *--------* *
* or * * SG * * ASP *
* STP * * * * *
******** *************** ********
+------+ +-------------+ +------+
| S7AP | | S7AP | | S7AP |
+------+ +------+------+ +------+
| SCCP | | SCCP | SUA | | SUA |
+------+ +------+------+ +------+
| MTP3 | | MTP3 | | | |
+------| +------+ SCTP | | SCTP |
| MTP2 | | MTP2 | | | |
+------+ +------+------+ +------+
| L1 | | L1 | IP | | IP |
+------+ +------+------+ +------+
Loughney, et al. [Page 6]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
| | | |
+---------------+ +------------+
S7AP - SS7 Application Protocol (e.g. - RANAP/RNSAP)
STP - SS7 Signaling Transfer Point
This architecture may simplify, in some cases, to carrying an SS7
application protocol between two IP based endpoints. In this
scenario, full SG functionality may not be needed. This
architecture is considered in the next section.
1.3.3 All IP Architecture
This architecture can be used to carry a protocol which uses the
transport services of SCCP, but is contained with an IP network.
This allows extra flexibility in developing networks, especially
when interaction between legacy signaling is not needed. The
architecture removes the need for signaling gateway functionality.
******** IP ********
* *--------* *
* AS * * AS *
* * * *
******** ********
+------+ +------+
| AP | | AP |
+------+ +------+
| SUA | | SUA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
| |
+----------------+
AP - Application Protocol (e.g. - RANAP/RNSAP)
In the case where a collision occurs during initiation, there exist
two possible solutions: 1) if there are sufficient resources, both
initiations could be accepted; 2) both ASPs should back-off and
after some amount of time, later re-establish an initiation.
1.3.4 Generalized Point-to-Point Network Architecture
Figure 1 shows an example network architecture which can support
robust operation and failover support. There needs to be some
management resources at the AS to manage traffic.
Loughney, et al. [Page 7]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
***********
* AS1 *
* +-----+ * SCTP Associations
* |ASP1 +-------------------+
* +-----+ * | ***********
* * | * AS3 *
* +-----+ * | * +-----+ *
* |ASP2 +-----------------------------------------+ASP1 | *
* +-----+ * | * +-----+ *
* * | * *
* +-----+ * | * +-----+ *
* |ASP3 | * +--------------------------+ASP2 | *
* +-----+ * | | * +-----+ *
*********** | | ***********
| |
*********** | | ***********
* AS2 * | | * AS4 *
* +-----+ * | | * +-----+ *
* |ASP1 +--------------+ +---------------------+ASP1 | *
* +-----+ * * +-----+ *
* * * *
* +-----+ * * +-----+ *
* |ASP2 +-----------------------------------------+ASP1 | *
* +-----+ * * +-----+ *
* * ***********
* +-----+ *
* |ASP3 | *
* +-----+ *
* *
***********
Figure 1: Generalized Architecture
In this example, the Application Servers are shown residing within
one logical box, with ASPs located inside. In fact, an AS could be
distributed among several hosts. In such a scenario, the host
should share state as protection in the case of a failure.
Additionally, in a distributed system, one ASP could be registered
to more than one AS. This draft should not restrict such systems -
though such a case in not specified.
1.3.5 Generalized Signaling Gateway Network Architecture
When interworking between SS7 and IP domains is needed, the SG acts
as the gateway node between the SS7 network and the IP network. The
SG will transport SCCP-user signaling traffic from the SS7 network
to the IP-based signaling nodes (for example IP-resident
Databases). The Signaling Gateway can be considered as a group of
Application Servers with additional functionality to interface
towards an SS7 network.
Loughney, et al. [Page 8]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
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
Loughney, et al. [Page 9]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
others may while any others are inactive but available in the event
of failure or unavailability of the active ASP(s).
The fail-over model supports an "n+k" redundancy model, where "n"
ASPs is the minimum number of redundant ASPs required to handle
traffic and "k" ASPs are available to take over for a failed or
unavailable ASP. Note that "1+1" active/standby redundancy is a
subset of this model. A simplex "1+0" model is also supported as a
subset, with no ASP redundancy.
To avoid a single point of failure, it is recommended that a minimum
of two ASPs be resident in the list, resident in separate physical
hosts and therefore available over different SCTP Associations.
1.4 Services Provided by the SUA Layer
1.4.1 Support for the transport of SCCP-User Messages
The SUA needs to support the transfer of SCCP-user messages. The SUA
layer at the SG needs to seamlessly transport the user messages.
1.4.2 SCCP Protocol Class Support
Depending upon the SCCP-users supported, the SUA shall support the 4
possible SCCP protocol classes transparently. The SCCP protocol
classes are defined as follows:
* Protocol class 0 provides unordered transfer of SCCP-user
messages in a connectionless manner.
* Protocol class 1 allows the SCCP-user to select the in-sequence
delivery of SCCP-user messages in a connectionless manner.
* Protocol class 2 allows the bi-directional transfer of SCCP-user
messages by setting up a temporary or permanent signaling
connection.
* Protocol class 3 allows the features of protocol class 2 with
the inclusion of flow control. Detection of message loss or
mis-sequencing is included.
Protocol classes 0 and 1 make up the SCCP connectionless service.
Protocol classes 2 and 3 make up the SCCP connection-oriented
service.
1.4.3 Native Management Functions
The SUA layer may provide management of the underlying SCTP layer to
ensure that transport is available according to the degree specified
by the SCCP-user application.
Loughney, et al. [Page 10]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
The SUA layer provides the capability to indicate errors associated
with the SUA-protocol messages and to provide notification to local
management and the remote peer as is necessary.
1.4.4 Interworking with SCCP Network Management Functions
The SUA layer needs to support the following SCCP network management
primitives (a reference to ITU and ANSI sections where these
primitives and corresponding parameters are described, is also
given):
Generic |Specific |
Name |Name |ANSI/ITU Reference
----------+-----------+---------------------------------------------
N-Coord |Request |ITU-Q.711 Chap 6.3.2.3.1 (Tab 13/Q.711)
|Indication |ANSI-T1.112 Chap 2.3.2.3.1 (Tab 8D/T1.112.1)
|Response |
|Confirm |
----------+-----------+---------------------------------------------
N-State |Request |ITU-Q.711 Chap 6.3.2.3.2 (Tab 14/Q.711)
|Indication |ANSI-T1.112 Chap 2.3.2.3.2 (Tab 8E/T1.112.1)
----------+-----------+---------------------------------------------
N-Pcstate |Indication |ITU-Q.711 Chap 6.3.2.3.3 (Tab 15/Q.711)
| |ANSI-T1.112 Chap 2.3.2.3.4 (Tab 8G/T1.112.1)
1.4.5 Support for the management between the SG and ASP.
The SUA layer should provide interworking with SCCP management
functions at the SG for seamless inter-operation between the SCN
network and the IP network. It should:
* Provide an indication to the SCCP-user at an ASP
that a remote SS7 endpoint/peer is unreachable.
* Provide an indication to the SCCP-user at an ASP
that a remote SS7 endpoint/peer is reachable.
* Provide congestion indication to SCCP-user at an ASP.
* Provide the initiation of an audit of remote SS7
endpoints at the SG.
1.5 Internal Functions Provided in the SUA Layer
1.5.1 Address Translation and Mapping at the SG
SCCP users may present the following options to address their peer
endpoints:
Global Title
PC + SSN
Host Name
IP Address(es)
Loughney, et al. [Page 11]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
The SG MUST translate the SS7 address presented at the SG (PC + SSN
or GT) to an SCTP-based ASP final destination, and not to another
SS7 MTP destination.
Global Titles are an interesting option for addressing. Currently,
the ITU does not support translation of Global Titles to IP
addresses. However, IP addresses are global in scope. There exist
many proprietary schemes for managing SS7 Address Translation to IP
addresses, and is considered outside of the scope of this document
to specify how this is done.
Some discussion of address translation should be made to insure
interoperability between implementations of the SUA. For further
instruction in the use of Global Titles the rules detailed in Annex
B of ITU Q.713 [ITU SCCP] or [ANSI SCCP] should be consulted.
That being said, currently, there is some work within the IETF
studying translation of E.164 numbers to Host Names [ENUMS], [E.164-
DNS].
In many cases, the network operator may have some control over the
SCCP-user protocols being transported by SUA. If possible, the
Upper Layer can present a Host Name or IP Address, which then can be
directly passed to SCTP.
An example of address translation at the SG would be that the CDPA
is extracted from the SCCP Header, processed by the SUA routing
function which yields a SA. The SA is fed back into extended SUA
routing analysis which yields the ASP to route the message to. This
is why the Source Address and Destination address-routing should be
performed based on the CDPA.
1.5.2 SCTP Stream Mapping
The SUA supports SCTP streams. The SG/AS needs to maintain a list of
SCTP and SUA-users for mapping purposes. SCCP-users requiring
sequenced message transfer need to be sent over a stream supporting
sequenced delivery.
SUA MUST use stream 0 for SUA management messages. It is recommended
that sequenced delivery be in order to preserve the order of
management message delivery.
1.6 Definition of SUA Boundaries
1.6.1 Definition of the upper boundary
The following primitives are supported between the SUA and an SCCP-
user (a reference to ITU and ANSI sections where these primitives
and corresponding parameters are described, is also given):
Loughney, et al. [Page 12]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Generic |Specific |
Name |Name |ANSI/ITU Reference
------------+----------+-------------------------------------------
N-Connect |Request |ITU-Q.711 Chap 6.1.1.2.2 (Tab 2/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.2 (Tab 2/T1.112.1)
|Response |
|Confirm |
------------+----------+-------------------------------------------
N-Data |Request |ITU-Q.711 Chap 6.1.1.2.3 (Tab 3/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 3/T1.112.1)
------------+----------+-------------------------------------------
N-Expedited |Request |ITU-Q.711 Chap 6.1.1.2.3 (Tab 4/Q.711)
Data |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 4/T1.112.1)
------------+----------+-------------------------------------------
N-Reset |Request |ITU-Q.711 Chap 6.1.1.2.3 (Tab 5/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 5/T1.112.1)
|Response |
|Confirm |
------------+----------+-------------------------------------------
N-Disconnect|Request |ITU-Q.711 Chap 6.1.1.2.4 (Tab 6/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.4 (Tab 6/T1.112.1)
------------+----------+-------------------------------------------
N-Inform |Request |ITU-Q.711 Chap 6.1.1.3.1 (Tab 7/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.5 (Tab 6A/T1.112.1)
------------+----------+-------------------------------------------
N-Unit Data |Request |ITU-Q.711 Chap 6.2.2.3.1 (Tab 10/Q.711)
|Indication|ANSI-T1.112 Chap 2.2.2.3.1 (Tab 8A/T1.112.1)
------------+----------+-------------------------------------------
N-Notice |Indication|ITU-Q.711 Chap 6.2.2.3.2 (Tab 11/Q.711)
| |ANSI-T1.112 Chap 2.2.2.3.2 (Tab 8B/T1.112.1)
1.6.2 Definition of the lower boundary
The upper layer primitives provided by the SCTP are provided in
[SCTP].
2 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
[RFC2119].
3 Protocol Elements
The general message format includes a Common Message Header together
with a list of zero or more parameters as defined by the Message
Type.
For forward compatibility, all Message Types may have attached
parameters even if none are specified in this version.
Loughney, et al. [Page 13]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
3.1 Common Message Header
The protocol messages for the SCCP-User Adaptation Protocol requires
a message structure which contains a version, message type, message
length and message contents. This message header is common among
all signaling protocol adaptation layers:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Message Class | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg data |
Note that the 'data' portion of SUA messages SHALL contain SCCP-User
data, not the encapsulated SCCP message.
Optional parameters can only occur at most once in an SUA message.
3.1.1 SUA Protocol Version
The version field (ver) contains the version of the SUA adaptation
layer. The supported versions are:
01 SUA version 1.0
3.1.2 Message Classes
Message Classes
0 Management (MGMT) Message
1 Reserved
2 SS7 Signaling Network Management (SSNM) Messages
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
5 Reserved
6 Reserved
7 Connectionless Messages
8 Connection-Oriented Messages
9 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
3.1.3 Message Types
SUA Management Messages
0 Error (ERR)
Loughney, et al. [Page 14]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
1 Notify (NTFY)
2 - 127 Reserved by the IETF
128- 255 Reserved for IETF-Defined Message Class Extensions
SS7 Signaling Network Management (SSNM) Messages
0 Reserved
1 Destination Unavailable (DUNA)
2 Destination Available (DAVA)
3 Destination State Audit (DAUD)
4 SS7 Network Congestion (SCON)
5 Destination User Part Unavailable (DUPU)
6 SCCP Management (SCMG)
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Application Server Process Maintenance (ASPM) Messages
0 Reserved
1 ASP Up (UP)
2 ASP Down (DOWN)
3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK)
5 ASP Down Ack (Down ACK)
6 Heartbeat Ack (BEAT ACK)
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
ASP Traffic Maintenance (ASPTM) Messages
0 Reserved
1 ASP Active (ACTIVE)
2 ASP Inactive (INACTIVE)
3 ASP Active Ack (ACTIVE ACK)
4 ASP Inactive Ack (INACTIVE ACK)
5 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Connectionless Messages
0 Reserved
1 Connectionless Data Transfer (CLDT)
2 Connectionless Data Response (CLDR)
3 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Connection-Oriented Messages
0 Reserved
1 Connection Request (CORE)
2 Connection Acknowledge (COAK)
Loughney, et al. [Page 15]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
3 Connection Refused (COREF)
4 Release Request (RELRE)
5 Release Complete (RELCO)
6 Reset Confirm (RESCO)
7 Reset Request (RESRE)
8 Connection Oriented Data Transfer (CODT)
9 Connection Oriented Data Acknowledge (CODA)
10 Connection Oriented Error (COERR)
11 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
3.1.4 Message Length
The Message Length defines the length of the message in octets,
including the header.
3.1.4 Tag-Length-Value Format
SUA messages consist of a Common Header followed by zero or more
parameters, as defined by the message type. The Tag-Length-Value
(TLV) parameters contained in a message are defined in a Tag-
Length-Value format as shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Tag | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Tag: 16 bits (unsigned integer)
Tag field is a 16-bit identifier of the type of parameter. It
takes a value of 0 to 65534.
Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Tag, Parameter Length, and
Parameter Value fields. The Parameter Length does not include any
padding bytes.
Parameter Value: variable-length.
The Parameter Value field contains the actual information to be
transferred in the parameter.
The total length of a parameter (including Tag, Parameter Length
Loughney, et al. [Page 16]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
and Value fields) MUST be a multiple of 4 bytes. If the length of
the parameter is not a multiple of 4 bytes, the sender pads the
Parameter at the end (i.e., after the Parameter Value field) with
all zero bytes. The length of the padding is NOT included in the
parameter length field. A sender should NEVER pad with more than
3 bytes. The receiver MUST ignore the padding bytes.
3.2 SUA Connectionless Messages
The following section describes the SUA Connectionless transfer
messages and parameter contents. The general message format
includes a Common Message Header together with a list of zero or
more parameters as defined by the Message Type. All Message Types
can have attached parameters.
3.2.1 Connectionless Data Transfer
This message transfers data between one SUA to another.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ destination address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Flags Mandatory
Source Address Mandatory
Destination Address Mandatory
Data Mandatory
Implementation note:
Loughney, et al. [Page 17]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
This message covers the following SCCP messages: unitdata (UDT),
extended unitdata (XUDT), long unitdata (LUDT).
3.2.2 Connectionless Data Response
This message is used as a response message by the peer and/or report
errors.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0109 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Error Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ destination address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Flags Mandatory
SCCP Error Cause Mandatory
Source Address Mandatory
Destination Address Mandatory
Data Optional
Implementation note:
This message covers the following SCCP messages: long unitdata
service (LUDTS), unitdata service (UDTS), extended unitdata service
(XUDTS).
3.3 Connection Oriented Messages
Loughney, et al. [Page 18]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Data Mandatory
Flags Mandatory *1
Sequence number Mandatory *2
NOTE *1: Mandatory for representing DT1 message.
NOTE *2: Mandatory when CODT message maps a DT2 message.
Otherwise, the parameter is not be present.
Implementation note:
This message covers the following SCCP messages: data form 1 (DT1),
data form 2 (DT2), expedited data (ED).
3.3.2 Connection Oriented Data Acknowledge
This message is used to acknowledge receipt of data by the peer.
This message is used only with protocol class 3.
Loughney, et al. [Page 19]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010F | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010C | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Receive Sequence number Mandatory *1
Credit Mandatory *1
NOTE *1: Mandatory when representing Data Acknowledgement (AK).
Implementation note:
This message covers the following SCCP messages: data
acknowledgement (AK), expedited data acknowledgement (EA).
3.3.3 Connect Request
This message is used for establishing a signaling connection between
two peer endpoints. This is used for connection oriented service.
Loughney, et al. [Page 20]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010C | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Flags Mandatory
Source Reference Number Mandatory
Destination Address Mandatory
Source Address Optional
Credit Optional
Data Optional
3.3.4 Connection Acknowledge
This message is used to acknowledge a connection request between two
peer endpoints.
Loughney, et al. [Page 21]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010C | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Source Reference Number Mandatory
Flags Mandatory
Credit Optional
Destination Address Optional *1
Data Optional
NOTE *1: Destination Address parameter will be present in case
that the received CORE message conveys the Source
Address parameter.
Implementation note:
This message covers the following SCCP message: connection confirm
(CC).
3.3.5 Connection Refused (COREF)
This message is used to refuse a connection request between two peer
endpoints.
Loughney, et al. [Page 22]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0109 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Error Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
SCCP Error Cause Mandatory
Destination Address Optional *1
Data Optional
Note *1: Destination Address parameter will be present in case
that the received CORE message conveys the Source
Address parameter.
3.3.6 Release Request
This message is used to request a signaling connection between two
peer endpoints be released. All associated resources can then be
released.
Loughney, et al. [Page 23]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Source Reference Number Mandatory
Return Cause Mandatory
Flags Optional
Data Optional
Implementation Note:
This message covers the following SCCP message: connection refused
(CREF).
3.3.7 Release Complete
This message is used to acknowledge the release of a signaling
connection between two peer endpoints. All associated resources
should be released.
Loughney, et al. [Page 24]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Source Reference Number Mandatory
3.3.8 Reset Request
This message is used to indicate that the sending SCCP/SUA wants to
initiate a reset procedure (re-initialization of sequence numbers)
the peer endpoint.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0109 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Error Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Source Reference Number Mandatory
SCCP Error Cause Mandatory
3.3.9 Reset Confirm
This message is used to confirm the Reset Request.
Loughney, et al. [Page 25]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Source Reference Number Mandatory
3.3.10 Connection Oriented Error (COERR)
The COERR message is sent when an invalid value is found in an
incoming message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0109 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Error Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
SCCP Error Cause Mandatory
Implementation Note:
This message covers the following SCCP message: Protocol data unit
error (ERR)
3.4 SS7 Signaling Network Management Messages
3.4.1 Destination Unavailable
The DUNA message is sent from the SG to all concerned ASPs to
indicate that the SG has determined that an SS7 destination is
unreachable. The SUA-User at the ASP is expected to stop traffic to
the affected destination through the SG initiating the DUNA.
Loughney, et al. [Page 26]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
The format for DUNA Message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Affected Point Code Mandatory
Network Appearance Optional
Info String Optional
3.4.2 Destination Available
The DAVA message is sent from the SG to all concerned ASPs to
indicate that the SG has determined that an SS7 destination is now
reachable. The ASP SUA-User protocol is expected to resume traffic
to the affected destination through the SG initiating the DAVA.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Loughney, et al. [Page 27]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Affected Point Code Mandatory
Network Appearance Optional
Info String Optional
3.4.3 Destination State Audit
The DAUD message can be sent from the ASP to the SG to query the
availability state of the SS7 routes to an affected destination. A
DAUD may be sent periodically after the ASP has received a DUNA,
until a DAVA is received. The DAUD can also be sent when an ASP
recovers from isolation from the SG.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Affected Point Code Mandatory
Network Appearance Optional
Info String Optional
3.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.
Loughney, et al. [Page 28]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0010 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Affected PC(s) \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Congestion Level Mandatory
Affected PCs Mandatory
Info String Optional
3.4.5 Destination User Part Unavailable
The DUPU message is used by an SG to inform an ASP that a remote
peer SUA-User User Part at an SS7 node is unavailable.
The format for DUPU Message parameters is as follows:
Loughney, et al. [Page 29]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause/User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Affected Point Code Mandatory Note *1
Cause/User Mandatory
Info String Optional
3.4.6 SCCP Management Message
The SCMG message is sent between SUA Peers to indicate status of
subsystems. Only one SCMG message type can be sent per message.
Loughney, et al. [Page 30]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCMG Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010E | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI | Subsystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected PC /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0108 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| congestion level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ INFO String \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
SCMG Message Type Mandatory
Subsystem/SMI Mandatory
Affected Point Code Mandatory *1
Congestion Level Mandatory *2
Info String Optional
Note *1: In the SCMG message, the Affected Point Code Parameter
MUST contain, at most, a single Affected Point Code.
Note *2: When the SCMG Message Type is SSC, then the Congestion
Level parameter is Mandatory, otherwise it is optional.
3.5 Application Server Process Maintenance Messages
3.5.1 ASP Up (ASPUP)
The ASP UP (ASPUP) message is used to indicate to a remote SUA peer
that the Adaptation layer is up and running.
Loughney, et al. [Page 31]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
ASP Capabilities Optional
Info String Optional
3.5.2 ASP Up Ack (UPACK)
The ASP UP Ack message is used to acknowledge an ASP-Up message
received from a remote SUA peer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
ASP Capabilities Optional
Info String Optional
3.5.3 ASP Down (ASPDN)
The ASP Down (ASPDN) message is used to indicate to a remote SUA
peer that the adaptation layer is not running.
Loughney, et al. [Page 32]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0002 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Cause Code Mandatory
Info String Optional
3.5.4 ASP Down Ack (DNACK)
The ASP DOWN Ack message is used to acknowledge an ASP-Down message
received from a remote SUA peer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0002 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Reason Mandatory
Info String Optional
3.5.5 Heartbeat (BEAT)
The Heartbeat message is optionally used to ensure that the SUA
peers are still available to each other.
The format for the BEAT message is as follows:
Loughney, et al. [Page 33]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 8 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Heartbeat Data Optional
3.5.6 Heartbeat Ack (BEAT ACK)
The Heartbeat ACK message is sent in response to a BEAT message. A
peer MUST send a BEAT ACK in response to a BEAT message. It includes
all the parameters of the received Heartbeat message, without any
change.
The format for the BEAT ACK message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 8 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Heartbeat Data Optional
3.6 ASP Traffic Maintenance Messages
3.6.1 ASP Active (ASPAC)
The ASPAC message is sent by an ASP to indicate to a remote SUA peer
that it is Active and ready to process signaling traffic for a
particular Application Server
The format for the ASPAC message is as follows:
Loughney, et al. [Page 34]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Status Type Mandatory
Routing Context Optional
INFO String Optional
3.6.2 ASP Active Ack
The ASPAC Ack message is used to acknowledge an ASP-Active message
received from a remote SUA peer.
The format for the ASPAC Ack message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Status Type Mandatory
Loughney, et al. [Page 35]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Routing Context Optional
INFO String Optional
The Status Type field in the ASPAC Ack message should contain the
type as the ASPAC message to which the message is acknowledging.
3.6.3 ASP Inactive (ASPIA)
The ASPIA message is sent by an ASP to indicate to a remote SUA peer
that it is no longer processing signaling traffic within a
particular Application Server.
The format for the ASPIA message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Status Type Mandatory
Routing Context Optional
INFO String Optional
A node that receives an ASPIA with an incorrect Type for a
particular Routing Context will respond with an Error Message
(Cause: Invalid Traffic Handling Mode).
3.6.4 ASP Inactive Ack
The ASPIA Ack message is used to acknowledge an ASP-Inactive message
received from a remote SUA peer.
The format for the ASPIA Ack message is as follows:
Loughney, et al. [Page 36]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Status Type Mandatory
Routing Context Optional
INFO String Optional
The Status Type field in the Ack message should contain the type as
the ASPIA message to which the message is acknowledging.
3.7 Management Messages
These messages are used for managing SUA and the representations of
the SCCP subsystems in the SUA layer.
3.7.1 Error (ERR)
The ERR message is sent between two SUA peers to indicate an error
situation. The Data parameter is optional, possibly used for error
logging and/or debugging.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000C | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Diagnostic Info /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Loughney, et al. [Page 37]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Error Code Mandatory
Diagnostic Info Optional
3.7.2 Notify (NTFY)
The Notify message used to provide an autonomous indication of SUA
events to an SUA peer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type / Status ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NTFY message contains the following parameters:
Parameters
Status Type Mandatory
Routing Context Optional
Info String Optional
3.8 Common Parameters
These TLV parameters are common across the different adaptation
layers.
Parameter Name Parameter ID
============== ============
Network Appearance 0x0001
Cause Code 0x0002
Data 0x0003
Info String 0x0004
Affected Point Code 0x0005
Routing Context 0x0006
Diagnostic Info 0x0007
Heartbeat Data 0x0008
Cause/User 0x0009
Congestion 0x000A
Not used 0x000B
Loughney, et al. [Page 38]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Not used 0x000C
Status Type / Status ID 0x000D
3.8.1 Network Appearance
The Network Appearance parameter identifies the SS7 network context
for the message, for the purposes of logically separating the
signaling traffic between the SG and the Application Server
Processes over common SCTP Associations. An example is where an SG
is logically partitioned to appear as an element in four different
national SS7 networks. A Network Appearance implicitly defines the
SS7 Destination Point Code used, the SS7 Network Indicator value and
SCCP/SCCP-User protocol type/variant/version used within the SS7
network partition. Where an SG operates in the context of a single
SS7 network, or individual SCTP associations are dedicated to each
SS7 network appearance, the Network Appearance parameter is not
required.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| network appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In an SSNM message, the Network Appearance parameter defines the
format of the Affected PC(s) in the Affected Destination parameter.
The PC point code length (e.g., 14-, 16-, or 24-bit) and sub-field
definitions (e.g., ANSI 24-bit network/cluster/member, ITU-
international 14-bit zone/region/signal_point, many national field
variants, ...) are fixed within a particular Network Appearance.
Where an SG operates in the context of a single SS7 network, or
individual SCTP associations are dedicated to each SS7 network
context, the Network Appearance parameter is not required and the
format of the Affected PC(s) is understood implicitly.
The format of the Network Appearance parameter is an integer, the
values of which are assigned according to network operator policy.
The values used are of local significance only, coordinated between
the SG and ASP.
Where the optional Network Appearance parameter is present, it must
be the first parameter in the message as it defines the format of
the Affected PCs in the Affected Destination parameter.
3.8.2 Cause Code
The Cause Code parameter indicates the reason that the remote SUA
adaptation layer is unavailable. The valid values for Reason are
shown in the following table.
Loughney, et al. [Page 39]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Value Description
0x1 Processor Outage
0x2 Management Inhibit
3.8.3 Data
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8.4 Info String
The INFO String parameter can carry any meaningful 8-BIT ASCII
character string along with the message. Length of the INFO String
parameter is from 0 to 255 characters. No procedures are presently
identified for its use but the INFO String may be used by Operators
for debugging purposes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8.5 Affected Point Code
The Affected Point Code parameter contains one or more Affected
Destination Point Codes, each a three-octet parameter to allow for
4-, 16- and 24-bit binary formatted SS7 Point Codes. Affected Point
codes that are less than 24-bits, are padded on the left to the 24-
bit boundary.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ . . . /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 40]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
The encoding is shown below for ANSI and ITU Point Code examples.
ANSI 24-bit Point Code:
0 1 2 3-->
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Network | Cluster | Member |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB-----------------------------------------LSB|
ITU 14-bit Point Code:
0 1 2 3-->
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB--------------------LSB|
It is optional to send an Affected Pointe Code parameter with more
than one Affected PC but it is mandatory to receive it. All the
Affected PCs included must be within the same Network Appearance.
Including multiple Affected PCs may be useful when reception of an
management message or a linkset event simultaneously affects the
availability status of a list of destinations at an SG.
Mask: 8-bits
The Mask parameter is used to identify a contiguous range of
Affected Destination Point Codes, independent of the point code
format. Identifying a contiguous range of Affected PCs may be
useful when reception of an MTP3 management message or a linkset
event simultaneously affects the availability status of a series of
destinations at an SG.
The Mask parameter is an integer representing a bit mask that can be
applied to the related Affected PC field. The bit mask identifies
how many bits of the Affected PC field is significant and which are
effectively "wildcarded". For example, a mask of "8" indicates that
the last eight bits of the PC is "wildcarded". For an ANSI 24-bit
Affected PC, this is equivalent to signaling that all PCs in an ANSI
Cluster are unavailable. A mask of "3" indicates that the last
three bits of the PC is "wildcarded". For a 14-bit ITU Affected PC,
this is equivalent to signaling that an ITU Region is unavailable.
3.8.6 Routing Context
Loughney, et al. [Page 41]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Routing Context parameter contains (a list of) integers indexing
the Application Server traffic that the sending ASP is configured to
receive. There is one-to-one relationship between an index entry
and an AS Name. Because an AS can only appear in one Network
Appearance, the Network Appearance parameter is not required in the
ASPAC message
An Application Server Process may be configured to process traffic
for more than one logical Application Server. From the perspective
of an ASP, a Routing Context defines a range of signaling traffic
that the ASP is currently configured to receive from the SG.
3.8.7 Diagnostic Information
The Diagnostic Information can be used to convey any information
relevant to an error condition, to assist in the identification of
the error condition. In the case of an Invalid Network Appearance,
Adaptation Layer Identifier or Traffic Handling Mode, the Diagnostic
information includes the received parameter. In the other cases,
the Diagnostic information may be the first 40 bytes of the
offending message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Diagnostic Information* /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8.8 Heartbeat Data
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 8 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 42]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
The data field can be used to store information in the heartbeat
message useful to the sending node (e.g. the data field can contain
a time stamp, a sequence number, etc.).
3.8.9 Cause/User
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause | User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unavailability Cause field: 16-bits (unsigned integer)
The Unavailability Cause parameter provides the reason for the
unavailability of the SUA-User. The valid values for the
Unavailability Cause parameter are shown in the following table.
0 Unknown
1 Unequipped Remote User
2 Inaccessible Remote User
User Identity field: 16-bits (unsigned integer)
The User Identity describes the specific SUA-User that is
unavailable. Some of the valid values for the User Identity are
shown below.
0 - 2 Reserved by M3UA
3 SCCP/SUA
4 - 10 Reserved by M3UA
3.8.10 Congestion Level
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0010 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Congestion Level field: 8-bits (unsigned integer)
The Congestion Level will have two different meanings, depending
upon the message it is received with.
Loughney, et al. [Page 43]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
For the SCON message, the Congestion Level field, contains one of
the following values, which are associated with a destination point
code:
0 No Congestion or Undefined
1 Congestion Level 1
2 Congestion Level 2
3 Congestion Level 3
The congestion levels are as defined in the national congestion
method in the appropriate MTP recommendation [ITU-MTP], [ANSI-MTP].
For MTP congestion methods that do not employ congestion levels
(e.g., the ITU international method, the parameter is always
"Undefined").
When an SCON is received at the SG, a TFC message is generated into
the SS7 network.
For the SCMG message, the valid values for the Congestion Level
parameter range from 0 to 7, where 0 indicates least congested and 7
indicates most congested.
4.8.11 Error Code
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x000C | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Code parameter indicates the reason for the Error Message.
The Error parameter value can be one of the following values:
Invalid Version 0x01
Invalid Network Identifier 0x02
Unexpected Message Class 0x03
Invalid Message Type 0x04
Unsupported Traffic Handling Mode 0x05
Unexpected Message 0x06
Protocol Error 0x07
Reserved 0x08
Invalid Stream Identifier 0x09
The "Invalid Version" error would be sent if a message was received
with an invalid or unsupported version. The Error message would
contain the supported version in the Common header. The Error
message could optionally provide the supported version in the
Diagnostic Information area.
Loughney, et al. [Page 44]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
The "Invalid Interface Identifier" error would be sent by a SG if
an ASP sends a message with an invalid (unconfigured) Interface
Identifier value.
The "Unsupported Traffic Handling Mode" error would be sent by a SG
if an ASP sends an ASP Active with an unsupported Traffic Handling
Mode. An example would be a case in which the SG did not support
load-sharing.
The "Unexpected Message" error would be sent by an ASP if it
received a message while it was in the Inactive state.
The "Protocol Error" error would be sent for any protocol anomaly
(i.e. a bogus message).
The "Invalid Stream Identifier" error would be sent if a message
was received on an unexpected SCTP stream (i.e. a stream that did
not have an Interface Identifier associated with it).
The "Unexpected Message Class" error would be sent if a message with
an unexpected or unsupported Message Class is received.
The optional Diagnostic information can be any information germane
to the error condition, to assist in identification of the error
condition. To enhance debugging, the Diagnostic information could
contain the first 40 bytes of the offending message.
The Cause parameter can be one of the following values:
Invalid Version 0x1
Invalid Network Appearance 0x2
Invalid Adaptation Layer Identifier 0x3
Invalid Message Type 0x4
Invalid Traffic Handling Mode 0x5
Unexpected Message Type 0x6
Protocol Error 0x7
Invalid Routing Context 0x8
Unsupported Message Type 0x9
3.8.12 Status
The Status Type parameter identifies the type of the status that is
being notified.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000D | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 45]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
The valid values are shown in the following table.
1 Application Server state change (AS_State_Change)
2 Other
The Status Id parameter identifies the status that is being
notified. The valid values are shown in the following table.
If the Status Type is AS_STATE_CHANGE
If the Status Type is AS_State_Change the following Status
Information values are used:
1 Application Server Down (AS_Down)
2 Application Server Up (AS_Up)
3 Application Server Active (AS_Active)
4 Application Server Pending (AS_Pending)
5 Alternate ASP Active
6 Insufficient ASPs
If the Status Type is Other, then the following Status Information
values are defined:
1 Insufficient ASP resources active in AS
This notification is not based on the SG reporting the state change
of an ASP or AS. For the value defined the SG is indicating to an
ASP(s) in the AS that another ASP is required in order to handle the
load of the AS.
3.9 SUA-Specific parameters
These TLV parameters are specific to the SUA protocol.
Parameter Name Parameter ID
============== ============
Sequence Number 0x0101
Source Address 0x0102
Destination Address 0x0103
Return Cause 0x0104
Flags 0x0105
Source Reference Number 0x0106
Destination Reference Number 0x0107
Reserved 0x0108
SCCP Error 0x0109
ASP Capabilities 0x010A
Status 0x010B
Credit 0x010C
Not used 0x010D
SMI / Subsystem 0x010E
Loughney, et al. [Page 46]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
3.9.1 Sequence Number
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Rec Seq Num | Sent Seq Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is used exclusively for protocol class 3 to number each DT
message sequentially for the purpose of flow control, sequence
numbering and segmenting and reassembly.
It is used to number each DT message sequentially for the purpose of
flow control. It contains the received as well as the sent sequence
number, P(R) and P(S) in Q.713.
As such it can be used to acknowledge the receipt of data transfers
from the peer in case of protocol class 3.
Sent Sequence Number is one octet and is coded as follows:
Bits 8-2 are used to indicate the Send Sequence Number P(S).
Bit 1 of octet 1 is spare.
Receive Sequence Number is one octet, and is coded as follows:
Bits 8-2 are used to indicate the Receive Sequence Number
P(R).
Bit 1 is used for the more data indication, as follows:
0 no more data
1 more data.
3.9.2 Source Address (=CLG)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 47]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 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 analyzed.
Type of Address
Unknown/Undeterminable 0x00000000
SS7 SCCP CLG 0x00000001
Host Name 0x00000002
IPv4 Address 0x00000003
IPv6 Address 0x00000004
The combinations of SS7 addressing schemes (ITU, ANSI, etc).
supported is implementation dependant.
The Source Address field can contain the SCCP Calling Party Address.
It is possible to simply encapsulate the information, as presented
by the upper layer.
3.9.3 Destination Address (=CLD)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing param | Address Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ address parameter(s) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following address combinations are valid:
0x00 Reserved
0x01 Global Title
0x02 Global Title + PC
0x03 Global Title + PC + SSN
0x04 PC + SSN
0x05 Hostname
0x06 Hostname + SSN
0x07 IPv4
0x08 IPv4 + SSN
0x09 IPv6
0x0A IPv6 + SSN
3.9.3.1 Fixed Parameters
Loughney, et al. [Page 48]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Routing parameter
+-+-+-+-+-+-+-+-+
| |A|B|C|D|
+-+-+-+-+-+-+-+-+
A : Routing indicator: 0x0 = route-on-Global Title / Name
0x1 = route-on-SSN
B : SSN present : 0x0 = no SSN present
0x1 = SSN present
C : Pointcode present: 0x0 = no pointcode present
0x1 = pointcode present
D : GT/Name present : 0x0 = no Global Title/Name present
0x1 = Global Title/Name present
The following combinations of B, C and D are valid:
B | C | D |
----+-----+------+
0 | 0 | 1 | (1)
1 | 1 | 1 | (2)
1 | 1 | 0 | (3)
(1) only Global Title/name present, the output of the GTT
function must yield a SSN in addition to the DPC.
(2) GT, PC and SSN present, which of the elements to use for
routing is determined by the routing indicator
(3) PC and SSN present, routing indicator must be route-on-SSN
Address tags:
0x00 Reserved
0x01 Global Title
0x02 PC
0x03 SSN
0x04 IPv4
0x05 Hostname
0x09 IPv6
3.6.3.2 Global Title
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG= GLOBALTITLE | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GTI | Trans. type |E| Num. Plan | Nature of Add |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Title |
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 49]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
GTI = 0: No parameters required.
GTI = 1:
Num Plan: Not Used
Odd/even Indicator:
0 Even number of address signals
1 Odd number of address signals
Nature of Address:
0 unknown
1 subscriber number
2 reserved for national use
3 national significant number
4 international number
5 - 255 Spare
Global Title:
Octets contain a number of address signals and possibly a filler as
shown:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 2nd addr.sig. | 1st addr.sig. |
+---+---+---+---+---+---+---+---+
| 4th addr.sig. | 3rd addr.sig. |
+---+---+---+---+---+---+---+---+
| ... |
+---+---+---+---+---+---+---+---+
| filler(if req)| nth addr.sig. |
+---+---+---+---+---+---+---+---+
Address signals to be coded as defined in ITU-T Q.713 Section
3.4.2.3.1.
GTI = 2: (This type is for National use only)
Translation Type:
Since the allocation of Translation types for GTI=2 is a national
matter, the values used should map directly onto the SCCP values (0
- 225). For North America, Translation type code values are listed
in GR-246-CORE Ch. T1.112.3 Annex A.
Global Title: as for GTI = 1
Loughney, et al. [Page 50]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
GTI = 3:
Numbering Plan: Not Used
Nature of Address: Not Used
Translation Type:
For GTI=3 (ANSI GTI=1) the Translation type coding is for further
study.
E = Odd/even Indicator
0 Even number of address signals
1 Odd number of address signals
Numbering Plan:
0 unknown
1 ISDN/telephony numbering plan (Recommendations E.163 and
E.164)
2 generic numbering plan
3 data numbering plan (Recommendation X.121)
4 telex numbering plan (Recommendation F.69)
5 maritime mobile numbering plan (Recommendations E.210,
E.211)
6 land mobile numbering plan (Recommendation E.212)
7 ISDN/mobile numbering plan (Recommendation E.214)
8 - 13 spare
14 private network or network-specific numbering plan
15 - 126 spare
127 reserved.
Global Title: as for GTI = 1
GTI = 4:
Translation type:
0 Unknown
1 - 63 international services
64 - 127 spare
128 - 254 national network specific
255 reserved
E and Numbering Plan: as for GTI = 3
Nature of Address: as for GTI = 1
Global Title: as for GTI = 1
Loughney, et al. [Page 51]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
3.6.3.2 Hostname
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG= HostName | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Name |
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the type of address is Host Name, then the labels in the host
name has to be reversed to obtain a efficient Host Name encoding
form for the Global title translation function.
hostname: zzzz.yyy....edc.ab
should be transformed to
HTname : ab.edc....yyy.zzzz
The labels of the Host Name are then encoded using the encoding
rules of the labels described in [IDNS]. The end of the Host name is
indicated by 0x00.
Example :
hostname = www.reindael.security.org
First the name has to be reverse to have the gTLD on the left side.
Global Title name: org.security.reindael.www
Then the result of applying the rules of the iDNS is:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
x | 3 | O |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
x+2 | R | G |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
x+4 | 7 | S |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
x+6 | E | C |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
x+8 | U | R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
x+10| I | T |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
x+12| Y | 8 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
x+14| R | E |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
x+16| I | N |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
x+18| D | A |
Loughney, et al. [Page 52]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
x+20| E | L |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
x+22| 3 | W |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
x+24| W | W |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 00 | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3.6.3.3 IP Addresses
The IP address formats can use different tags. It should be noted
that if the called is in a certain IP version ,the calling should
also be in the same IP version. CLD = Ipv6, thus CLG must be = Ipv6
and vice versa.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG= IPvx | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.6.3.4 Subsystem number
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAG= SSN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSN value |
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.9.4 Return Cause
The Return Cause corresponds to the return cause of the SCCP
message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 53]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
The Length is a one octet unsigned integer.
Possible values for the Return Cause are:
0x00 no translation for an address of such nature
0x01 no translation for this specific address
0x02 subsystem congestion
0x03 subsystem failure
0x04 unequipped user
0x05 MTP failure
0x06 network congestion
0x07 unqualified
0x08 error in message transport (Note)
0x09 error in local processing (Note)
0x0A destination cannot perform reassembly (Note)
0x0B SCCP failure
0x0C hop counter violation
0x0D segmentation not supported
0x0E segmentation failure
0xFA Invalid ISNI routing request (Note)
0xFB Unauthorized message
0xFC Message Incompatibility
0xFD Cannot perform ISNI Constrained routing (Note)
0xFE Redundant ISNI constrained routing information (Note)
0xFF Unable to perform ISNI identification (Note)
NOTE: Only applicable to XUDT(S) message.
3.9.5 Flags
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| trans. type | Hop Counter | segmenting |D| B |A| C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Error Return option
Value Description
0x0 No error message
0x1 Return message on error
B Protocol class
Value Description
0x0 Class 0 (connectionless service)
0x1 Class 1 (connectionless service)
0x2 Class 2 (connection-oriented service)
0x3 Class 3 (connection-oriented service
Loughney, et al. [Page 54]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
C Importance
Value Description
0x0 Least important
:
0x7 Highest importance
D Segmentation
Value Description
0x0 No segmentation
0x1 Segmentation
Transfer Type is used when either a SG or ASP has knowledge about
the type of data transfer to send. If unable to determine which
type is needed, a value of undetermined is used. The field has
following values:
0 undetermined
1 unitdata
2 long unitdata
3 extended unitdata
Hop Counter
Value Description
0x0
:
0x15 Maximum number of GTT
Segmenting field corresponds to the SCCP Segmenting parameter.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| segmenting |
+-+-+-+-+-+-+-+-+
Bit 7 is coded as the following:
_ 0: in all segments but the first;
_ 1: first segment.
Bit 6 is used to keep in the message in sequence delivery option
required by the SCCP user and is coded as follows:
_ 0: Class 0 selected;
_ 1: Class 1 selected.
Bits 4 and 5 are spare bits.
Loughney, et al. [Page 55]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Bits 0-3 of octet 1 are used to indicate the number of remaining
segments. The values 0000 to 1111 are possible; the value 0000
indicates the last segment.
An SUA-layer MUST support receiving segmented messages & MUST be
able to re-assembled segmented messages. An SUA-layer at an SG MUST
be able to segment SCCP messages destined for the SS7 network. An
SUA-layer at an IPSP MAY support sending segmented messages.
3.9.6 Source Reference Number
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The source reference number is a 3 octet long integer, which is
generated by the local source to identify a connection.
Valid values are from 0x0 to 0xFFFFFE, while 0xFFFFFF is reserved
for future use.
3.9.7 Destination Reference Number
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Destination Reference Number is a 3 octet long integer, which is
generated by the destination node to identify a connection.
Valid values are from 0x0 to 0xFFFFFE, while 0xFFFFFF is reserved
for future use.
3.9.8 SCCP Error
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0109 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Cause Type | Cause Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 56]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Cause Type can have the following values:
Return Cause 0x1
Refusal Cause 0x2
Release Cause 0x3
Reset Cause 0x4
Error Cause 0x5
Cause Value contains the specific error value. Below gives examples
for ITU SCCP values. ANSI references can be found in ANSI T1.112.3
Cause value in Correspondence with Reference
SUA message SCCP parameter
------------------ ----------------- ---------
CLDR Return Cause ITU-T Q.713 Chap 3.12
COREF Refusal Cause ITU-T Q.713 Chap 3.15
RELRE Release Cause ITU-T Q.713 Chap 3.11
RESRE Reset Cause ITU-T Q.713 Chap 3.13
ERR Error Cause ITU-T Q.713 Chap 3.14
3.9.9 ASP Capabilities
This parameter is used so that the ASP can report it's capabilities
for supporting different protocol classes and interworking
scenarios.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Variant |0 0 0 0|a|b|c|d| interworking |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length is two octets.
SCCP Variant field can contain the following values:
Unidentified/unknown 0x0
ITU-I SCCP 0x1
ITU-N SCCP 0x2
ANSI SCCP 0x3
Japanese SCCP 0x4
Chinese SCCP 0x5
Other 0x6
Flags
a - Protocol Class 3
b - Protocol Class 2
c - Protocol Class 1
Loughney, et al. [Page 57]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
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.
3.9.10 Credit
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010C | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length is one octet.
3.9.11 SCMG Message Type
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCMG Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SCMG Message Type field may have the following values:
0 Reserved
1 SSA
2 SSP
3 SST
4 SOR
5 SOG
6 SSC
7 - 252 Reserved
253 SNR
254 SBR
255 SRT
3.9.12 SMI / Subsystem
0 1 2 3
Loughney, et al. [Page 58]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010E | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI | Spare | SSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subsystem Number (SSN) is one octet.
Subsystem multiplicity indicator (SMI) can have the following
values:
0x00 Reserved
0x01 Replicated
0x02 Solitary
0x03 Unknown
3.9.13 Receive Sequence Number
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010F | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Rec Seq Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is used exclusively for protocol class 3 in the data
acknowledgment message to indicate the lower edge of the receiving
window.
It is a 1 octet long integer coded as follows:
Bits 8-2 are used to indicate the Receive Sequence Number P(R).
Bit 1 is spare.
4 Procedures
The SUA layer needs to respond to various local primitives it
receives from other layers as well as the messages that it receives
from the peer SUA layers. This section describes the SCU procedures
in response to these events.
4.1 Peer Message Procedures
On receiving a message, the SUA layer at the SG performs address
translation and mapping (if needed), to determine the appropriate
Application Server Process (ASP). The appropriate ASP can be
determined based on the routing information in the incoming message,
local load sharing information, etc. The appropriate SUA message is
Loughney, et al. [Page 59]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
then constructed and sent to the appropriate endpoint, via the
correct SCTP association.
4.1.1 Connection Oriented Timers
The SUA layer needs to start a timer after sending a CR, RLSD or RSR
message.
4.2 Signaling Gateway Related Procedures
These support the SUA transport of SCCP-User/SCCP boundary
primitives.
On receiving a SCCP message at the SG, the SUA layer performs
address translation and mapping, to determine the appropriate
Application Server Process (ASP). The appropriate ASP can be
determined based on the information in the incoming message, local
load sharing information, etc. The appropriate SUA message is then
constructed and sent to the appropriate endpoint, via the correct
SCTP association.
The SUA needs to setup and maintain the appropriate SCTP association
to the selected endpoint. SUA also manages the usage SCTP streams.
4.2.1 ASP Down
The SG maintains the availability of the remote ASPs, and will need
to issue the correct SCCP management message (where applicable) to
the SS7 node(s).
ASPDN or even an ASPIA may not correlate to a SCCP SSP, as it
depends upon the ASP load configuration (primary/backup or
loadsharing specified in the routing context 'type' field) and also
upon the ASP routing configuration.
Where traffic for a single SSN is routed to just one ASP then the
withdrawal of that ASP will result in a SSP being issued. By
contrast, where a SSN is associated with more than one ASP and
routing to the different ASPs is achieved using the routing context
(e.g. TCAP TIDs) then the withdrawal of just one ASP will not yield
a SSP message.
4.2.2 MTP 3 - SUA interaction
The Signaling Gateway will need to manage the availability of the
ASPs within the IP network; while reporting the status of endpoints
in the SS7 network. Therefore, there will be interworking between
the MTP 3 layer and SUA. MTP 3 indication messages (MTP Pause, MTP
resume, MPT Status) need to be indicated to the peer SUA layer.
Loughney, et al. [Page 60]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
4.2.3 Support of Connectionless Data Transfer
When SUA operates in an interworking scenario with traditional SS7
networks, the SG (interworking function between SCCP and SUA) must
ensure that the selected outgoing connectionless message type
(UDT/S, XUDT/S or LUDT/S) is correctly understood by the recipient
SCCP node. The criteria for message type selection shall be handled
locally; this information can be based on the underlying MTP or
remote SCCP capabilities, or selected messages types preferred by
the recipient SCCP node.
4.3 Layer Management Procedures
The SUA layer needs to send and receive layer management messages.
4.4 SCTP Management Procedures
These procedures support the SUA management of SCTP Associations and
ASP Paths between SGs and ASPs.
4.4.1 State Management
The SUA layer on at each AS needs to maintain the state of each ASP
under its control, as a way to manage the state and connections of
the local ASPs. At a SG, the state of each ASP is needed as input
to the SGs address translation and mapping function.
4.4.1.1 ASP States
The state of each ASP is maintained in the SUA layer at the
controlling AS. The state of an ASP changes due to events. The
events include:
* Reception of messages from that ASP's SUA layer
* Reception of messages from a different ASP's SUA layer
* Reception of indications from the SCTP layer
* Switch over timer triggers
The ASP state transition diagram is shown in Figure 4. The possible
states of an ASP are:
ASP-DOWN: The Application Server Process is unavailable. Initially
all ASPs will be in this state.
ASP-UP: The Application Server Process is available but application
traffic is stopped.
ASP-ACTIVE: The Application Server Process is available and
application traffic is active.
Loughney, et al. [Page 61]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Figure 4: ASP State Transition Diagram
+-------------+
| |
+----------------------| ASP-ACTIVE |
| | |
| +-------------+
| ^ |
| ASP | | ASP
| Active | | Inactive
| | v
| +-------------+
| | |
| | ASP-UP |-------------+
| +-------------+ |
| ^ | |
ASP Down | ASP | | ASP Down / | ASP
SCTP Down| Up | | SCTP Down | Down/
| | v | SCTP
| +-------------+ | Down
| | | |
+--------------------->| ASP-DOWN |<------------+
| |
+-------------+
Figure 4: ASP State Transition Diagram
SCTP Down: The local SCTP layer's SHUTDOWN COMPLETE notification or
COMMUNICATION LOST notification.
4.4.1.2 AS States
The state of the AS is maintained in the SUA layer.
The state of an AS changes due to events. These events include:
* ASP state transitions
* Recovery timer triggers
The possible states of an AS are:
AS-DOWN: The Application Server is unavailable. This state implies
that all related ASPs are in the ASP-DOWN state for this AS.
Initially the AS will be in this state.
AS-UP: The Application Server is available but no application
traffic is active (i.e., one or more related ASPs are in the ASP-UP
state, but none in the ASP-Active state).
Loughney, et al. [Page 62]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
AS-ACTIVE: The Application Server is available and application
traffic is active. This state implies that one ASP is in the ASP-
ACTIVE state.
AS-PENDING: An active ASP has transitioned from active to inactive
or down and it was the last remaining active ASP in the AS. A
recovery timer T(r) will be started and all incoming SCN messages
will be queued by the SG. If an ASP becomes active before T(r)
expires, the AS will move to AS-ACTIVE state and all the queued
messages will be sent to the active ASP.
If T(r) expires before an ASP becomes active, the SG stops queuing
messages and discards all previously queued messages. The AS will
move to AS-UP if at least one ASP is in ASP-UP state, otherwise it
will move to AS-DOWN state.
+----------+ one ASP trans to ACTIVE +-------------+
| |---------------------------->| |
| AS-UP | | AS-ACTIVE |
| |<--- | |
+----------+ \ +-------------+
^ | \ Tr Expiry, ^ |
| | \ at least one | |
| | \ ASP in UP | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | all ASP \ one ASP | | Last ACT.
trans | | trans to \ trans to | | asp trans
to UP | | DOWN -------\ ACTIVE | | to UP or
| | \ | | DOWN
| | \ | |
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | --| |
| AS-DOWN | | AS-PENDING |
| | | (queueing) |
| |<----------------------------| |
+----------+ Tr Expiry no ASP +-------------+
in UP state
Tr = Recovery Timer
Figure 5: AS State Transition Diagram
4.4.2 ASPM procedures for primitives
Loughney, et al. [Page 63]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Before the establishment of an SCTP association the ASP state at
both the AS and ASP is assumed to be "Down".
When the SUA layer receives an M-SCTP ESTABLISH request primitive
from the Layer Management, the SUA layer will try to establish an
SCTP association with the remote SUA peer. Upon reception of an
eventual SCTP-Communication Up confirm primitive from the SCTP, the
SUA layer will invoke the primitive M-SCTP ESTABLISH confirm to the
Layer Management.
Alternatively, if the remote SUA-peer establishes the SCTP
association first, the SUA layer will receive an SCTP Communication
Up indication primitive from the SCTP. The SUA layer will then
invoke the primitive M-SCTP ESTABLISH indication to the Layer
Management.
Once the SCTP association is established, The SUA layer at an ASP
will then find out the state of its local SUA-user from the Layer
Management using the primitive M-ASP STATUS. Based on the status of
the local SUA-User, the local ASP SUA Application Server Process
Maintenance (ASPM) function will initiate the ASPM procedures, using
the ASP-Up/-Down/-Active/-Inactive messages to convey the ASP-state
to the SG - see Section 2.5.
If the SUA layer subsequently receives an SCTP-Communication Down
indication from the underlying SCTP layer, it will inform the Layer
Management by invoking the M-SCTP STATUS indication primitive. The
state of the ASP will be moved to "Down."
At an ASP, the Layer Management may try to reestablish the SCTP
association using M-SCTP ESTABLISH request primitive.
4.4.3 ASPM procedures for peer-to-peer messages
4.4.3.1 ASP-Up
An ASP sends an ASPUP to each remote AS to which it is a member of.
When the ASPUP message is received, the remote AS will mark the
remote ASP Inactive, as long as the ASP is not considered locked-out
for local management reasons. The remote peer replies with an ASP-
Up Ack message in acknowledgement, to every ASPUP, even if the ASP
is already marked as Inactive. If for any local reason (e.g.,
management lock-out) the remote peer cannot respond with an ASP-Up
Ack, the SG responds to an ASP-Up with an ASP-Down Ack message with
Reason "Management Blocking".
If the ASP does not receive a ASPUP ACK, the ASP may resend ASP-Up
messages until it receives an ASP-Up Ack message. The ASP must wait
for the ASP-Up Ack message before sending any other messages. If the
Loughney, et al. [Page 64]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
remote peer receives any other SUA messages from an ASP, before an
ASP Up is received, the message should be discarded.
4.4.3.2 ASP Down
The AS will mark the ASP as down and send a ASPDN message to the ASP
if one of the following events occur:
- an ASP Down (ASPDN) message is received from the ASP,
- the ASP is locked by local maintenance.
The SG sends an ASP-Down Ack message in response to a received ASP-
Down message from the ASP even if the ASP is already marked as Down.
The ASP will send ASPDN whenever it wants to take down a ASP. Since
it is possible for ASPDN and ASPDN ACK messages to be lost (for
example, during a node failover), the ASP can send ASPDN messages
every t(a) seconds until the path comes down (i.e. until it receives
a ASPDN message from the remote peer for that path).
4.4.3.3 ASP Version Control
If a ASP Up message with an unknown version is received, the
receiving end will respond with an Error message. This will
indicate to the sender which version the receiving node supports.
This is useful when protocol version upgrades are being performed.
A node with the newer version should support the older versions used
on other nodes it is communicating with.
The version field in the Error message header associated will
indicate the version supported by the node.
4.4.3.4 ASP Active
When an ASP is ready to start processing traffic, it sends an ASP
Active message to the remote peer. When an ASP Active (ASPAC)
message is received, the remote peer responds with an ASPAC ACK.
The ASP cannot send any other messages until after the ASPAC ACK is
received. If the ASPAC ACK is not received within a certain period,
the ASP may resend the ASPAC message.
The ASP Active message optionally contains a list of one more
Routing Contexts, indicating for which Application Servers the ASP
is joining. If no Routing Contexts are present, then local
configuration data is used to determine to which Application
Server(s) the ASP belongs.
The Type parameter in the ASPAC message indicates the traffic
handling mode used in a particular Application Server, either Over-
Loughney, et al. [Page 65]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
ride, Over-ride (standby), Load-share or Load-share (standby). If
the remote peer determines that the mode indicated in an ASPAC is
incompatible with the mode currently used in the AS, the remote peer
responds with an Error message indicating "Invalid Traffic Handling
Mode".
In the Over-ride mode, reception of an ASPAC message at a remote
peer causes the all traffic for the AS to be sent to the ASP which
sent the ASPAC. All previously active ASPs in the AS are now
considered Inactive and will no longer receive traffic for that
particular AS. The remote peer sends a Notify (Alternate ASP-
Active) to the previously active ASPs in the AS, after stopping all
traffic to that ASP.
In the Over-ride (Standby) mode, the actions are the same with the
exception that the traffic is not started to the ASP until the
previously active ASP transitions to "Inactive or "Down" state. At
this point the ASP that sent the Over-Ride (Standby) ASPAC is moved
to the Active state and the traffic is redirected. No Notify
messages are needed.
In the Load-share mode, reception of an ASPAC message causes the
redistribution of traffic to the ASP sending the ASPAC, in addition
to all the other ASPs that are currently active in the AS. The
algorithm at the SG for load-sharing traffic within an AS to all the
active ASPs is implementation dependent. All ASPs marked load-
sharing should be able to handle any traffic within the AS, in order
to accommodate any potential fail-over or re-balancing of the
offered load.
In the Load-share (Standby) mode, the actions are the same as the
Load-share mode, with the exception that the traffic is not started
to the ASP until the remote peer determines that additional
resources are needed the AS. When needed, the ASP which sent the
Loadshare (Standby) ASPAC is moved to the Active state and traffic
is started. No Notify messages are needed to be sent.
A node that receives an ASPAC with an incorrect Type for a
particular Routing Context will respond with an Error Message, Cause
= Invalid Traffic Handling Mode. A node that receives an unknown
Routing Context value responds with an Error message, Cause =
Invalid Routing Context.
4.4.3.5 ASP Inactive
When an ASP wishes to withdraw from receiving traffic, it sends an
ASPIA to the applicable remote ASPs, within the AS from which it is
withdrawing. If the ASP is withdrawing from more than one AS, then
the ASP issues either multiple ASPIA message, if multiple SCTP
Loughney, et al. [Page 66]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
associations exist to the remote ASPs; or a single ASPIA message
containing multiple Routing Contexts.
There are two ASPIA modes, Over-ride and load-share. If the remote
peer determines that the Type parameter in the ASPIA is inconsistent
with the mode being used by the Application Server, an error is
reported to the local layer management, Invalid Traffic Handling
Mode. However, the ASPIA is still handled.
In the Over-ride mode, the ASP which sent the ASPIA is marked as
Inactive. No further traffic is sent from and to the ASP marked
Inactive.
In the Load-sharing mode, the remote AS marks the ASP as inactive
and re-allocates the traffic to the remaining active ASPs. The
load-sharing mechanism used is outside of the scope of SUA. If there
is insufficient resources, a NTFY (Insufficient ASPs) may be sent to
all inactive ASPs. If a Loadshare (Standby) ASP is available, it
may be now immediately included in the loadshare group and a Notify
message may not be sent. An ASPIA Ack message is sent to the ASP
after all traffic is halted.
In the case when no other ASPs are active or standby in the
Application Server, the remote peer should send a NTFY (AS-Pending)
to all inactive ASPs of the AS. The remote peer then either
discards all incoming messages for the AS or starts buffering the
incoming messages for T(r) seconds, after which messages will be
discarded. T(r) is configurable by the network operator.
If the remote peer receives an ASPAC from an ASP in the AS before
expiry of T(r), the buffered traffic is directed to the ASP and the
timer is cancelled. If T(r) expires, the AS is moved to the "Down"
state.
4.4.3.6 Notify
A NTFY message reflecting a change in the AS state is sent to all
ASPs in the AS, except those in the "Down" state, with appropriate
Status Identification.
In the case where a NTFY (AS-Pending) message is sent by an SG that
now has no ASPs active to service the traffic, or a NTFY
Insufficient ASPs) is sent in the Loadshare mode, the NTFY does not
explicitly force the ASP(s) receiving the message to become active.
The ASPs remain in control of what (and when) action is taken.
4.3.3.7 Heartbeat
Loughney, et al. [Page 67]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
The optional Heartbeat message may be sent in order to query the
status of the remote peer. It is optional to send, but mandatory to
acknowledge.
The data field can be used to store information in the heartbeat
message useful to the sending node (e.g. the data field can contain
a time stamp, a sequence number, etc.).
5 Examples of SUA Procedures
The following sequence charts overview the procedures of SUA. These
are meant as examples, they do not, in and of themselves, impose
additional requirements upon an instance of SUA.
5.1 SG Architecture
The sequences below outline logical steps for a variety of scenarios
within a SG architecture. Please note that these scenarios cover a
Primary/Backup configuration. Where there is a load-sharing
configuration then the SG can declare availability when 1 ASP issues
ASPAC but can only declare unavailability when all ASPs have issued
ASPIA.
5.1.1 Establishment of SUA connectivity
The following must be established before SUA/SCCP traffic can flow.
Each node is configured (via MIB or through discovery protocol) with
the connections that need to be setup
ASP-a1 ASP-a2 SG SEP
(Primary) (Backup)
|------Establish SCTP Association------|
|--Estab. SCTP Ass--|
|--Align SS7 link---|
Each ASP declares to the SG that it is running.
+----------------ASP Up---------------->
<--------------ASP Up Ack--------------+
+------ASP Up------->
<---ASP Up Ack------+
The Primary ASP declares to the SG that it is active.
The SG notifies all ASPs.
+-------------ASP Active--------------->
<----------ASP Active Ack--------------+
<----------NTFY (ASP Active)-----------+
<-NTFY (ASP Active)-+
Loughney, et al. [Page 68]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
The SG declares the availability of the signaling
user on ASP-a1 to the SEP. The SG has been
configured (via a MIB) that the SEP is concerned
about its signaling users. N.B. The SGs SS7 address
is presented in the SSA, i.e. the SG represents the
availability of ASP-a1 to the SEP.
+--------SSA-------->
The SEP declares its availability to the SG since
the SG appears within its concerned list. Similarly,
the SG informs the active ASP of the availability of
the SEP as dictated by SGs concerned list. N.B.
The SG maps the SS7 address of the SEP to an
IP address which the SG knows ASP-a1 will understand.
<--------SSA--------+
<-----------------DAVA-----------------+
Traffic can now flow. A connectionless flow is shown
for simplicity. Nevertheless, the SG is responsible
for mapping IP to SS7 addresses and vice-versa. Only
the Routing Context for ASP-a1 persists from ASP-a1 to
SEP.
+-----------------CLDT----------------->
+--------UDT-------->
5.1.2 Failover scenarios
The following sequences address failover of SEP and ASP
5.1.2.1 SEP Failover
The SEP knows that the SG is 'concerned' about its availability.
Similarly, the SG knows that ASP-a1 is concerned about the SEPs
availability, therefore the incoming SSP is translated into DUNA.
ASP-a1 can then instruct the SG to invoke the SS7 Sub-system Test
procedure using AUD.
ASP-a1 ASP-a2 SG SEP
(Primary) (Backup)
<--------SSP--------+
<-----------------DUNA-----------------+
+-----------------DAUD----------------->
+--------SST-------->
5.1.2.2 Successful ASP Failover scenario
Loughney, et al. [Page 69]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
The following is an example of a successful failover scenario, where
there is a failover from ASP-a1 to ASP-a2, i.e. Primary to Backup.
During the failover, the SG buffers any incoming data messages from
the SEP, forwarding them when the Backup becomes available.
ASP-a1 ASP-a2 SG SEP
(Primary) (Backup)
+-------------ASP Inactive------------->
<----------NTFY (ASP Inactive)---------+
<-NTFY (ASP Inact.)-+
+----ASP Active----->
<--ASP Active Ack---+
<-NTFY (ASP Active)-+
<----------NTFY (ASP Active)-----------+
5.1.2.3 Unsuccessful ASP Failover scenario
ASP-a1 ASP-a2 SG SEP
(Primary) (Backup)
+-------------ASP Inactive------------->
<----------NTFY (ASP Inactive)---------+
<-NTFY (ASP Inact.)-+
After some time elapses (i.e. timeout).
+--------SSP-------->
<--------SST--------+
5.2 IP-IP Architecture
The sequences below outline logical steps for a variety of scenarios
within an IP-IP architecture. Please note that these scenarios
cover a Primary/Backup configuration. Where there is a load-sharing
configuration then the AS can declare availability when 1 ASP issues
ASPAC but can only declare unavailability when all ASPs have issued
ASPIA.
5.2.1 Establishment of SUA connectivity
The following shows an example establishment of SUA connectivity.
In this example, each IP SP consists of a Management Instance (MI)
and two ASPs. The Management Instance handles the address mapping
mechanisms and monitors the states of the remote peer. For
simplicity, the Management Instances and ASPs are considered as a
separate entity. This is not a requirement, as they can be co-
located with an ASP.
The following must be established before SUA traffic can flow. A
connectionless flow is shown for simplicity.
Loughney, et al. [Page 70]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Each node is configured (via MIB or through discovery protocol) with
the connections that need to be setup
IP SEP A IP SEP B
ASP-a1 ASP-a2 MI a MI b ASP-b2 ASP-b1
(Primary) (Backup) (Backup) (Primary)
Establish SCTP Connectivity
|-- Est. SCTP Ass.--|
|------ Establish SCTP Association -------|
|------------- Establish SCTP Association -------------|
|------------------ Establish SCTP Association ------------------|
|--- Establish SCTP Assoc. ----|
|------- Establish SCTP Association --------|
|------------ Establish SCTP Association -------------|
|-- Establish SCTP Association -|
|------- Establish SCTP Association ------|
Establish SUA Connectivity
+---------------ASP Up------------------->
<---------------ASP Up Ack---------------+
+------------ASP Up----------->
<------------ASP Up Ack-------+
<--------------ASP Up-------------+
+--------------ASP Up Ack--------->
<----------------ASP Up---------------------+
+----------------ASP Up Ack----------------->
+---------------ASP Act------------------>
<---------------ASP Act Ack--------------+
<----------------ASP Act--------------------+
+----------------ASP Act Ack---------------->
Traffic can now flow directly between ASPs.
+-------------------------------CLDT------------------------------->
5.2.2 Failover scenarios
Loughney, et al. [Page 71]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
The following sequences address failover of ASP
5.2.2.1 Successful ASP Failover scenario
The following is an example of a successful failover scenario, where
there is a failover from ASP-a1 to ASP-a2, i.e. Primary to Backup.
Since data transfer passes directly between peer ASPs, ASP-b1 is
notified of the failover of ASP-a1 and must buffer outgoing data
messages until ASP-a2 becomes available.
IP SEP A IP SEP B
ASP-a1 ASP-a2 MI a MI b ASP-b2 ASP-b1
(Primary) (Backup) (Backup) (Primary)
+--------------ASP Inact----------------->
<--------------ASP Inact Ack-------------+
<----NTFY (ASP-a1 Inactive)---+
+----------ASP Act------------>
<----------ASP Act Ack--------+
5.2.2.2 Unsuccessful ASP Failover scenario
The sequence is the same as 4.2.2.1 except that, since the backup
fails to come in then, the Notify messages declaring the
availability of the backup are not sent.
6 Message Routing Scenarios
6.1 Basic case with single SG acting as end- or relay-point
______ _____ ______
| | SS7 | | IP | |
| SEP |-----------| SG |-----------| ASP |
|_____| |____| |_____|
6.1.1 SG as end-point
Address information in (X)UDT message from SEP to SG :
- MTP routing label OPC = SEP, DPC = SG
- SCCP calling party address contains SSN, optionally OPC = SEP
- SCCP called party address contains SSN
At the SG, the SCCP subsystem identified by SSN (and for non-
standardized SSN, also MTP network) is regarded as a local
subsystem. From SEP point of view, the SCCP-user is located at the
SG.
Loughney, et al. [Page 72]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Depending on administration data, the SG knows the SCCP-user is
serviced by an AS, which means a set of ASPs working in n+k
redundancy mode. An ASP is selected and the CLDT message is sent on
the appropriate SCTP association/stream.
Actually, the primitive interface between SCCP and SCCP-user is
transported here over SUA.
Address information in CLDT message from SG to ASP :
- Association ID : SG-ASP, Stream ID : based on SLS (and
possibly OPC, MTP network ID)
- Source address contains PC (SEP) + SSN + MTP network ID,
needed for back routing
- Destination address contains SSN, to select the SCCP-user at
the ASP.
The MTP network ID is needed if the SG operates in more than 1 MTP
network. PC and SSN only have meaning within an MTP network. In the
response, the ASP should pass a unique, unambiguous source address.
Further messages from SEP belonging to the same transaction /
connection will then reach the same ASP.
Address information in CLDT message from ASP to SG :
- Association ID : ASP-SG, Stream ID : implementation
dependent, but in-sequence-delivery must be taken care of
- Source address contains unique ASP address : when used as
SCCP called party address at the SG, the SG SHOULD select the
same ASP again.
- Destination address copied from source address in received
CLDT message.
6.1.2 SG as relay-point
Address information in (X)UDT message from SEP to SG :
- MTP routing label OPC = SEP, DPC = SG
- SCCP calling party address contains SSN, optionally OPC =
SEP, and a GT
- SCCP called party address contains SSN and a GT
Since routing is done on GT, the actual location of the SCCP-user is
irrelevant to the SEP. Translation of the GT always leads to a "SCCP
entity set", which in this case equals an AS. Selection of the AS is
thus based on the SCCP called party address (and possibly other
parameters, e.g. OPC, depending on the implementation). Basically
this means splitting the SS7 traffic over different AS's based on GT
information After this, the same as in 6.1.1 applies.
Loughney, et al. [Page 73]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Address information in CLDT message from SG to ASP :
- Association ID : SG-ASP, Stream ID : based on SLS (and
possibly OPC, MTP network ID)
- Source address contains PC (SEP) + SSN + MTP network ID or a
GT, needed for back routing
- Destination address contains SSN, to select the SCCP-user at
the ASP.
6.2 Replicated SG acting as end-point
______ _____
| | | |
| STP |------------| SG |
|_____| |____|
/ \ / \
/ \ / \
/ \ / \
/ \ / \
______ / \ / \ ______
| | / \ / \| |
| SEP |/ \ /| ASP |
|_____|\ / \ / |_____|
\ / \ /
\ / \ /
\ / \ /
\ / \ /
______/ _____/
| | | |
| STP |-----------| SG |
|_____| |____|
This case does not differ much from the basic case 6.1.1. The SCCP-
user is still considered to be located at the SG. Only for the first
message of the transaction/connection, a SG selection must be made
(possibly via GTT at the STPs, or by implementation dependent means
on the SEP). Once selected, the same SG is used throughout the
transaction/connection.
6.3 Replicated SG acting as relay-point
Loughney, et al. [Page 74]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
______ _____
| | | |
| STP |------------| SG |
|_____| |____|
/ \ / \
/ \ / \
/ \ / \
/ \ / \
______ / \ / \ ______
| | / \ / \| |
| SEP |/ \ /| ASP |
|_____|\ / \ / |_____|
\ / \ /
\ / \ /
\ / \ /
\ / \ /
______/ _____/
| | | |
| STP |-----------| SG |
|_____| |____|
The final GTT occurs in one of the mated pair SGs (with identical
database). The ASP is selected in the same way as in 6.1.2. In
normal circumstances, the path from SEP to ASP will always go via
the same SG when in-sequence-delivery is requested. However, linkset
failures may cause re-routing to the other SG. This should be kept
in mind when the SG is to reassemble XUDT segments received from SEP
into a single CLDT before sending to the ASP.
7 Security
7.1 Introduction
SUA is designed to carry signaling messages for telephony services.
As such, SUA must involve the security needs of several parties: the
end users of the services; the network providers and the
applications involved. Additional security requirements may come
from local regulation. While having some overlapping security
needs, any security solution should fulfill all of the different
parties' needs.
7.2 Threats
There is no quick fix, one-size-fits-all solution for security. As
a transport protocol, SUA has the following security objectives:
* Availability of reliable and timely user data transport.
* Integrity of user data transport.
* Confidentiality of user data.
Loughney, et al. [Page 75]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
SUA runs on top of SCTP. SCTP provides certain transport related
security features, such as:
* Blind Denial of Service Attacks
* Flooding
* Masquerade
* Improper Monopolization of Services
When SUA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network
includes an appropriate security policy framework. The "Site
Security Handbook" [2196] should be consulted for guidance.
When the network in which SUA runs in involves more than one party,
it may not be reasonable to expect that all parties have implemented
security in a sufficient manner. End-to-end security should be the
goal, therefore, it is recommended that IPSEC is used to ensure
confidentiality of user payload. Consult [2409] for more
information on configuring IPSEC services.
7.3 Protecting Confidentiality
Particularly for mobile users, the requirement for confidentiality
may include the masking of IP addresses and ports. In this case
application level encryption is not sufficient; IPSEC ESP should be
used instead. Regardless of which level performs the encryption, the
IPSEC ISAKMP service should be used for key management.
8 IANA Considerations
8.1 SCTP Payload Protocol ID
A request will be made to IANA to assign SCTP Payload Protocol IDs.
A Payload ID for the SUA will be registered.
The Payload ID is included in each SCTP data chunk, to indicate
which protocol SCTP is carrying. This Payload ID is not directly
used by SCTP but may be used by certain network entities to identify
the type of information being carried in this DATA chunk.
It is assumed that the Payload ID for SUA will be 4.
8.2 Port Number
SUA will use port number 14001, which is currently registered to
"ITU-T SCCP". This Port Number is the port which the SG listen to
when receiving SCTP datagrams.
Protocol Extensions
This protocol may also be extended through IANA in three ways:
Loughney, et al. [Page 76]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
-- through definition of additional message classes,
-- through definition of additional message types, and
-- through definition of additional message parameters.
The definition and use of new message classes, types and parameters
is an integral part of SIGTRAN adaptation layers. Thus, these
extensions are assigned by IANA through an IETF Consensus action as
defined in [RFC2434].
The proposed extension must in no way adversely affect the general
working of the protocol.
8.3 IETF Defined Message Classes
The documentation for a new message class MUST include the following
information:
(a) A long and short name for the message class;
(b) A detailed description of the purpose of the message class.
8.3.1 IETF Defined Message Types
Documentation of the message type MUST contain the following
information:
(a) A long and short name for the new message type;
(b) A detailed description of the structure of the message.
(c) A detailed definition and description of intended use of each
field within the message.
(d) A detailed procedural description of the use of the new message
type within the operation of the protocol.
(e) A detailed description of error conditions when receiving this
message type.
When an implementation receives a message type which it does not
support, it MUST respond with an Error (ERR) message, with an Error
Code = Unsupported Message Type.
8.3.3 IETF-defined TLV Parameter Extension
Documentation of the message parameter MUST contain the following
information:
(a) Name of the parameter type.
(b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described earlier in the document.
(c) Detailed definition of each component of the parameter value.
(d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances
multiple instances of this parameter type may be found within
the same message type.
Loughney, et al. [Page 77]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
9 Timer Values
Ta 2 seconds
Tr 2 seconds
T(ack) 2 seconds
10 Acknowledgements
The authors would like to thank Al Varney, Brian Bidulock, Marja-
Liisa Hamalainen and Markus Maanoja for their insightful comments
and suggestions.
Funding for the RFC editor function is currently provided by the
Internet Society.
10 Authors' Addresses
John Loughney
Nokia Research Center
PO Box 407
FIN-00045 Nokia Group
Finland
EMail: john.loughney@nokia.com
Greg Sidebottom
Nortel Networks
3685 Richmond Rd,
Nepean, Ontario, Canada K2H 5B7
EMail: gregside@nortelnetworks.com
Guy Mousseau
Nortel Networks
3685 Richmond Rd
Nepean, Ontario, Canada K2H 5B7
Stephen Lorusso
Unisphere Solutions
One Executive Drive
Chelmsford, MA 01824
USA
email: SLorusso@UnisphereSolutions.com
Lode Coene
Siemens Atea
Atealaan 34
B-2200 Herentals
Belgium
Phone: +32-14-252081
EMail: lode.coene@siemens.atea.be
Loughney, et al. [Page 78]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Gery Verwimp
Siemens Atea
34 Atealaan
PO 2200
Herentals
Belgium
Phone : +32 14 25 3424
EMail:gery.verwimp@siemens.atea.be
Joe Keller
Tekelec
5200 Paramount Parkway
Morrisville, NC 27560
USA
EMail: joe.keller@tekelec.com
Florencio Escobar Gonzalez
Ericsson Spain S.A.
Retama 7, 2nd floor
28045, Madrid
Spain
EMail: florencio.escobar@ericsson.com
Steven Furniss
Marconi
New Century Park
Coventry CV3 1HJ
United Kingdom
EMail: steven.furniss@marconi.com
William Sully
Marconi
New Century Park
Coventry CV3 1HJ
United Kingdom
EMail: william.sully@marconi.com
11 References
[2719] RFC 2719, "Framework Architecture for Signaling
Transport"
[ITU SCCP] ITU-T Recommendations Q.711-714, 'Signaling System
No. 7 (SS7) - Signaling Connection Control Part
(SCCP)'
[ANSI SCCP] ANSI T1.112 'Signaling System Number 7 - Signaling
Connection Control Part'
[ITU TCAP] ITU-T Recommendation Q.771-775 'Signaling System No.
7 SS7) - Transaction Capabilities (TCAP)
Loughney, et al. [Page 79]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
[ANSI TCAP] ANSI T1.114 'Signaling System Number 7 - Transaction
Capabilities Application Part'
[RANAP] 3G TS 25.413 V3.3.0 (2000-09) 'Technical
Specification 3rd Generation Partnership Project;
Technical Specification Group Radio Access Network;
UTRAN Iu Interface RANAP Signalling'
[SCTP] RFC 2960 "Stream Control Transport Protocol" R.
Stewart, et. Al. November 2000.
[M3UA] MTP3-User Adaptation Layer <draft-ietf-sigtran-m3ua-
04.txt>, September 2000, Work in Progress.
[2401] RFC 2401, "Security Architecture for the Internet
Protocol", S. Kent, R. Atkinson, November 1998.
[UTRAN IUR] 3G TS 25.420 V3.2.0 (2000-09) "Technical
Specification 3rd Generation Partnership Project;
Technical Specification Group Radio Access Network;
UTRAN Iur Interface General Aspects and Principles"
[2196] RFC 2196, "Site Security Handbook", B. Fraser Ed.,
September 1997.
[ENUM] "ENUM Requirements" <draft-ietf-enum-rqmts-01.txt>,
June 2000, Work in Progress.
[E.164-DNS] RFC 2916 "E.164 number and DNS", P. Faltstrom,
September 2000.
[IDNS] Blanchet, M., Hoffman, P., "Internationalized domain
names using EDNS (IDNE)", <draft-ietf-idn-idne-
01.txt>, Work in progress, July 2000
[RFC2434] RFC 2434 "Guidelines for Writing an IANA
Considerations Section in RFCs", T. Narten, H.
Alvestrand, October 1998.
[ITU-MTP] ITU-T Recommendations Q.701-Q.705, 'Signalling System
No. 7 (SS7) - Message Transfer Part (MTP)'
[ANSI-MTP] ANSI T1.111 'Signaling System Number 7 - Message
Transfer Part'
Appendix A: Message mapping between SCCP and SUA.
This is for illustrative purposes only.
SUA SCCP SCCP Classes Mgt. SUA
Loughney, et al. [Page 80]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Name Name Full Name 0 1 2 3 Msg.Usage
====================================================================
Connectionless Messages
CLDT UDT Unitdata X X - - - -
CLDT XUDT Extended unitdata X X - - - -
CLDT LUDT Long unitdata X X - - - -
CLDR UDTS Unitdata service X X - - - -
CLDR XUDTS Extended unitdata serv. X X - - - -
CLDR LUDTS Long unitdata service X X - - - -
Connection-Oriented Messages
CODT DT1 Data form 1 - - X - - -
CODT DT2 Data form 2 - - - X - -
CODT ED Expedited data - - - X - -
CODA AK Data acknowledgement - - - X - -
CODA EA Expedited data ack. - - - X - -
CORE CR Connection request - - X X - -
COAK CC Connection confirm - - X X - -
COAK CREF Connection refused - - X X - -
RELRE RLSD Released - - X X - -
RELCO RLC Release complete - - X X - -
RESRE RSR Reset request - - - X - -
RESCO RSC Reset confirm - - - X - -
General Protocol Messages
ERR ERR Protocol data unit error - - X X - X
AUD IT Inactivity test - - X X - X
SS7 MGT Messages
DUNA n/a n/a - - - - - X
DAVA n/a n/a - - - - - X
DAUD n/a n/a - - - - - X
SCMG SSC SCCP/subsystem-congested - - - - X -
SCMG SSA subsystem-allowed - - - - X -
SCMG SSP subsystem-prohibited - - - - X -
SCMG SST subsystem-status-test - - - - X -
SCMG SOR subsystem-oos-req - - - - X -
SCMG SOG subsystem-oos-grant - - - - X -
SUA MGT Messages
ASPUP n/a n/a - - - - - X
ASPDN n/a n/a - - - - - X
ASPAC n/a n/a - - - - - X
ASPIA n/a n/a - - - - - X
NTFY n/a n/a - - - - - X
- = Message not applicable for this protocol class.
X = Message applicable for this protocol class.
n/a = not applicable
Loughney, et al. [Page 81]
Internet Draft SS7 SCCP-User Adaptation Layer November 24, 2000
Appendix B: Message Mapping Examples
1 SUA->SCCP
2 SCCP->SUA
CLDT
- A and B flags are mapped from 'Protocol Class' parameter
received in XUDT/LUDT/UDT (or from Data Request primitive).
- C flag is mapped from 'Importance parameter' received in XUDT/LUDT
(or from Data Request primitive), or if not present a default
value for the message type shall be used.
Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Loughney, et al. [Page 82]
| ||||||||||||||||
| Last modified: Wed, 12 Nov 2014 06:08:29 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||