| draft-ietf-sigtran-sua-16 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-16.txt.
INTERNET-DRAFT J. Loughney (Editor)
Internet Engineering Task Force Nokia
G. Sidebottom
gregside Consulting
Issued: December 11, 2003 L. Coene, G. Verwimp
Expires: June 10, 2003 Siemens
J. Keller
Tekelec
B. Bidulock
OpenSS7 Corporation
Signalling Connection Control Part User Adaptation Layer (SUA)
<draft-ietf-sigtran-sua-16.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 April 5, 2003.
Abstract
This Internet Draft defines a protocol for the transport of any
Signalling Connection Control Part-User signalling over IP using the
Stream Control Transmission
Protocol. The protocol is designed to 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.
Internet Draft SUA December 11, 2003
Abstract..............................................................1
1. Introduction.......................................................3
1.1 Scope.............................................................3
1.2 Terminology and Abbreviations.....................................3
1.3 Signalling Transport Architecture.................................6
1.4 Services Provided by the SUA Layer................................8
1.5 Internal Functions Provided in the SUA Layer.....................10
1.6 Definition of SUA Boundaries.....................................13
2 Conventions........................................................18
3 Protocol Elements..................................................18
3.1 Common Message Header............................................18
3.2 SUA Connectionless Messages......................................22
3.3 Connection Oriented Messages.....................................26
3.4 Signalling Network Management (SNM) Messages.....................37
3.5 Application Server Process State Maintenance Messages............43
3.6 ASP Traffic Maintenance Messages.................................46
3.7 SUA Management Messages..........................................49
3.8 Routing Key Management (RKM) Messages............................51
3.9 Common Parameters................................................54
3.10 SUA-Specific parameters.........................................66
4. Procedures........................................................82
4.1 Procedures to Support the SUA-User Layer.........................82
4.2 Receipt of Primitives from the Layer Management..................83
4.3 AS and ASP State Maintenance.....................................85
4.4 Routing Key Management Procedures................................98
4.5 Availability and/or Congestion Status of SS7 Destination Support101
4.6 MTP3 Restart....................................................103
4.7 SCCP - SUA Interworking at the SG...............................104
4.8 NIF Not Available on SGP...............Error! Bookmark not defined.
5 Examples of SUA Procedures........................................106
5.1 SG Architecture.................................................106
5.2 IPSP Examples...................................................107
6 Security Considerations...........................................109
7 IANA Considerations...............................................110
7.1 SCTP Payload Protocol ID........................................110
7.2 Port Number.....................................................110
7.3 Protocol Extensions.............................................110
8 Timer Values......................................................111
9 Acknowledgements..................................................111
10 Authors' Addresses...............................................112
11 References.......................................................113
11.1 Normative......................................................113
11.2 Non-Normative..................................................113
Appendix A Signalling Network Architecture..........................114
A.1 Generalized Peer-to-Peer Network Architecture...................114
A.2 Signalling Gateway Network Architecture.........................115
A.3 Signalling Gateway Message Distribution Recommendations.........116
Loughney (editor) [Page 2]
Internet Draft SUA December 11, 2003
1. Introduction
There is on-going integration of switched circuit networks and IP
networks. Network service providers are designing IP-based
signalling architectures that need 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 is need for interworking between
the SS7 and IP domains [2719].
This draft defines a protocol for the transport SS7 SCCP user-
protocols [ANSI SCCP] [ITU SCCP], such as TCAP and RANAP, over IP
using the Stream Control Transmission Protocol (SCTP) [2960].
1.1 Scope
This document details the delivery of SCCP-user messages (MAP & CAP
over TCAP [ANSI TCAP] [ITU TCAP], RANAP [RANAP], etc.) messages over
IP between two signalling endpoints. Consideration is given for the
transport from a signalling gateway 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
* Support for SCCP connectionless service.
* Support for SCCP connection oriented service.
* Support for the operation of SCCP-User protocol peers.
* Support for the management of SCTP transport associations
between signalling gateways and IP-based signalling nodes.
* Support for distributed IP-based signalling nodes.
* Support for the asynchronous reporting of status changes to
management functions.
1.2 Terminology and Abbreviations
1.2.1 Appreviations
CAP - CAMEL Application Protocol.
GTT - Global Title Translation.
MAP - Mobile Application Protocol.
PC - Signalling System no. 7 Point Code.
RANAP - Radio Access Network Application Protocol.
SCTP - Stream Control Transmission Protocol.
Loughney (editor) [Page 3]
Internet Draft SUA December 11, 2003
SS7 - Signalling System no. 7.
TCAP - Transaction Capabilities Application Protocol.
1.2.2 Terminology
Signalling Gateway (SG) - Network element that terminates switched
circuit networks 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.
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 an 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
Loughney (editor) [Page 4]
Internet Draft SUA December 11, 2003
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 keys MUST NOT span
multiple network appearances.
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
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 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.
Host - The computing platform that the SGP or ASP process is running
on.
Layer Management - Layer Management is a nodal function that handles
the inputs and outputs between the SUA layer and a local management
entity.
Network Appearance - The Network Appearance is an SUA local
reference (typically an integer) shared by SG and AS that together
with a Signalling Point Code uniquely identifies an SS7 node by
indicating the specific SS7 network it belongs to.
Network Byte Order - Most significant byte first, a.k.a. Big Endian.
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.
Loughney (editor) [Page 5]
Internet Draft SUA December 11, 2003
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 switched
circuit networks 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 switched circuit networks 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 to 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.
Interworking between the SCCP and SUA layers is needed to provide
for the transfer of the user messages as well as the management
messages.
******** 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
Loughney (editor) [Page 6]
Internet Draft SUA December 11, 2003
See Appendix A.3.1 for operation recommendations.
1.3.1.1 SG as endpoint
In this case, the connectionless SCCP messages are routed on point
code (PC) and subsystem number (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.
1.3.1.2 Signalling Gateway as relay-point
A Global Title translation is executed at the signalling gateway,
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", from which an Application
Server can be derived. Selection of the Application Server is based
on the SCCP called party address (and possibly other SS7 parameters
depending on the implementation).
1.3.2 Protocol Architecture for Connection-Oriented Transport
In this architecture, the SCCP and SUA layers share an interface in
the signalling gateway process 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 the signalling end point via
signalling gateway process to ASP and visa-versa. The routing of
the Connect Request message is performed in the same way as
described in 1.3.1.
******** SS7 *************** IP ********
* SEP/ *---------* 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)
Loughney (editor) [Page 7]
Internet Draft SUA December 11, 2003
STP - SS7 Signalling Transfer Point
See Appendix A.3.2 for operation recommendations.
1.3.3 All IP Architecture
This architecture can be used to carry a protocol that uses the
transport services of SCCP within an IP network. This allows
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)
1.3.4 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).
For operation recommendations, see Appendix A.
1.4 Services Provided by the SUA Layer
1.4.1 Support for the transport of SCCP-User Messages
The SUA supports the transfer of SCCP-user messages. The SUA layer
at the signalling gateway and at the ASP support the seamless
transport of user messages between the signalling gateway and the
ASP.
Loughney (editor) [Page 8]
Internet Draft SUA December 11, 2003
1.4.2 SCCP Protocol Class Support
Depending upon the SCCP-users supported, the SUA supports 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.
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 (defined in section
3) on receipt of SSP, SSA, SST or SSC (defined by SCCP) to the
appropriate ASPs. See also chapter 1.4.5. The primitives below are
sent between the SCCP and SUA management functions in the SG to
trigger events in the IP and SS7 domain.
Loughney (editor) [Page 9]
Internet Draft SUA December 11, 2003
Generic |Specific |
Name |Name |ANSI/ITU Reference
----------+-----------+---------------------------------------------
N-State |Request |ITU-Q.711 Chap 6.3.2.3.2 (Tab 16/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 1/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 15/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 provides interworking with SCCP management functions
at the SG for interoperation between the switched circuit networks
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.
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.)
Loughney (editor) [Page 10]
Internet Draft SUA December 11, 2003
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 address mapping 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 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 MAY 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;
Loughney (editor) [Page 11]
Internet Draft SUA December 11, 2003
within the routing context which it is currently active and
receiving traffic.
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 and PC or SSN and 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".
1.5.4 SCTP Stream Mapping
The SUA supports SCTP streams. Signalling Gateway SG and Application
Servers need 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 with sequenced delivery.
SUA uses stream 0 for SUA management messages. It is OPTIONAL that
sequenced delivery be used to preserve the order of management
message delivery.
Stream selection based on protocol class:
- Protocol class 0: SUA MAY select unordered delivery. The
stream selected is based on traffic information available
to the SGP or ASP.
- Protocol class 1: SUA MUST select ordered delivery. The
stream selected is based upon the sequence parameter given by
the upper layer over the primitive interface and other
traffic information available to the SGP or ASP
Loughney (editor) [Page 12]
Internet Draft SUA December 11, 2003
- Protocol classes 2 and 3: SUA MUST select ordered delivery.
The stream selected is based upon the source local reference
of the connection and other traffic information available to
the SGP or ASP.
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.5.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 SUA 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.
1.6 Definition of SUA Boundaries
1.6.1 Definition of the upper boundary
The following primitives are supported between the SUA and an SCCP-
user (a reference to ITU and ANSI sections where these primitives
and corresponding parameters are described, is also given):
Loughney (editor) [Page 13]
Internet Draft SUA December 11, 2003
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.2 (Tab 8/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.5 (Tab 6A/T1.112.1)
------------+----------+-------------------------------------------
N-UNITDATA |Request |ITU-Q.711 Chap 6.2.2.3.1 (Tab 12/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 13/Q.711)
| |ANSI-T1.112 Chap 2.2.2.3.2 (Tab 8B/T1.112.1)
------------+----------+--------------------------------------------
N-STATE |Request |ITU-Q.711 Chap 6.3.2.3.2 (Tab 16/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 17/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 15/Q.711)
|Indication|ANSI-T1.112 Chap 2.3.2.3.3 (Tab 8F/T1.112.1)
|Response |
|Confirm |
1.6.2 Definition of the lower boundary
The upper layer primitives provided by the SCTP are provided in
[SCTP].
1.6.3 Definition of the Boundary between SUA and Layer Management
M-SCTP_ESTABLISH request
Direction: LM -> SUA
Loughney (editor) [Page 14]
Internet Draft SUA December 11, 2003
Purpose: LM requests ASP to establish an SCTP association with its
peer.
M-STCP_ESTABLISH confirm
Direction: SUA -> LM
Purpose: ASP confirms to LM that it has established an SCTP
association with its peer.
M-SCTP_ESTABLISH indication
Direction: SUA -> LM
Purpose: SUA informs LM that a remote ASP has established an SCTP
association.
M-SCTP_RELEASE request
Direction: LM -> SUA
Purpose: LM requests ASP to release an SCTP association with its
peer.
M-SCTP_RELEASE confirm
Direction: SUA -> LM
Purpose: ASP confirms to LM that it has released SCTP association
with its peer.
M-SCTP_RELEASE indication
Direction: SUA -> LM
Purpose: SUA informs LM that a remote ASP has released an SCTP
Association or the SCTP association has failed.
M-SCTP RESTART indication
Direction: SUA -> LM
Purpose: SUA informs LM that an SCTP restart indication has been
received.
M-SCTP_STATUS request
Direction: LM -> SUA
Purpose: LM requests SUA to report the status of an SCTP
association.
M-SCTP_STATUS confirm
Direction: SUA -> LM
Purpose: SUA responds with the status of an SCTP association.
M-SCTP STATUS indication
Direction: SUA -> LM
Purpose: SUA reports the status of an SCTP association.
M-ASP_STATUS request
Direction: LM -> SUA
Purpose: LM requests SUA to report the status of a local or remote
ASP.
M-ASP_STATUS confirm
Loughney (editor) [Page 15]
Internet Draft SUA December 11, 2003
Direction: SUA -> LM
Purpose: SUA reports status of local or remote ASP.
M-AS_STATUS request
Direction: LM -> SUA
Purpose: LM requests SUA to report the status of an AS.
M-AS_STATUS confirm
Direction: SUA -> LM
Purpose: SUA reports the status of an AS.
M-NOTIFY indication
Direction: SUA -> LM
Purpose: SUA reports that it has received a Notify message from its
peer.
M-ERROR indication
Direction: SUA -> LM
Purpose: SUA reports that it has received an Error message from its
peer or that a local operation has been unsuccessful.
M-ASP_UP request
Direction: LM -> SUA
Purpose: LM requests ASP to start its operation and send an ASP Up
message to its peer.
M-ASP_UP confirm
Direction: SUA -> LM
Purpose: ASP reports that is has received an ASP UP Ack message
from its peer.
M-ASP_UP indication
Direction: SUA -> LM
Purpose: SUA reports it has successfully processed an incoming ASP
Up message from its peer.
M-ASP_DOWN request
Direction: LM -> SUA
Purpose: LM requests ASP to stop its operation and send an ASP Down
message to its peer.
M-ASP_DOWN confirm
Direction: SUA -> LM
Purpose: ASP reports that is has received an ASP Down Ack message
from its peer.
M-ASP_DOWN indication
Direction: SUA -> LM
Purpose: SUA reports it has successfully processed an incoming ASP
Down message from its peer, or the SCTP association has
been lost/reset.
Loughney (editor) [Page 16]
Internet Draft SUA December 11, 2003
M-ASP_ACTIVE request
Direction: LM -> SUA
Purpose: LM requests ASP to send an ASP Active message to its peer.
M-ASP_ACTIVE confirm
Direction: SUA -> LM
Purpose: ASP reports that is has received an ASP Active Ack message
from its peer.
M-ASP_ACTIVE indication
Direction: SUA -> LM
Purpose: SUA reports it has successfully processed an incoming ASP
Active message from its peer.
M-ASP_INACTIVE request
Direction: LM -> SUA
Purpose: LM requests ASP to send an ASP Inactive message to its
peer.
M-ASP_INACTIVE confirm
Direction: LM -> SUA
Purpose: ASP reports that is has received an ASP Inactive
Ack message from its peer.
M-ASP_INACTIVE indication
Direction: SUA -> LM
Purpose: SUA reports it has successfully processed an incoming ASP
Inactive message from its peer.
M-AS_ACTIVE indication
Direction: SUA -> LM
Purpose: SUA reports that an AS has moved to the AS-ACTIVE state.
M-AS_INACTIVE indication
Direction: SUA -> LM
Purpose: SUA reports that an AS has moved to the AS-INACTIVE state.
M-AS_DOWN indication
Direction: SUA -> LM
Purpose: SUA reports that an AS has moved to the AS-DOWN state.
If the SUA layer supports dynamic registration of Routing Key, the
layer MAY support the following additional primitives:
M-RK_REG request
Direction: LM -> SUA
Purpose: LM requests ASP to register RK(s) with its peer by sending
REG REQ message
M-RK_REG confirm
Direction: SUA -> LM
Loughney (editor) [Page 17]
Internet Draft SUA December 11, 2003
Purpose: ASP reports that it has received REG RSP message with
registration status as successful from its peer.
M-RK_REG indication
Direction: SUA -> LM
Purpose: SUA informs LM that it has successfully processed an
incoming REG REQ message.
M-RK_DEREG request
Direction: LM -> SUA
Purpose: LM requests ASP to deregister RK(s) with its peer by
sending DEREG REQ message.
M-RK_DEREG confirm
Direction: SUA -> LM
Purpose: ASP reports that it has received DEREG RESP message with
deregistration status as successful from its peer.
M-RK_DEREG indication
Direction: SUA -> LM
Purpose: SUA informs LM that it has successfully processed an
incoming DEREG REQ from its peer.
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.
The Reserved field is set to 0 in messages sent and is not to be
examined in messages received.
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:
Loughney (editor) [Page 18]
Internet Draft SUA December 11, 2003
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.
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)
Loughney (editor) [Page 19]
Internet Draft SUA December 11, 2003
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)
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)
Loughney (editor) [Page 20]
Internet Draft SUA December 11, 2003
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. Message Length
is a 32-bit identifier.
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Loughney (editor) [Page 21]
Internet Draft SUA December 11, 2003
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.
3.2.1 Connectionless Data Transfer (CLDT)
This message transfers data between one SUA to another.
Loughney (editor) [Page 22]
Internet Draft SUA December 11, 2003
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 = 0x0116 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SS7 Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0113 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Importance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0114 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0013 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0117 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segmentation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010b | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney (editor) [Page 23]
Internet Draft SUA December 11, 2003
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.
Loughney (editor) [Page 24]
Internet Draft SUA December 11, 2003
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SS7 Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0113 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Importance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0114 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0013 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0117 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segmentation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010b | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
SCCP Cause Mandatory
Source Address Mandatory
Loughney (editor) [Page 25]
Internet Draft SUA December 11, 2003
Destination Address Mandatory
SS7 Hop Count Optional
Importance Optional
Message Priority Optional
Correlation ID Optional
Segmentation 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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0114 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0013 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010b | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Sequence Number Optional *1
Loughney (editor) [Page 26]
Internet Draft SUA December 11, 2003
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)
The peer uses this message to acknowledge receipt of data. 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 = 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 Optional *1
Credit Mandatory *1
Loughney (editor) [Page 27]
Internet Draft SUA December 11, 2003
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 when:
Receive 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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0115 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0116 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney (editor) [Page 28]
Internet Draft SUA December 11, 2003
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SS7 Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0113 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Importance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0114 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010b | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Protocol Class Mandatory
Source Reference Number Mandatory
Destination Address Mandatory
Sequence Control Mandatory
Sequence Number Optional *1
Source Address Optional
SS7 Hop Count Optional
Importance Optional
Message Priority Optional
Credit Optional *1
Data Optional
NOTE *1: Manditory for protocol class 3 only.
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.
Loughney (editor) [Page 29]
Internet Draft SUA December 11, 2003
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 = 0x01116 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0113 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Importance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0114 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010b | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney (editor) [Page 30]
Internet Draft SUA December 11, 2003
Parameters
Routing Context Mandatory
Protocol Class Mandatory
Destination Reference Number Mandatory
Source Reference Number Mandatory
Sequence Control Mandatory
Credit Mandatory *2
Source Address Optional
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.
Loughney (editor) [Page 31]
Internet Draft SUA December 11, 2003
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0113 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Importance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010b | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Mandatory
Destination Reference Number Mandatory
SCCP Cause Mandatory
Source Address Optional
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).
Loughney (editor) [Page 32]
Internet Draft SUA December 11, 2003
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0113 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Importance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010b | 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.
Loughney (editor) [Page 33]
Internet Draft SUA December 11, 2003
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
Loughney (editor) [Page 34]
Internet Draft SUA December 11, 2003
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)
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
Loughney (editor) [Page 35]
Internet Draft SUA December 11, 2003
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
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.
Loughney (editor) [Page 36]
Internet Draft SUA December 11, 2003
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
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
Loughney (editor) [Page 37]
Internet Draft SUA December 11, 2003
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 = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0112 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
Affected Point Code Mandatory *1
SSN Optional *1
SMI Optional
Info String Optional
Note 1: When the SSN is included, the DUNA message
corresponds to the SCCP N-STATE primitive. When SSN
is not, the DUNA message corresponds to the SCCP N-
PCSTATE primitive. When SSN is not, 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
Loughney (editor) [Page 38]
Internet Draft SUA December 11, 2003
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 = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0112 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
Affected Point Code Mandatory *1
SSN Optional *1
SMI Optional
Info String Optional
Note 1: When the SSN is included, the DAVA message corresponds to
the SCCP N-STATE primitive. When SSN is not included, the
DAVA message corresponds to the SCCP N-PCSTATE primitive.
The Affected Point Code can only contain one point code
when SSN is present.
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
Loughney (editor) [Page 39]
Internet Draft SUA December 11, 2003
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 = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010c | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User/Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
Affected Point Code Mandatory *1
SSN Optional *1
User / Cause Optional
Info String Optional
Note 1: If the SSN is present, the DAUD is "soliciting" N-STATE
primitives, otherwise it is "soliciting" N-PCSTATE
primitives.
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.
Loughney (editor) [Page 40]
Internet Draft SUA December 11, 2003
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 = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0118 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0112 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
Affected Point Code Mandatory *1
SSN Optional *1
Congestion Level Mandatory
SMI Optional
Info String Optional
Note 1: When the SSN is included, the SCON message corresponds to
the SCCP N-STATE primitive. When the SSN is not
included, the SCON message corresponds to the SCCP N-
PCSTATE primitive reporting signalling point or network
congestion status.
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:
Loughney (editor) [Page 41]
Internet Draft SUA December 11, 2003
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 = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010c | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User/Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
Affected Point Code Mandatory *1
User/Cause Mandatory
Info String Optional
Note 1: The DUPU corresponds to the SCCP N-PCSTATE primitive.
3.4.6 Destination Restricted (DRST)
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 SG of equal priority, but only if such an alternate route
exists and is available. If the ASP currently considers the affected
destination unavailable, the peer should be informed that traffic to
the affected destination could be resumed. In this case, the SUA
layer should route the traffic through the SG initiating the DRST
message.
This message is optional for the SG 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney (editor) [Page 42]
Internet Draft SUA December 11, 2003
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0112 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SMI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
Affected Point Code Mandatory *1
SSN Optional *1
SMI Optional *1
Info String Optional
Note 1: The Affected Point Code referes to the node to which
become restricted or which has requested coordinated
service outgage. When SSN is included in the message
parameter, the DRST message corresponds to the SCCP N-
COORD primitive. If the SMI parameter is also included
in the message, the DRST message corresponds to the N-
COORD Request and N-COORD Indication primitives,
otherwise, the DRST message corresponse to the N-COORD
Response and N-COORD Confirm primitives. The Affected
Point Code can only contain one point code when SSN is
present. When SSN is not present, DRST corresponds to N-
PCSTATE primitive.
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
Loughney (editor) [Page 43]
Internet Draft SUA December 11, 2003
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
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 = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Info String Optional
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.
|
Documentation