| draft-ietf-sigtran-sua-08 Description: Request For Comments
You can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-sua-08.txt.
INTERNET-DRAFT J. Loughney (Editor)
Internet Engineering Task Force Nokia
G. Sidebottom
gregside Consulting
Guy Mousseau
Issued: 5 October 2001 Nortel Networks
Expires: 5 April 2002 S. Lorusso
Unisphere Networks
L. Coene, G. Verwimp
Siemens
J. Keller
Tekelec
F. Escobar
Ericsson
W. Sully, S. Furniss
Marconi
B. Bidulock
OpenSS7 Corporation
SS7 SCCP-User Adaptation Layer (SUA)
<draft-ietf-sigtran-sua-08.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 5 April 2002.
Abstract
This Internet Draft defines a protocol for the transport of any SS7
SCCP-User signalling (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 Signalling Gateway to IP Signalling Endpoint architecture as well
as a peer-to-peer IP Signalling 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 October 5, 2001
Abstract.............................................................1
1. Introduction......................................................3
1.1 Scope...........................................................3
1.2 Terminology.....................................................3
1.3 Signalling 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...................................17
2 Conventions.......................................................17
3 Protocol Elements.................................................18
3.1 Common Message Header..........................................18
3.2 SUA Connectionless Messages....................................21
3.3 Connection Oriented Messages...................................24
3.4 Signalling Network Management (SNM) Messages...................35
3.5 Application Server Process State Maintenance Messages..........41
3.6 ASP Traffic Maintenance Messages...............................43
3.7 SUA Management Messages........................................46
3.8 Routing Key Management (RKM) Messages..........................47
3.9 Common Parameters..............................................50
3.10 SUA-Specific parameters.......................................59
4. Procedures.......................................................77
4.1 Procedures to Support the SUA-User Layer.......................77
4.2 Receipt of Primitives from the Layer Management................78
4.3 AS and ASP State Maintenance...................................80
4.4 Routing Key Management Procedures..............................92
4.5 Procedures to Support the Availability
or Congestion Status of SS7 Destination........................94
4.6 MTP3 Restart...................................................97
4.7 SCCP - SUA Interworking at the SG..............................97
5 Examples of SUA Procedures........................................99
5.1 SG Architecture...............................................100
5.2 IP-IP Architecture............................................102
6 Security.........................................................104
6.1 Introduction..................................................104
6.2 Threats.......................................................104
6.3 Protecting Confidentiality....................................104
7 IANA Considerations..............................................105
7.1 SCTP Payload Protocol ID......................................105
7.2 Port Number...................................................105
7.3 Protocol Extensions...........................................105
8 Timer Values.....................................................106
9 Acknowledgements.................................................106
10 Authors' Addresses..............................................107
11 References......................................................108
Copyright Statement................................................109
Loughney (editor) [Page 2]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 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 that
include support for SS7 and SS7-like signalling 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 signalling endpoints. Consideration is
given for the transport from an SS7 Signalling Gateway (SG) to an IP
signalling node (such as an IP-resident Database) as described in
the Framework Architecture for Signalling Transport [2719]. This
protocol can also support transport of SCCP-user messages between
two endpoints wholly contained within an IP network.
The delivery mechanism addresses 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 signalling nodes).
* Support for distributed IP-based signalling 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
Signalling Gateway (SG) - Network element that terminates SCN
signalling and transports SCCP-User signalling over IP to an IP
signalling endpoint. A Signalling Gateway could be modeled as one
or more Signalling Gateway Processes, which are located at the
border of the SS7 and IP networks. Where an SG contains more than
one SGP, the SG is a logical entity and the contained SGPs are
assumed to be coordinated into a single management view to the SS7
network and to the supported Application Servers.
Loughney (editor) [Page 3]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
Application Server (AS) - A logical entity serving a specific
Routing Key. An example of an Application Server is a virtual IP
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 backup process of an Application Server
(e.g., part of a distributed signalling 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 Signalling Gateway.
Signalling Gateway Process (SGP) - A process instance of a
Signalling Gateway. It serves as an active, load-sharing or
broadcast process of a Signalling Gateway.
Signalling Process - A process instance that uses SUA to communicate
with other signalling process. An ASP, a SGP and an IPSP are all
signalling 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
signalling traffic configured to be handled by a particular
Application Server. An example would be where a Routing Key consists
of a particular SS7 SCCP SSN plus an identifier to uniquely mark the
network that the SSN belongs to, for which all traffic would be
directed to a particular Application Server. Routing Keys are
mutually exclusive in the sense that a received SS7 signalling
message cannot be directed to more than one Routing Key. Routing
Keys can be provisioned, for example, by a MIB or registered using
SUA's dynamic registration procedures.
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 the SGP and
the ASP (or between two ASPs), identifying the relevant Application
Server. From the perspective of an SGP/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
Loughney (editor) [Page 4]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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. The Routing Context also uniquely identifies an SS7 entity
(point code) into a SS7 network, as presented by the SG.
Address Mapping Function (AMF) - The AMF is an implementation
dependent function that is responsible for resolving the address
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 signalling 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 Byte Order - Most significant byte first, a.k.a. Big Endian.
Layer Management - Layer Management is a nodal function that handles
the inputs and outputs between the SUA layer and a local management
entity.
Host - The computing platform that the SGP or 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 that 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 Signalling Transport Architecture
The framework architecture that has been defined for SCN signalling
transport over IP [2719] uses multiple components, including an IP
transport protocol, a signalling common transport protocol and an
adaptation module to support the services expected by a particular
SCN signalling 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
Loughney (editor) [Page 5]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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 Signalling 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 Routing Context 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 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
Loughney (editor) [Page 6]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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 are 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 SGP needs to 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 SGP to ASP,
with association ID = SG-ASP, Stream ID based on sequence control
and possibly other parameters, e.g. OPC:
- Routing Context: based on SS7 Network ID and AS membership,
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.
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:
- Routing Context: as received in previous message.
- Source address: unique address provided so that when used as
the SCCP called party address in the SEP, it must yield the
same AS, the SSN might 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.
1.3.1.2 SG as relay-point
A Global Title translation is 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", from an AS can be derived. Selection of
the AS is thus based on the SCCP called party address (and possibly
other SS7 parameters depending on the implementation).
Loughney (editor) [Page 7]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
1.3.2 Protocol Architecture for Connection-Oriented Transport
In this architecture, the SCCP and SUA layers interface in the SGP
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 SGP to ASP 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 |
| MTP2 | | MTP2 | | | |
+------+ +------+------+ +------+
| L1 | | L1 | IP | | IP |
+------+ +------+------+ +------+
| | | |
+---------------+ +------------+
SUAP - SCCP/SUA Application Protocol (e.g. - RANAP/RNSAP)
STP - SS7 Signalling Transfer Point
The above architecture may simplify, in some cases, to carrying SS7
application protocols between two IP based endpoints. In this
Loughney (editor) [Page 8]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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 that 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 signalling is not needed. The
architecture removes the need for signalling 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
Figure 1 shows an example network architecture that can support
robust operation and failover. There need to be some management
resources at the AS to manage traffic.
Loughney (editor) [Page 9]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
***********
* 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 Signalling Gateway Network Architecture
When interworking between SS7 and IP domains is needed, the SGP acts
as the gateway node between the SS7 network and the IP network. The
SGP will transport SCCP-user signalling traffic from the SS7 network
to the IP-based signalling nodes (for example IP-resident
Databases). The Signalling Gateway can be considered as a group of
Application Servers with additional functionality to interface
towards an SS7 network.
Loughney (editor) [Page 10]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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 SGPs (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 is
performed at the ASP, it will be necessary for the ASP to maintain
the status of each distant SGPs to which it communicates on the
basis of the SG through which it may route.
Signalling Gateway
SCTP Associations
+----------+ **************
| SG1 | * AS3 *
| ******** | * ******** *
| * SGP11+--------------------------------------------+ ASP1 * *
| ******** | / * ******** *
| ******** | | * ******** *
| * SGP12+--------------------------------------------+ ASP2 * *
| ******** | \ / | * ******** *
+----------+ \ | | * . *
\ | | * . *
+---------- \ | | * . *
| SG2 | \ | | * . *
| ******** | \ | | * ******** *
| * SGP21+---------------------------------+-* * ASPN * *
| ******** | \ * ******** *
| ******** | \ **************
| * SGP22+---+--+ \
| ******** | | | \ **************
+----------+ | | \ * AS4 *
| | \ * ******** *
| +-------------------------------------+ ASP1 * *
| * ******** *
| * . *
| * . *
| * *
| * ******** *
+----------------------------------------+ ASPn * *
* ******** *
**************
Figure 2: Signalling Gateway Architecture
The pair of SGs can either operate as replicated endpoints or as
replicated relay points from the SS7 network point of view.
Loughney (editor) [Page 11]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
Replicated endpoints: the coupling between the SGs and the ASPs when
the SGs act as replicated endpoints is an implementation issue.
Replicated relay points: in normal circumstances, the path from SEP
to ASP will always go via the same SGP 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 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 SHALL support the transfer of SCCP-user messages. The SUA
layer at the SG SHALL 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
signalling connection.
* Protocol class 3 allows the features of protocol class 2 with
the inclusion of flow control. Detection of message loss or
mis-sequencing is included.
Protocol classes 0 and 1 make up the SCCP connectionless service.
Protocol classes 2 and 3 make up the SCCP connection-oriented
service.
Loughney (editor) [Page 12]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
1.4.3 Native Management Functions
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 messages consists
of DUNA, DAVA, DAUD, DRST, DUPU 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 send 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)
N-Coord |Request |ITU-Q.711 Chap 6.3.2.3.1 (Tab 13/Q.711)
|Indication |ANSI-T1.112 Chap 2.3.2.3.3 (Tab 8F/T1.112.1)
|Response |
|Confirm |
1.4.5 Support for the management between the SGP 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 SS7
endpoint/peer is unreachable.
* Provide an indication to the SCCP-user at an ASP that a SS7
endpoint/peer is reachable.
* Provide congestion indication to SCCP-user at an ASP.
* Provide the initiation of an audit of SS7 endpoints at the
SG.
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.
Loughney (editor) [Page 13]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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
To perform its addressing and relaying capabilities, the SUA makes
use of an 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 [2916],
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
hostnames can also be used as Routing Key Information.
It is expected that the routing keys be provisioned via a MIB,
dynamic registration 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 SGP
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
expiry of t(r), the SGP 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
MAY 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
Loughney (editor) [Page 14]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
to management. The treatment of unallocated traffic is
implementation dependent.
1.5.2 Address Mapping at the ASP
To direct messages to the SS7 network, the ASP MUST perform an
address mapping to choose the proper SGP for a given message. This
is accomplished by observing the Destination Point Code and other
elements of the outgoing message, SS7 network status, SGP
availability, and Routing Context configuration tables.
A Signalling 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.
An ASP routes responses to the SGP that it received messages from;
within the routing context which it is currently active and
receiving traffic. The routing context itself is used by the ASP to
select the SGP.
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 yields one
of the following:
- Route on SSN: SCTP association ID towards the destination
node, SSN and optionally Routing Context and/or IP address.
- Route on GT: SCTP association ID towards next relay node,
(new) GT and optionally SSN and/or Routing Context.
- Routing on Hostname: SCTP association ID towards next relay
node, (new) Hostname and optionally SSN and/or Routing
Context.
- A local SUA-user (combined relay/end node)
To prevent looping, an SS7 hop counter is used. The originating end
node (be it an SS7 or an IP node) sets the value of the SS7 hop
counter to the maximum value (15 or less). Each time the relay
function is invoked within an intermediate (relay) node, the SS7 hop
counter is decremented. When the value reaches zero, the return or
refusal procedures are invoked with reason "Hop counter violation".
Loughney (editor) [Page 15]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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 SHOULD use stream 0 for SUA management messages. It is
RECOMMENDED that sequenced delivery be used to preserve the order of
management message delivery.
Stream selection based on protocol class:
- Protocol class 0: SUA SHOULD select unordered delivery.
- Protocol class 1: SUA MUST select ordered delivery within a
stream, based on a sequence parameter given by the upper
layer over the primitive interface.
- Protocol classes 2 and 3: SUA MUST select ordered delivery
within a stream, based on its own source local reference.
1.5.5 Flow Control
Local Management at an ASP may wish to stop traffic across an SCTP
association to temporarily remove the association from service or to
perform testing and maintenance activity. The function could
optionally be used to control the start of traffic on to a newly
available SCTP association.
1.4.6 Congestion Management
The SUA layer is informed of local and IP network congestion by
means of an implementation-dependent function (e.g., an
implementation-dependent indication from the SCTP of IP network
congestion).
At an ASP or IPSP, the SUA layer indicates congestion to local SCCP-
Users by means of an appropriate SCCP primitive (e.g. N-INFORM, N-NOTICE), as
per current SCCP procedures, to invoke appropriate upper layer
responses. When an SG determines that the transport of SS7 messages
is encountering congestion, the SG MAY trigger SS7 SCCP Congestion
messages to originating SS7 nodes, per the congestion procedures of
the relevant SCCP standard. The triggering of SS7 SCCP Management
messages from an SG is an implementation-dependent function.
The SCCP layer at an ASP or IPSP MAY indicate local congestion to an
SUA peer with an SCON message. When an SG receives a congestion
message (SCON) from an ASP, and the SG determines that an endpoint
is now encountering congestion, it MAY trigger congestion procedures
of the relevant SCCP standard.
Loughney (editor) [Page 16]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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)
|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].
Loughney (editor) [Page 17]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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 class, message
type, message length and message contents. This message header is
common among all signalling 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Data |
Note that the 'data' portion of SUA messages SHALL contain SCCP-User
data, not the encapsulated SCCP message.
Optional parameters can only occur at most once in an SUA message.
3.1.1 SUA Protocol Version
The version field (ver) contains the version of the SUA adaptation
layer. The supported versions are:
1 SUA version 1.0
3.1.2 Message Classes
Message Classes
0 SUA Management (MGMT) Message
1 Reserved
2 Signalling 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 Routing Key Management (RKM) Messages.
Loughney (editor) [Page 18]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
10 - 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
Signalling Network Management (SNM) Messages
0 Reserved
1 Destination Unavailable (DUNA)
2 Destination Available (DAVA)
3 Destination State Audit (DAUD)
4 Network Congestion (SCON)
5 Destination User Part Unavailable (DUPU)
6 Destination Restricted (DRST)
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)
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
Routing Key Management (RKM) Messages
0 Reserved
1 Registration Request (REG REQ)
2 Registration Response (REG RSP)
Loughney (editor) [Page 19]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
3 Deregistration Request (DEREG REQ)
4 Deregistration Response (DEREG RSP)
5 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Connectionless (CL) 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 (CO) 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
(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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney (editor) [Page 20]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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 65535.
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
trasnfered 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 Routing Context).
- Mandatory parameters preferably SHOULD precede any optional
parameters.
- 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.
Loughney (editor) [Page 21]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0115 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010e | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SS7 Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0113 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Importance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0114 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0117 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segmentation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
Loughney (editor) [Page 22]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Protocol Class Mandatory
Source Address Mandatory
Destination Address Mandatory
Sequence Control Mandatory
SS7 Hop Count Optional
Importance Optional
Message Priority Optional
Correlation ID Optional
Segmentation Optional
Data Mandatory
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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length = 8 |
Loughney (editor) [Page 23]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SS7 Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0113 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Importance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0114 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
SCCP Cause Mandatory
Source Address Mandatory
Destination Address Mandatory
SS7 Hop Count Optional
Importance Optional
Message Priority Optional
Correlation ID Optional
Data Optional
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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Loughney (editor) [Page 24]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0114 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Sequence Number Mandatory *1
Destination Reference Number Mandatory
Message Priority Optional
Correlation ID Optional
Data Mandatory
NOTE *1: This parameter is not present in case of Expedited Data
(ED).
Implementation note: In order for the CODT to represent DT1, DT2 and
ED messages, the following conditions MUST be met:
DT1 is represented by a CODT when:
Sequence Number parameter is present (contains "more" indicator).
DT2 is represented by a CODT when:
Sequence Number parameter is present (contains P(S), P(R) and more
indicator)
ED is represented by a CODT with:
Sequence Number parameter is not present
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.
Loughney (editor) [Page 25]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0108 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Destination Reference Number Mandatory
Receive Sequence number Mandatory *1
Credit Mandatory *1
NOTE *1: Mandatory when representing Data Acknowledgement (AK).
Implementation note: In order for the CODA to represent DA and EA
messages, the following conditions MUST be met:
DA is represented by a CODA when:
Receive Sequence Number parameter is present (contains P(S), P(R)
and more indicator)
EA is represented by a CODA with:
Sequence Number parameter is not present
3.3.3 Connection Request (CORE)
This message is used for establishing a signalling 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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
Loughney (editor) [Page 26]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0115 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SS7 Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0113 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Importance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0114 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Protocol Class Mandatory
Source Reference Number Mandatory
Destination Address Mandatory
Sequence Number Mandatory
Loughney (editor) [Page 27]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
Source Address Optional
SS7 Hop Count Optional
Importance Optional
Message Priority 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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0115 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0113 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Importance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0114 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney (editor) [Page 28]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Protocol Class Mandatory
Destination Reference Number Mandatory
Source Reference Number Mandatory
Sequence Number Mandatory
Credit Mandatory *2
Importance Optional
Message Priority Optional
Destination Address Optional *1
Data Optional
NOTE *1: Destination Address parameter will be present in case
that the received CORE message conveys the Source
Address parameter.
NOTE *2: Only applicable for protocol class 3.
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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney (editor) [Page 29]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0113 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Importance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Destination Reference Number Mandatory
SCCP Cause Mandatory
Destination Address Optional *1
Importance Optional
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 REFused (CREF).
3.3.6 Release Request (RELRE)
This message is used to request a signalling 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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
Loughney (editor) [Page 30]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0113 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Importance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Destination Reference Number Mandatory
Source Reference Number Mandatory
SCCP Cause Mandatory
Importance Optional
Data Optional
Implementation note: This message covers the following SCCP message:
connection ReLeaSeD (RLSD).
3.3.7 Release Complete (RELCO)
This message is used to acknowledge the release of a signalling
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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0113 | Length = 8 |
Loughney (editor) [Page 31]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Importance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Destination Reference Number Mandatory
Source Reference Number Mandatory
Importance Optional
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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Destination Reference Number Mandatory
Source Reference Number Mandatory
SCCP Cause Mandatory
Implementation note: This message covers the following SCCP message:
ReSet Request (RSR).
3.3.9 Reset Confirm (RESCO)
Loughney (editor) [Page 32]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Destination Reference Number Mandatory
Loughney (editor) [Page 33]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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)
This message is used for auditing the signalling connection state
and the consistency of connection data at both ends of the
signalling 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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0115 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Protocol Class Mandatory
Source Reference Number Mandatory
Destination Reference number Mandatory
Sequence Number Mandatory *1
Credit Mandatory *1
NOTE *1: Information in these parameter fields reflects those
values sent in the last data form 2 or data
Loughney (editor) [Page 34]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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 Signalling Network Management (SNM) 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
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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0118 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String / \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
Destination Address Mandatory *1
SMI Optional
Info String Optional
Loughney (editor) [Page 35]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
Note 1: The destination address refers to the node that has
become unavailable. The Destination Address parameters
MUST include the Affected Point Code and MAY include the
SSN. When the SSN is included in the Destination Address
parameter, the DUNA message corresponds to the SCCP N-
STATE primitive. When SSN is not included in the
Destination Address parameter, the DUNA message
corresponds to the SCCP N-PCSTATE primitive.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0118 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String / \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
Destination Address Mandatory *1
SMI Optional
Info String Optional
Note 1: The destination address refers to the node that has
become unavailable. The Destination Address parameters
Loughney (editor) [Page 36]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
MUST include the Affected Point Code and MAY include the
SSN. When the SSN is included in the Destination Address
parameter, the DAVA message corresponds to the SCCP N-
STATE primitive. When SSN is not included in the
Destination Address parameter, the DAVA message
corresponds to the SCCP N-PCSTATE primitive.
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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0118 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String / \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
Destination Address Mandatory *1
SMI Optional
Info String Optional
Note 1: The destination address refers to the node that has
become unavailable. The Destination Address parameters
MUST include the Affected Point Code and MAY include the
SSN. When the SSN is included in the Destination Address
parameter, the DAUD message corresponds to the SCCP N-
STATE primitive. When SSN is not included in the
Loughney (editor) [Page 37]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
Destination Address parameter, the DAUD message
corresponds to the SCCP N-PCSTATE primitive.
3.4.4 Network Congestion (SCON)
The SCON message can be sent from the SG or relay node 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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000F | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0118 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
Destination Address Mandatory *1
Congestion Level Mandatory
SMI Optional
Info String Optional
Note 1: The destination address refers to the node that has
become unavailable. The Destination Address parameters
MUST include the Affected Point Code and MAY include the
SSN. When the SSN is included in the Destination Address
parameter, the SCON message corresponds to the SCCP N-
STATE primitive. When SSN is not included in the
Destination Address parameter, the SCON message
corresponds to the SCCP N-PCSTATE primitive.
Loughney (editor) [Page 38]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
3.4.5 Destination User Part Unavailable (DUPU)
The DUPU message is used by an SG to inform an ASP that a remote
peer at an SS7 node is unavailable.
The format for DUPU message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010c | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User/Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
Destination Address Mandatory *1
User/Cause Mandatory
SMI Optional
Info String Optional
Note 1: The destination address refers to the node that has
become unavailable. The Destination Address parameters
MUST include the Affected Point Code and MAY include the
SSN. When the SSN is included in the Destination Address
parameter, the DUPU message corresponds to the SCCP N-
STATE primitive. When SSN is not included in the
Destination Address parameter, the DUPU message
corresponds to the SCCP N-PCSTATE primitive.
3.4.5 Destination Restricted (DRST)
Loughney (editor) [Page 39]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
The DRST message is optionally sent from the SG to all concerned
ASPs to indicate that the SG has determined that one or more
destinations are now restricted from the point of view of the SG, or
in response to a DAUD message if appropriate. The SUA layer at the
ASP is expected to send traffic to the affected destination via an
alternate SGP of equal priority, but only if such an alternate route
exists and is available. If the affected destination is currently
considered unavailable by the ASP, the peer should be informed that
traffic to the affected destination can be resumed. In this case,
the SUA layer should route the traffic through the SGP initiating
the DRST message.
This message is optional for the SGP to send and it is optional for
the ASP to act on any information received in the 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 = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
Destination Address Mandatory *1
Info String Optional
Note 1: The destination address refers to the node that has
become unavailable. The Destination Address parameters
MUST include the Affected Point Code and MAY include the
SSN. When the SSN is included in the Destination Address
parameter, the DRST message corresponds to the SCCP N-
STATE primitive. When SSN is not included in the
Destination Address parameter, the DRST message
corresponds to the SCCP N-PCSTATE primitive.
Loughney (editor) [Page 40]
Internet Draft SS7 SCCP-User Adaptation Layer October 5, 2001
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 = 0x0011 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Tag = 0x0109 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String / \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
ASP Identifier Optional *1
Info String Optional
Note 1: ASP Identifier MUST be used where the IPSP/SGP cannot
identify the ASP by pre-configured address/port number
information (e.g., where an ASP is resident on a Host using
dynamic address/port number assignment).
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 = 0x0011 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String / \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
ASP Identifier Optional *1
Info String Optional
Loughney (editor) [Page 41]
Internet Draft |
Documentation