| draft-ietf-sigtran-sua-06Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-sua-06.txt.
INTERNET-DRAFT J. Loughney (Editor)
Internet Engineering Task Force Nokia
G. Sidebottom, Guy Mousseau
Issued: 15 June 2001 Nortel Networks
Expires: 15 December 2001 S. Lorusso
Unisphere Solutions
L. Coene, G. Verwimp
Siemens
J. Keller
Tekelec
F. Escobar
Ericsson
W. Sully, S. Furniss
Marconi
SS7 SCCP-User Adaptation Layer (SUA)
<draft-ietf-sigtran-sua-06.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as 'work in progress.'
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
.
This draft expires on 15 December 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 June 15, 2001
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 .............................12
1.5 Internal Functions Provided in the SUA Layer ...................14
1.6 Definition of SUA Boundaries ...................................16
2 Conventions........................................................17
3 Protocol Elements..................................................17
3.1 Common Message Header ..........................................17
3.2 SUA Connectionless Messages ....................................21
3.3 Connection Oriented Messages ...................................23
3.4 Signaling Network Management Messages ..........................30
3.5 Application Server Process State Maintenance Messages ..........34
3.6 ASP Traffic Maintenance Messages ...............................36
3.7 SUA Management Messages ........................................39
3.8 Common Parameters ..............................................40
3.9 SUA-Specific parameters ........................................48
4 Procedures.........................................................59
4.1 SCCP _ SUA Interworking at the SG ..............................59
4.2 Primitives received from the local SUA-user ....................61
4.3 Layer Management Procedures ....................................62
4.4 SUA Management Procedures ......................................62
5 Examples of SUA Procedures.........................................69
5.1 SG Architecture ................................................69
5.2 IP-IP Architecture .............................................72
6 Security...........................................................73
6.1 Introduction ...................................................74
6.2 Threats ........................................................74
6.3 Protecting Confidentiality .....................................74
7 IANA Considerations................................................74
7.1 SCTP Payload Protocol ID .......................................74
7.2 Port Number ....................................................75
7.3 Protocol Extensions ............................................75
8 Timer Values.......................................................76
9 Acknowledgements...................................................76
10 Authors' Addresses................................................76
11 References........................................................78
Appendix A: Message mapping between SCCP and SUA.....................80
Copyright Statement..................................................81
Loughney, et al. [Page 2
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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 SCCP-User Part messages (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-
oriented service or both services.
1.2 Terminology
Signaling Gateway (SG) - Network element that terminates SCN
signaling and transports SCCP-User signaling over IP to an IP
signaling endpoint. A Signaling Gateway could be modeled as one or
more Signaling Gateway Processes, which are located at the border of
the SS7 and IP networks.
Application Server (AS) - A logical entity serving a specific
Routing Key. An example of an Application Server is a virtual IP
Loughney, et al. [Page 3
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
database element handling all requests for a SCCP-user. The AS
contains a set of one or more unique Application Server Processes,
of which one or more is normally actively processing traffic.
Application Server Process (ASP) - An Application Server Process
serves as an active or standby process of an Application Server
(e.g., part of a distributed signaling node or database element).
Examples of ASPs are MGCs, IP SCPs, or IP-based HLRs. An ASP
contains an SCTP end-point and may be configured to process traffic
within more than one Application Server.
IP Server Process (IPSP) - A process instance of an IP-based
application. An IPSP is essentially the same as an ASP, except that
it uses SUA in a peer-to-peer fashion. Conceptually, an IPSP does
not use the services of a Signaling Gateway.
Signaling Gateway Process (SGP) - A process instance of a Signaling
Gateway. It serves as an active, standby or load-sharing process of
a Signaling Gateway.
Signaling Process - A process instance that uses SUA to communicate
with other signaling process. An ASP, a signaling gateway process
and an IPSP are all signaling processes.
Association - An association refers to an SCTP association. The
association provides the transport for the delivery of SCCP-User
protocol data units and SUA layer peer messages.
Routing Key - The Routing Key describes a set of SS7 parameters
and/or parameter-ranges that uniquely defines the range of signaling
traffic configured to be handled by a particular Application Server.
An example would be where a Routing Key consists of a particular SS7
network ID and SCCP SSN for which all traffic would be directed to a
particular Application Server. Routing Keys are mutually exclusive
in the sense that a received SS7 signaling message cannot be
directed to more than one Routing Key. Routing Keys should be
provisioned, for example, by a MIB.
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.
Address Mapping Function (AMF) - The AMF is an implementation
dependent function which is responsible for resolving the address
Loughney, et al. [Page 4
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
presented in the incoming SCCP/SUA message to correct SCTP
association for the desired endpoint. The AMF MAY use routing
context / rouging key information as selection criteria for the
appropriate SCTP association.
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-over may apply upon
the return to service of a previously unavailable Application Server
Process.
Network Appearance - The Network Appearance uniquely identifies an
SS7 entity (point code) into a SS7 network, as presented by the SG.
It is used for the purposes of logically separating the signaling
traffic between the SG and the Application Server Processes over a
common SCTP Association. This partitioning is necessary where an SG
is logically partitioned to appear as an end-node element in
multiple separate SS7 networks, in which case there is a separate
network appearance for each point code in the SS7 networks. It is
also necessary when an SG is configured as an STP hosting multiple
point codes, or when configured as multiple end nodes within the
same network, in which case each point code is a separate network
appearance.
Network Byte Order - Most significant byte first, a.k.a. Big Endian.
Layer Management - Layer Management is a nodal function in an SG or
ASP that handles the inputs and outputs between the SUA layer and a
local management entity.
Host - The computing platform that the ASP process is running on.
Stream - A stream refers to an SCTP stream; a uni-directional
logical channel established from one SCTP endpoint to another
associated SCTP endpoint, within which all user messages are
delivered in-sequence except for those submitted to the un-ordered
delivery service.
Transport address - an address which serves as a source or
destination for the unreliable packet transport service used by
SCTP. In IP networks, a transport address is defined by the
combination of an IP address and an SCTP port number. Note, only
one SCTP port may be defined for each endpoint, but each SCTP
endpoint may have multiple IP addresses.
1.3 Signaling Transport Architecture
The framework architecture that has been defined for SCN signaling
transport over IP [2719] uses multiple components, including an IP
transport protocol, a signaling common transport protocol and an
Loughney, et al. [Page 5
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
adaptation module to support the services expected by a particular
SCN signaling protocol from its underlying protocol layer.
In general terms, the SUA architecture can be modeled as a peer-to-
peer architecture. The first section considers the SS7-IP
interworking architectures for connectionless and connection-
oriented transport. For this case, it is assumed that the ASP
initiates the establishment of the SCTP association with SG.
1.3.1 Protocol Architecture for Connectionless Transport
In this architecture, the SCCP and SUA layers interface in the SG.
There needs to be interworking between the SCCP and SUA layers to
provide for the seamless transfer of the user messages as well as
the management messages. For messages destined for an ASP, there
are two scenarios.
******** SS7 *************** IP ********
* SEP *---------* *--------* *
* or * * SG * * ASP *
* STP * * * * *
******** *************** ********
+------+ +------+
| SUAP | | SUAP |
+------+ +------+------+ +------+
| SCCP | | SCCP | SUA | | SUA |
+------+ +------+------+ +------+
| MTP3 | | MTP3 | | | |
+------| +------+ SCTP | | SCTP |
| MTP2 | | MTP2 | | | |
+------+ +------+------+ +------+
| L1 | | L1 | IP | | IP |
+------+ +------+------+ +------+
| | | |
+---------------+ +------------+
SUAP - SCCP/SUA User Protocol (TCAP, for example)
STP - SS7 Signaling Transfer Point
1.3.1.1 SG as endpoint
In this case, the connectionless SCCP messages are routed on PC and
SSN. The subsystem identified by SSN and SS7 network appearance is
regarded as local to the SG. This means from SS7 point of view, the
SCCP-user is located at the SG.
By means of configuration, the SG knows the local SCCP-user is
actually represented by an AS, and serviced by a set of ASPs
Loughney, et al. [Page 6
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
working in n+k redundancy mode. An ASP is selected and a CLDT
message is sent on the appropriate SCTP association/stream.
The selection criterion can be based on a round robin mechanism, or
any other method that guarantees a balanced load-sharing over the
active ASPs. However, when TCAP messages are transported, load-
sharing is only possible for the first message in a TCAP dialogue
(TC_Begin, TC_Query, TC_Unidirectional). All other TCAP messages in
the same dialogue must be sent to the same ASP that was selected for
the first message, unless the ASPs are able to share state and
maintain in sequence delivery. To this end, the SG must know the TID
allocation policy of the ASPs in a single AS :
- state sharing
- fixed range of TIDs per ASP in the AS
This information may be preconfigured in the SG, or may be
dynamically exchanged via the ASP_Active message.
An example for a INAP/TCAP message exchange between SEP and ASP is
given below.
Address information in CLDT message (e.g. TC_Query) from SG to ASP,
with association ID = SG-ASP, stream ID based on SLS and possibly
other parameters, e.g. OPC or network ID :
- Network appearance : based on SS7 network ID, so that the
message can be transported to the correct ASP.
- Source address : valid combination of SSN, PC and GT, as
needed for back-routing to the SEP,
- Destination address : at least SSN, to select the SCCP/SUA-
user at the ASP.
The Network Appearance is needed if the SG operates in more than one
SS7 network domain, since PC and SSN only have meaning within a
specific SS7 network domain.
Address information in CLDT message (e.g. TC_Response) from ASP to
SG, with association ID = ASP-SG, stream ID selected by
implementation dependent means with regards to in-sequence-delivery:
- Network appearance: as received in previous message,
- Source address: unique address provided so that when used as
SCCP called party address in the SEP, MUST yield the same AS
again; the SSN could be sufficient,
- Destination address: copied from source address in received
CLDT message.
Further messages from the SEP belonging to the same TCAP transaction
will now reach the same ASP.
Loughney, et al. [Page 7
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
1.3.1.2 SG as relay-point
A Global Title translation must be executed at the SG, before the
destination of the message can be determined. The actual location
of the SCCP-user is irrelevant to the SS7 network. GT Translation
yields an "SCCP entity set", which now may contain one or more AS's.
Selection of the AS is thus based on the SCCP called party address
(and possibly other SS7 parameters depending on the implementation).
Basically this means splitting the SS7 traffic over different AS's
based on GT information. After this, the same as in 1.3.1.1
applies.
1.3.2 Protocol Architecture for Connection-Oriented Transport
In this architecture, the SCCP and SUA layers interface in the SG to
associate the two connection sections needed for the connection-
oriented data transfer between SEP and ASP. Both connection
sections are setup when routing the Connect Request messages from
SEP via SG to AS or the other way. The routing of the Connect
Request message is done in the same way as described in 1.3.1.
Further messages for this connection are routed on DPC in the SS7
connection section (MTP routing label), and on IP address in the IP
connection section (SCTP header). No other routing information is
present in the SCCP or SUA messages themselves. Resources are kept
within the SG to forward messages from one section to another and to
populate the MTP routing label or SCTP header, based on the
destination local reference of these messages (Connect Confirm, Data
Transfer, ...)
This means that in the SG, two local references are allocated, one 3
byte value used for the SS7 section and one 4 byte value for the IP
section. Also a resource containing the connection data for both
sections is allocated, and either of the two local references can be
used to retrieve this data e.g. for an incoming DT1 or CODT, for
example.
******** SS7 *************** IP ********
* SEP *---------* *--------* *
* or * * SG * * ASP *
* STP * * * * *
******** *************** ********
+------+ +------+
| SUAP | | SUAP |
+------+ +------+------+ +------+
| SCCP | | SCCP | SUA | | SUA |
+------+ +------+------+ +------+
| MTP3 | | MTP3 | | | |
+------| +------+ SCTP | | SCTP |
Loughney, et al. [Page 8
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
| MTP2 | | MTP2 | | | |
+------+ +------+------+ +------+
| L1 | | L1 | IP | | IP |
+------+ +------+------+ +------+
| | | |
+---------------+ +------------+
SUAP - SCCP/SUA Application Protocol (e.g. - RANAP/RNSAP)
STP - SS7 Signaling Transfer Point
The above architecture may simplify, in some cases, to carrying SS7
application protocols between two IP based endpoints. In this
scenario, full SG functionality is not 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 ********
* *--------* *
* IPSP * * IPSP *
* * * *
******** ********
+------+ +------+
| SUAP | | SUAP |
+------+ +------+
| SUA | | SUA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
| |
+----------------+
SUAP - SCCP/SUA 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 Peer-to-Peer Network Architecture
Loughney, et al. [Page 9
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Figure 1 shows an example network architecture which can support
robust operation and failover. There need to be some management
resources at the AS to manage traffic.
***********
* AS1 *
* +-----+ * SCTP Associations
* |ASP1 +-------------------+
* +-----+ * | ***********
* * | * AS3 *
* +-----+ * | * +-----+ *
* |ASP2 +-----------------------------------------+ASP1 | *
* +-----+ * | * +-----+ *
* * | * *
* +-----+ * | * +-----+ *
* |ASP3 | * +--------------------------+ASP2 | *
* +-----+ * | | * +-----+ *
*********** | | ***********
| |
*********** | | ***********
* AS2 * | | * AS4 *
* +-----+ * | | * +-----+ *
* |ASP1 +--------------+ +---------------------+ASP1 | *
* +-----+ * * +-----+ *
* * * *
* +-----+ * * +-----+ *
* |ASP2 +-----------------------------------------+ASP1 | *
* +-----+ * * +-----+ *
* * ***********
* +-----+ *
* |ASP3 | *
* +-----+ *
* *
***********
Figure 1: Generalized Architecture
In this example, the Application Servers are shown residing within
one logical box, with ASPs located inside. In fact, an AS could be
distributed among several hosts. In such a scenario, the host
should share state as protection in the case of a failure.
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 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).
Loughney, et al. [Page 10
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
The Signaling Gateway can be considered as a group of Application
Servers with additional functionality to interface towards an SS7
network.
The SUA protocol should be flexible enough to allow different
configurations and transport technology to allow the network
operators to meet their operation, management and performance
requirements.
An ASP may be connected to multiple SGs (see figure 2). In such a
case, a particular SS7 destination may be reachable via more than
SG, therefore, more than one route. Given that proper SLS selection,
loadsharing, and SG selection based on point code availability must
be performed at the ASP, it will be necessary for the ASP to
maintain the status of each distant signalling point to which it
communicates on the basis of the SG through which it may route.
Signaling Gateway
SCTP Associations
+----------+ **************
| SG1 | * AS3 *
| ******** | * ******** *
| * SGP11+--------------------------------------------+ ASP1 * *
| ******** | / * ******** *
| ******** | | * ******** *
| * SGP12+--------------------------------------------+ ASP2 * *
| ******** | \ / | * ******** *
+----------+ \ | | * . *
\ | | * . *
+----------+ \ | | * . *
| SG2 | \ | | * . *
| ******** | \ | | * ******** *
| * SGP21+---------------------------------+-+ * * ASPN * *
| ******** | \ * ******** *
| ******** | \ **************
| * SGP22+---+--+ \
| ******** | | | \ **************
+----------+ | | \ * AS4 *
| | \ * ******** *
| +-------------------------------------+ ASP1 * *
| * ******** *
| * . *
| * . *
| * *
| * ******** *
+----------------------------------------+ ASPn * *
* ******** *
**************
Figure 2: Signaling Gateway Architecture
Loughney, et al. [Page 11
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
The pair of SGs can either operate as replicated endpoints or as
replicated relay points from the SS7 network point of view.
Replicated endpoints: only for the first message in a transaction or
connection one of the SGs is chosen, depending on the traffic mode
(primary/backup or loadsharing) and overload conditions. Once
selected, the same SG is used for the subsequent messages.
Replicated relay points : in normal circumstances, the path from SEP
to ASP will always go via the same SG when in-sequence-delivery is
requested. However, linkset failures may cause MTP to re-route to
the other SG.
1.3.6 ASP Fail-over Model and Terminology
The SUA protocol supports ASP fail-over functions in order to
support a high availability of transaction processing capability.
An Application Server can be considered as a list of all ASPs
configured/registered to handle SCCP-user messages within a certain
range of routing information, known as a Routing Key. One or more
ASPs in the list may normally be active to handle traffic, while
others may be inactive but available in the event of failure or
unavailability of the active ASP(s).
1.4 Services Provided by the SUA Layer
1.4.1 Support for the transport of SCCP-User Messages
The SUA needs to support the transfer of SCCP-user messages. The SUA
layer at the SG needs to seamlessly transport the user messages.
1.4.2 SCCP Protocol Class Support
Depending upon the SCCP-users supported, the SUA shall support the 4
possible SCCP protocol classes transparently. The SCCP protocol
classes are defined as follows:
* Protocol class 0 provides unordered transfer of SCCP-user
messages in a connectionless manner.
* Protocol class 1 allows the SCCP-user to select the in-
sequence delivery of SCCP-user messages in a connectionless
manner.
* Protocol class 2 allows the bi-directional transfer of SCCP-
user messages by setting up a temporary or permanent
signaling connection.
Loughney, et al. [Page 12
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
* Protocol class 3 allows the features of protocol class 2 with
the inclusion of flow control. Detection of message loss or
mis-sequencing is included.
Protocol classes 0 and 1 make up the SCCP connectionless service.
Protocol classes 2 and 3 make up the SCCP connection-oriented
service.
1.4.3 Native Management Functions
The SUA layer may provide management of the underlying SCTP layer to
ensure that transport is available according to the degree specified
by the SCCP-user application.
The SUA layer provides the capability to indicate errors associated
with the SUA-protocol messages and to provide notification to local
management and the remote peer as is necessary.
1.4.4 Interworking with SCCP Network Management Functions
SUA uses the existing ASP management messages for ASP status
handling. The interworking with SCCP management consists on the
sending of DUNA, DAVA, DAUD or SCON messages on receipt of SSP, SSA,
SST or SSC to the appropriate ASPs. See also chapter 1.4.5. The
primitives below are considered to be sent between the SCCP and SUA
management functions in the SG to trigger events in the IP and SS7
domain.
Generic |Specific |
Name |Name |ANSI/ITU Reference
----------+-----------+---------------------------------------------
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.
Loughney, et al. [Page 13
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
1.4.6 Relay function
For network scalability purposes, the SUA may be enhanced with a
relay functionality to determine the next hop SCTP association
towards the destination SUA endpoint.
The determination of the next hop may be based on Global Title
information (e.g. E.164 number), in analogy with SCCP GTT in SS7
networks, modeled in [ITU-T Q.714]. It may also be based on Hostname
information, IP address, or pointcode contained in the called party
address.
This allows for greater scalability, reliability and flexibility in
wide-scale deployments of SUA. The usage of a relay function is a
deployment decision.
1.5 Internal Functions Provided in the SUA Layer
In order to perform its addressing and relaying capabilities, the
SUA makes use of a Address Mapping Function (AMF). This function is
considered part of SUA, but the way it is realized is left
implementation / deployment dependent (local tables, DNS (ENUM),
LDAP, etc.)
The AMF is invoked when a message is received at the incoming
interface. The AMF is responsible for resolving the address
presented in the incoming SCCP/SUA message to SCTP associations to
destinations within the IP network. The AMF will select the
appropriate SCTP association based upon routing context / routing
key information available. The destination might be the end SUA node
or a SUA relay node. The Routing Keys reference an Application
Server, which will have one or more ASPs processing traffic for the
AS. The availability and status of the ASPs is handled by SUA ASP
management messages.
Possible SS7 address/routing information that comprise a Routing Key
entry includes, for example, OPC, DPC, SIO found in the MTP3 routing
label, SCCP subsystem number, or Transaction ID. IP addresses and
host names can also be used as Routing Key information.
It is expected that the routing keys are provisioned via a MIB or
external process, such as a database.
1.5.1 Address Mapping at the SG
Normally, one or more ASPs are active in the AS (i.e., currently
processing traffic) but in certain failure and transition cases it
is possible that there may not be an active ASP available. The SG
will buffer the message destined for this AS for a time t(r) or
until an ASP becomes available. When no ASP becomes available before
Loughney, et al. [Page 14
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
expiry of t(r), the SG will flush the buffered messages and initiate
the appropriate return or refusal procedures.
If there is no match for an incoming message, a default treatment
MUST be specified. Possible solutions are to provide a default
Application Server to direct all unallocated traffic to a (set of)
default ASP(s), or to drop the messages and provide a notification
to management. The treatment of unallocated traffic is
implementation dependent.
1.5.2 Address Mapping at the ASP
In order to direct messages to the SS7 network, the ASP must also
perform an address mapping in order to choose the proper SG for a
given message. This is accomplished by observing the Destination
Point Code and other elements of the outgoing message, SS7 network
status, SG availability, and network appearance configuration
tables.
A remote Signaling Gateway may be composed of one or more SGPs.
There is, however, no SUA messaging to manage the status of an SGP.
Whenever an SCTP association to an SGP exists, it is assumed to be
available. Also, every SGP of one SG communicating with one ASP
regarding one AS provides identical SS7 connectivity to this ASP.
1.5.3 Address Mapping Function at a Relay Node
The relay function is invoked when:
- routing is on Global Title
- routing is on Hostname
- routing is on SSN+PC or SSN+IP Address and the address
presented is not the one of the relay node
Translation/resolution of the above address information must yield
either of the following:
- Route on SSN: SCTP association ID towards the destination
node, SSN and optionally Network Appearance and/or IP
address.
- Route on GT: SCTP association ID towards next relay node,
(new) GT and optionally SSN and/or Network Appearance.
- Routing on Hostname: SCTP association ID towards next relay
node, (new) Hostname and optionally SSN and/or Network
Appearance.
- A local SUA-user (combined relay/end node)
To prevent looping, a hop counter is used. The originating end node
(be it an SS7 or an IP node) sets the value of the hop counter to
the maximum value (15 or less). Each time the relay function is
invoked within an intermediate (relay) node, the hop counter must be
Loughney, et al. [Page 15
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
decremented. When the value reaches zero, the return or refusal
procedures are invoked with reason "Hop counter violation".
1.5.4 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 is used to preserve the order of management
message delivery.
Stream selection based on protocol class :
- protocol class 0: SUA SHOULD select an unordered stream;
- protocol class 1: SUA MUST select an ordered stream, based on
a sequence parameter given by the upper layer over the
primitive interface;
- protocol classes 2 and 3: SUA will select an ordered stream,
based on its own source local reference.
1.6 Definition of SUA Boundaries
1.6.1 Definition of the upper boundary
The following primitives are supported between the SUA and an SCCP-
user (a reference to ITU and ANSI sections where these primitives
and corresponding parameters are described, is also given):
Generic |Specific |
Name |Name |ANSI/ITU Reference
------------+----------+-------------------------------------------
N-Connect |Request |ITU-Q.711 Chap 6.1.1.2.2 (Tab 2/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.2 (Tab 2/T1.112.1)
|Response |
|Confirm |
------------+----------+-------------------------------------------
N-Data |Request |ITU-Q.711 Chap 6.1.1.2.3 (Tab 3/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 3/T1.112.1)
------------+----------+-------------------------------------------
N-Expedited |Request |ITU-Q.711 Chap 6.1.1.2.3 (Tab 4/Q.711)
Data |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 4/T1.112.1)
------------+----------+-------------------------------------------
N-Reset |Request |ITU-Q.711 Chap 6.1.1.2.3 (Tab 5/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 5/T1.112.1)
|Response |
|Confirm |
------------+----------+-------------------------------------------
N-Disconnect|Request |ITU-Q.711 Chap 6.1.1.2.4 (Tab 6/Q.711)
Loughney, et al. [Page 16
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
|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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Me sa s ge Data
|
Note that the 'data' portion of SUA messages SHALL contain SCCP-User
data, not the encapsulated SCCP message.
Loughney, et al. [Page 17
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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 SUA Management (MGMT) Message
1 Reserved
2 Signaling Network Management (SNM) Messages
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
5 Reserved
6 Reserved
7 Connectionless Messages
8 Connection-Oriented Messages
9 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
3.1.3 Message Types
SUA Management Messages
0 Error (ERR)
1 Notify (NTFY)
2 - 127 Reserved by the IETF
128- 255 Reserved for IETF-Defined Message Class Extensions
Signaling Network Management (SNM) Messages
0 Reserved
1 Destination Unavailable (DUNA)
2 Destination Available (DAVA)
3 Destination State Audit (DAUD)
4 SS7 Network Congestion (SCON)
5 Reserved
6 Reserved
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Application Server Process State Maintenance (ASPSM) Messages
0 Reserved
1 ASP Up (UP)
2 ASP Down (DOWN)
Loughney, et al. [Page 18
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK)
5 ASP Down Ack (DOWN ACK)
6 Heartbeat Ack (BEAT ACK)
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
ASP Traffic Maintenance (ASPTM) Messages
0 Reserved
1 ASP Active (ACTIVE)
2 ASP Inactive (INACTIVE)
3 ASP Active Ack (ACTIVE ACK)
4 ASP Inactive Ack (INACTIVE ACK)
5 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Connectionless Messages
0 Reserved
1 Connectionless Data Transfer (CLDT)
2 Connectionless Data Response (CLDR)
3 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Connection-Oriented Messages
0 Reserved
1 Connection Request (CORE)
2 Connection Acknowledge (COAK)
3 Connection Refused (COREF)
4 Release Request (RELRE)
5 Release Complete (RELCO)
6 Reset Confirm (RESCO)
7 Reset Request (RESRE)
8 Connection Oriented Data Transfer (CODT)
9 Connection Oriented Data Acknowledge (CODA)
10 Connection Oriented Error (COERR)
11 Inactivity Test (COIT)
12 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
3.1.4 Message Length
The Message Length defines the length of the message in octets,
including the header and including all padding bytes.
3.1.5 Tag-Length-Value Format
SUA messages consist of a Common Header followed by zero or more
parameters, as defined by the message type. The Tag-Length-Value
Loughney, et al. [Page 19
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
(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. However, composite parameters will contain all
padding bytes, since all parameters contained within this
composite parameter will be considered multiples of 4 bytes.
Parameter Value: variable-length.
The Parameter Value field contains the actual information to be
transferred in the parameter.
The total length of a parameter (including Tag, Parameter Length
and Value fields) MUST be a multiple of 4 bytes. If the length of
the parameter is not a multiple of 4 bytes, the sender pads the
Parameter at the end (i.e., after the Parameter Value field) with
all zero bytes. The length of the padding is NOT included in the
parameter length field. A sender should NEVER pad with more than
3 bytes. The receiver MUST ignore the padding bytes.
Implementation note: the use of TLV in principle allows the
parameters to be placed in a random order in the message. However,
some guidelines should be considered for easy processing in the
following order:
- parameters needed to correctly process other message
parameters, preferably should precede these parameters (such
as Network Appearance),
- mandatory parameters preferably SHOULD precede any optional
parameters,
Loughney, et al. [Page 20
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
- the data parameter will normally be the final one in the
message.
- the receiver SHOULD accept parameters in any order, except
where explicitly mandated.
3.2 SUA Connectionless Messages
The following section describes the SUA Connectionless transfer
messages and parameter contents. The general message format
includes a Common Message Header together with a list of zero or
more parameters as defined by the Message Type. All Message Types
can have attached parameters.
3.2.1 Connectionless Data Transfer (CLDT)
This message transfers data between one SUA to another.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Flags Mandatory
Source Address Mandatory
Destination Address Mandatory
Data Mandatory
Loughney, et al. [Page 21
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Implementation note: This message covers the following SCCP
messages: unitdata (UDT), extended unitdata (XUDT), long unitdata
(LUDT).
3.2.2 Connectionless Data Response (CLDR)
This message is used as a response message by the peer to report
errors in the received CLDT message, when the return on error option
is set.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Flags Mandatory
SCCP Cause Mandatory
Source Address Mandatory
Destination Address Mandatory
Data Optional
Loughney, et al. [Page 22
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Implementation note: This message covers the following SCCP
messages: unitdata service (UDTS), extended unitdata service (XUDTS)
and long unitdata service (LUDTS).
3.3 Connection Oriented Messages
3.3.1 Connection Oriented Data Transfer (CODT)
This message transfers data between one SUA to another for
connection oriented service.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Sequence number Mandatory *1
Destination Reference Number Mandatory
Data Mandatory
NOTE *1: This parameter is not present in case of Expedited Data
(ED).
Implementation note: This message covers the following SCCP
messages: DaTa form 1 (DT1), DaTa form 2 (DT2), Expedited Data (ED).
3.3.2 Connection Oriented Data Acknowledge (CODA)
This message is used to acknowledge receipt of data by the peer.
This message is used only with protocol class 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 23
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
| Tag = 0x0108 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | 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 Connection Request (CORE)
This message is used for establishing a signaling connection between
two peer endpoints.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
Loughney, et al. [Page 24
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Flags Mandatory
Source Reference Number Mandatory
Destination Address Mandatory
Source Address Optional
Credit Mandatory, protocol class 3 only
Data Optional
Implementation note: This message covers the following SCCP message:
Connection Request (CR).
3.3.4 Connection Acknowledge (COAK)
This message is used to acknowledge a connection request from 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 = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
Loughney, et al. [Page 25
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Flags Mandatory
Destination Reference Number Mandatory
Source Reference Number Mandatory
Credit Mandatory, protocol class 3 only
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.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
SCCP Cause Mandatory
Destination Address Optional *1
Data Optional
Loughney, et al. [Page 26
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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 REFused (CREF).
3.3.6 Release Request (RELRE)
This message is used to request a signaling connection between two
peer endpoints be released. All associated resources can then be
released.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Source Reference Number Mandatory
SCCP Cause Mandatory
Flags Optional
Data Optional
Implementation note: This message covers the following SCCP message:
connection ReLeaSeD (RLSD).
3.3.7 Release Complete (RELCO)
Loughney, et al. [Page 27
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
This message is used to acknowledge the release of a signaling
connection between two peer endpoints. All associated resources
should be released.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Source Reference Number Mandatory
Implementation note: This message covers the following SCCP message:
ReLease Complete (RLC).
3.3.8 Reset Request (RESRE)
This message is used to indicate that the sending SCCP/SUA wants to
initiate a reset procedure (re-initialization of sequence numbers)
to the peer endpoint.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Source Reference Number Mandatory
SCCP Cause Mandatory
Loughney, et al. [Page 28
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Implementation note: This message covers the following SCCP message:
ReSet Request (RSR).
3.3.9 Reset Confirm (RESCO)
This message is used to confirm the Reset Request.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Source Reference Number Mandatory
Implementation note: This message covers the following SCCP message:
ReSet Confirmation (RSC).
3.3.10 Connection Oriented Error (COERR)
The COERR message is sent to indicate a protocol data unit error.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
SCCP Cause Mandatory
Implementation note: This message covers the following SCCP message:
Protocol Data Unit ERRor (ERR).
3.3.11 Connection Oriented Inactivity Test (COIT)
Loughney, et al. [Page 29
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
This message is used for auditing the signaling connection state and
the consistency of connection data at both ends of the signaling
connection.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Flags Mandatory
Source Reference Number Mandatory
Destination Reference number Mandatory
Sequence number Mandatory *1
Credit Mandatory *1
NOTE *1: Information in these parameter fields reflect those
values sent in the last data form 2 or data
acknowledgement message. They are ignored if the
protocol class indicates class 2.
Implementation note: This message covers the following SCCP message:
Inactivity Test (IT).
3.4 Signaling Network Management Messages
3.4.1 Destination Unavailable (DUNA)
In the scope of SUA, this message is covered by the PC- or N-state
indication passed between SCCP and local SCCP-user. The DUNA message
is sent from the SG or relay node to all concerned ASPs (servicing
SCCP-users considered local to the SG or relay node, see chapter
Loughney, et al. [Page 30
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
1.3.1.1), when a destination or SCCP-user has become unreachable.
The SUA-User at the ASP is expected to stop traffic to the affected
destination or SCCP-user through the SG or relay node initiating the
DUNA.
The format for DUNA Message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Destination Address Mandatory *1
Info String Optional
Note 1: The destination address refers to the node that has
become unavailable. It SHOULD include only:
- point code + SSN (optional): case for interworking with a SS7
network, with already defined actions for the SG.
- IP address + SSN (optional): case for an all-IP environment.
3.4.2 Destination Available (DAVA)
In the scope of SUA, this message is covered by the PC- and N-state
indication passed between SCCP and local SCCP-user. The DAVA message
is sent from the SG or relay node to all concerned ASPs (servicing
SCCP-users considered local to the SG or relay node, see chapter
1.3.1.1) to indicate that a destination (PC or SCCP-user) is now
reachable. The ASP SUA-User protocol is expected to resume traffic
to the affected destination through the SG or relay node 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 31
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Destination Address Mandatory *1
Info String Optional
Note 1: The destination address refers to the node that has
become available. It SHOULD include only:
- point code + SSN (optional): case for interworking with a SS7
network, with already defined actions for the SG.
- IP address + SSN (optional): case for an all-IP environment.
3.4.3 Destination State Audit (DAUD)
The DAUD message can be sent from the ASP to the SG (or relay node)
to query the availability state of the 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 (or relay node).
0 1 2 3
0 1 2 3 4 5 6 7 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 = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
Loughney, et al. [Page 32
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Destination Address Mandatory *1
Info String Optional
Note 1: The destination address refers to the node that is being
audited. It SHOULD include only:
- point code + SSN (optional): case for interworking with a SS7
network, with already defined actions for the SG.
- IP address + SSN (optional): case for an all-IP environment.
3.4.4 SS7 Network Congestion (SCON)
The SCON message can be sent from the SG to all concerned ASPs to
indicate that the congestion level in the SS7 network to a specified
destination has changed.
0 1 2 3
0 1 2 3 4 5 6 7 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 = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000E | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Congestion Level Mandatory
Destination Address Mandatory *1
Info String Optional
Note 1: The destination address refers to the node that is
experiencing congestion. It SHOULD include only:
Loughney, et al. [Page 33
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
- point code + SSN (optional): case for interworking with a SS7
network, with already defined actions for the SG.
- IP address + SSN (optional): case for an all-IP environment.
3.5 Application Server Process State Maintenance Messages
3.5.1 ASP Up (UP)
The ASP UP (UP) message is used to indicate to a remote SUA peer
that the Adaptation layer is up and running.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0109 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
ASP Capabilities Optional
Info String Optional
3.5.2 ASP Up Ack (UP ACK)
The ASP UP Ack message is used to acknowledge an ASP-Up message
received from a remote SUA peer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0109 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
ASP Capabilities Optional
Info String Optional
Loughney, et al. [Page 34
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
3.5.3 ASP Down (DOWN)
The ASP Down (DOWN) message is used to indicate to a remote SUA peer
that the adaptation layer is not running.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Reason Mandatory
Info String Optional
Note: The reason is only relevant for layer management and/or
logging.
3.5.4 ASP Down Ack (DOWN ACK)
The ASP DOWN Ack message is used to acknowledge an ASP-Down message
received from a remote SUA peer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Reason Mandatory
Info String Optional
Note: ASP DOWN ACK will always be sent to acknowledge an ASP DOWN.
The Reason received in the ASP DOWN is only relevant for layer
management and/or logging.
Loughney, et al. [Page 35
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
3.5.5 Heartbeat (BEAT)
The Heartbeat message is optionally used to ensure that the SUA
peers are still available to each other.
The format for the BEAT message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0008 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Heartbeat Data Optional
3.5.6 Heartbeat Ack (BEAT ACK)
The Heartbeat ACK message is sent in response to a BEAT message. A
peer MUST send a BEAT ACK in response to a BEAT message. It includes
all the parameters of the received Heartbeat message, without any
change.
The format for the BEAT ACK message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0008 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Heartbeat Data Optional
3.6 ASP Traffic Maintenance Messages
3.6.1 ASP Active (ACTIVE)
The ASPAC message is sent by an ASP to indicate to a remote SUA peer
that it is Active and ready to process signaling traffic for a
particular Application Server.
The format for the ACTIVE message is as follows:
0 1 2 3
Loughney, et al. [Page 36
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000B | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Traffic Mode Type Mandatory
Routing Context Optional
Info String Optional
3.6.2 ASP Active Ack (ACTIVE ACK)
The ASPAC Ack message is used to acknowledge an ASP-Active message
received from a remote SUA peer.
The format for the ACTIVE Ack message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000B | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Traffic Mode Type Mandatory
Routing Context Optional
Info String Optional
Loughney, et al. [Page 37
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
The value of the Traffic Mode Type and Routing Context parameters is
the same as for the ASP-Active message.
The value of the optional Info String parameter is the same as for
the ASP-Active message.
3.6.3 ASP Inactive (INACTIVE)
The INACTIVE message is sent by an ASP to indicate to a remote SUA
peer that it is no longer processing signaling traffic within a
particular Application Server.
The format for the ASPIA message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
INFO String Optional
3.6.4 ASP Inactive Ack (INACTIVE ACK)
The INACTIVE Ack message is used to acknowledge an ASP-Inactive
message received from a remote SUA peer.
The format for the INACTIVE Ack message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ INFO String /
Loughney, et al. [Page 38
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
INFO String Optional
The value of the optional Info String parameter is the same as for
the ASP-Active message.
3.7 SUA Management Messages
These messages are used for managing SUA and the representations of
the SCCP subsystems in the SUA layer.
3.7.1 Error (ERR)
The ERR message is sent between two SUA peers to indicate an error
situation. The Data parameter is optional, possibly used for error
logging and/or debugging.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000C | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Diagnostic Info /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Error Code Mandatory
Diagnostic Info Optional
3.7.2 Notify (NTFY)
The Notify message used to provide an autonomous indication of SUA
events to an SUA peer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type/ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
Loughney, et al. [Page 39
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NTFY message contains the following parameters:
Parameters
Status Type/ID Mandatory
Routing Context Optional
Info String Optional
3.8 Common Parameters
These TLV parameters are common across the different adaptation
layers.
Parameter Name Parameter ID
============== ============
Network Appearance 0x0001
Not used in SUA 0x0002
Data 0x0003
Info String 0x0004
Affected Point Code 0x0005
Routing Context 0x0006
Diagnostic Info 0x0007
Heartbeat Data 0x0008
Not used in SUA 0x0009
Reason 0x000A
Traffic Mode Type 0x000B
Error Code 0x000C
Status Type/ID 0x000D
Congestion Level 0x000E
3.8.1 Network Appearance
The Network Appearance parameter identifies the SS7 network context
for the message, for the purposes of logically separating the
signaling traffic between the SG and the Application Server Process
over a common SCTP Association. An example is where an SG is
logically partitioned to appear as an element in several different
national SS7 networks.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 40
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
| Tag = 0x0001 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Network Appearance implicitly defines the SS7 Point Code format
used, the SS7 Network Indicator value and SCCP protocol
type/variant/version used within the SS7 network partition. It also
defines the network context for the PC and SSN values. Where an SG
operates in the context of a single SS7 network, or individual SCTP
associations are dedicated to each SS7 network context, the Network
Appearance parameter is not required.
The Network Appearance parameter value is of local significance
only, coordinated between the SG and ASP.
Where the optional Network Appearance parameter is present, it must
be the first parameter in the message as it defines the format
and/or interpretation of the parameters containing a PC or SSN
value.
3.8.2 Not used
Use of Parameter ID 0x0002 (Routing Key) in SUA messages is not
supported.
3.8.3 Data
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Data parameter field contains the SS7 SCCP-User application
message, for example an INAP/TCAP message.
3.8.4 Info String
The INFO String parameter can carry any meaningful 8-BIT ASCII
character string along with the message. Length of the INFO String
parameter is from 0 to 255 characters. No procedures are presently
identified for its use but the INFO String may be used by Operators
for debugging purposes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 41
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
| 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
14-, 16- and 24-bit binary formatted SS7 Point Codes. Affected
Point codes that are less than 24-bits, are padded on the left to
the 24-bit boundary.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ . . . /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding is shown below for ANSI and ITU Point Code examples.
ANSI 24-bit Point Code:
0 1 2 3-->
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Network | Cluster | Member |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB-----------------------------------------LSB|
ITU 14-bit Point Code:
0 1 2 3-->
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB--------------------LSB|
It is optional to send an Affected Point 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.
Loughney, et al. [Page 42
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Including multiple Affected PCs may be useful when reception of a
management message or a linkset event simultaneously affects the
availability status of a list of destinations at an SG.
Mask: 8-bits
The Mask parameter can be used to identify a contiguous range of
Affected Destination Point Codes, independent of the point code
format. Identifying a contiguous range of Affected PCs may be
useful when reception of an MTP3 management message or a linkset
event simultaneously affects the availability status of a series of
destinations at an SG.
The Mask parameter is an integer representing a bit mask that can be
applied to the related Affected PC field. The bit mask identifies
how many bits of the Affected PC field are significant and which are
effectively "wild-carded". For example, a mask of "8" indicates
that the last eight bits of the PC is "wild-carded". For an ANSI
24-bit Affected PC, this is equivalent to signaling that all PCs in
an ANSI Cluster are unavailable. A mask of "3" indicates that the
last three bits of the PC is "wild-carded". For a 14-bit ITU
Affected PC, this is equivalent to signaling that an ITU Region is
unavailable.
For use in SUA, the mask parameter MUST always be coded zero and
there MUST be only a single point code present.
3.8.6 Routing Context
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Routing Context parameter contains (a list of) 4-byte unsigned
integers indexing the Application Server traffic that the sending
ASP is configured/registered to receive. There is a one-to-one
relationship between an index entry and a Routing Key or AS Name.
Since an AS can only appear in one Network Appearance, the Network
Appearance parameter is not required in the ASP Active message.
An Application Server Process may be configured to process traffic
for more than one logical Application Server. From the perspective
of an ASP, a Routing Context defines a range of signaling traffic
that the ASP is currently configured to receive from the SG.
Loughney, et al. [Page 43
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
3.8.7 Diagnostic Information
The Diagnostic Information can be used to convey any information
relevant to an error condition, to assist in the identification of
the error condition. In the case of an Invalid Network Appearance,
Adaptation Layer Identifier or Traffic Handling Mode, the Diagnostic
information includes the received parameter. In the other cases,
the Diagnostic information may be the first 40 bytes of the
offending message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Diagnostic Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8.8 Heartbeat Data
The Heartbeat Data field contents are defined by the sending node.
It may include a Heartbeat Sequence Number and/or Timestamp, or
other implementation specific details.
The receiver of a Heartbeat message does not process this field as
it is only of significance to the sender. The receiver echoes the
content of the Heartbeat Data in a BEAT-Ack message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0008 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The data field can be used to store information in the heartbeat
message useful to the sending node (e.g. the data field can contain
a time stamp, a sequence number, etc.).
3.8.9 Cause/User
Parameter ID 0x0009 (Cause/User) is not used in SUA.
3.8.10 Reason
The Reason parameter indicates the reason why the remote SUA
adaptation layer is unavailable.
Loughney, et al. [Page 44
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000A | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reason: 32-bit (unsigned integer)
The valid values for Reason are shown in the following table.
0 Unspecified
1 User Unavailable
2 Management Blocking
3 ASP Fault
3.8.11 Traffic Mode Type
The Traffic Mode Type parameter identifies the traffic mode of
operation of the ASP within an AS.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000B | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Type are shown in the following table.
1 Over-ride
2 Load-share
3 Over-ride (Standby)
4 Loadshare (Standby)
Within a Routing Context, Over-ride and Loadshare Types cannot be
mixed. The Over-ride value indicates that the ASP is operating in
Over-ride mode, and the ASP wishes to take over all traffic for an
Application Server (i.e., primary/back-up operation), over-riding
any currently active ASP in the AS. In Load-share mode, the ASP
wishes to share in the traffic distribution with any other currently
active ASPs. The Standby versions of the Over-ride and Loadshare
Types indicate that the ASP is declaring itself ready to accept
traffic but leaves it up to the sender as to when the traffic is
started. Over-ride (Standby) indicates that the traffic sender
continues to use the currently active ASP until it can no longer
send/receive traffic (i.e., the currently active ASP transitions to
Down or Inactive). At this point the sender may immediately move
the ASP to Active and commence traffic. Loadshare (Standby) is
Loughney, et al. [Page 45
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
similar - the sender continues to loadshare to the current ASPs
until it is determined that there is insufficient resources in the
Loadshare group. When there are insufficient ASPs, the sender may
immediately move the ASP to Active.
3.8.12 Error Code
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x000C | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Code parameter indicates the reason for the Error Message.
The Error parameter value can be one of the following values:
Invalid Version 0x01
Invalid Network Appearance 0x02
Unexpected Message Class 0x03
Invalid Message Type 0x04
Unsupported Traffic Handling Mode 0x05
Unexpected Message 0x06
Protocol Error 0x07
Invalid Routing Context 0x08
Invalid Stream Identifier 0x09
Parameter Field Error 0x0B
Unexpected Parameter 0x0C
Duplicated Parameter 0x0D
The "Invalid Version" error would be sent if a message was received
with an invalid or unsupported version. The Error message would
contain the supported version in the Common header. The Error
message could optionally provide the supported version in the
Diagnostic Information area.
The "Invalid Network Appearance" error would be sent by a SG if an
ASP sends a message with an invalid (unconfigured) Network
Appearance value.
The "Unexpected Message Class" error would be sent if a message with
an unsupported Message Class is received.
The "Unexpected Message Type" error would be sent if a message with
an unsupported Message Type is received.
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.
Loughney, et al. [Page 46
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
The "Unexpected Message" error would be sent by an ASP if it
received a message which is unexpected in the ASP's current state.
The "Protocol Error" error would be sent for any protocol anomaly
(i.e. a bogus message).
The "Invalid Routing Context" error would be sent by a SG if the
routing context cannot be supported, e.g. not unique.
The "Invalid Stream Identifier" error would be sent if a message
was received on an unexpected SCTP stream.
The "Parameter Field Error" would be sent if a message with a
parameter having a wrong length field.
The "Unexpected Parameter" error would be sent if a message contains
an invalid parameter.
The "Duplicated Parameter" error would be sent if a message contains
a parameter more than once.
3.8.13 Status Type/ID
The Status Type/ID parameter identifies the type of the status that
is being notified and the status ID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000D | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Status Type (16 bit unsigned integer) are:
1 Application Server state change (AS_State_Change)
2 Other
The Status ID parameter contains more detailed information for the
notification, based on the value of the Status Type.
If the Status Type is AS_STATE_CHANGE, then the Status ID (16 bit
unsigned integer) values are:
1 reserved
2 Application Server Inactive (AS-Inactive)
3 Application Server Active (AS-Active)
4 Application Server Pending (AS-Pending)
Loughney, et al. [Page 47
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
These notifications are sent from an SG to an ASP upon a change in
status of a particular Application Server. The value reflects the
new state of the Application Server.
If the Status Type is Other, then the following Status Information
values are defined:
1 Insufficient ASP resources active in AS
2 Alternate ASP Active
These notifications are not based on the SG reporting the state
change of an ASP or AS. In the Insufficient ASP Resources case, the
SG is indicating to an "Inactive" ASP(s) in the AS that another ASP
is required in order to handle the load of the AS (Load-sharing
mode). For the Alternate ASP Active case, an ASP is informed when
an alternate ASP transitions to the ASP-Active state in Over-ride
mode.
3.8.14 Congestion Level
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000E | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Congestion Level field: 8-bits (unsigned integer)
The valid values for the Congestion Level parameter range from 0 to
7, where 0 indicates least congested and 7 indicates most congested
subsystem.
3.9 SUA-Specific parameters
These TLV parameters are specific to the SUA protocol.
Parameter Name Parameter ID
============== ============
Flags 0x0101
Source Address 0x0102
Destination Address 0x0103
Source Reference Number 0x0104
Destination Reference Number 0x0105
SCCP Cause 0x0106
Sequence Number 0x0107
Receive Sequence Number 0x0108
ASP Capabilities 0x0109
Credit 0x010A
Loughney, et al. [Page 48
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Reserved 0x010B
SMI / Subsystem 0x010C
Destination/Source Address Sub Parameters
========================================
Global Title 0x8001
Point Code 0x8002
Subsystem Number 0x8003
IPv4 Address 0x8004
Hostname 0x8005
IPv6 Addresses 0x8006
3.9.1 Flags
The Flags parameter is a conglomerate of following parameters,
described in ITU-T Recommendation Q.713 :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Importance | Hop Counter | Protocol Cl. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol class (3.6/Q.713)
Bits 1-2 indicate the protocol class
Value Description
0x0 Class 0 (connectionless service)
0x1 Class 1 (connectionless service)
0x2 Class 2 (connection-oriented service)
0x3 Class 3 (connection-oriented service)
Bit 8 indicates the use of the return on error procedure
Value Description
0x0 No special options
0x1 Return message on error
Bits 3-7 are spare and should be coded zero.
Hop Counter (3.18/Q.713)
The value of the hop counter is decremented with each global title
translation, and should be in the range 15 to 1.
Importance (3.19/Q.713)
Loughney, et al. [Page 49
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Bits 1-3 are coded to indicate the importance of the messages. The
values are between 0 and 7, where the value of 0 indicates the least
important and 7 indicates the most important.
Bits 4-8 are spare bits and should be coded zero.
3.9.2 Source Address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Indicator | Address Indicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Address parameter(s) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Source Address field may contain the SCCP Calling Party Address.
See chapters 3.4 and 3.5 of ITU-T Recommendation Q.713.
The following combinations of address parameters are valid :
- Global Title (e.g. E.164 number) + optional PC and/or SSN,
SSN may be zero, when routing is done on Global Title
- SSN (non-zero) + optional PC and/or Global Title, when
routing is done on PC + SSN. The PC is mandatory in the
source address when sending from SG to ASP, and in the
destination address when sending from ASP to SG in order to
reach the SS7 SEP.
- Hostname + optional SSN, when routing is done by Hostname
- SSN (non-zero) and optional IP address (IPv4 or IPv6) when
routing is done on IP address + SSN
3.9.2.1 Routing Indicator
The following values are valid for the routing indicator :
Reserved 0
Route on Global Title 1
Route on SSN + PC 2
Route on Hostname 3
Route on SSN + IP Address 4
The routing indicator determines which address parameters need to be
present in the address parameters field.
3.9.2.2 Address Indicator
Loughney, et al. [Page 50
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
This parameter is needed for interworking with SS7 networks. The
address indicator specifies what address parameters are actually
received in the SCCP address from the SS7 network, or are to be
populated in the SCCP address when the message is sent into the SS7
network. The value of the routing indicator needs to be taken into
account.
The address indicator is coded as follows:
Bit 1 is used to indicate inclusion of the SSN
0 do not include SSN when optional
1 include SSN
Bit 2 is used to indicate inclusion of the PC
0 do not include PC, regardless of the routing indicator
value
1 include PC
Bit 3 is used to indicate inclusion of the Global Title
0 do not include GT when optional (routing indicator /= 1)
1 include GT
Bits 4-8 are spare and should be coded zero.
In the next chapters, the layout of the address parameters is given.
The following tags are used to identify the address parameters:
0x8000 Reserved
0x8001 Global Title
0x8002 Point Code
0x8003 Subsystem Number
0x8004 IPv4
0x8005 Hostname
0x8006 IPv6
3.9.2.3 Global Title
Loughney, et al. [Page 51
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
0 1 2 3
0 1 2 3 4 5 6 7 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 = 0x8001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. Digits | Trans. type | Num. Plan | Nature of Add |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Title Digits |
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Digits:
This is the number of digits contained in the Global Title.
Translation type:
0 Unknown
1 - 63 international services
64 - 127 spare
128 - 254 national network specific
255 reserved
Numbering Plan:
0 unknown
1 ISDN/telephony numbering plan (Recommendations E.163 and
E.164)
2 generic numbering plan
3 data numbering plan (Recommendation X.121)
4 telex numbering plan (Recommendation F.69)
5 maritime mobile numbering plan (Recommendations E.210,
E.211)
6 land mobile numbering plan (Recommendation E.212)
7 ISDN/mobile numbering plan (Recommendation E.214)
8 - 13 spare
14 private network or network-specific numbering plan
15 - 126 spare
127 reserved.
Nature of Address:
0 unknown
1 subscriber number
2 reserved for national use
3 national significant number
4 international number
5 - 255 Spare
Global Title:
Loughney, et al. [Page 52
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Octets contain a number of address signals and possibly a filler as
shown:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|2 addr.|1 addr.|4 addr.|3 addr.|6 addr.|5 addr.|8 addr.|7 addr.|
| sig. | sig. | sig. | sig. | sig. | sig. | sig. | sig. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............. |filler |N addr.| filler |
| |if req | sig. | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All filler bits MUST be set to 0.
Address signals to be coded as defined in ITU-T Q.713 Section
3.4.2.3.1.
The actual Global Title format to be used for interworking with the
SS7 network is defined by the network appearance, or is implicitly
understood if the SG only operates in one SS7 network partition.
The formats are defined in chapter 3.4.2.3 of Q.713. The following
conversions of the Translation Type, Numbering Plan and Nature of
Address elements apply :
1) SS7 network uses GTI = 0001
Nature of Address is taken over. It is implicitly assumed that
Translation Type = Unknown and Numbering Plan = E.164 (value 1). The
number of digits is determined by the SCCP address length and
Odd/Even indicator.
2) SS7 network uses GTI = 0010
This is most commonly used in North American networks. The
Translation Type implicitly determines Nature of Address and
Numbering Plan. This data can be configured in the SG. The number of
digits is always even and determined by the SCCP address length. The
routing tables must be able to handle a possible trailing digit.
3) SS7 network uses GTI = 0011
Numbering Plan and Translation Type are taken over. It is implicitly
assumed that the Nature of Address = Unknown. The number of digits
is determined by the SCCP address length and the Odd/Even indicator.
4) SS7 network uses GTI = 0100
Loughney, et al. [Page 53
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
This format is used in international networks and most commonly in
networks outside North America. All information to populate the
source address is present in the SCCP Address.
3.9.2.4 Point Code
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8002 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See chapter 3.2.5 Affected Point Code for the layout of the Point
Code field.
3.9.2.5 Subsystem Number
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8003 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | SSN value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The internationally standardized SSN values are described in chapter
3.4.2.2 of Q.713.
3.9.2.6 IP Addresses
The IP address formats can use different tags. It should be noted
that if the source address is in a certain IP version, the
destination address should also be in the same IP version.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8004/0x8006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 or IPv6 Address |
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The tag value 0x8004 is for an IPv4 address and 0x8006 is for
IPv6.
Loughney, et al. [Page 54
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
3.9.2.7 Hostname
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Name |
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the type of address is Host Name, then the labels in the host
name have to be reversed to obtain an efficient Host Name encoding
form for the Global title translation function.
hostname: zzzz.yyy....edc.ab
should be transformed to
HTname : ab.edc....yyy.zzzz
The labels of the Host Name are then encoded using the encoding
rules of the labels described in [IDNS]. The end of the Host name is
indicated by 0x00.
Example :
hostname = www.reindael.security.org
First the name has to be reverse to have the gTLD on the left side.
Global Title name: org.security.reindael.www
Then the result of applying the rules of the iDNS is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
x | 3 | O | R | G |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+4 | 7 | S | E | C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+8 | U | R | I | T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+12| Y | 8 | R | E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+16| I | N | D | A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+20| E | L | 3 | W |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+24| W | W | 00 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 55
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
3.9.3 Destination Address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Indicator | Address Indicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ address parameter(s) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of this parameter is identical to the Source Address
parameter.
3.9.4 Source Reference Number
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The source reference number is a 4 octet long integer. This is
allocated by the source SUA instance.
3.9.5 Destination Reference Number
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The destination reference number is a 4 octet long integer. This is
allocated by the destination SUA instance.
3.9.6 SCCP Cause
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Cause Type | Cause Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 56
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
This parameter bundles the SCCP parameters Release cause, Return
cause, Reset cause, Error cause and Refusal cause.
Cause Type can have the following values:
Return Cause 0x1
Refusal Cause 0x2
Release Cause 0x3
Reset Cause 0x4
Error Cause 0x5
Cause Value contains the specific cause value. Below gives examples
for ITU SCCP values. ANSI references can be found in ANSI T1.112.3
Cause value in Correspondence with Reference
SUA message SCCP parameter
------------------ ----------------- ---------
CLDR Return Cause ITU-T Q.713 Chap 3.12
COREF Refusal Cause ITU-T Q.713 Chap 3.15
RELRE Release Cause ITU-T Q.713 Chap 3.11
RESRE Reset Cause ITU-T Q.713 Chap 3.13
ERR Error Cause ITU-T Q.713 Chap 3.14
3.9.7 Sequence Number
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Rec Seq Num|M| Sent Seq Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This parameter is used to indicate whether _more_ data will follow
in subsequent CODT messages, and/or to number each CODT 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, chapters 3.7 and 3.9.
As such it can also be used to acknowledge the receipt of data
transfers from the peer in case of protocol class 3.
Sent Sequence Number is one octet and is coded as follows:
Bits 2-8 are used to indicate the Send Sequence Number P(S).
Bit 1 (LSB) of octet 1 is spare.
Received Sequence Number is one octet, and is coded as follows:
Bits 2-8 are used to indicate the Received Sequence Number
P(R).
Loughney, et al. [Page 57
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Bit 1 (LSB) is used for the more data indication, as follows:
0 no more data
1 more data
3.9.8 Receive Sequence Number
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0108 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Rec Seq Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This parameter is used exclusively for protocol class 3 in the data
acknowledgment message to indicate the lower edge of the receiving
window. See Q.713, chapter 3.8.
It is a 1 octet long integer coded as follows:
Bits 8-2 are used to indicate the Receive Sequence Number P(R).
Bit 1 is spare.
3.9.9 ASP Capabilities
This parameter is used so that the ASP can report it's capabilities
regarding SUA for supporting different protocol classes and
interworking scenarios.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0109 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare |0 0 0 0|a|b|c|d| Interworking |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags
a - Protocol Class 3
b - Protocol Class 2
c - Protocol Class 1
d - Protocol Class 0
It is mandatory to support at least Protocol Class 0.
Interworking
Loughney, et al. [Page 58
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Values
0x0 indicates no interworking with SS7 Networks.
0x1 indicates IP Signaling Endpoint (ASP), interworking with SS7
networks.
0x2 indicates Signaling Gateway.
0x3 indicates relay node support.
3.9.10 Credit
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of the credit field is is one octet. See ITU-T Q.713
chapter 3.10. The parameter is used for protocol class 3
exclusively.
3.9.11 SMI / Subsystem
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010C | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
4 Procedures
The SUA layer needs to respond to various local primitives it
receives from other layers as well as the messages that it receives
from the peer SUA layers. This section describes the SUA procedures
in response to these events.
4.1 SCCP _ SUA Interworking at the SG
Loughney, et al. [Page 59
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
On the SG, the SCCP routing or interworking function determines that
the message must be sent to an AS via the SUA stack, based on
information in the incoming message. The SUA Address Mapping
Function identifies the appropriate Application Server (AS) and
selects an active ASP from the list of ASPs servicing this AS. The
appropriate ASP can be determined based on the routing information
in the incoming message, local load sharing information, etc. The
appropriate SUA message is then constructed and sent to the
appropriate endpoint, via the correct SCTP association and stream.
4.1.1 Connection Oriented Procedures
On receipt of a CR message from the SS7 network, a first connection
section is established between the SG and SS7 originating node. A
second connection section is to be setup between the SG and the
appropriate ASP, determined by the SUA outgoing mapping function.
Local resources and source local reference numbers are allocated to
keep/retrieve the required address information and the connection
state in order to format and route subsequent messages for the
connection based on reference numbers only. The existing SCCP
procedures MAY be deployed at the SG to perform this coupling.
The same applies for a CORE message received from the IP network,
destined for an SS7 node. After allocating the necessary resources,
the SUA incoming mapping function formats the appropriate SCCP
message and passes it on to SCCP routing for further processing
(sending into the SS7 network).
The SG MUST take care of any segmentation / reassembly issues at the
border of the SS7 and IP networks. The IPSP may not have any
knowledge about the requirements regarding the maximum supported
message length of the SS7 network to which it is sending. However,
since there is in principle no limit to the use of the more
indicator in SS7 networks, there is still need for connection-
oriented segmentation / reassembly procedures in the IPSP as well.
4.1.2 Connectionless Procedures
The existing SCCP routing functions may be enhanced to support
interworking with the SUA layer. The function of SUA can be limited
to outgoing mapping (formatting of the CLDT or CLDR message) and
selection of the correct SCTP association (ASP) and stream. For the
direction ASP to SG, the SUA incoming mapping formats the
appropriate SCCP message (UDT(S), XUDT(S) or LUDT(S)) and passes it
on to SCCP routing for further processing.
The SG MUST take care of any segmentation / reassembly at the border
of the SS7 and IP networks. The IPSP may not have any knowledge
about the requirements of the SS7 network to which it is sending.
Loughney, et al. [Page 60
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
No connectionless segmenting / reassembly procedures are required at
the IPSP.
4.1.3 SS7 Signaling Network Management Procedures
When an SCCP Subsystem Management (SCMG) message is received from
the SS7 network, it has to be determined whether there are concerned
Application Servers, interested in subsystem status changes. The SUA
management function is informed with the N-State indication
primitive upon which it formats and transfers the applicable SNM
message to the list of concerned ASPs using stream ID "0".
When MTP-3 Management indications are received (MTP-PAUSE, MTP-
RESUME, MTP-STATUS), SCCP Subsystem Management determines whether
there are concerned local SCCP-users. When these local SCCP-users
are in fact Application Servers, serviced by ASPs, SUA management is
informed with the PC-State indication primitive upon which it
formats and transfers the applicable SNM message (DUNA, DAVA or
SCON) to the list of concerned ASPs using stream ID "0".
When the DAUD message is received at the SG from an ASP, the SG
checks the status of the specified SS7 destination and returns DAVA,
DUNA or SCON depending on the result of the check. The SG initiates
SST (Subsystem Status Test) procedures following the SCCP procedures
described in Q.714, these are not triggered by the receipt of a DAUD
message.
SCCP Subsystem Management procedures may also be triggered in case
of AS state changes, see chapter 4.4.1.2.
4.2 Primitives received from the local SUA-user
These support the SUA transport of SCCP-User/SCCP boundary
primitives. The same services as supported by SCCP (connectionless
and connection-oriented) are to be provided by SUA. The SCCP-users
at the SG should be able to use the same primitive interface to
SCCP/SUA without any changes. The SCCP-SUA interworking function
takes care of selecting the appropriate stack.
The SUA needs to setup and maintain the appropriate SCTP association
to the selected endpoint. SUA also manages the usage of SCTP
streams.
The address information passed by the SUA-user at an ASP must
contain either :
- a valid SS7 address to reach a destination in the SS7 network
via the appropriate SCTP association to a SG,
- a valid IP address/hostname to reach another ASP in the IP
network via the appropriate SCTP association.
Loughney, et al. [Page 61
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
4.3 Layer Management Procedures
On receiving primitives from the local Layer Management, the SUA
layer will take the requested action and provide a response to Layer
Management.
An M-SCTP-ESTABLISH request from Layer Management will initiate the
establishment of an SCTP association. An M-SCTP-ESTABLISH confirm
will be sent to Layer Management when the initiated association set-
up is complete. An M-SCTP-ESTABLISH indication is sent upon
successful completion of an incoming SCTP association set-up from a
peer SUA node.
An M-SCTP-RELEASE request from Layer Management initiates the tear-
down of an SCTP association. An M-SCTP-RELEASE confirm is sent to
Layer Management when the association tear-down is complete. An M-
SCTP-RELEASE indication is sent to Layer Management upon successful
tear-down of an SCTP association initiated by a peer SUA.
An M-SCTP-STATUS request supports a Layer Management query of the
local status of a particular SCTP association. The SUA responds with
the association status in an M-SCTP-STATUS confirm. No peer SUA
protocol is invoked.
An M-ASP-STATUS request supports a Layer Management query of the
status of a particular local or remote ASP. The SUA responds with an
M-ASP-STATUS confirm. No peer SUA protocol is invoked.
An M-AS-STATUS request supports a Layer Management query of the
status of a particular AS. The SUA responds with an M-AS-STATUS
confirm. No peer SUA protocol is invoked.
M-ASP-UP, -DOWN, -ACTIVE and _INACTIVE request primitives allow
Layer Management at an IPSP to force state changes. Upon successful
completion, a corresponding confirm primitive is issued by SUA to
the Layer Management. If the invocation is unsuccessful, an Error
indication is provided.
Layer Management is informed by SUA Management about AS/ASP state
changes with the corresponding indications. It is also informed of
received NTFY or ERR messages, see chapter 4.4.3.
4.4 SUA Management Procedures
This functionality comprises the handling of AS/ASP state and
traffic management messages, SUA peer management messages, SCTP
notifications and the interface with local Layer Management.
These procedures support the SUA management of SCTP Associations and
ASP paths between SGs and ASPs.
Loughney, et al. [Page 62
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
4.4.1 AS and ASP State and Traffic Management
The SUA layer on each IPSP (e.g. SG) needs to maintain the state of
each connected IPSP (e.g. ASP), as a way to manage the traffic to
these IPSPs and the (logical) ASs they service. In particular at a
SG, the state of each connected ASP is needed as input to the SGs
routing function.
4.4.1.1 ASP States
The state of each ASP is maintained in the SUA layer at the
controlling AS. The state of an ASP changes due to events. The
events include:
- ASP Management messages (ASP-Up, ASP-Down, ASP-Active, ASP-
Inactive)
- SCTP Communication Down Notification (SCTP CDI)
The state of the ASP within each AS is important in particular for
the routing function at the SG, in order to direct traffic for a
specific routing key (AS) to the appropriate ASP.
At an ASP, if it is connected to a set of redundant SGs, this set
can also be seen as an AS handling all traffic destined for the SS7
network.
The ASP state transition diagram is shown in Figure 4. The possible
states of an ASP are:
ASP-DOWN: The Application Server Process is unavailable. Initially
all ASPs will be in this state.
ASP-UP: The Application Server Process is available but application
traffic is not possible. The ASP can only handle management
messages.
ASP-ACTIVE: The Application Server Process is available and
application traffic is possible. Whether traffic will be directed to
this ASP depends on the Traffic Mode Type (over-ride, loadshare with
or without Standby option).
Loughney, et al. [Page 63
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
+-------------+
| |
+----------------------| ASP-ACTIVE |
| | |
| +-------------+
| ^ |
| ASP | | ASP
| Active | | Inactive
| | v
| +-------------+
| | |
| | ASP-UP |-------------+
| +-------------+ |
| ^ | |
ASP Down | ASP | | ASP Down / | ASP
SCTP CDI | Up | | SCTP CDI | Down/
| | v | SCTP
| +-------------+ | CDI
| | | |
+--------------------->| ASP-DOWN |<------------+
| |
+-------------+
Figure 4: ASP State Transition Diagram
SCTP CDI: The local SCTP layer's SHUTDOWN COMPLETE notification or
COMMUNICATION LOST notification. The shutdown of an SCTP association
may have been requested by local Layer Management, see chapter 4.3.
Local Layer Management
4.4.1.2 AS States
The AS is configured in the IPSP as a logical entity to handle
traffic for a specific (unique) routing key. The state of the AS is
maintained in the SUA layer, and can change due to following events:
- ASP state changes : when the first ASP within an AS goes UP
or ACTIVE, or when the last ASP within an AS goes DOWN or
INACTIVE
- Recovery Timer expiry
The possible states of an AS are:
AS-DOWN: The Application Server is unavailable. This state implies
that all related ASPs are in the ASP-DOWN state for this AS.
Initially the AS will be in this state.
AS-UP: The Application Server is available but no application
traffic is possible (i.e. one or more related ASPs are in the ASP-UP
state, but none in the ASP-ACTIVE state).
Loughney, et al. [Page 64
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
AS-ACTIVE: The Application Server is available and application
traffic is possible. This state implies that at least one ASP is in
the ASP-ACTIVE state.
AS-PENDING: An active ASP has transitioned from active to inactive
or down and it was the last remaining active ASP in the AS. A
recovery timer T(r) will be started and all incoming SCN messages
will be queued by the SG. If an ASP becomes active before T(r)
expires, the AS will move to AS-ACTIVE state and all the queued
messages will be sent to the active ASP.
If T(r) expires before an ASP becomes active, the SG stops queuing
messages and discards all previously queued messages. The AS will
move to AS-UP if at least one ASP is in ASP-UP state, otherwise it
will move to AS-DOWN state.
+----------+ one ASP trans to ACTIVE +-------------+
| |---------------------------->| |
| AS-UP | | AS-ACTIVE |
| |<--- | |
+----------+ \ +-------------+
^ | \ Tr Expiry, ^ |
| | \ at least one | |
| | \ ASP in UP | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | all ASP \ one ASP | | Last ACT.
trans | | trans to \ trans to | | asp trans
to UP | | DOWN -------\ ACTIVE | | to UP or
| | \ | | DOWN
| | \ | |
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | --| |
| AS-DOWN | | AS-PENDING |
| | | (queuing) |
| |<----------------------------| |
+----------+ Tr Expiry no ASP +-------------+
in UP state
Tr = Recovery Timer
Figure 5: AS State Transition Diagram
Loughney, et al. [Page 65
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
The SG maintains the availability of the ASs, and will need to issue
the correct SCCP management message (where applicable) to the SS7
node(s).
When an AS transitions to the UP or DOWN state, and it is the only
(or last) one handling traffic for a certain SSN, an SSP message
must be broadcast to the concerned remote SCCP-users in the SS7
network.
When an AS transitions to the ACTIVE state, and it is the first one
handling traffic for a certain SSN, an SSA message must be broadcast
to the concerned remote SCCP-users in the SS7 network.
4.4.2 AS/ASP Management procedures
Once an SCTP association is established between two IPSPs, one (or
both) side(s) might issue an ASP-UP message.
4.4.2.1 ASP-Up
An ASP sends an ASP-UP to each communication partner. When the ASP-
UP message is received, the receiving IPSP can react in three
different ways:
- Mark the remote ASP Inactive and reply with an ASP-UP Ack
message in acknowledgement to every received ASP-UP, even if
the ASP is already marked as Inactive.
- If for any local reason (e.g. management lock-out) the IPSP
cannot respond with an ASP-UP Ack, it responds with an ASP-
DOWN Ack message with Reason "Management Blocking".
- If an unknown version is received with the ASP-UP message,
the receiving end must respond with an Error message with
Error Code _Invalid Version_. The version field in the common
header will indicate to the sender which version(s) the
receiving node supports. This is useful when protocol version
upgrades are being performed. A node with the newer version
should support the older versions as well to fallback upon in
a subsequent ASP-UP message.
If the ASP does not receive any of the above reactions, the ASP may
resend ASP-Up messages until it receives an response. The ASP must
wait for the ASP-UP Ack message before sending any other messages.
If the remote peer receives any other SUA messages from an ASP,
before an ASP-UP is received and acknowledged, the message should be
discarded.
4.4.2.2 ASP-Down
The IPSP will mark an ASP as down if one of the following events
occur:
- an ASP Down (DOWN) message is received from the ASP,
Loughney, et al. [Page 66
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
- the ASP is locked by local Layer Management.
The IPSP sends an ASP DOWN Ack message in response to a received
ASP-DOWN message from the ASP even if the ASP is already marked as
Down.
The IPSP will send an ASP DOWN message whenever it wants to take
down a ASP. Since it is possible for ASP DOWN and ASP DOWN Ack
messages to be lost (for example, during a node failover), the IPSP
can send ASP DOWN messages repeatedly until the path comes down
(i.e. until it receives a ASP-DOWN message from the remote peer or
the SCTP association goes down).
4.4.2.3 ASP-Active
When an ASP is ready to start processing traffic, it sends an ASP-
ACTIVE message to the remote peer. When an ASP-ACTIVE message is
received, the remote peer responds with an ASP-ACTIVE Ack. The ASP
cannot send any other messages until after the ASP-ACTIVE Ack is
received. If the ASP-ACTIVE Ack is not received within a certain
time, the ASP may resend the ASP-ACTIVE message.
The ASP-ACTIVE message optionally contains a list of one or more
Routing Contexts, indicating which Application Servers the ASP is
joining. If no Routing Contexts are present, then local
configuration data is used to determine to which Application
Server(s) the ASP belongs.
The Traffic Mode Type parameter in the ASP-ACTIVE message indicates
the traffic handling mode used in a particular Application Server,
either Over-ride, Over-ride (Standby), Load-share or Load-share
(Standby). If the remote peer determines that the mode indicated in
an ASP-ACTIVE is incompatible with the mode currently used in the
AS, the remote peer responds with an Error message indicating
"Invalid Traffic Handling Mode".
In the Over-ride mode, reception of an ASP-ACTIVE message at a
remote peer causes the all traffic for the AS to be sent to the ASP
which sent the ASP-ACTIVE. All previously active ASPs in the AS are
now considered Inactive and will no longer receive traffic for that
particular AS. The remote peer sends a Notify (Alternate ASP-
Active) to the previously active ASP in the AS, after stopping all
traffic to that ASP. All existing connections/transactions with the
previously active ASP should be terminated however.
In the Over-ride (Standby) mode, the actions are the same with the
exception that the traffic is not started to the ASP until the
previously active ASP transitions to the "Inactive or "Down" state.
At this point the ASP that sent the Over-Ride (Standby) ASP-ACTIVE
message takes over the traffic. No Notify messages are needed.
Loughney, et al. [Page 67
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
In the Load-share mode, reception of an ASP-ACTIVE message causes
the redistribution of traffic to the ASP sending the ASP-ACTIVE, in
addition to all the other ASPs that are currently active in the AS.
The algorithm at the SG for load-sharing traffic within an AS to all
the active ASPs is implementation dependent. All ASPs marked for
load-sharing should be able to handle any traffic within the AS, in
order to accommodate any potential fail-over or re-balancing of the
offered load.
In the Load-share (Standby) mode, the actions are the same as the
Load-share mode, with the exception that the traffic is not started
to the ASP until the remote peer determines that additional
resources are needed to service the AS. When needed, the ASP which
sent the Loadshare (Standby) ASP-ACTIVE message is taken up in the
loadsharing scheme and traffic is started. No Notify messages are
needed to be sent.
A node that receives an ASP-ACTIVE with an incorrect Traffic Mode
Type for a particular Routing Context will respond with an Error
Message with Error Cause _Invalid Traffic Handling Mode_. A node
that receives an unknown Routing Context value responds with an
Error message with Error Cause _Invalid Routing Context_.
4.4.2.4 ASP-Inactive
When an ASP wishes to withdraw from handling traffic, it sends an
ASP-INACTIVE to the applicable remote IPSPs, specifying the AS
(Routing Context) from which it is withdrawing. If the ASP is
withdrawing from more than one AS, then the ASP issues either
multiple ASP-INACTIVE messages, if multiple SCTP associations exist
to the remote ASPs; or a single ASP-INACTIVE message containing
multiple Routing Contexts.
There are two ASP-INACTIVE modes, Over-ride and load-share. If the
remote peer determines that the Traffic Mode Type parameter in the
ASP-INACTIVE is inconsistent with the mode being used by the
Application Server, an error is reported to the local layer
management, indicating _Invalid Traffic Handling Mode_. However,
the ASP-INACTIVE is still handled.
In the Over-ride mode, the ASP which sent the ASP-INACTIVE is marked
as Inactive. No further traffic is sent from and to the ASP marked
Inactive.
In the Load-sharing mode, the IPSP marks the ASP as Inactive and re-
allocates the traffic to the remaining active ASPs. The load-sharing
mechanism used is outside of the scope of SUA. If there are
insufficient resources, a NTFY (Insufficient ASPs) may be sent to
all inactive ASPs. If a Loadshare (Standby) ASP is available, it
may be now immediately included in the loadshare group and a Notify
Loughney, et al. [Page 68
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
message must not be sent. An ASP-INACTIVE Ack message is sent to
the ASP after all traffic is halted.
In the case when no other ASPs are active or standby in the
Application Server, the remote peer should send a NTFY (AS-Pending)
to all inactive ASPs of the AS. The remote peer then either discards
all incoming messages for the AS or starts buffering the incoming
messages for T(r) seconds, after which messages will be discarded.
T(r) is configurable by the network operator.
If the remote peer receives an ASP-ACTIVE from an ASP in the AS
before expiry of T(r), the buffered traffic is directed to the ASP
and the timer is cancelled. If T(r) expires, the AS is moved to the
"Down" state.
4.4.3 SUA peer management messages
4.4.3.1 Notify
A NTFY message reflecting a change in the AS state is sent to all
ASPs in the AS, except those in the "Down" state, with appropriate
Status Type/ID.
In the case where a NTFY (AS-Pending) message is sent by an SG that
now has no active ASPs to service the traffic, or a NTFY
(Insufficient ASPs) is sent in the Loadshare mode, the NTFY does not
explicitly force the ASP(s) receiving the message to become active.
The ASPs remain in control of what (and when) action is taken.
4.4.3.2 Error
The ERR message is used to signal invalid protocol behavior.
4.4.4 Heartbeat procedure
The optional Heartbeat message may be sent in order to query the
status of the remote peer. It is optional to send, but mandatory to
acknowledge.
The data field can be used to store information in the heartbeat
message useful to the sending node (e.g. the data field can contain
a time stamp, a sequence number, etc.).
5 Examples of SUA Procedures
The following sequence charts overview the procedures of SUA. These
are meant as examples, they do not, in and of themselves, impose
additional requirements upon an instance of SUA.
5.1 SG Architecture
Loughney, et al. [Page 69
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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)-+
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. 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.
Loughney, et al. [Page 70
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
<--------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 use a DAUD to instruct the SG to invoke the SS7 Sub-system
Test procedure.
ASP-a1 ASP-a2 SG SEP
(Primary) (Backup)
<--------SSP--------+
<-----------------DUNA-----------------+
+-----------------DAUD----------------->
+--------SST-------->
5.1.2.2 Successful ASP Failover scenario
The following is an example of a successful failover scenario, where
there is a failover from ASP-a1 to ASP-a2, i.e. Primary to Backup.
During the failover, the SG buffers any incoming data messages from
the SEP, forwarding them when the Backup becomes available.
ASP-a1 ASP-a2 SG SEP
(Primary) (Backup)
+-------------ASP Inactive------------->
<----------NTFY (ASP Inactive)---------+
<-NTFY (ASP Inact.)-+
+----ASP Active----->
<--ASP Active Ack---+
<-NTFY (ASP Active)-+
<----------NTFY (ASP Active)-----------+
Loughney, et al. [Page 71
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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 an Application Server and
two ASPs. The AS
The following must be established before SUA traffic can flow. A
connectionless flow is shown for simplicity.
Each node is configured (via MIB, for example) with the connections
that need to be setup
IP SEP A IP SEP B
AS A AS B
ASP-a1 ASP-a2 ASP-b2 ASP-b1
(Primary) (Backup) (Backup) (Primary)
[Establish SCTP Connectivity]
|------------- Establish SCTP Association -------------|
|------------------ Establish SCTP Association ------------------|
|------- Establish SCTP Association --------|
|------------ Establish SCTP Association -------------|
[Establish SUA Connectivity]
+----------------------ASP Up-------------------------->
<--------------------ASP Up Ack------------------------+
Loughney, et al. [Page 72
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
+---------------------------ASP Up------------------------------->
<-------------------------ASP Up Ack-----------------------------+
<----------------ASP Up---------------------+
+----------------ASP Up Ack----------------->
+------------------------ASP Up----------------------->
<----------------------ASP Up Ack---------------------+
+---------------------------ACTIVE------------------------------->
<-------------------------ACTIVE Ack-----------------------------+
[Traffic can now flow directly between ASPs]
+-----------------------------CLDT------------------------------->
5.2.2 Failover scenarios
The following sequences address failover of ASP
5.2.2.1 Successful ASP Failover scenario
The following is an example of a successful failover scenario, where
there is a failover from ASP-a1 to ASP-a2, i.e. Primary to Backup.
Since data transfer passes directly between peer ASPs, ASP-b1 is
notified of the failover of ASP-a1 and must buffer outgoing data
messages until ASP-a2 becomes available.
IP SEP A IP SEP B
ASP-a1 ASP-a2 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 Security
Loughney, et al. [Page 73
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
6.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.
6.2 Threats
There is no quick fix, one-size-fits-all solution for security. As
a transport protocol, SUA has the following security objectives:
* Availability of reliable and timely user data transport.
* Integrity of user data transport.
* Confidentiality of user data.
SUA runs on top of SCTP. SCTP provides certain transport related
security features, such as:
* Blind Denial of Service Attacks
* Flooding
* Masquerade
* Improper Monopolization of Services
When SUA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network
includes an appropriate security policy framework. The "Site
Security Handbook" [2196] should be consulted for guidance.
When the network in which SUA runs in involves more than one party,
it may not be reasonable to expect that all parties have implemented
security in a sufficient manner. End-to-end security should be the
goal, therefore, it is recommended that IPSEC is used to ensure
confidentiality of user payload. Consult [2409] for more
information on configuring IPSEC services.
6.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.
7 IANA Considerations
7.1 SCTP Payload Protocol ID
Loughney, et al. [Page 74
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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.
7.2 Port Number
SUA will use port number 14001. This Port Number is the port which
the SG listen to when receiving SCTP datagrams.
7.3 Protocol Extensions
This protocol may also be extended through IANA in three ways:
-- through definition of additional message classes,
-- through definition of additional message types, and
-- through definition of additional message parameters.
The definition and use of new message classes, types and parameters
is an integral part of SIGTRAN adaptation layers. Thus, these
extensions are assigned by IANA through an IETF Consensus action as
defined in [RFC2434].
The proposed extension must in no way adversely affect the general
working of the protocol.
7.3.1 IETF Defined Message Classes
The documentation for a new message class MUST include the following
information:
(a) A long and short name for the message class;
(b) A detailed description of the purpose of the message class.
7.3.2 IETF Defined Message Types
Documentation of the message type MUST contain the following
information:
(a) A long and short name for the new message type;
(b) A detailed description of the structure of the message.
(c) A detailed definition and description of intended use of each
field within the message.
(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.
Loughney, et al. [Page 75
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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.
7.3.4 IETF-defined TLV Parameter Extension
Documentation of the message parameter MUST contain the following
information:
(a) Name of the parameter type.
(b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described earlier in the document.
(c) Detailed definition of each component of the parameter value.
(d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances
multiple instances of this parameter type may be found within
the same message type.
8 Timer Values
Ta 2 seconds
Tr 2 seconds
T(ack) 2 seconds
T(ias) Inactivity Send timer 7 minutes
T(iar) Inactivity Receive timer 15 minutes
9 Acknowledgements
The authors would like to thank Brian Bidulock, Martin Booyens,
Klaus Gradischnig, Miguel A. Garcia, Marja-Liisa Hamalainen, Sherry
Karl, Markus Maanoja, Chirayu Patel, Michael Purcell, Michael
Tuexen, Al Varney, Ben Wilson and Michael Wright 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: [email protected]
Greg Sidebottom
Nortel Networks
3685 Richmond Rd,
Nepean, Ontario, Canada K2H 5B7
Loughney, et al. [Page 76
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
EMail: [email protected]
Guy Mousseau
Nortel Networks
3685 Richmond Rd
Nepean, Ontario, Canada K2H 5B7
Stephen Lorusso
Unisphere Solutions
One Executive Drive
Chelmsford, MA 01824
USA
email:
[email protected]
Lode Coene
Siemens Atea
Atealaan 34
B-2200 Herentals
Belgium
Phone: +32-14-252081
EMail: [email protected]
Gery Verwimp
Siemens Atea
34 Atealaan
PO 2200
Herentals
Belgium
Phone : +32 14 25 3424
EMail:[email protected]
Joe Keller
Tekelec
5200 Paramount Parkway
Morrisville, NC 27560
USA
EMail: [email protected]
Florencio Escobar Gonzalez
Ericsson Spain S.A.
Retama 7, 2nd floor
28045, Madrid
Spain
EMail:
[email protected]
Steven Furniss
Marconi
New Century Park
Coventry CV3 1HJ
United Kingdom
EMail: [email protected]
Loughney, et al. [Page 77
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
William Sully
Marconi
New Century Park
Coventry CV3 1HJ
United Kingdom
EMail: [email protected]
11 References
[2196] RFC 2196, "Site Security Handbook", B. Fraser Ed.,
September 1997.
[2396] Berners-Lee, T., Fielding, R.T. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998.
[2401] RFC 2401, "Security Architecture for the Internet
Protocol", S. Kent, R. Atkinson, November 1998.
[2434] RFC 2434 "Guidelines for Writing an IANA
Considerations Section in RFCs", T. Narten, H.
Alvestrand, October 1998.
[2719] RFC 2719, "Framework Architecture for Signaling
Transport"
[ANSI-MTP] ANSI T1.111 'Signaling System Number 7 - Message
Transfer Part'
[ANSI SCCP] ANSI T1.112 'Signaling System Number 7 - Signaling
Connection Control Part'
[ANSI TCAP] ANSI T1.114 'Signaling System Number 7 - Transaction
Capabilities Application Part'
[ENUM] 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
[ITU-MTP] ITU-T Recommendations Q.701-Q.705, 'Signalling System
No. 7 (SS7) - Message Transfer Part (MTP)'
[ITU SCCP] ITU-T Recommendations Q.711-714, 'Signaling System
No. 7 (SS7) - Signaling Connection Control Part
(SCCP)'
Loughney, et al. [Page 78
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
[ITU TCAP] ITU-T Recommendation Q.771-775 'Signaling System No.
7 SS7) - Transaction Capabilities (TCAP)
[M3UA] MTP3-User Adaptation Layer <draft-ietf-sigtran-m3ua-
06.txt>, March 2001, Work in Progress.
[RANAP] 3G TS 25.413 V3.5.0 (2001-03) '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.
[UTRAN IUR] 3G TS 25.422 V3.5.0 (2000-12) "Technical
Specification 3rd Generation Partnership Project;
Technical Specification Group Radio Access Network;
UTRAN Iur Interface Signaling Transport (Release
1999)"
Loughney, et al. [Page 79
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Appendix A: Message mapping between SCCP and SUA.
This is for illustrative purposes only.
SUA SCCP SCCP Classes Mgt. SUA
Name Name Full Name 0 1 2 3 Msg.Usage
====================================================================
Connectionless Messages
CLDT UDT Unitdata X X - - - -
CLDT XUDT Extended unitdata X X - - - -
CLDT LUDT Long unitdata X X - - - -
CLDR UDTS Unitdata service X X - - - -
CLDR XUDTS Extended unitdata serv. X X - - - -
CLDR LUDTS Long unitdata service X X - - - -
Connection-Oriented Messages
CODT DT1 Data form 1 - - X - - -
CODT DT2 Data form 2 - - - X - -
CODT ED Expedited data - - - X - -
CODA AK Data acknowledgement - - - X - -
CODA EA Expedited data ack. - - - X - -
CORE CR Connection request - - X X - -
COAK CC Connection confirm - - X X - -
COAK CREF Connection refused - - X X - -
RELRE RLSD Released - - X X - -
RELCO RLC Release complete - - X X - -
RESRE RSR Reset request - - - X - -
RESCO RSC Reset confirm - - - X - -
COIT IT Integrity Test - - X X - -
COERR ERR Protocol Data Unit Error - - X X - -
Signaling Network Management Messages
SCON SSC SCCP/subsystem-congested - - - - X -
DAVA SSA subsystem-allowed - - - - X -
DUNA SSP subsystem-prohibited - - - - X -
DAUD SST subsystem-status-test - - - - X -
n/a SOR subsystem-oos-req - - - - X -
n/a SOG subsystem-oos-grant - - - - X -
SUA MGT Messages
ASPUP n/a n/a - - - - - X
ASPDN n/a n/a - - - - - X
ASPAC n/a n/a - - - - - X
ASPIA n/a n/a - - - - - X
NTFY n/a n/a - - - - - X
ERR n/a n/a - - - - - X
- = Message not applicable for this protocol class.
X = Message applicable for this protocol class.
n/a = not applicable
Loughney, et al. [Page 80
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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 81]
| ||||||||||||||||
| Last modified: Wed, 27 Nov 2024 04:58:35 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||