.\" -*- nroff -*-
.\" =========================================================================
.\"
.\" @(#) draft-bidulock-sigtran-tua-00.me,v 0.8 2002/04/02 08:10:26 brian Exp
.\"
.\" -------------------------------------------------------------------------
.\"
.\" Copyright (C) 2002  OpenSS7 Corporation <http://www.openss7.com>
.\"
.\" All Rights Reserved.
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not have
.\" taken the same level of care in the production of this manual, which is
.\" licensed free of charge, as they might when working professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by the
.\" source, must acknowledge the copyright and authors of this work.
.\"
.\" -------------------------------------------------------------------------
.\"
.\" U.S. GOVERNMENT RESTRICTED RIGHTS.  If you are licensing this Software on
.\" behalf of the U.S. Government ("Government"), the following provisions
.\" apply to you.  If the Software is supplied by the Department of Defense
.\" ("DoD"), it is classified as "Commercial Computer Software" under
.\" paragraph 252.227-7014 of the DoD Supplement to the Federal Acquisition
.\" Regulations ("DFARS") (or any successor regulations) and the Government
.\" is acquiring only the license rights granted herein (the license rights
.\" customarily provided to non-Government users).  If the Software is
.\" supplied to any unit or agency of the Government other than DoD, it is
.\" classified as "Restricted Computer Software" and the Government's rights
.\" in the Software are defined in paragraph 52.227-19 of the Federal
.\" Acquisition Regulations ("FAR") (or any success regulations) or, in the
.\" cases of NASA, in paragraph 18.52.227-86 of the NASA Supplement to the
.\" FAR (or any successor regulations).
.\"
.\" -------------------------------------------------------------------------
.\"
.\" SS7preBetaRelease(0.8) modified 2002/04/02 08:10:26 by brian
.\"
.\" =========================================================================
.R1
abbreviate A
label L
no-default-database
no-accumulate
database ../idrefs
annotate X pp
move-punctuation
discard YZ
join-authors ", " ", " ", "
et-al " et all" 1 2
# reverse A
.R2
.de $0
.if \\$3>0 \{\
.if \\$3<4 \{\
.(x 0
.ie '\\$2'' \\$1
.el \\$2 \\$1
.\"'
.)x
.\}
.\}
..
.if '\*(.T'ascii' \{\
.\"'
.fo 'B. Bidulock'Version 0.1'FORMFEED[Page %]'
.ds |x txt
.ds #n <\\**>
.m1 1 \" top margin above header
.m2 1 \" top margin below header
.m3 1 \" btm margin above footer
.m4 0 \" btm margin below footer
.pl 9.8i
.ll 7.2i
.lt 7.2i
.nr PL 9.8i
.nr LL 7.2i
.nr LT 7.2i
.ad l
.hy 0
.ta 3
.ba 0
.po 0
.nr so 0
.nr ii 3n
.nr pi 0n
.nr po 2n
.nr bi 2n
.nr hi 6n
.nr ps 1v
.de #v
.ad l
.hy 0
..
.\}
.if '\*(.T'ps' \{\
.\"'
.fo 'B. Bidulock'Version 0.0'Page %'
.ds |x ps
.ds #n \\**
.m1 0.25i \" top margin above header
.m2 0.25i \" top margin below header
.m3 0.25i \" btm margin above footer
.m4 0.25i \" btm margin below footer
.pl 11.0i
.ll 7.2i
.lt 7.2i
.nr PL 11.0i
.nr LL 7.2i
.nr LT 7.2i
.ad b
.hy 6
.ta 3
.ba 0
.po 0.75i
.nr so 0
.nr ii 0.25i
.nr pi 0.25i
.nr po 0.25i
.nr bi 0.25i
.nr hi 0.5i
.nr pp 10
.nr fp 8
.nr gp 8
.nr sp 12
.nr tp 10
.de #v
.ad b
.hy 6
..
.\}
.dn &a
.dn &b
.dn &n
.dn &p
.nr &a 1
.nr &b 0
.nr &n 1
.nr &p 0
.ds &f Figure\ 
.ds &t Table\ 
.\".de $1
.\".ds &f Figure \\n($1-
.\".nr &n 1
.\".nr &p 0
.\"..
.\".de $2
.\".ds &f Figure \\n($1.\\n($2-
.\".nr &n 1
.\".nr &p 0
.\"..
.\".de $3
.\".ds &f Figure \\n($1.\\n($2.\\n($3-
.\".nr &n 1
.\".nr &p 0
.\"..
.de #f
.(l C F
.sz \n(pp
\fI\\*(&f\\n(&n.\fR  \\$1
.(x 2
\\*(&f\\n(&n \\$1
.)x
.)l
.nr &p \\n(&n
.nr &n +1
..
.de #t
.ce 1
\fI\\*(&t\\n(&a.\fR \\$1
.(x 3
\\*(&t\\n(&a \\$1
.)x
.nr &b \\n(&a
.nr &a +1
..
.de #e
.if \\n($d>1 \{\
.uh "Endnotes for Section \\\\n($1"
.pd
.\}
..
.ds a \a
.bp
.he 'Internet Draft'SS7 TCAP-User Adaptation Layer'January 10, 2002'
.TS
expand tab(;);
l c r.
Network Working Group;;Brian Bidulock
INTERNET-DRAFT;;OpenSS7 Corporation
.bl 2
Expires in six months;;January 10, 2002
.bl 2
.TE
.(l C
\fB\
SS7 TCAP-User Adaptation Layer
TUA
<draft-bidulock-sigtran-tua-00.\*(|x>

.)l
.rr |x
.ne 4
.uh "Status of this Memo"
.pp
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 or 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.
.pp
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'.
.pp
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
.pp
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
.pp
To learn the current status of any Internet-Draft, please check the
\'1id-abstracts.txt\' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
.uh "Abstract"
.pp
This document defines a protocol for the transport of any SS7 TCAP-User
signalling (e.g, INAP, MAP, etc.) over IP using the Stream Control
Transport Protocol.
.[
RFC 2960
.]
The protocol should be modular and symmetric, to allow it to work in
diverse architectures, such as a Signalling Gateway and IP Signalling
End-point architecture.  Protocol elements are added to allow seamless
operation between peers in the SS7 and IP domains.
.sh 1 "Introduction"
.pp
This draft defines a protocol for the transport of SS7 TCAP
.[
q771
.]
.[
t1.114
.]
Users (i.e, MAP, INAP, etc.) signalling messages over IP using the
Stream Control Transmission Protocol (SCTP).
.[
RFC 2960
.]
This protocol would be used between a Signalling Gateway (SG) and
Signalling End-point located in an IP network.  Additionally, the
protocol can be used to transport SS7 TCAP users between two signalling
end-points located within an IP network.
.sh 2 "Scope"
.pp
There is on-going integration of SCN networks and IP networks.  Network
service providers are designing all IP architectures that include
support for SS7 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 a need for interworking between the SS7
and IP domains.
.[
RFC 2719
.]
.pp
This document details the delivery of TC-user messages (MAP, CAP,
INAP, etc.) over IP between two signalling end-points.  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
.[
RFC 2719
.]
This protocol can also support transport of TC-user messages between two
end-points wholly contained within and IP network.
.pp
The delivery mechanism addresses the following criteria:
.bu
Support for transfer of TCAP messages (INAP, MAP, etc.)
.bu
Support for TCAP operation class 1, 2, 3 and 4 operation.
.bu
Support for the seamless operation of TC-User protocol peers.
.bu
Support for the management of SCTP transport associations between an SG
and one ore more IP-based signalling nodes.
.bu
Support for distributed IP-based signalling nodes.
.bu
Support for the asynchronous reporting of status changes to management.
.sh 2 "Terminology"
.lp
\fI\)Application Server (AS)\fR \-
.ix +\n(iiu
a logical entity serving a specific Routing Key.  An example of an Application
Server is a virtual database element handling all HLR or SCP transactions for
a particular SS7 Signalling Point.  The \fI\)AS\fR contains a set of one or
more unique \fI\)Application Server Processes\fR, of which one or more is
normally actively processing traffic.  There is a 1:1 relationship between an
Application Server and a Routing Key.
.lp
\fI\)Application Server Process (ASP)\fR \-
.ix +\n(iiu
a process instance of an Application Server.  An \fI\)Application Server
Process\fR serves as an active, backup, load-share or broadcast 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 HLRs.  An ASP contains an
SCTP end-point and may be configured to process traffic within more that one
\fI\)Application Server\fR.
.lp
\fI\)Association\fR \-
.ix +\n(iiu
refers to an SCTP association.
.[
RFC 2960
.]
The association provides the transport for the delivery of TCAP protocol data
units and TUA layer peer messages.
.ip "\fI\)Component Sub-layer (TC)\fR"
The Component Sub-layer of TCAP.
.[
q771
.]
.lp
\fI\)Fail-over\fR \-
.ix +\n(iiu
the capability to reroute 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.  \fI\)Fail-over\fR may apply upon the return to service of a
previously unavailable Application Server Process.
.lp
\fI\)Host\fR \-
.ix +\n(iiu
the computing platform that the process (SGP, ASP or IPSP) is running on.
.lp
\fI\)IP Server Process (IPSP)\fR \-
.ix +\n(iiu
a process instance of an IP-based application.  An IPSP is essentially the
same as an ASP, except that it uses TUA in a point-to-point fashion.
.lp
\fI\)Layer Management (LM)\fR \-
.ix +\n(iiu
a nodal function that handles the inputs and outputs between the TUA layer and
a local management entity.
.ip "\fI\)Message Transfer Part (MTP)\fR"
The Message Transfer Part
.[
q701
.]
.[
t1.111
.]
of the SS7 protocol.
.lp
\fI\)Nodal Interworking Function (NIF)\fR \-
.ix +\n(iiu
an implementation dependent interworking function present at a Signalling
Gateway that interworks primitives and procedures between the TCAP and TUA
layers in the SG.
.lp
\fI\)Network Appearance (NA)\fR \-
.ix +\n(iiu
a value that identifies the SS7 network context of a Routing Key.
The \fI\)Network Appearance\fR value is of significance only within an
administrative domain; it is coordinated between the SG and ASP.
.lp
\fI\)Network Byte Order\fR \-
.ix +\n(iiu
the ordering of bytes most-significant-byte first, also referred to as
Big Endian.
.lp
\fI\)Routing Context (RC)\fR \-
.ix +\n(iiu
a value that uniquely identifies a Routing Key and an Application Server.
\fI\)Routing Context\fR values are either configured using a configuration
management interface, or by using the Routing Key Management (RKM) messages
and procedures defined for TUA.
.lp
\fI\)Routing Key (RK)\fR \-
.ix +\n(iiu
describes a set of SS7 parameters and parameter values that uniquely
define the range of signalling traffic to be handled by a particular
Application Server.
.lp
\fI\)Signalling Connection Control Part (SCCP)\fR \-
.ix +\n(iiu
The Signalling Connection Control Part
.[
q711
.]
of the SS7 protocol.
.lp
\fI\)Signalling Gateway (SG)\fR \-
.ix +\n(iiu
a signalling agent that exchanges SCN native signalling at the edge of the IP
network.
.[
RFC 2719
.]
An SG appears to the SS7 network as an SS7 Signalling Point.  An SG contains a
set of one or more Signalling Gateway Processes, of which one or more is
normally actively processing traffic.  When 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 both toward the SS7 network and
toward the supported Application Servers.
.lp
\fI\)Signalling Gateway Process (SGP)\fR \-
.ix +\n(iiu
a process instance of a Signalling Gateway.  It serves as an active,
backup, load-sharing or broadcast process of a Signalling Gateway.
.lp
\fI\)Stream\fR \-
.ix +\n(iiu
an SCTP stream; a unidirectional 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
unordered delivery service.
.lp
\fI\)Transaction Capabilities Application Part (TCAP)\fR \-
.ix +\n(iiu
The Transaction Capabilities Application Part
.[
q771
.]
.[
t1.114
.]
of the SS7 protocol.
.lp
\fI\)Transaction Mapping Function (TMF)\fR \-
.ix +\n(iiu
an implementation dependent function that is responsible for resolving
the address and application context presented in the incoming TUA message to
the correct SCTP association and Routing Context for the desired application.
The TMF \fB\)MAY\fR use routing context or routing key information as
selection criteria for the appropriate SCTP association.
.lp
\fI\)Transaction Sublayer (TR)\fR \-
.ix +\n(iiu
The Transaction Sublayer of TCAP.
.[
q771
.]
.lp
\fI\)Transport Address\fR \-
.ix +\n(iiu
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 IP address and an SCTP port
number \*#.
.(d
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR\  Only one SCTP port may be defined for
each endpoint, but each SCTP endpoint may have multiple IP addresses.
.[
RFC 2960
.]
.)d
.sh 2 "TUA Overview"
.sh 3 "Signalling Transport Architecture"
.pp
The framework architecture that has been defined for SCN signalling
transport over IP
.[
RFC 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.
.pp
In general terms, the TUA architecture can be modeled as a peer-to-peer
architecture.  The first section considers the SS7-to-IP interworking
architectures for TCAP class 1, 2, 3, and 4 operations.  For this case, it is
assumed that the ASP initiates the establishment of the SCTP association with
the SG.
.sh 3 "Protocol Architecture for Classes 1, 2, 3 and 4"
.pp
In this architecture (illustrated in \fI\*(&f\n(&n\fR), the TCAP and TUA layers
interface in the SG.  A Nodal Interworking Function (NIF) provides for
interworking between the TCAP and TUA layers and provides for the transfer of
the user messages as well as management messages.
.ie '\*(.T'ps' \{
.\"'
.(z
.so tua01.pic
.#f "Protocol Architecture"
.)z
.\}
.el \{
.(b
.(c
.nf
.sz -2
\fC\)\
.........         ...............        .........
:       :         :             :        :       :
:  SEP  :   SS7   :             :   IP   :       :
:   or  :.........:     SG      :........:  ASP  :
:  STP  :         :             :        :       :
:.......:         :.............:        :.......:
 _______           _____________          _______
|       |         |             |        |       |
| TC-U  |         |     NIF     |        | TC_U  |
|-------|         |------ ------|        |-------|
| TCAP  |         | TCAP |      |        |       |
|-------|         |------| TUA  |        |  TUA  |
| SCCP  |         | SCCP |      |        |       |
|-------|         |------|------|        |-------|
| MTP3  |         | MTP3 |      |        |       |
|-------|         |------| SCTP |        | SCTP  |
| MTP2  |         | MTP2 |      |        |       |
|-------|         |------|------|        |-------|
|  L1   |         |  L1  |  IP  |        |  IP   |
|_______|         |______|______|        |_______|
    |                |       |               |
    |________________|       |_______________|

       TC-U - TCAP-User (e.g. - MAP/INAP)
       STP  - SS7 Signaling Transfer Point
       NIF  - Nodal Interworking Function
.fi
.sz +2
.)c
.#f "Protocol Architecture"
.)b
.\}
.sh 3 "All IP Architecture"
.pp
This architecture, illustrated in \fI\*(&f\n(&n\fR, can be used to carry a
protocol which uses the transport services of TCAP, but is contained within 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 a signalling gateway function.
.ie '\*(.T'ps' \{\
.\"'
.(z
.so tua02.pic
.#f "All IP Architecture"
.)z
.\}
.el \{
.(b
.(c
.nf
.sz -2
\fC\)\
        ........        ........
        :      :   IP   :      :
        :  AS  :........:  AS  :
        :      :        :      :
        :......:        :......:
         ______          ______
        |      |        |      |
        |  AP  |        |  AP  |
        |------|        |------|
        | TUA  |        | TUA  |
        |------|        |------|
        | SCTP |        | SCTP |
        |------|        |------|
        |  IP  |        |  IP  |
        |______|        |______|
           |                |
           |________________|

AP - Application Protocol (e.g. - MAP/INAP)
.sz +2
.)c
.#f "All IP Architecture"
.)b
.\}
.sh 3 "ASP Fail-over Model and Terminology"
.pp
The TUA protocol supports ASP fail-over functions to support a high
availability of transaction processing capability.
.pp
An Application Server can be considered as a list of all ASPs configured or
registered to handled TC-user messages within a certain range of routing
information, or within a certain set of transaction dialogues, 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 ASPs.
.pp
For operational considerations, see Appendix A.
.sh 3 "Services Provided by the TUA Layer"
.sh 4 "Support for the transport of TCAP-User Messages"
.pp
The TUA supports the transfer of TC-user messages.  The TUA layer at
the SG and the ASP support the seamless transport of user messages
between the SG and the ASP.
.sh 5 "TCAP Operation Class Support"
.pp
Depending on the TC-users supported, the TUA shall support the 4
possible TCAP operation classes transparently.  The TCAP operation
classes are defined as follows:
.TS
tab(:);
li1c1lw(4.5i).
Operation Class 1:\-:T{
.#v
provides for transactions reporting both success and failure.
T}
Operation Class 2:\-:T{
.#v
provides for transactions reporting failure.
T}
Operation Class 3:\-:T{
.#v
provides for transactions reporting success.
T}
Operation Class 4:\-:T{
.#v
provides for transactions reporting neither success nor failure.
T}
.TE
.sh 4 "Native Management Functions"
.pp
The TUA layer provides the capability to indicate errors associated with
the TUA-protocol messages and to provide notification to local
management and the remote peer as necessary.
.sh 4 "Interworking with TCAP Management Functions"
.pp
The TUA layer provides interworking with TCAP management functions at the SG
for seamless interoperation between the SCN network and the IP network.  TUA
provides the following management functions:
.np
Provides an indication to the TC-user at an ASP that an SS7 subsystem, SCCP
User Part or MTP Destination is unavailable.
.np
Provides an indication to the TC-user at an ASP that an SS7 subsystem, SCCP
User Part or MTP Destination is available.
.np
Provides an indication to the TC-user at an ASP that an SS7 subsystem or MTP
Destination is congested (flow controlled).
.np
Provides the initiation of an audit of SS7 subsystems or MTP Destinations
status at the SG.
.(z
.#t "Mapping of Management Primitives"
.TS
center box tab(:);
cbs|cbs|cb
cbs|cbs|cb
lb|lb|cb|cb|cb
l|l|n|n|c.
Name:Reference:TUA
_:_:Management
 Generic:Specific:ITU-T Q.711:ANSI T1.112:Message
=
 N-STATE:Request:6.3.2.3.2:2.3.2.3.2:DUNA
:Indication:::DAVA
::::SCON
_
 N-PCSTATE:Indication:6.3.2.3.3:2.3.2.3.4:DUNA
::::DAVA
::::SCON
::::DUPU
_
 N-COORD:Request:6.3.2.3.1:2.3.2.3.3:DRST
:Indication:
:Response:
:Confirm:
.TE
.)z
.pp
The interworking with TCAP management messages consists of DUNA, DAVA, DAUD,
DRST, DUPU or SCON messages on receipt of management events to the appropriate
ASPs.  The primitives in \fI\*(&t\n(&b\fR are sent between the TCAP and TUA
management functions in the SG to trigger events in the IP and SS7 domain.
.pp
The TUA layer provides transparent passing of SCCP availability,
unavailability and congestion status indication primitives (N-STATE, N-PCSTATE
and N-COORD) as provided for in \fI\)ITU-T Q.771 2.2.3\fR.
.[
q771
.]
.sh 4 "Support for the Management of SCTP Associations"
.pp
The TUA layer at the SGP maintains the availability state of all configured
remote ASPs, to manage the SCTP Associations and the traffic between TUA
peers.  As well, the active/inactive and congestion state of remote ASPs is
maintained.
.pp
The TUA layer \fB\)MAY\fR be instructed by local management to establish an
SCTP association to a peer TUA node.  This can be achieved using the
M-SCTP_ESTABLISH primitives to request, indicate and confirm the establishment
of an SCTP association with a peer TUA node.  To avoid redundant SCTP
associations between two TUA peers, one side (client) \fB\)SHOULD\fR be
designated to establish the SCTP association, or TUA configuration information
maintained to detect redundant associations (e.g, via knowledge of the
expected local and remote SCTP endpoint addresses).
.pp
Local management \fB\)MAY\fR request from the TUA layer the status of the
underlying SCTP associations using the M-SCTP_STATUS request and confirm
primitives.  Also, the TUA \fB\)MAY\fR autonomously inform local management of
the reason for the release of an SCTP association, determined either locally
within the TUA layer or by a primitive from the SCTP.
.pp
Also, the TUA layer \fB\)MAY\fR inform the local management of the change in
status of an ASP or AS.  This \fB\)MAY\fR be achieved using the M-ASP_STATUS
request or M-AS_STATUS request primitives.
.sh 2 "Functional Areas"
.sh 3 "Dialogue Identifiers, Routing Contexts and Routing Keys"
.sh 4 "Overview"
.pp
The mapping of TCAP messages into dialogues between the SGP and the
Application Servers is determined by Dialogue Identifiers, Routing Keys and
their associated Routing Contexts.
.pp
A Routing Key is essentially a set of TCAP parameters used to direct TCAP
messages; whereas, the Routing Context parameter is a 4-byte value (unsigned
integer) that is associated to that Routing Key in a 1:1 relationship.  The
Routing Context therefore can be viewed as an index into a sending node's
Transaction Mapping Function tables containing the Routing Key entries.
.pp
Possible TCAP address/routing information that comprise a Routing Key entry
includes, for example, a local and remote Point Code, Subsystem Number, Global
Title Address, Application Context, local and remote Transaction Id pairs, or
TC-User specific information such as User Information, IMSI, SLP.  The
particular information used to define a TUA Routing Key is application and
network dependent, and none of the above examples are requirements for TUA.
.pp
An Application Server Process (ASP) may be configured to process signalling
traffic related to more than one Application Server (AS), over a single SCTP
Association.  ASP Active (ASPAC) and ASP Inactive (ASPIA) management
messages (see Section 3) use the Routing Context to discriminate signalling
traffic to be started or stopped.  At an ASP, the Routing Context parameter
uniquely identifies the range of signalling traffic associated with each
Application Server that the ASP is configured to receive.
.sh 4 "Routing Key Limitations"
.pp
Routing Keys \fB\)SHOULD\fR be unique in the sense that each received TCAP
message \fB\)SHOULD\fR have a full or partial match to a single routing
result.  It is not necessary for the parameter range values within a
particular Routing Key to be continuous.  For example, an AS could be
configured to support transaction processing for multiple ranges of
subscribers that are not represented by contiguous Global Title Addresses.
.sh 4 "Managing Routing Context and Routing Keys"
.pp
There are two ways to provision a Routing Key at an SGP.  A Routing Key may be
configured statically using an implementation dependent management interface,
or dynamically managed using the the TUA Routing Key registration procedures.
.pp
When using a management interface to configure Routing Keys, the Transaction
Mapping Function within the SGP is not limited to the set of parameters
defined in this document.  Other implementation dependent distribution
algorithms may be used.
.sh 4 "Transaction Mapping Function"
.pp
To perform its addressing and relaying capabilities, the TUA makes use of an
Transaction Mapping Function (TMF).  This function is considered part of TUA,
but the way it is realized is left implementation or deployment dependent
(local tables, SCCP GTT database, DNS,
.[
RFC 2916
.]
LDAP, etc.)
.pp
The TMF is invoked when a message is received at the incoming interface.
The TMF is responsible for resolving the application context, address and
transaction ids presented in the incoming TCAP message to SCTP associations
and destinations within the IP network.  The TMF will select the key
information available.  The Routing Keys reference an Application Server,
which will normally have one or more ASPs processing transactions for the AS.  The
availability and status of the ASPs is handled by TUA ASP management messages.
.pp
Possible SS7 application context, address or routing information that comprise
a Routing Key entry includes, for example, SCCP subsystem number and SCCP
addresses and Global Title addresses, Transaction ID, and Application Context.
.\"IP addresses and host names could also be used as Routing Key Information.
.pp
It is expected that the routing keys will be provisioned via a MIB, dynamic
registration or an external process, such as a database.
.sh 5 "Transaction Mapping at the SG"
.pp
To direct messages received from the SS7 network to the appropriate IP
destination, the SGP must perform a transaction mapping function using
information from the received TCAP message.
.pp
To support this transaction mapping, the SGP might, for example, maintain the
equivalent of a network address translation table, mapping incoming TCAP
message information to an Application Server for a particular application and
set of transactions.  This could be accomplished by comparing the addressing,
dialog or component portions of the incoming TCAP message to currently defined
Routing Keys in the SGP.  These Routing Keys could in turn map directly to an
Application Server that is enabled by one or more ASPs.  These ASPs proxy
dynamic status information regarding their availability, transaction handling
capabilities and congestion to the SGP using various management messages
defined in the TUA protocol.
.pp
The list of ASPs in the AS is assumed to be dynamic, taking into account the
availability, transaction handling capability and congestion status of the
individual ASPs in the list, as well as configuration changes and possible
fail-over mechanisms.
.pp
Normally, one or more ASPs are active in the AS (i.e, currently processing
transactions) 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 TCAP abort procedures.
.pp
If there is no match for an incoming message, a default treatment \fB\)MAY\fR
be specified.  Possible solutions are to provide a default Application Server
to direct all unallocated transactions to a (set of) default ASP(s), or to drop the
messages and provide a notification to management.  The treatment of
unallocated transactions is implementation dependent.
.sh 5 "Transaction Mapping at the ASP"
.pp
To direct messages to the SS7 network, the ASP \fB\)MAY\fR perform a
transaction mapping to choose the proper SGP for the given message.  This is
accomplished by observing the Application Context, Destination Address,
Destination Transaction Id, and other elements of the outgoing message, SS7
network status, SGP availability, and Routing Context configuration tables.
.pp
A Signalling Gateway may be composed of one or more SGPs \*#.
.(d
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR  Where more than one route (or SG) is possible
for routing to the SS7 network, the ASP could, for example, maintain a dynamic
table of available SG routes for the SS7 destinations and subsystems,
taking into account the destination and subsystem availability and congestion
status received from the SG(s), the availability status of individual SGs and
configuration changes or fail-over mechanisms.
.)d
There is, however, no TUA 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.
.pp
In general, an ASP routes responses to the SGP that it received messages from;
within the routing context which it is currently active and receiving
transactions.  The routing context itself is used by the ASP to select the
SGP.
.sh 4 "Signalling Gateway SS7 Layers"
.pp
The SG is responsible for terminating up to the TC-user of the SS7 protocol,
and offering an IP-based extension to its users.
.pp
From an SS7 perspective, it is expected that the Signalling Gateway transmits
and receives TCAP messages to and from the SS7 Network over standard SS7
network interfaces, using the services of the SCCP
.[
q.711
.]
and MTP
.[
q.704
.]
to provide transport of the messages.
.pp
Note that it is also possible for the SCCP services to be provided using the
services of the SCCP-User Adaptation Layer (SUA)
.[
sua-09
.]
and the MTP3-User Adaptation Layer (M3UA).
.[
m3ua-10
.]
.pp
The TC-SAP through which TUA at the SG obtains its services could reside at a
Signalling Transfer Point (STP) or Signalling End Point (SEP).
.[
q.705
.]
.\".pp
.\"The TC-SAP through which TUA at the SG obtains it services could also be
.\"transported using an ISO Network Service Protocol, such as X.25, instead of
.\"using the services of the SCCP.  The SG in this case could be associated with
.\"DTE on a packet or Frame Relay network.  Using the services of FoA, the SG
.\"could reside at an ATM node.
.\".pp
.\"The TC-SAP could also reside on an IP host providing ISOT
.\".[
.\"isot
.\".]
.\"or CMOT,
.\".[
.\"cmot
.\".]
.\"or reside at a host providing ISO networking services over Ethernet or ATM
.\"AAL5.
.sh 4 "SS7 and TUA Interworking at the SG"
.pp
The SGP provides a functional interworking of transport functions between the
SS7 network and the IP network by also supporting the TUA adaptation layer.
It allows the TCAP application to exchange  components in dialogues with an
IP-based Application Server Process where the peer TC-User protocol layer
exists.
.pp
To perform TCAP management, it is required that the TC-User protocols at ASPs
receive indications of subsystem availability and congestion, as well as
user part availability and signalling point availability and congestion as
they would be expected by an SS7 TCAP application.  To accomplish this, the
N-PCSTATE, N-STATE and N-COORD primitives received at the TCAP upper layer
interface at the SG need to be propagated to the remote TC-user lower layer
interface at the ASP.
.pp
SCCP management messages (such as SSP, SSA) and MTP management messages (such
as TFP, TFA) received from the SS7 network \fB\)MUST NOT\fR be encapsulated.
The SG \fB\)MUST\fR terminate these messages and generate TUA message as
appropriate.
.sh 4 "Application Server"
.pp
A cluster of Application Servers is responsible for providing the overall
support for one ore more SS7 upper layers.  From an TCAP standpoint, an
Application Part provides complete support for the upper layer service within
a given Application Context.  As an example, an Application Part providing HLR
capabilities could provide complete support for GSM MAP HLR (and any other,
MSC or VLR application parts located at the signalling point) for a given
point code.
.pp
Where an ASP is connected to more than one SG, the TUA layer must maintain
the status of configured SS7 destinations and route messages according to the
availability/congestion status of potentially replicated subsystem.
.sh 4 "SCTP Stream Mapping"
.pp
The TUA supports SCTP streams.  The SG and AS need to maintain a list of SCTP
and TC-Users for mapping purposes.  TC-Users requiring sequenced message
transfer need to be sent over a stream using sequenced delivery.
.pp
TUA \fB\)SHOULD NOT\fR use stream 0 for TUA management messages.  It is
\fB\)OPTIONAL\fR that sequence delivery be used to preserve the order of
management message delivery.
.pp
All TUA Dialogue Handling (DH) messages not using the optional component
handling interface (i.e, DH messages with components included) \fB\)MAY\fR
select unordered delivery, depending on the requirements of the TC-User \*#.
.(d
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR\  When the TC-User selects sequenced delivery
using the "Sequence Control" fields in the Quality of Service parameter, the
DH message \fB\)SHOULD\fR be sent on an SCTP stream using ordered delivery.
When the TC-User does not select sequenced delivery and does not utilize the
optional component handling interface (i.e. the DH message has components
included), the DH message \fB\)MAY\fR be sent on an SCTP stream using
unordered delivery.
.)d
All TUA Component Handling (CH) messages and Dialogue Handling (DH) messages
with external components \fB\)SHOULD\fR select ordered delivery.
.pp
The stream selected is based upon the Sequence Control field in the Quality of
Service parameter, the Dialogue Id given by the TC-User over the primitive
interface and other traffic information available to the SGP or ASP.
.sh 3 "Redundancy Models"
.sh 4 "Application Server Redundancy"
.pp
All TQRY and SSNM messages (e.g, TC-BEGIN, N-STATE) which match a provisioned
Routing Key at an SGP are mapped to an Application Server.
.pp
The Application Server is the set of all ASPs associated with a specific
Routing Key.  Each ASP in this set may be active, inactive or unavailable.
Active ASPs handle traffic; inactive ASPs might be used when active ASPs
become unavailable.
.pp
The fail-over model supports an "n+k" redundancy model, where "n" ASPs is the
minimum number of redundant ASPs required to handle traffic and "k" ASPs are
available to take over for a failed or available ASP.  A "1+1" active/backup
redundancy is a subset of this model.  A simplex "1+0" model is also supported
as a subset, with no ASP redundancy.
.sh 3 "Flow Control"
.pp
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 onto a newly available SCTP association.
.sh 3 " Congestion Management"
.pp
The TUA 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).
.pp
At an ASP or IPSP, the TUA layer indicates congestion to local TC-users by
means of an appropriate TCAP primitive (N-PCSTATE, N-STATE, TC-NOTICE), as per
current TCAP procedures, to invoke appropriate upper layer responses.  When an
SG determines that the transport of SS7 messages is encountering congestion,
the SG might trigger SS7 Congestion messages to originating SS7 nodes, per the
congestion procedures of the relevant SCCP
.[
q711
.]
.[
t1.112
.]
or MTP
.[
q704
.]
.[
t1.111
.]
standard.  (The triggering of SS7 Management messages from an SG is an
implementation-dependent function.)
.sh 2 "Definition of TUA Boundaries"
.pp
TUA has three protocol boundaries: an upper boundary between TUA and the
TC-User; a lower boundary between TUA and SCTP; and a layer management
boundary between TUA and the Layer Management Function.
.\"\fI\*(&f\n(&n\fR illustrates the TUA protocol boundaries.
.ie '\*(.T'ps' \{\
.\"'
.(z
.so tua03.pic
.#f "TUA Protocol Boundaries"
.)z
.\}
.el \{
.(b L
.(c
.nf
.sz -2
\fC\
          ...........
          : TC-User :
          :.........:  Layer
Upper Boundary :       Management
           ____:____   Boundary   ............
          |   TUA   |.............:    LM    :
          |_________|             :..........:
Lower Boundary :
          .....:.....
          :   SCTP  :
          :.........:
.sz +2
.)c
.#f "TUA Protocol Boundaries"
.)b
.\}
.sh 3 "Definition of Upper Boundary"
.pp
The primitives and messages listed in \fI\*(&t\n(&a\fR are provided
between the TUA and TC-User in support of Dialogue Handling.
.[
q771
.]
.[
t1.114
.]
.(b M
.#t "Mapping of Dialogue Handling Primitives"
.TS H
center box tab(:);
lb|lb|cb|cb|cb
lb|lb|cb|cb|cb
l|l|l|l|l.
Generic:Specific:ITU-T Q.771:ANSI T1.114:TUA
Name:Name:Reference:Message:Msg
=
.TH
TC-UNI:Request:3.1.2.2.1:Unidirectional:TUNI
:Indication:::
_
TC-BEGIN:Request:3.1.2.2.2.1:Query w/ Perm:
:Indication:::TQRY
_:_:_:_:
\R\-:\R\-:\R\-:Query w/o Perm:
_
TC-CONTINUE:Request:3.1.2.2.2.2::
(Initial):Indication:::
_:_:_:Conv w/ Perm:
TC-CONTINUE:Request:3.1.2.2.2.3::TCNV
(Non-initial):Indication:::
_:_:_:_:
\R\-:\R\-:\R\-:Conv w/o Perm:
_
TC-END:Request::Response:TRSP
:Indication::
_:_:3.1.2.2.2.4:_:_
TC-U-ABORT:Request::U-Abort:TUAB
:Indication:::
_
TC-P-ABORT:Indication:3.1.4.2:P-Abort:TPAB
_
TC-NOTICE:Indication:3.1.2.2.3:\R\-:TNOT
.TE
.)b
.pp
The primitives and messages listed in \fI\*(&t\n(&a\fR are provided
between the TUA and TC-User in \fB\)OPTIONAL\fR support of Component
Handling.
.[
q771
.]
.[
t1.114
.]
.(b L
.#t "Mapping of Component Handling Primitives"
.TS H
center box tab(:);
lb|lb|cb|cb|cb
lb|lb|cb|cb|cb
l|l|l|l|l.
Generic:Specific:ITU-T Q.771:ANSI T1.114:TUA
Name:Name:Reference:Message:Msg
=
.TH
TC-INVOKE:Request:3.1.3.2:Invoke L:
:Indication:::CINV
_:_:_:_:
\R\-:\R\-:\R\-:Invoke NL:
_
TC-RESULT-L:Request:3.1.3.3:Ret Result L:CRES
TC-RESULT-NL:Indication::Ret Result NL:
_
TC-U-ERROR:Request:3.1.3.4:Ret Error:CERR
:Indication::
_
TC-U-REJECT:Request:3.1.3.5::
:Indication::
_:_:_::
TC-L-REJECT:Request::Reject:CREJ
:Indication:::
_:_:3.1.4.1::
TC-R-REJECT:Request:::
:Indication:::
_
TC-U-CANCEL:Request:3.1.3.6::CCAN
TC-L-CANCEL:Indication::\R\-:
.TE
.)b
.sh 3 "Definition of Boundary between TUA and Layer Management"
.lp
.TS
tab(;);
ls
l1lw(5.7i).
M-SCTP_ESTABLISH request
Direction:;LM->TUA
Purpose:;T{
.#v
LM request ASP to establish an SCTP association with its peer.
T}

.T&
ls
l1lw(5.7i).
M-SCTP_ESTABLISH confirm
Direction:;TUA -> LM
Purpose:;T{
.#v
ASP confirms to LM that it has established an SCTP association with its
peer.
T}

.T&
ls
l1lw(5.7i).
M-SCTP_ESTABLISH indication
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA informs LM that a remote ASP has established an SCTP association.
T}

.T&
ls
l1lw(5.7i).
M-SCTP_RELEASE request
Direction:;LM -> TUA
Purpose:;T{
.#v
LM requests ASP to release an SCTP association with its peer.
T}

.T&
ls
l1lw(5.7i).
M-SCTP_RELEASE confirm
Direction:;TUA -> LM
Purpose:;T{
.#v
ASP confirms to LM that it has released SCTP association with its peer.
T}

.T&
ls
l1lw(5.7i).
M-SCTP_RELEASE indication
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA informs LM that a remote ASP has released an SCTP Association or the
SCTP association
has failed.
T}

.T&
ls
l1lw(5.7i).
M-SCTP RESTART indication
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA informs LM that an SCTP restart indication has been received.
T}

.T&
ls
l1lw(5.7i).
M-SCTP_STATUS request
Direction:;LM -> TUA
Purpose:;T{
.#v
LM requests TUA to report the status of an SCTP association.
T}

.T&
ls
l1lw(5.7i).
M-SCTP_STATUS confirm
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA responds with the status of an SCTP association.
T}

.T&
ls
l1lw(5.7i).
M-SCTP_STATUS indication
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA reports the status of an SCTP association.
T}

.T&
ls
l1lw(5.7i).
M-ASP_STATUS request
Direction:;LM -> TUA
Purpose:;T{
.#v
LM requests TUA to report the status of a local or remote ASP.
T}

.T&
ls
l1lw(5.7i).
M-ASP_STATUS confirm
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA reports status of local or remote ASP.
T}

.T&
ls
l1lw(5.7i).
M-AS_STATUS request
Direction:;LM -> TUA
Purpose:;T{
.#v
LM requests TUA to report the status of an AS.
T}

.T&
ls
l1lw(5.7i).
M-AS_STATUS confirm
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA reports the status of an AS.
T}

.T&
ls
l1lw(5.7i).
M-NOTIFY indication
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA reports that it has received a Notify message from its peer.
T}

.T&
ls
l1lw(5.7i).
M-ERROR indication
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA reports that it has received an Error message from its peer or that
a local operation has been unsuccessful.
T}

.T&
ls
l1lw(5.7i).
M-ASP_UP request
Direction:;LM -> TUA
Purpose:;T{
.#v
LM requests ASP to start its operation and send an ASP Up message to its
peer.
T}

.T&
ls
l1lw(5.7i).
M-ASP_UP confirm
Direction:;TUA -> LM
Purpose:;T{
.#v
ASP reports that is has received an ASP UP Ack message from its peer.
T}

.T&
ls
l1lw(5.7i).
M-ASP_UP indication
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA reports it has successfully processed an incoming ASP Up message
from its peer.
T}

.T&
ls
l1lw(5.7i).
M-ASP_DOWN request
Direction:;LM -> TUA
Purpose:;T{
.#v
LM requests ASP to stop its operation and send an ASP Down message to
its peer.
T}

.T&
ls
l1lw(5.7i).
M-ASP_DOWN confirm
Direction:;TUA -> LM
Purpose:;T{
.#v
ASP reports that is has received an ASP Down Ack message from its peer.
T}

.T&
ls
l1lw(5.7i).
M-ASP_DOWN indication
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA reports it has successfully processed an incoming ASP Down message
from its peer, or the SCTP association has been lost or reset.
T}

.T&
ls
l1lw(5.7i).
M-ASP_ACTIVE request
Direction:;LM -> TUA
Purpose:;T{
.#v
LM requests ASP to send an ASP Active message to its peer.
T}

.T&
ls
l1lw(5.7i).
M-ASP_ACTIVE confirm
Direction:;TUA -> LM
Purpose:;T{
.#v
ASP reports that is has received an ASP Active Ack message from its
peer.
T}

.T&
ls
l1lw(5.7i).
M-ASP_ACTIVE indication
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA reports it has successfully processed an incoming ASP Active message
from its peer.
T}

.T&
ls
l1lw(5.7i).
M-ASP_INACTIVE request
Direction:;LM -> TUA
Purpose:;T{
.#v
LM requests ASP to send an ASP Inactive message to its peer.
T}

.T&
ls
l1lw(5.7i).
M-ASP_INACTIVE confirm
Direction:;LM -> TUA
Purpose:;T{
.#v
ASP reports that is has received an ASP Inactive Ack message from its
peer.
T}

.T&
ls
l1lw(5.7i).
M-ASP_INACTIVE indication
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA reports it has successfully processed an incoming ASP Inactive
message from its peer.
T}

.T&
ls
l1lw(5.7i).
M-AS_ACTIVE indication
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA reports that an AS has moved to the AS-ACTIVE state.
T}

.T&
ls
l1lw(5.7i).
M-AS_INACTIVE indication
Direction:;TUA -> LM
Purpose:;T{
.#v
UA reports that an AS has moved to the AS-INACTIVE state.
T}

.T&
ls
l1lw(5.7i).
M-AS_DOWN indication
Direction:;TUA -> LM
Purpose:;T{
.#v
UA reports that an AS has moved to the AS-DOWN state.
T}

.T&
ls
l1lw(5.7i).
M-RK_REG request
Direction:;LM -> TUA
Purpose:;T{
.#v
LM requests ASP to register RK(s) with its peer by sending REG REQ
message
T}

.T&
ls
l1lw(5.7i).
M-RK_REG confirm
Direction:;TUA -> LM
Purpose:;T{
.#v
ASP reports that it has received REG RSP message with registration
status as successful from its peer.
T}

.T&
ls
l1lw(5.7i).
M-RK_REG indication
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA informs LM that it has successfully processed an incoming REG REQ
message.
T}

.T&
ls
l1lw(5.7i).
M-RK_DEREG request
Direction:;LM -> TUA
Purpose:;T{
.#v
LM requests ASP to deregister RK(s) with its peer by sending DEREG REQ
message.
T}

.T&
ls
l1lw(5.7i).
M-RK_DEREG confirm
Direction:;TUA -> LM
Purpose:;T{
.#v
ASP reports that it has received DEREG REQ message with deregistration
status as successful from its peer.
T}

.T&
ls
l1lw(5.7i).
M-RK_DEREG indication
Direction:;TUA -> LM
Purpose:;T{
.#v
TUA informs LM that it has successfully processed an incoming DEREG REQ
from its peer.
T}
.TE
.sh 3 "Definition of the Lower Boundary"
.lp
The upper layer primitives provided by the SCTP are provided in the SCTP
specification "Stream Control Transmission Protocol (SCTP)".
.[
RFC 2960
.]
.sh 1 "Conventions"
.pp
The keywords \fB\)MUST\fR, \fB\)MUST NOT\fR, \fB\)REQUIRED\fR,
\fB\)SHALL\fR, \fB\)SHALL NOT\fR, \fB\)SHOULD\fR, \fB\)SHOULD NOT\fR,
\fB\)RECOMMENDED\fR, \fB\)NOT RECOMMENDED\fR, \fB\)MAY\fR, and
\fB\)OPTIONAL\fR, when they appear in this document, are to be
interpreted as described in.
.[
RFC 2119
.]
.pp
In this document, the following conventions are used to describe how a
parameter is used in the message:
.ix +2
.TS
tab(:);
lilw(5.0i).
Mandatory:T{
.#v
The parameter \fB\)MUST\fR be present in the message.  A message listing a
parameter as \fI\)Mandatory\fR without containing such a parameter is is
incorrectly formatted.
T}

Conditional:T{
.#v
The parameter \fB\)SHOULD\fR be present in the message under the conditions
specified.  A message listing a parameter as \fI\)Conditional\fR without
containing such a parameter under the conditions specified is incorrectly
formatted.
T}

Optional:T{
.#v
The parameter \fB\)MAY\fR be present in the message as specified.  A message
listing a parameter as \fI\)Optional\fR without containing such a parameter is
correctly formatted.
T}
.TE
.sh 1 "Protocol Elements"
.pp
The general message format includes a Common Message Header together
with a list of zero or more parameters as defined by the Message Type.
.pp
For forward compatibility, all Message Types \fB\)MAY\fR have attached
parameters even if none are specified in this version.
.sh 2 "Common Message Header"
.pp
The protocol messages for the TCAP-User Adaptation Protocol (TUA)
require a message structure that contains a version, message type,
message length and message contents:
.(b
.(c
.nf
.sz -2
\fC\)\
 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                          |
.sz +2
.)c
.)b
.lp
Notes:
.bu
This message header is common among all signalling protocol adaptation
layers.
.bu
The 'data' portion of TUA messages \fB\)SHALL\fR contain zero or more TUA
parameters, and \fB\)SHALL NOT\fR contain an encapsulated TCAP message.
.bu
All fields in the TUA message \fB\)MUST\fR be transmitted in the network
byte order, unless otherwise stated.
.\".lp
.\"Optional parameters can only occur at most once in an TUA message.
.sh 3 "TUA Protocol Version"
.ip "\fB\)Version: 8-bits (unsigned integer)\fR" 2

The \fI\)Version\fR field of the Common Message Header contains the
version of the TUA adaptation layer.  The supported versions are:
.ix +4
.TS
tab(;);
c1l.
1;\- TUA Version 1.0
.TE
.sh 3 "Message Classes"
.ip "Message Class: 8-bits (unsigned integer)\fR" 2

The \fI\)Message Class\fR field of the Common Message Header contains
the class of the message.  The supported classes are as follows:
.TS
tab(;);
n1c1n2l.
0;;;Management (MGMT) Message
7;;;Reserved for Other Signalling Adaptation Layers
2;;;SS7 Signalling Network Management (SSNM) Messages
3;;;ASP State Maintenance (ASPSM) Messages
4;;;ASP Traffic Maintenance (ASPTM) Messages
5;;;TUA Dialogue Handling (DH) Messages
6;;;TUA Component Handling (CH) Messages
7;;;Reserved for Other Signalling Adaptation Layers
8;;;Reserved for Other Signalling Adaptation Layers
9;;;Routing key Management (RKM) Messages
10;-;127;Reserved by the IETF
128;-;255;Reserved for IETF-Defined Message Class Extensions
.TE
.sh 3 "Message Types"
.ip "Message Type: 8-bits (unsigned integer)\fR" 2

The \fI\)Message Type\fR field of the Common Message Header contains the
type of message within a message class.  The supported types of messages
within the supported classes are as follows:
.TS
tab(;);
lsss
n1c1n2l.
Management (MGMT) Messages
0;;;Error (ERR)
1;;;Notify (NTFY)
2;-;127;Reserved by the IETF
128;-;255;Reserved for IETF-Defined Message Class Extensions

.T&
lsss
n1c1n2l.
SS7 Signalling Network Management (SSNM) Messages
0;;;Reserved
1;;;Destination Unavailable (DUNA)
2;;;Destination Available (DAVA)
3;;;Destination State Audit (DAUD)
4;;;Destination 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

.T&
lsss
n1c1n2l.
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

.T&
lsss
n1c1n2l.
Application Server Process Traffic Maintenance (ASPTM) Messages
0;;;Reserved
1;;;ASP Active (ASPAC)
2;;;ASP Inactive (ASPIA)
3;;;ASP Active Ack (ASPAC ACK)
4;;;ASP Inactive Ack (ASPIA ACK)
5;-;127;Reserved by the IETF
128;-;255;Reserved for IETF-Defined Message Class Extensions

.T&
lsss
n1c1n2l.
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

.T&
lsss
n1c1n2l.
TUA Dialogue Handling (DH) Messages
0;;;Unidirectional(TUNI)
1;;;Query (TQRY)
2;;;Conversation (TCNV)
3;;;Response (TRSP)
4;;;U-Abort (TUAB)
5;;;P-Abort (TPAB)
6;;;Notice (TNOT)
7;-;127;Reserved by the IETF
128;-;255;Reserved for IETF-Defined Message Class Extensions

.T&
lsss
n1c1n2l.
TUA Component Handling (CH) Messages
1;;;Invoke (CINV)
2;;;Result (CRES)
3;;;Error (CERR)
4;;;Reject (CREJ)
5;;;Cancel (CCAN)
6;-;127;Reserved by the IETF
128;-;255;Reserved for IETF-Defined Message Class Extensions
.TE
.nr ps 1v
.sh 3 "Message Length"
.ip "\fB\)Message Length: 32-bits (unsigned integer)\fR" 2

The \fI\)Message Length\fR field of the Common Message Header defines
the length of the message in octets, including the header.
.sh 3 "Tag-Length-Value Format"
.pp
TUA messages consist of a Common Message 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 \*#.
.(d
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR\  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:
.ba +\\n(iiu
.np
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,
.np
the data parameter will normally be the final one in the message.
.ba -\\n(iiu
.)d
.(b
.(c
.nf
.sz -2
\fC\)\
 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                         /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b

.ip "\fB\)Parameter Tag: 16-bits (unsigned integer)\fR" 2
The Parameter Tag field is a 16-bit identifier of the type of parameter.  It
takes a value of 0 to 65534.
.ip "\fB\)Parameter Length: 16-bits (unsigned integer)\fR" 2
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.
.ip "\fB\)Parameter Value: variable-length\fR" 2
The Parameter Value field contains the actual information to be transferred in
the parameter.  The total length of a parameter (including Tag, Parameter
Length and Value fields) \fB\)MUST\fR be a multiple of 4 bytes.  If the length
of the parameter is not a multiple of 4 bytes, the sender \fB\)MUST\fR pad the
Parameter at the end (i.e., after the Parameter Value field) with all zero
bytes.  The length of the padding \fB\)MUST NOT\fR be included in the
parameter length field.  A sender \fB\)SHOULD NOT\fR pad with more than 3
bytes.  The receiver \fB\)MUST\fR ignore the padding bytes.
.sh 2 "TUA Message Header"
.pp
In addition to the Common Message Header, a specific message header is
included for TUA messages.  The TUA message header will immediately follow the
Common Message Header in TUA Dialogue Handling (DH) and Component Handling
(CH) messages.
.pp
The \fI\)TUA Message Header\fR is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\)\
 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 = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                        Routing Context                        |
+-------------------------------+-------------------------------+
|         Tag = 0x0013          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                        Correlation Id                         |
+-------------------------------+-------------------------------+
|         Tag = 0x0401          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          Dialogue Id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The TUA Message header can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Routing Context:Conditional:*1
Correlation Id:Conditional:*2
Dialogue Id:Conditional:*3
.TE
.ip "Note 1:" 8
When an ASP is registered or configured for multiple AS with an SG, the
Routing Context \fB\)MUST\fR be present in the TUA Message Header.  The
Routing Context \fB\)SHOULD\fR always be placed in the TUA Message Header.
When the Routing Context is present in the TUA Message Header it
\fB\)SHOULD\fR be placed first in the header because the context of the
Dialogue Id depends on the Routing Context.
.ip "Note 2:" 8
Under some circumstances, the Correlation Id parameter \fB\)MUST\fR be
included in the TUA Message Header.  See sections "Correlation Id" and "ASP
Active Procedures".
.ip "Note 3:" 8
When an AS is handling multiple Dialogues, the Dialogue Id parameter
\fB\)MUST\fR be placed in the TUA Message Header.  The Dialogue Id parameter
\fB\)SHOULD\fR always be placed in the TUA Message Header.  The Dialogue Id
parameter \fB\)MAY\fR be excluded from the TUA header for \fI\)TUNI\fR and
\fI\)TPAB\fR DH messages, or may be included but then \fB\)MUST\fR contain a
value of zero.
.sh 2 "TUA Dialogue Handling (DH) Messages"
.pp
The following section describes the TUA Dialogue Handling (DH) messages and
parameter contents.  The general message format includes a Common Message
Header, the TUA Message Header and the DH Message Header, together with a list
of zero or more parameters as defined by the Message Type.  For forward
compatibility, all Message Types \fB\)MAY\fR have optional attached parameters
in addition to the message headers.
.sh 3 "DH Message Header"
.pp
In addition to the Common Message Header and TUA Message Header, a specific
message header is included for TUA Dialogue Handling (DH) messages.  The DH
Message Header will immediately follow the TUA Message header in these
messages.
.pp
The \fI\)DH Message Header\fR is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0402          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Dialogue Flags                        |
+-------------------------------+-------------------------------+
|         Tag = 0x0403          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                       Quality of Service                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.(b
.pp
The \fI\)DH Message header\fR contains the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Dialogue Flags:Mandatory:
Quality of Service:Mandatory:
.TE
.)b
.sh 3 "Unidirectional (TUNI)"
.pp
The \fI\)Unidirectional (TUNI)\fR Request message is sent from an ASP to an SG
or IPSP to invoke a TCAP class 4 operation.  The \fI\)TUNI\fR Indication
message is sent from an SGP to an ASP to indicate the TCAP class 4 operation.
.pp
The \fI\)TUNI\fR message corresponds to the ITU-T `TC-UNI' primitive,
.[
q771
.]
and the ITU-T and ANSI `Unidirectional' message.
.[
q773
.]
.[
t1.114
.]
.pp
The \fI\)TUNI\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x0404          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                      Destination Address                      /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0405          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                      Originating Address                      /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0406          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                    Application Context Name                   /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0407          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        User Information                       /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0408          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        Security Context                       /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0409          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        Confidentiality                        /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x040E          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Components                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)TUNI\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Destination Address:Conditional:*1
Originating Address:Conditional:*1
Application Context Name:Optional:
User Information:Optional:
Security Context:Optional:
Confidentiality:Optional:
Components:Optional:*2
.TE
.ip "Note 1:" 8
The \fI\)Destination Address\fR or \fI\)Originating Address\fR parameter
\fB\)MUST\fR be present in the \fI\)TUNI\fR message when either parameter is
not implied by the Routing Context in the TUA Message Header.
.ip "Note 2:" 8
Any components \fB\)SHOULD\fR be included in the \fI\)TUNI\fR messages
but \fB\)MAY\fR be formatted in separate TUA Component Handling (CH)
messages.
.sh 3 "Query (TQRY)"
.pp
The \fI\)Query (TQRY)\fR message is sent to a TUA peer to begin a new dialogue
between TC-Users.
.pp
The \fI\)TQRY\fR message corresponds to the ITU-T `TC-BEGIN' primitive,
.[
q771
.]
the ITU-T `Begin' message
.[
q773
.]
and the ANSI `Query' message.
.[
t1.114
.]
.pp
The \fI\)TQRY\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x0410          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Transaction Id                        |
+-------------------------------+-------------------------------+
|         Tag = 0x0404          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                      Destination Address                      /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0405          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                      Originating Address                      /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0406          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                    Application Context Name                   /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0407          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        User Information                       /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0408          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        Security Context                       /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0409          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        Confidentiality                        /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x040E          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Components                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)TQRY\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Transaction Id:Mandatory
Destination Address:Conditional:*1
Originating Address:Conditional:*1
Application Context Name:Optional:
User Information:Optional:
Security Context:Optional:
Confidentiality:Optional:
Components:Optional:*2
.TE
.ip "Note 1:" 8
The \fI\)Destination Address\fR or \fI\)Originating Address\fR parameter
\fB\)MUST\fR be present in the \fI\)TQRY\fR message when the parameter is not
implied by the Routing Context in the TUA Message Header.
.ip "Note 2:" 8
Any components \fB\)SHOULD\fR be included in the \fI\)TQRY\fR messages but
\fB\)MAY\fR be formatted in separate Component Handling (CH) messages.
.sh 3 "Conversation (TCNV)"
.pp
The \fI\)Conversation (TCNV)\fR message is used in response to a \fI\)TQRY\fR
message or another \fI\)TCNV\fR message.
.pp
When sent in response to a \fI\)TQRY\fR message, the \fI\)TCNV\fR message
confirms and continues a dialogue; when in response to a received \fI\)TCNV\fR
message, it only continues a dialogue.  The Dialogue Flags in the DH Message
Header indicate whether the initiator of the \fI\)TCNV\fR message give
permission to the peer to terminate the dialogue.
.pp
The \fI\)TCNV\fR message corresponds to the ITU-T `TC-CONTINUE' primitive,
.[
q771
.]
ITU-T `Continue' message
.[
q773
.]
and the ANSI `Conversation' message.
.[
t1.114
.]
.pp
The \fI\)TCNV\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x0410          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Transaction Id                        |
+-------------------------------+-------------------------------+
|         Tag = 0x0405          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                      Originating Address                      /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0406          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                    Application Context Name                   /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0407          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        User Information                       /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0408          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        Security Context                       /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0409          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        Confidentiality                        /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x040E          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Components                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)TCNV\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Transaction Id:Conditional:*1
Originating Address:Conditional:*2
Application Context Name:Conditional:*3
User Information:Conditional:*3
Security Context:Conditional:*3
Confidentiality:Conditional:*3
Components:Optional:*4
.TE
.ip "Note 1:" 8
The \fI\)Transaction Id\fR parameter \fB\)MUST\fR be present in the
\fB\)TCNV\fR message when the message is sent in response to a \fB\)TQUR\fR
message.  The \fI\)Transaction Id\fR parameter contains the Transaction
Identifier assigned by the remote TC-User.
.ip "Note 2:" 8
The \fI\)Originating Address\fI parameter \fB\)MUST\fR be present in the
\fI\)TCNV\fR message when the message is used in response to a \fI\)TQRY\fR
message and the parameter is not implied by the Routing Context in the TUA
Message Header.
.ip "Note 3:" 8
These dialogue portion parameters \fB\)SHOULD\fR only be optionally included in
the \fI\)TCNV\fR message when the message is used in response to a
\fI\)TQRY\fR message.  When the \fI\)TCNV\fR message is sent in response to a
received \fI\)TCNV\fR message, these parameters \fB\)SHOULD NOT\fR be included
in the responding \fI\)TCNV\fR message.
.ip "Note 4:" 8
Any components \fB\)SHOULD\fR be included in the \fI\)TCNV\fR messages but
\fB\)MAY\fR be formatted in separate Component Handling (CH) messages.
.sh 3 "Response (TRSP)"
.pp
The \fI\)Response (TRSP)\fR message is used in response to a \fI\)TQRY\fR
message or \fI\)TCNV\fR message to complete and existing dialogue.
.pp
When sent in response to a \fI\)TQRY\fR message, the \fI\)TRSP\fR message
confirms and completes a dialogue; when in response to a received \fI\)TCNV\fR
message, it only terminates a dialogue.
.pp
The \fI\)TRSP\fR message corresponds to the ITU-T `TC-END' primitive,
.[
q771
.]
ITU-T `End' message
.[
q773
.]
and the ANSI `Response' message.
.[
t1.114
.]
.pp
The \fI\)TRSP\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x040A          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          Termination                          |
+-------------------------------+-------------------------------+
|         Tag = 0x0406          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                    Application Context Name                   /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0407          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        User Information                       /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0408          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        Security Context                       /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0409          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        Confidentiality                        /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x040E          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Components                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)TRSP\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Termination:Mandatory:
Application Context Name:Optional:*1
User Information:Optional:*1
Security Context:Optional:*1
Confidentiality:Optional:*1
Components:Optional:*2
.TE
.ip "Note 1:" 8
These dialogue portion parameters \fB\)SHOULD\fR only be optionally included
in the \fI\)TRSP\fR message when it is issued in response to an \fI\)TQRY\fR
message.  When the \fI\)TRSP\fR message is in response to a \fI\)TCNV\fR
message, the dialogue portion parameters \fB\)SHOULD NOT\fR be included in the
\fI\)TRSP\fR message.
.ip "Note 2:" 8
Any components \fB\)SHOULD\fR be included in the \fI\)TRSP\fR messages but
\fB\)MAY\fR be formatted in separate TUA Component Handling (CH) messages.
.sh 3 "U-Abort (TUAB)"
.pp
The TUA peer sends an \fI\)U-Abort (TUAB)\fR message when it wishes to abort a
dialogue, either under TUA-user control (TC-U-ABORT).
.pp
When sent in response to a \fI\)TQRY\fR message, the \fI\)TUAB\fR message
negatively confirms and aborts a dialogue; when in response to a received
\fI\)TCNV\fR message, it only aborts a dialogue.
.pp
The \fI\)TUAB\fR message corresponds to the ITU-T `TC-U-ABORT' primitive,
.[
q771
.]
the ITU-T `Abort' message
.[
q773
.]
and the ANSI `Abort' message.
.[
t1.114
.]
.pp
The \fI\)TUAB\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x040D          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Abort Reason                          |
+-------------------------------+-------------------------------+
|         Tag = 0x0405          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                      Originating Address                      /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0406          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                    Application Context Name                   /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0407          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        User Information                       /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)TUAB\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Abort Reason:Mandatory:
Application Context Name:Conditional:*1
User Information:Optional:*2
.TE
.ip "Note 1:" 8
These dialogue portion parameters \fB\)SHOULD\fR only be optionally included
in the \fI\)TUAB\fR message when it is issued in response to an \fI\)TQRY\fR
message.  When the \fI\)TUAB\fR message is in response to a \fI\)TCNV\fR
message, the dialogue portion parameters \fB\)SHOULD NOT\fR be included in the
\fI\)TUAB\fR message.
.ip "Note 2:" 8
The User Information parameter carries any User Abort Information.
.sh 3 "P-Abort (TPAB)"
.pp
The TUA peer sends an \fI\)P-Abort (TPAB)\fR message when it wishes to abort a
dialogue, either under TUA control (TC-P-ABORT).
.pp
The \fI\)TPAB\fR message corresponds to the ITU-T `TC-P-ABORT' primitive,
.[
q771
.]
the ITU-T `Abort' message
.[
q773
.]
and the ANSI `Abort' message.
.[
t1.114
.]
.pp
The \fI\)TPAB\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x040B          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          Abort Cause                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)TPAB\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Abort Cause:Mandatory:
.TE
.sh 3 "Notice (TNOT)"
.pp
An SG sends a \fI\)Notice (TNOT)\fR message when it wishes to inform the ASP
of a network condition that concerns the transmission of TCAP or TUA messages
to the remote TC-User in a dialogue.
.[
q775
.]
It is used at the SG when an SCCP message containing TC-User information from
an AS has been returned in a UDTS when the "Return Option" flag was set in the
Quality of Service parameters when the message was sent.
.pp
The \fI\)TNOT\fR message corresponds to the ITU-T
.[
q771
.]
TC-NOTICE primitive.
.pp
The \fI\)TNOT\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x040C          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          Report Cause                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)TNOT\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Report cause:Mandatory:
.TE
.sh 2 "TUA Component Handling (CH) Messages"
.pp
The following section describes the TUA Component Handling messages and
parameter contents.  The general message format includes a Common Message
Header, a TUA Message Header, a CH Message Header, followed by a list of zero
or more parameters as defined by the Message Type.  For forward compatibility,
all Message Types \fB\)MAY\fR have attached optional parameters in addition to
the message headers.
.pp
Component Handling (CH) messages are used to convey components
associated with operations within a dialogue.  They are issued prior to
the Dialogue Handling (DH) message with which they are associated, but
are received after receiving a Dialogue Handling (DH) message that has
the "Components Present" bit set in the Dialogue Flags parameter within
the DH message.
.sh 3 "CH Message Header"
.pp
In addition to the Common Message Header and TUA Message Header, a specific
message header is included for TUA Component Handling (CH) messages.  The CH
Message Header will immediately follow the TUA Message Header in these
messages.
.pp
The \fI\)CH Message Header\fR if formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0411          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                           Invoke Id                           |
+-------------------------------+-------------------------------+
|         Tag = 0x0412          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                           Linked Id                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)CH Message Header\fR can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Invoke Id:Mandatory:
Linked Id:Optional:
.TE
.sh 3 "Invoke (CINV)"
.pp
The \fI\)Invoke (CINV)\fR message is used to invoke an operation within a
dialogue.
.pp
The \fI\)CINV\fR message corresponds to the ITU-T `TC-INVOKE' primitive,
.[
q771
.]
the ITU-T `Invoke' component,
.[
q773
.]
and the ANSI `Invoke (Last)' and `Invoke (Not Last)' components.
.[
t1.114
.]
.pp
The \fI\)CINV\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0413          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                        Component Flags                        |
+-------------------------------+-------------------------------+
|         Tag = 0x0418          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                            Timeout                            |
+-------------------------------+-------------------------------+
|         Tag = 0x0414          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Operation                           /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0415          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Parameters                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)CINV\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Component Flags:Mandatory:*1
Timeout:Mandatory
Operation:Mandatory:
Parameters:Optional:
.TE
.ip "Note 1:" 8
The Component Flags parameter \fB\)MAY\fR be ignored by the receiver of the
\fI\)CINV\fR message for ITU-T protocol variants of TC-Users that do not
support the concept of a "Not Last" TC-INVOKE primitive.
.sh 3 "Result (CRES)"
.pp
The \fI\)Result (CRES)\fR message is used to report the successful completion
of an operation within a dialogue.
.pp
The \fI\)CRES\fR message corresponds to the ITU-T `TC-RESULT-L' and
`TC-RESULT-NL' primitives,
.[
q771
.]
the ITU-T `Return Result (Last)' and `Return Result (Not Last)'
components
.[
q773
.]
and the ANSI `Return Result (Last)' and `Return Result (Not Last)'
components.
.pp
The \fI\)CRES\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0413          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                        Component Flags                        |
+-------------------------------+-------------------------------+
|         Tag = 0x0414          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Operation                           /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0415          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Parameters                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)CRES\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Component Flags:Mandatory:
Operation:Conditional:*1
Parameters:Optional:
.TE
.ip "Note 1:" 8
The Operation parameter \fB\)MUST\fR be present in the \fB\)CRES\fR message when
the Parameters parameter is also present.
.sh 3 "Error (CERR)"
.pp
The \fI\)Error (CERR)\fR message is used to report the failure of an operation
within a dialogue.
.pp
The \fI\)CERR\fR message corresponds to the ITU-T `TC-U-ERROR' primitive,
.[
q771
.]
the ITU-T `Return Error' component
.[
q773
.]
and the ANSI `Return Error' component.
.[
t1.114
.]
.pp
The \fI\)CERR\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0416          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                             Error                             /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0415          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Parameters                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)CERR\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Error:Mandatory:
Parameters:Conditional:*1
.TE
.ip "Note 1:" 8
The \fI\)Parameters\fR parameter is only included in the message
for specific error codes.
.sh 3 "Reject (CREJ)"
.pp
The \fI\)Reject (CREJ)\fR message is used to reject an operation within
a dialogue.
.pp
The \fI\)CREJ\fR message corresponds to the ITU-T `TC-L-REJECT', `TC-R-REJECT'
and `TC-U-REJECT' primitives,
.[
q771
.]
the ITU-T `Reject' component
.[
q773
.]
and the ANSI `Reject' component.
.[
t1.114
.]
.pp
The \fI\)CREJ\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0417          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                          Problem Code                         /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.(b
.pp
The \fI\)CREJ\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Problem Code:Mandatory:
.TE
.)b
.sh 3 "Cancel (CCAN)"
.pp
The \fI\)Cancel (CCAN)\fR message is used to cancel an operation within
a dialogue.i
.pp
The \fI\)CCAN\fR message corresponds to the ITU-T `TC-L-CANCEL' and
`TC-U-CANCEL' primitives.
.[
q771
.]
.pp
The \fI\)CCAN\fR message presently contains no Message-Type-specific
parameters.
.sh 2 "SS7 Signalling Network Management (SSNM) Messages"
.pp
SS7 Signalling Network Management (SSNM) Messages are used to convey network
management information to the TC-User.  Theses messages correspond to specific
N-STATE, N-PCSTATE and N-COORD primitives.
.sh 3 "Destination Unavailable (DUNA)"
.pp
The \fB\)Destination Unavailable (DUNA)\fR message is sent from an SGP to all
concerned ASPs to indicate the unavailability of an SS7 SCCP subsystem or
signalling point.  The TC-User at the ASP is expected to stop traffic to
TC-User peers at the affected subsystems or signalling points via the SG
initiating the \fB\)DUNA\fR message.
.pp
When the \fB\)DUNA\fR message contains the \fI\)Subsystem Number\fR parameter,
the message corresponds to the ITU-T
.[
q711
.]
and ANSI
.[
t1.112
.]
`N-STATE' primitive.
When the \fB\)DUNA\fR message does not contain the \fI\)Subsystem Number\fR parameter,
message, the message corresponds to the ITU-T
.[
q711
.]
and ANSI
.[
t1.112
.]
`N-PCSTATE' primitive.
.pp
The \fI\)DUNA\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x0419          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Subsystem Number                      |
+-------------------------------+-------------------------------+
|         Tag = 0x041A          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                 Subsystem Multiplicity Indicator              |
+-------------------------------+-------------------------------+
|         Tag = 0x0004          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Info String                         /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)DUNA\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Routing Context:Mandatory
Affected Point Code:Mandatory:
Subsystem Number:Conditional:*1
Subsystem Multiplicity Indicator:Optional:*2
Info String:Optional
.TE
.ip "Note 1:" 8
The \fI\)Subsystem Number\fR parameter \fB\)SHALL\fR be present in the
\fB\)DUNA\fR message when indicating the unavailability of a subsystem, and
\fB\)SHALL NOT\fR be present when indicating the unavailability of a
signalling point.
.ip "Note 2:" 8
The \fI\)Subsystem Multiplicity Indicator\fR parameter \fB\)SHOULD NOT\fR be
present in the \fB\)DUNA\fR message when the \fI\)Subsystem Number\fR
parameter is not also present.
.sh 3 "Destination Available (DAVA)"
.pp
The \fB\)Destination Available (DAVA)\fR message is sent from an SGP to all
concerned ASPs to indicate the availability of an SS7 SCCP Subsystem or
signalling point.  The TC-User at the ASP is expected to resume traffic to
TC-Users peers at the affected subsystems or signalling points via the SG
initiating the \fB\)DAVA\fR message.
.pp
When the \fB\)DAVA\fR message contains the \fI\)Subsystem Number\fR parameter,
the message corresponds to the ITU-T
.[
q711
.]
and ANSI
.[
t1.112
.]
`N-STATE' primitive.
When the \fB\)DAVA\fR message does not contain the \fI\)Subsystem Number\fR parameter,
message, the message corresponds to the ITU-T
.[
q711
.]
and ANSI
.[
t1.112
.]
`N-PCSTATE' primitive.
.pp
The \fI\)DAVA\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x0419          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Subsystem Number                      |
+-------------------------------+-------------------------------+
|         Tag = 0x041A          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                 Subsystem Multiplicity Indicator              |
+-------------------------------+-------------------------------+
|         Tag = 0x0004          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Info String                         /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)DAVA\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Routing Context:Mandatory
Affected Point Code:Mandatory:
Subsystem Number:Conditional:*1
Subsystem Multiplicity Indicator:Optional:*2
Info String:Optional
.TE
.ip "Note 1:" 8
The \fI\)Subsystem Number\fR parameter \fB\)SHALL\fR be present in the
\fB\)DAVA\fR message when indicating the availability of a subsystem, and
\fB\)SHALL NOT\fR be present when indicating the availability of a
signalling point.
.ip "Note 2:" 8
The \fI\)Subsystem Multiplicity Indicator\fR parameter \fB\)SHOULD NOT\fR be
present in the \fB\)DAVA\fR message when the \fI\)Subsystem Number\fR
parameter is not also present.
.sh 3 "Destination State Audit (DAUD)"
.pp
The \fB\)Destination State Audit (DAUD)\fR message is sent from an ASP to an
SG to query the availability state of routes to SS7 SCCP subsystems or
signalling points.  A \fB\)DAUD\fR message \fB\)MAY\fR be sent periodically
after the ASP has received a \fB\)DUNA\fR message, and until a \fB\)DAVA\fR is
received for the affected subsystem or signalling point.  The \fB\)DAUD\fR
message can also be sent when an ASP recovers from isolation from the SG.
.pp
When the \fB\)DAVA\fR message contains the \fI\)Subsystem Number\fR parameter,
the message is soliciting responses that correspond to the ITU-T
.[
q711
.]
and ANSI
.[
t1.112
.]
`N-STATE' primitive.
When the \fB\)DAVA\fR message does not contain the \fI\)Subsystem Number\fR
parameter, message, the message soliciting responses that correspond to the
ITU-T
.[
q711
.]
and ANSI
.[
t1.112
.]
`N-PCSTATE' primitive.
.pp
The \fI\)DAUD\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x0419          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Subsystem Number                      |
+-------------------------------+-------------------------------+
|         Tag = 0x0004          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Info String                         /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)DAUD\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Routing Context:Mandatory
Affected Point Code:Mandatory:
Subsystem Number:Conditional:*1
Info String:Optional
.TE
.ip "Note 1:" 8
The \fI\)Subsystem Number\fR parameter \fB\)SHALL\fR be present in the
\fB\)DAVA\fR message when auditing the status of a subsystem, and
\fB\)SHALL NOT\fR be present when auditing the status of a signalling point.
.sh 3 "Network Congestion (SCON)"
.pp
The \fB\)Network Congestion (SCON)\fR message is sent from an SG to all
concerned ASPs to indicate that the congestion level in the SS7 network to a
specified subsystem or signalling point has changed. The TC-User at the ASP is
expected to stop traffic at the indicated importance level to TC-User peers at
the affected subsystems or signalling points via the SG initiating the
\fB\)SCON\fR message.
.pp
When the \fB\)SCON\fR message contains the \fI\)Subsystem Number\fR parameter,
the message corresponds to the ITU-T
.[
q711
.]
and ANSI
.[
t1.112
.]
`N-STATE' primitive.
When the \fB\)SCON\fR message does not contain the \fI\)Subsystem Number\fR parameter,
message, the message corresponds to the ITU-T
.[
q711
.]
and ANSI
.[
t1.112
.]
`N-PCSTATE' primitive.
.pp
The \fI\)SCON\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x041B          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Congestion Level                      |
+-------------------------------+-------------------------------+
|         Tag = 0x0419          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Subsystem Number                      |
+-------------------------------+-------------------------------+
|         Tag = 0x041A          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                 Subsystem Multiplicity Indicator              |
+-------------------------------+-------------------------------+
|         Tag = 0x0004          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Info String                         /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)SCON\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Routing Context:Mandatory
Affected Point Code:Mandatory:
Congestion Level:Mandatory
Subsystem Number:Optional:*1
Subsystem Multiplicity Indicator:Optional:*2
Info String:Optional
.TE
.ip "Note 1:" 8
The \fI\)Subsystem Number\fR parameter \fB\)SHALL\fR be present in the
\fB\)SCON\fR message when indicating the congestion of a subsystem, and
\fB\)SHALL NOT\fR be present when indicating the congestion of a signalling
point.
.ip "Note 2:" 8
The \fI\)Subsystem Multiplicity Indicator\fR parameter \fB\)SHOULD NOT\fR be
present in the \fB\)SCON\fR message when the \fI\)Subsystem Number\fR
parameter is not also present.
.sh 3 "Destination User Part Unavailable (DUPU)"
.pp
The \fB\)Destination User Part Unavailable (DUPU)\fR message is sent from an SG
to all concerned ASPs to indicate the unavailability of an SS7 SCCP.
.pp
The \fB\)DUPU\fR message corresponds to the ITU
.[
q711
.]
and ANSI
.[
t1.112
.]
`N-PCSTATE' primitive.
.pp
The \fI\)DUPU\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x041C          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                           User/Cause                          |
+-------------------------------+-------------------------------+
|         Tag = 0x0004          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Info String                         /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)DUPU\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Routing Context:Mandatory
Affected Point Code:Mandatory:
User/Cause:Mandatory:*1
Info String:Optional
.TE
.ip "Note 1:" 8
The \fI\)User\fR field of the \fI)User/Cause\fR parameter must indicate an SCCP
MTP-User part and can be ignored by the receiver of the \fB\)DUPU\fR message.
.sh 3 "Destination Restricted (DRST)"
.pp
The \fB\)Destination Restricted (DRST)\fR message is sent from an SG to all
concerned ASPs to indicate one of the following:
.np
A replicated subsystem is requesting that the TUA layer at the ASP accept
transactions for the affected subsystem.  The TUA layer at the ASP is expected
to determine whether it can accept the traffic of the affected subsystem and
respond with a \fB\)DRST\fR message.
.np
An SG representing a signalling transfer point is requesting that the TUA
layer at the ASP routing message traffic via an alternate SG if possible.
.pp
The \fB\)DRST\fR is sent from an ASP to an SG in response to a \fB\)DRST\fR
from the SG when the TUA layer at the ASP is prepared to accept traffic for
the affected subsystem.
.pp
When the \fB\)DRST\fR message contains the \fI\)Subsystem Number\fR parameter,
this message corresponds to the
ITU
.[
q711
.]
and ANSI
.[
t1.112
.]
`N-COORD' primitive.
When the \fB\)DRST\fR message contains the \fI\)Subsystem Multiplicity
Indicator\fR parameter, the message corresponds to the `Request' and
`Indication' forms of the `N-COORD' primitive; when it dos not include the
parameter, it corresponds to the `Response' and `Confirm' forms of the
`N-COORD' primitive.
.pp
When the \fB\)DRST\fR message does not contain the \fI\)Subsystem Number\fR
parameter, the message corresponds to the
ITU
.[
q704
.]
and ANSI
.[
t1.111
.]
`Transfer Restricted' message.
.pp
The \fI\)DRST\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x0419          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Subsystem Number                      |
+-------------------------------+-------------------------------+
|         Tag = 0x041A          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                 Subsystem Multiplicity Indicator              |
+-------------------------------+-------------------------------+
\\                                                               \\
/                           Info String                         /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)DRST\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Routing Context:Mandatory
Affected Point Code:Mandatory:*1
Subsystem Number:Conditional:*2
Subsystem Multiplicity Indicator:Conditional:*3
Info String:Optional
.TE
.ip "Note 1:" 8
The Affected Point Code refers to the node which has become restricted
or which has requested coordinated service outage.
.ip "Note 2:" 8
The \fI\)Subsystem Number\fR parameter \fB\)SHALL\fR be present in the
\fB\)SCON\fR message when requesting or responding to a subsystem coordinated
service outage, and \fB\)SHALL NOT\fR be present when indicating the
restriction of a signalling point.
.ip "Note 3:" 8
The \fI\)Subsystem Multiplicity Indicator\fR parameter \fB\)SHOULD NOT\fR be
present in the \fB\)SCON\fR message when the \fI\)Subsystem Number\fR
parameter is not also present.  The \fI\)Subsystem Multiplicity Indicator\fR
parameter \fB\)SHALL\fR be present in the \fB\)SCON\fR message when requesting
or indicating a coordinated service outage, and \fB\)SHALL NOT\fR be present
when responding to or confirming a coordinated service outage.
.sh 2 "Application Server Process State Maintenance (ASPSM) Messages"
.sh 3 "ASP Up (UP)"
.pp
The \fI\)ASP Up (UP)\fR message is used to indicate to a remote TUA peer
that the Adaptation layer is up and running.
.pp
The \fI\)ASP UP\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)ASP UP\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
ASP Identifier:Conditional:*1
Info String:Optional
.TE
.ip "Note 1:" 8
ASP Identifier \fB\)MUST\fR 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).
.sh 3 "ASP Up Ack (UP ACK)"
.pp
The \fI\)ASP Up Ack (UP ACK)\fR message is used to acknowledge an
\fI\)ASP UP\fR message received from a remote TUA peer.
.pp
The \fI\)ASP UP ACK\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)ASP UP ACK\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Info String:Optional
.TE
.sh 3 "ASP Down (DOWN)"
.pp
The \fI\)ASP Down (DOWN)\fR message is used to indicate to a remote TUA
peer that the adaptation layer is not running.
.pp
The \fI\)ASP DOWN\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)ASP DOWN\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Info String:Optional
.TE
.sh 3 "ASP Down Ack (DOWN ACK)"
.pp
The \fI\)ASP Down Ack (DOWN ACK)\fR message is used to acknowledge an
\fI\)ASP DOWN\fR message received from a remote TUA peer.
.pp
The \fI\)ASP DOWN ACK\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)ASP DOWN ACK\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Info String:Optional
.TE
.ip "Note:" 8
The \fI\)ASP DOWN ACK\fR message will always be sent to acknowledge an
\fI\)ASP DOWN\fR message.
.sh 3 "Heartbeat (BEAT)"
.pp
The \fI\)Heartbeat (BEAT)\fR message is optionally used to ensure that
the TUA peers are still available to each other.
.pp
The \fI\)BEAT\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0009          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                         Heartbeat Data                        /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)BEAT\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Heartbeat Data:Optional
.TE
.sh 3 "Heartbeat Ack (BEAT ACK)"
.pp
The \fI\)Heartbeat ACK (BEAT ACK)\fR message is sent in response to a
\fI\)BEAT\fR message.  A peer \fB\)MUST\fR send a \fI\)BEAT ACK\fR in
response to a \fI\)BEAT\fR message.  It includes all the parameters of
the received \fI\)BEAT\fR message, without any change.
.pp
The \fI\)BEAT ACK\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0009          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                         Heartbeat Data                        /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)BEAT ACK\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Heartbeat Data:Optional
.TE
.sh 2 "Application Server Process Traffic Maintenance (ASPTM) Messages"
.sh 3 "ASP Active (ASPAC)"
.pp
The \fI\)ASP Active (ASPAC)\fR message is sent by an ASP to indicate to
a remote TUA peer that it is Active and ready to process signalling
traffic for a particular Application Server.
.pp
The \fI\)ASPAC\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x000B          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                       Traffic Mode Type                       |
+-------------------------------+-------------------------------+
|         Tag = 0x0004          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                          Info String                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)ASPAC\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Routing Context:Conditional:*1
Traffic Mode Type:Optional:*2
Info String:Optional
.TE
.ip "Note 1:" 8
When an ASP is registered or configured for multiple AS with an SG, the
Routing Context associated with the AS whose activation is being
requested \fB\)MUST\fR be placed in the \fI\)ASPAC\fR message.
.ip "Note 2:" 8
The Traffic Mode Type parameter is not necessary in the \fI\)ASPAC\fR
message when both peers are aware of the traffic mode of the AS by
configuration or registration.
.sh 3 "ASP Active Ack (ASPAC ACK)"
.pp
The \fI\)ASP Active Ack (ASPAC)\fR Ack message is used to acknowledge an
\fI\)ASPAC\fR message received from a remote TUA peer.
.pp
The \fI\)ASPAC ACK\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x000B          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                       Traffic Mode Type                       |
+-------------------------------+-------------------------------+
|         Tag = 0x0004          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                          Info String                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)ASPAC ACK\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Routing Context:Conditional:*1
Traffic Mode Type:Optional:
Info String:Optional:
.TE
.ip "Note 1:" 8
When an ASP is registered or configured for multiple AS with an SG, the
Routing Context associated with the AS whose activation is being
acknowledged \fB\)MUST\fR be placed in the \fI\)ASPAC ACK\fR message.
.sh 3 "ASP Inactive (ASPIA)"
.pp
The \fI\)ASP Inactive (ASPIA)\fR message is sent by an ASP to indicate
to a remote TUA peer that it is no longer processing signalling traffic
within a particular Application Server.
.pp
The \fI\)ASPIA\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Tag = 0x0006          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                       Routing Context                         /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0004          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                          INFO String                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The ASPIA message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Routing Context:Conditional:*1
INFO String:Optional
.TE
.ip "Note 1:" 8
When an ASP is registered or configured for multiple AS with an SG, the
Routing Context associated with the AS whose deactivation is being
requested \fB\)MUST\fR be placed in the \fI\)ASPIA\fR message.
.sh 3 "ASP Inactive Ack (ASPIA ACK)"
.pp
The \fI\)ASP Inactive Ack (ASPIA ACK)\fR message is used to acknowledge
an \fI\)ASPIA\fR message received from a remote TUA peer.
.pp
The \fI\)ASPIA\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Tag = 0x0006          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                       Routing Context                         /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0004          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                          INFO String                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)ASPIA\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Routing Context:Conditional:*1
INFO String:Optional
.TE
.ip "Note 1:" 8
When an ASP is registered or configured for multiple AS with an SG, the
Routing Context associated with the AS whose deactivation is being
acknowledged \fB\)MUST\fR be placed in the \fI\)ASPIA ACK\fR message.
.sh 2 "Management (MGMT) Messages"
.sh 3 "Error (ERR)"
.pp
The \fI\)Error (ERR)\fR message is used by a TUA peer to indicate an
error situation.  \fI\)ERR\fR messages \fB\)MUST NOT\fR be generated in
response to other \fI\)ERR\fR messages.
.pp
The \fI\)ERR\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Tag = 0x000C          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          Error Code                           |
+-------------------------------+-------------------------------+
|         Tag = 0x0006          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                         Routing Context                       /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0012          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                       Affected Point Code                     /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0419          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                        Subsystem Number                       |
+-------------------------------+-------------------------------+
|         Tag = 0x041D          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                       Network Appearance                      |
+-------------------------------+-------------------------------+
|         Tag = 0x0007          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                         Diagnostic Info                       /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)ERR\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Error Code:Mandatory:
Routing Context:Conditional:*1
Affected Point Code:Conditional:*2
Subsystem Number:Conditional:*3
Network Appearance:Conditional:*4
Diagnostic Info:Conditional:*5
.TE
.ip "Note 1:" 8
When the Error Code is "Invalid Routing Context," the Routing Context
parameter \fB\)MUST\fR contain the invalid routing context value(s).
.ip "Note 2:" 8
When the Error Code is "Destination Status Unknown" or "Subsystem Status
Unknown," the Affected Point Code parameter \fB\)MUST\fR contain the
point codes for which status is unknown or unauthorized.
.ip "Note 3:" 8
When the Error Code is "Subsystem Status Unknown," the Subsystem Number
parameter \fB\)MUST\fR contain the subsystem for which status is unknown
or unauthorized.
.ip "Note 4:" 8
When the Error Code is "Invalid Network Appearance," the Network
Appearance parameter \fB\)MUST\fR contains the invalid network
appearance value.
.ip "Note 5:" 8
The Diagnostic Info parameter \fB\)SHOULD\fR contain the first 40 bytes
of the message that caused the ERR message to be sent.
.sh 3 "Notify (NTFY)"
.pp
The Notify message is used to provide an autonomous indication of TUA
events at an SG or IPSP to an ASP.
.pp
The \fI\)NTFY\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 0                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Tag = 0x000D          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                           Status                              |
+-------------------------------+-------------------------------+
|         Tag = 0x0011          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                        ASP Identifier                         |
+-------------------------------+-------------------------------
|         Tag = 0x0006          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                       Routing Context                         /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0004          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                          Info String                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)NTFY\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Status:Mandatory
ASP Identifier:Conditional:*1
Routing Context:Conditional:*2
Info String:Optional
.TE
.ip "Note 1:" 8
ASP Identifier \fB\)MUST\fR 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)
and the Status parameter is set to "Alternate ASP Active" or "ASP
Failure".
.ip "Note 2:" 8
When an ASP is registered or configured for multiple AS with an SG, to
identify the Application Server, the Routing Context associated with the
AS whose state is being notified \fB\)MUST\fR be placed in the
\fI\)NTFY\fR message when the Status parameter is set to
"AS_State_Change".
.sh 2 "Routing Key Management (RKM) Messages"
.pp
\fI\)Routing Key Management (RKM)\fR messages are used to manage the
Routing Keys that are used by an SG to direct traffic toward an
Application Server.
.sh 3 "Registration Request (REG REQ)"
.pp
The \fI\)Registration Request (REG REQ)\fR message is sent by an ASP to
indicate to a remote TUA peer that it wishes to register one or more
given Routing Keys with the remote peer.  Typically, an ASP would send
this message to an SGP, and expects to receive a REG RSP message in
return with an associated Routing Context value.
.pp
The \fI\)REG REQ\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x041E          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                          Routing Key 1                        /
\\                                                               \\
+-------------------------------+-------------------------------+
\\                                                               \\
/                              ...                              /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x041E          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                          Routing Key n                        /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)REG REQ\fR message can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Routing Key:Mandatory:*1
.TE
.ip "Note 1:" 8
One or more Routing Key parameters \fB\)MAY\fR be included in a single
\fI\)REG REQ\fR message.  Whereas it is \fB\)OPTIONAL\fR for an
implementation to be able to generate a \fI\)REG REQ\fR message with
more than one Routing Key parameter, it is \fB\)REQUIRED\fR that the
implementation be able to receive multiple Routing Key parameters in a
single \fI\)REG REQ\fR message.
.sh 3 "Registration Response (REG RSP)"
.pp
The \fI\)Registration Response (REG RSP)\fR message is sent by an SG to
an ASP to indicate the result of a previous \fI\)REG REQ\fR from an ASP.
When successful, the \fI\)REG RSP\fR message contains the Routing
Context assigned to the one or more Routing Keys that were presented in
the \fI\)REG REQ\fI message.
.pp
The \fI\)REG RSP\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x041F          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                     Registration Result 1                     /
\\                                                               \\
+-------------------------------+-------------------------------+
\\                                                               \\
/                              ...                              /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x041F          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                     Registration Result n                     /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)REG RSP\fR message can contain the following parameters:
.pp
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Registration Result:Mandatory:*1
.TE
.ip "Note 1:" 8
\fI\)REG RSP\fR message.  Whereas it is \fB\)OPTIONAL\fR for an
implementation to be able to generate a \fI\)REG RSP\fR message with
more than one Routing Key parameter, it is \fB\)REQUIRED\fR that the
implementation be able to receive multiple Routing Key parameters in a
single \fI\)REG RSP\fR message.
.sh 3 "Deregistration Request (DEREG REQ)"
.pp
The \fI\)Deregistration Request (DEREG REQ)\fR message is sent by an ASP
to indicate to a remote TUA peer that it wishes to deregister a given
Routing Key as identified by the given Routing Context.  Typically, an
ASP would send this message to an SGP, and expects to receive a
\fI\)DEREG RSP\fR message in return with the associated Routing Context
value.
.pp
The \fI\)DEREG REQ\fR message is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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                        /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)DEREG REQ\fR message contains the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Routing Context:Mandatory:*1
.TE
.ip "Note 1:" 8
One or more Routing Context values \fB\)MAY\fR be included in the
Routing Context parameter.  Whereas it is \fB\)OPTIONAL\fR for an
implementation to be able to generate a \fI\)DEREG REQ\fR message with
multiple Routing Context values in the Routing Context parameter, it is
\fB\)REQUIRED\fR that an implementation be able to receive multiple
Routing Context values in the Routing Context parameter of the
\fI\)DEREG REQ\fR message.
.sh 3 "Deregistration Response (DEREG RSP)"
.pp
The \fI\)Deregistration Response (DEREG RSP)\fR message is used as a
response to the \fI\)DEREG REQ\fR message from a remote TUA peer.
.pp
The \fI\)DEREG REQ\fR message is formatted as follows:
.(l I
.(c
.nf
.sz -2
\fC\
 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 = 0x0420          |            Length = 12        |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                   Deregistration Result 1                     |
+-------------------------------+-------------------------------+
\\                                                               \\
/                              ...                              /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0420          |            Length = 12        |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                   Deregistration Result n                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)l
.pp
The \fI\)DEREG REQ\fR message contains the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Deregistration Result:Mandatory:*1
.TE
.ip "Note 1:" 8
One or more Deregistration Result parameters \fB\)MAY\fR be included in
one \fI\)DEREG RSP\fR message.  Whereas it is \fB\)OPTIONAL\fR for an
implementation to be able to generate a \fI\)DEREG RSP\fR message with
multiple Deregistration Result parameters, it is \fB\)REQUIRED\fR that
an implementation be able to receive multiple Deregistration Result
parameters in a single \fI\)DEREG RSP\fR message.
.sh 2 "Common Parameters"
.pp
These TLV parameters are common across the different adaptation layers.
.TS
tab(:);
lb2cbcb
li2cn.
Parameter Name:Parameter ID:Section
=
Reserved:0x0000:\-
Not used in TUA:0x0001:\-
Not used in TUA:0x0002:\-
Not used in TUA:0x0003:\-
Info String:0x0004:3.10.1
Not used in TUA:0x0005:\-
Routing Context:0x0006:3.10.2
Diagnostic Info:0x0007:3.10.3
Not used in TUA:0x0008:\-
Heartbeat Data:0x0009:3.10.4
Not used in TUA:0x000A:\-
Traffic Mode Type:0x000B:3.10.5
Error Code:0x000C:3.10.6
Status:0x000D:3.10.7
Not used in TUA:0x000E:\-
Not used in TUA:0x000F:\-
Not used in TUA:0x0010:\-
ASP Identifier:0x0011:3.10.8
Affected Point Code:0x0012:3.10.9
Correlation Id:0x0013:3.10.12
.TE
.sh 3 "Info String"
.pp
The \fI\)Info String\fR parameter is optionally included in all MGMT,
ASPSM and ASPTM messages to provide additional debugging or diagnostic
information.
.pp
The \fI\)Info String\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Info String\fR parameter contains the following fields:
.ip "\fB\)Info String field: variable (ASCII string)\fR" 2

The \fI\)Info String\fR field can carry any meaningful 8-bit ASCII
character string along with the message.  Length of the Info String
field is from 0 to 255 characters.  No procedures are presently
identified for its use but implementations may use the Info String for
debugging purposes.
.sh 3 "Routing Context"
.pp
The \fI\)Routing Context\fR parameter is included in all TUA SSNM, DH
and CH messages as well as in MGMT, ASPTM, ASPSM that reference one or
more Application Servers.  The \fI\)Routing Context\fR parameter is used
to uniquely identify an Application Server and Routing Key within an
association between an SGP and ASP.
.pp
The \fI\)Routing Context\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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(s)                       /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Routing Context\fR parameter can contain the following fields:
.ip "\fB\)Routing Context field: list of 32-bit (unsigned integer)\fR" 2

The \fI\)Routing Context\fR field contains (a list of) 32-bit unsigned
integers indexing the Application Server traffic that the sending ASP is
configured or registered to receive.  There is 1:1 relationship between
a Routing Context value, an SG Routing Key and an Application Server \*#.
.\"Since an AS can only appear in one Network Appearance, the Network Appearance
.\"parameter is not required in the ASP Active message.
.(d
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR\  An Application Server Process may be
configured to process traffic for more than one logical Application
Server.  From the perspective of an ASP, a Routing Context defines a
range of signalling traffic that the ASP is currently configured to
receive from the SG.

Additionally, the Routing Context parameter identifies the SS7 network
context for the message, for the purposes of logically separating the
signalling traffic between the SGP and the Application Server Process
over a common SCTP Association, when needed.  An example is where an SGP
is logically partitioned to appear as an element in several different
national SS7 networks.  It implicitly defines the SS7 Point Code format
used, the SS7 Network Indicator value and TCAP protocol
type/variant/version used within a separate SS7 network.  It also
defines the network context for the PC and SSN values.  Where an SGP
operates in the context of a single SS7 network, or individual SCTP
associations are dedicated to each SS7 network context, this
functionality is not needed.
.)d
.\"If the Routing Context parameter is present, it \fB\)SHOULD\fR be the first
.\"parameter in the message as it defines the format and/or interpretation of the
.\"parameters containing a PC or SSN value.
.sh 3 "Diagnostic Information"
.pp
The \fI\)Diagnostic Info\fR parameter is used in the MGMT Error (ERR)
message to provide additional information concerning the message that
generated an Error message reply.  The \fI\)Diagnostic Info\fR parameter
\fB\)SHOULD\fR contain the first 40 bytes of the message that generated
the error.
.pp
The \fI\)Diagnostic Info\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Tag = 0x0007          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                         Diagnostic Info                       /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Diagnostic Info\fR parameter contains the following fields:
.ip "\fB\)Diagnostic Info field: variable length (bytes)\fR" 2

The \fI\)Diagnostic Info\fR field can contain any information germane to
the error condition, to assist in the identification of the error
condition.  The Diagnostic Info \fB\)SHOULD\fR be the first 40 bytes of
the offending message.
.sh 3 "Heartbeat Data"
.pp
The \fB\)Heartbeat Data\fR parameter is used in the BEAT and BEAT-Ack
messages and contains whatever information the sender of the BEAT
message chooses to include.  Some uses for the Heartbeat Data parameter
are described in Section 4.
.pp
The \fB\)Heartbeat Data\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0009          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                         Heartbeat Data                        /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fB\)Heartbeat Data\fR parameter contains the following fields:
.ip "\fB\)Heartbeat Data field: variable length (opaque)\fR" 2

The sending node defines the Heartbeat Data field contents.  It may
include a Heartbeat Sequence Number or Time-stamp, or other
implementation specific details.  The receiver of a Heartbeat message
does not process this field as it is only of significance to the sender.
The receiver \fB\)MUST\fR echo the content of the Heartbeat Data in a
BEAT-Ack message.  The data field can be used to store information in
the heartbeat message useful to the sending node (e.g. the data field
can contain a time stamp, a sequence number, etc.).
.sh 3 "Traffic Mode Type"
.pp
The \fI\)Traffic Mode Type\fR parameter indicates the fail-over and
traffic distribution algorithm and procedures that will be used for an
Application Server Process serving an Application Server.  Each
Application Server has associated with it only one Traffic Mode
Type.
.pp
The \fI\)Traffic Mode Type\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Tag = 0x000B          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                       Traffic Mode Type                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Traffic Mode Type\fR parameter contains the following fields:
.ip "\fB\)Traffic Mode Type field: 32-bits (unsigned integer)\fR" 2

The Traffic Mode Type field identifies the traffic mode of operation of
an ASP within an AS.  The valid values for the Traffic Mode Type field
are as follows:
.ix +4
.TS
tab(;);
nl.
1;Override
2;Loadshare
3;Broadcast
.TE
.ix -4

Within a Routing Context, Override, Load-share Types and Broadcast
cannot be mixed.  The Override value indicates that the ASP is operating
in Override mode, and that when the ASP becomes active for the
Application Server, it will take over all traffic for the AS (i.e,
primary/back-up operation), overriding any currently active ASP in the
AS.  In Load-share mode, when the ASP becomes active for the AS, the ASP
will share in the traffic distribution with any other active ASPs.  In
Broadcast mode, when the ASP becomes active for the AS, the ASP will
receive the same traffic as any other active APSs.
.sh 3 "Error Code"
.pp
The \fI\)Error Code\fR parameter is used in the Error (ERR) message to
indicate the reason that the ERR message was generated and, along with
the other parameters in the Error message, help to locate the problem
that generated the error condition.
.pp
The \fI\)Error Code\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Tag = 0x000C          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          Error Code                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Error Code\fR parameter contains the following fields:
.ip "\fB\)Error Code field: 32-bit (unsigned integer)\fR" 2

The \fI\)Error Code\fR field indicates the reason for the Error Message.
The Error Code field value can be one of the following values:
.ix +4
.TS
tab(:);
nl.
1:Invalid Version
3:Unsupported Message Class
4:Unsupported Message Type
5:Unsupported Traffic Handling Mode
6:Unexpected Message
7:Protocol Error
9:Invalid Stream Identifier
13:Refused - Management Blocking
14:ASP Identifier Required
15:Invalid ASP Identifier
17:Invalid Parameter Value
18:Parameter Field Error
19:Unexpected Parameter
20:Destination Status Unknown
21:Invalid Network Appearance
22:No configured AS for ASP
23:Invalid Routing Context
24:Subsystem Status Unknown
.TE
.pp
The "Invalid Version" error is sent if a message was received with an invalid
or unsupported version.  The Error message contains the supported version in
the Common header.  The Error message could optionally provide the supported
version in the Diagnostic parameter.
.pp
The "Unsupported Message Class" error is sent if a message with an unexpected
or unsupported Message Class is received.
.pp
The "Unsupported Message Type" error is sent if a message with an unexpected
or unsupported Message Type is received.
.pp
The "Unsupported Traffic Handling Mode" error is sent by a SGP if an ASP sends
an ASP Active message with an unsupported Traffic Mode Type or a Traffic Mode
Type that is inconsistent with the presently configured mode for the
Application Server.  An example would be a case in which the SGP did not
support load-sharing.
.pp
The "Unexpected Message" error \fB\)MAY\fR be sent if a defined and recognized
message is received that is not expected in the current state (in some cases
the ASP may optionally silently discard the message and not send an Error
message).  For example, silent discard is used by an ASP if it received a DATA
message from an SGP while it was in the ASP-INACTIVE state.  If the Unexpected
message contained Routing Context(s), the Routing Context(s) \fB\)SHOULD\fR be
included in the Error message.
.pp
The "Protocol Error" error is sent for any protocol anomaly (i.e., reception
of a parameter that is syntactically correct but unexpected in the current
situation.
.pp
The "Invalid Stream Identifier" error is sent if a message is received on an
unexpected SCTP stream (e.g, a Management message was received on a stream
other than "0", or a Data message was received on stream "0").
.pp
The "Refused - Management Blocking" error is sent when an ASP Up or ASP Active
message is received and the request is refused for management reasons (e.g,
management lockout").  If this error is in response to an ASP Active message,
the Routing Context(s) in the ASP Active message \fB\)SHOULD\fR be included in
the Error message.
.pp
The "ASP Identifier Required" is sent by a SGP in response to an ASP Up
message which does not contain an ASP Identifier parameter when the SGP
requires one.  The ASP \fB\)SHOULD\fR resend the ASP Up message with an ASP
Identifier.
.pp
The "Invalid ASP Identifier" is send by a SGP in response to an ASP Up message
with an invalid (i.e., non-unique) ASP Identifier.
.pp
The "Invalid Parameter Value" error is sent if a message is received with an
invalid parameter value (e.g, a DUPU message was received with a Mask value
other than "0").
.pp
The "Parameter Field Error" would be sent if a message is received with a
parameter having a wrong length field.
.pp
The "Unexpected Parameter" error would be sent if a message contains an
invalid parameter.
.pp
The "Destination Status Unknown" Error \fB\)MAY\fR be sent if a DAUD is
received at an SG inquiring of the availability or congestion status of a
destination, and the SG does not wish to provide the status (e.g, the sender
is not authorized to know the status).  For this error, the invalid or
unauthorized Point Code(s) \fB\)MUST\fR be included along with any Network
Appearance or Routing Context associated with the Point Code(s) from the DAUD
message.
.pp
The "Invalid Network Appearance" error is sent by a SGP if an ASP sends a
message with an invalid (unconfigured) Network Appearance value.  For this
error, the invalid (unconfigured) Network Appearance \fB\)MUST\fR be included
in the Network Appearance parameter in the Error message.
.pp
The "No Configured AS for ASP" error is sent if a message is received from a
peer without a Routing Context parameter and it is not known by configuration
data which Application Servers are referenced.
.pp
The "Invalid Routing Context" error is sent if a message is received from a
peer with an invalid (unconfigured) Routing Context value, or if a message is
received from a peer without a Routing Context parameter and it is not known
by configuration data which Application Servers are referenced.  For this
error, the invalid Routing Context(s) \fB\)MUST\fR be included in the Error
message.
.pp
The "Subsystem Status Unknown" Error \fB\)MAY\fR be sent if a DAUD is received
at an SG inquiring of the availability or congestion status of a subsystem,
and the SG does not wish to provide the status (e.g, the sender is not
authorized to know the status).  For this error, the invalid or unauthorized
Point Code and Subsystem Number \fB\)MUST\fR be included along with any
Network Appearance or Routing Context associated with the Point Code and
Subsystem Number from the DAUD message.
.sh 3 "Status"
.pp
The Status parameter identifies the type of the status that is being
notified in a Notify (NTFY) message and the Status ID.
.pp
The \fI\)Status\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Tag = 0x000D          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|         Status Type           |            Status ID          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Status\fR parameter contains the following fields:
.ip "\fB\)Status Type field: 16-bits (unsigned integer)\fR" 2

The valid values for Status Type field are as follows:
.ix +4
.TS
tab(;);
nl.
1;Application Server state change (AS_State_Change)
2;Other
.TE
.ix -4
.ip "\fB\)Status ID field: 16-bits (unsigned integer)\fR" 2

The Status ID parameter contains more detailed information for the
notification, based on the value of the Status Type.
.ba +1n
.np
If the Status Type is "AS_State_Change", then the Status ID values are
as follows:
.ix +4
.TS
tab(;);
nl.
1;reserved
2;Application Server Inactive (AS-Inactive)
3;Application Server Active (AS-Active)
4;Application Server Pending (AS-Pending)
.TE
.ix -4

These notifications are sent from an SGP to an ASP upon a change in
status of a particular Application Server.  The value reflects the new
state of the Application Server.
.np
If the Status Type is "Other", then the following Status Information
values are defined:
.ix +4
.TS
tab(;);
nl.
1;Insufficient ASP resources active in AS
2;Alternate ASP Active
3;ASP failure
.TE
.ix -4

These notifications are not based on the SGP reporting the state change
of an ASP or AS.  In the Insufficient ASP Resources case, the SGP is
indicating to an "Inactive" ASP(s) in the AS that another ASP is
required to handle the load of the AS (Load-sharing mode or Broadcast
mode).  For the Alternate ASP Active case, an ASP is informed when an
alternate ASP transitions to the ASP-Active state in Override mode.
.ba -1n
.sh 3 "ASP Identifier"
.pp
The \fI\)ASP Identifier\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                        ASP Identifier                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)ASP Identifier\fR parameter contains the following fields:
.ip "\fB\)ASP Identifier field: 32-bits (unsigned integer)\fR" 2

The ASP Identifier field contains a unique value that is locally
significant among the ASPs that support an AS.  The SGP should save the
ASP Identifier to be used, if necessary, with the Notify message (see
Section 3.7.2).
.pp
The optional ASP Identifier parameter would contain a unique value that
is locally significant among the ASPs that support an AS.  The SGP
should save the ASP Identifier to be used, if necessary, with the Notify
message (see Section 3.3.3.2).
.sh 3 "Affected Point Code"
.pp
The \fI\)Affected Point Code\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0012          |            Length             |
+- - - - - - - -+- - - - - - - -+- - - - - - - - - - - - - - - -+
|     Mask      |             Affected Point Code 1             |
+- - - - - - - -+- - - - - - - - - - - - - - - - - - - - - - - -+
\\                                                               \\
/                              ...                              /
\\                                                               \\
+- - - - - - - -+- - - - - - - - - - - - - - - - - - - - - - - -+
|     Mask      |             Affected Point Code n             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Affected Point Code\fR parameter contains the following fields:
.ip "\fB\)Affected Destination Point Code field: n x 32-bits\fR" 2

The \fI\)Affected Point Code\fR parameter contains a list of one or more
Affected Destination Point Code fields.  It is \fB\)OPTIONAL\fR to
generate an Affected Point Code parameter with more than one Affected
Destination Point Code field, but it is \fB\)REQUIRED\fR to accept it.
.pp
Each Affected Destination Point Code field in the list contains the
following fields:
.ip "\fB\)Affected Point Code field: 24-bits (unsigned integer)\fR" 2

Each Affected Point Code field is a three-octet field to allow for up to
24-bit binary formatted SS7 Point Codes.  Affected Point Codes that are
less than 24-bits are padded on the left to the 24-bit boundary.  The
following examples show ANSI and ITU-T point codes:
.ba +2
.ip "\fI\)ANSI 24-bit Point Code:\fR" 2
.(b L
.nf
.sz -2
\fC\
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Mask      |    Network    |    Cluster    |     Member    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |MSB-----------------------------------------LSB|
.)b
.ip "\fI\)ITU-T 14-bit Point Code:\fR" 2
.(b L
.nf
.sz -2
\fC\
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Mask      |0 0 0 0 0 0 0 0 0 0|Zone |     Region    | SP  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |MSB---------------------LSB|
.)b
.ba -2
.ip "\fB\)Mask field: 8-bits (unsigned integer)\fR" 2

The Mask parameter can be used to identify a contiguous range of
Affected Point Codes, independent of the point code format.  Identifying
a contiguous range of Affected Point Codes may be useful when a
management event simultaneously affects the status of a series of
destinations at an SG.

The Mask parameter is an integer representing a bit mask that can be
applied to the related Affected PC field.  The bit mask identifies how
many bits of the Affected PC field are significant and which are
effectively "wild-carded".  For example, a mask of "8" indicates that
the last eight bits of the PC is "wild-carded".  For an ANSI 24-bit
Affected PC, this is equivalent to signalling that all PCs in an ANSI
Cluster are unavailable.  A mask of "3" indicates that the last 3 bits
of the PC is "wild-carded".  For a 14-bit ITU Affected PC, this is
equivalent to signalling that an ITU Region is unavailable.

A Mask value equal (or greater than) the number of bits in the Point
Code indicates that the entire network access is affected: this is used
to indicate network isolation to the ASP.
.sh 3 "Correlation Id"
.pp
The \fI\)Correlation Id\fR parameter is used to tag messages sent to an
ASP in a Broadcast group as well as during fail-over.
.pp
The \fI\)Correlation Id\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0013          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Correlation Id                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Correlation Id\fR parameter can contain the following fields:
.ip "\fB\)Correlation Id field: 32-bits (unsigned integer)\fR" 2

The \fI\)Correlation Id\fR field contains a Correlation Id.  The
Correlation Id is a 32-bit identifier that is attached to the TUA
Message Header to indicate to a newly entering ASP in a Broadcast AS
where in the traffic flow of TUA messages the ASP is joining.  It is
attached to the TUA Message Header of the first DH or CH message sent to
an ASP by an SG after sending an ASP Active Ack or otherwise starting
traffic to an ASP.  The Correlation Id is only significant within a
Routing Context \*#.
.(d
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR\  Correlation Id parameter can be used for
features like Synchronization of ASPs and SGPs in a Broadcast Mode AS or
SG; avoid message duplication and mis-sequencing in case of fail-over of
association from one ASP or SGP to another ASP or SGP, etc.
.)d
.sh 2 "TUA-Specific parameters"
.pp
These TLV parameters are specific to the TUA protocol.
.TS
tab(:);
liss
lb2cb2cb
lcc.
Parameters used in DH Messages
_
Parameter Name:Parameter ID:Section
_
Dialogue Id:0x0401:3.11.1.1
Dialogue Flags:0x0402:3.11.1.2
Quality of Service:0x0403:3.11.1.3
Destination Address:0x0404:3.11.1.4
Originating Address:0x0405:3.11.1.5
Application Context Name:0x0406:3.11.1.6
User Information:0x0407:3.11.1.7
Security Context:0x0408:3.11.1.8
Confidentiality:0x0409:3.11.1.9
Termination:0x040A:3.11.1.10
Abort Cause:0x040B:3.11.1.11
Report Cause:0x040C:3.11.1.12
Abort Reason:0x040D:3.11.1.13
Components:0x040E:3.11.1.14
Component:0x040F:3.11.1.15
Transaction Id:0x0410:3.11.1.16
_
.TE

.TS
tab(:);
liss
lb2cb2cb
lcc.
Parameters used in CH Messages
_
Parameter Name:Parameter ID:Section
_
Invoke Id:0x0411:3.11.2.1
Linked Id:0x0412:3.11.2.2
Component Flags:0x0413:3.11.2.3
Operation:0x0414:3.11.2.4
Parameters:0x0415:3.11.2.5
Error:0x0416:3.11.2.6
Problem Code:0x0417:3.11.2.7
Timeout:0x0418:3.11.2.8
_
.TE

.TS
tab(:);
liss
lb2cb2cb
lcc.
Other Parameters
_
Parameter Name:Parameter ID:Section
_
Subsystem Number:0x0419:3.11.3.1
Subsystem Multiplicity Indicator:0x041A:3.11.3.2
Congestion Level:0x041B:3.11.3.3
User/Cause:0x041C:3.11.3.4
Network Appearance:0x041D:3.11.3.5
Routing Key:0x041E:3.11.3.6
Registration Result:0x041F:3.11.3.7
Deregistration Result:0x0420:3.11.3.8
Address Range:0x0421:3.11.3.9
Destination Transaction Id:0x0422:3.11.3.10
Originating Transaction Id:0x0423:3.11.3.11
Transaction Id Range:0x0424:3.11.3.12
Global Title:0x0425:3.11.3.13
Point Code:0x0426:3.11.3.14
.TE
.sh 3 "Parameters used in DH Messages"
.sh 4 "Dialogue Id"
.pp
The \fI\)Dialogue Id\fR parameter is used in the TUA Message Header to
identify the dialogue within the Application Server indicated by the
Routing Context (also in the TUA Message Header).
.pp
The \fI\)Dialogue Id\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0401          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          Dialogue Id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Dialogue Id\fR parameter contains the following fields:
.ip "\fB\)Dialogue Id field: 32-bits (unsigned integer)\fR" 2

The \fI\)Dialogue Id\fR field contains an identifier that is used both
at the SG and the ASP to identify a dialogue within an Application
Server.  The Dialogue Id value must be unique within the scope of a
given Application Server and Routing Context.

For a given AS and Routing Context, either the SG or the ASP is
responsible for assigning Dialogue Ids, but not both.
.sh 4 "Dialogue Flags"
.pp
The \fI\)Dialogue Flags\fR parameter is used in the DH Message Header
and is used to indicate whether components are present (when the message
is sent from SG to ASP) and whether permission is granted for the
receiving TC-User to terminate the dialogue.
.pp
The \fI\)Dialogue Flags\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0402          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Dialogue Flags                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Dialogue Flags\fR parameter contains the following fields:
.ip "\fB\)Dialogue Flags field: 32-bits (bit field)\fR" 2

The Dialogue Flags field contains flag bits used in to indicate
additional characteristics of the DH message.  The Dialogue Flags field
is formatted as follows:
.(b L
.(c
.nf
.sz -2
\fC\
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        reserved                         |C|P| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.ba +2
.ip "\fI\)Bits 0-28: Reserved (coded zero)\fR" 2

Reserved bits are reserved for later IETF extensions and are coded zero.
.ip "\fI\)Bit 29: Components Present\fR" 2

The \fI\)Components Present\fR bit is set in the indication (i.e, sent
from SG to ASP) forms of Dialogue Handling (DH) messages to indicate
that Component Handling (CH) messages will follow containing the
components associated with the Dialogue Handing message.
.ip "\fI\)Bit 20: Permission\fR" 2

The \fI\)Permission\fR bit is cleared in Dialogue Handling (DH) messages
to indicate that the remote TC-User is not permitted to end the
dialogue.
.ip "\fI\)Bit 31: Reserved (coded zero)\fR" 2

Reserved bits are reserved for later IETF extensions and are coded zero.
.ba -2
.sh 4 "Quality of Service"
.pp
The \fI\)Quality of Service\fR parameter contains the QoS parameters for
the underlying SCCP Network Service.
.pp
The \fI\)Quality of Service\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0403          |            Length = 8         |
+- - - - - - - -+- - - - - - - -+- - - - - - - -+-+- - -+- - - -+
| Msg Priority  |  Importance   |  Seq Control  |R|  -  | P Cls |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Quality of Service\fR parameter contains the following fields:
.ip "\fB\)Protocol Class field: 4-bits (unsigned integer)\fR" 2

The Protocol Class field indicates the SCCP Protocol Class requested by
the TC-User for the current Dialogue Handling message.  Valid values for
the Protocol Class field are as follows:
.ix +4
.TS
tab(:);
nll.
0:SCCP Protocol Class 0:TCAP Operation Class 4
1:SCCP Protocol Class 1:TCAP Operation Class 1, 2, and 3
2:SCCP Protocol Class 2:TCAP Operation Class 1, 2, and 3
3:SCCP Protocol Class 3:TCAP Operation Class 1, 2, and 3
.TE
.ip "\fB\)Spare field: 3-bits (coded zero)\fR" 2

Spare bits are coded zero.
.ip "\fB\)Return Option field: 1-bit (boolean)\fR" 2

Specifies whether the SCCP "return message on error" is requested when
the Protocol Class field is set to SCCP Protocol Class 0 or 1.  When the
Protocol Class field is set to SCCP Protocol Class 2 or 3, this field
\fB\)MAY\fR be ignored by the SG.  The Return Option field has the
following values:
.ix +4
.TS
tab(:);
nl.
0:No "Return On Error" option requested.
1:"Return On Error" option requested.
.TE
.ip "\fB\)Sequence Control field: 8-bits (unsigned integer)\fR" 2

When the Protocol Class field is other than SCCP Protocol Class 0, the
\fI\)Sequence Control\fR field provides a sequence control parameter
which is used by the underlying SS7 SCCP and MTP layer at the SG to
generate an SLS value.  When the Protocol Class field is set to Protocol
Class 0, this field \fB\)SHOULD\fR be coded to zero and \fB\)MUST\fR be
ignored by the SG.
.ip "\fB\)Importance field: 8-bits (unsigned integer)\fR" 2

The Importance field contains the SCCP Importance level requested by the
TC-User.  Where the underlying SCCP transport at an SG does not support SCCP
flow control,
.[
q714
.]
this field \fB\)SHOULD\fR be coded to zero and \fB\)MUST\fR be ignored by the
SG \*#.  Valid values for the Importance field are as follows:
.ix +4
.TS
tab(:);
nl.
0:SCCP Importance Level 0 or Unspecified
1:SCCP Importance Level 1
2:SCCP Importance Level 2
3:SCCP Importance Level 3
4:SCCP Importance Level 4
5:SCCP Importance Level 5
6:SCCP Importance Level 6
7:SCCP Importance Level 7
.TE
.(d
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR\  The value in the Importance field in the
Quality of Service parameter \fB\)MAY\fR be ignored or modified by a
Signalling Gateway if the value contained is not consistent with SCCP flow
control policy at the SG.
.)d
.ip "\fB\)Message Priority field: 8-bits (unsigned integer)\fR" 2

The Message Priority field contains the MTP Message Priority requested when
the underlying SS7 transport at an SG supports multiple congestion levels.
.[
q704
.]
When the underlying transport does not support multiplex congestion levels or
states, this field \fB\)SHOULD\fR be coded to zero and \fB\)MUST\fR be ignored
by the SG \*#.  Valid values for the Message Priority field are as follows:
.ix +4
.(b
.TS
tab(:);
nl.
0:Message Priority 0 or Unspecified
1:Message Priority 1
2:Message Priority 2
3:Message Priority 3
.TE
.)b
.(d
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR\  The value in the Message Priority field in
the Quality of Service parameter \fB\)MAY\fR be ignored or modified by a
Signalling Gateway if the value contained is not consistent with MTP
congestion policy at the SG.
.)d
.sh 4 "Destination Address"
.pp
The \fI\)Destination Address\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0404          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                      Address parameter(s)                     /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Destination Address\fR parameter contains the following fields:
.ip "\fB\)Address field: variable length (address parameter list)\fR" 2

The \fI\)Address\fR field contains a list of one or more address parameters.
At least one address parameter \fB\)MUST\fR be present in the Address field.
The \fI\)Address\fR field can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Point Code:Conditional:*1
Subsystem Number:Conditional:*1
Global Title:Optional:
.TE
.ip "Note :1" 8
When the Address field contains a \fI\)Subsystem Number\fR parameter, it must
also contain a \fI\)Point Code\fR parameter.
.sh 4 "Originating Address"
.pp
The \fI\)Originating Address\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0405          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                      Address parameter(s)                     /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.pp
The \fI\)Originating Address\fR parameter contains the following fields:
.ip "\fB\)Address field: variable length (address parameter list)\fR" 2

The \fI\)Address\fR field contains a list of one or more address parameters.
At least one address parameter \fB\)MUST\fR be present in the Address field.
The \fI\)Address\fR field can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Point Code:Conditional:*1
Subsystem Number:Conditional:*1
Global Title:Optional:
.TE
.ip "Note :1" 8
When the Address field contains a \fI\)Subsystem Number\fR parameter, it must
also contain a \fI\)Point Code\fR parameter.
.)c
.)b
.sh 4 "Application Context Name"
.pp
The \fI\)Application Context Name\fR parameter contains the identifier of the
application context proposed by the dialogue initiator or by the dialogue
responder.  An application context is an explicitly identified set of
application-service-elements, related options and any other necessary
information for the interworking of application-entities on a dialogue.
.pp
For a description of the \fR\)Application Context Name\fR parameter,
see the ITU
.[
q771
.]
TCAP specifications.
.pp
The \fI\)Application Context Name\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0406          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                       Application Id Type                     |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
\\                                                               \\
/                      Application Identifier                   /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Application Context Name\fR parameter contains the following fields:
.ip "\fB\)Application Id Type field: 32-bits (unsigned integer)\fR" 2

The \fI\)Application Id Type\fR field indicates the type of Application
Identifier that is present in the Application Identifier field.
Valid values for the Application Id Type are as follows:
.ix +4
.TS
tab(:);
nl.
0:ASN.1 OBJECT IDENTIFIER
1:ASN.1 INTEGER
.TE
.ip "\fB\)Application Identifier field: variable length (bytes)\fR" 2

The \fI\)Application Identifier\fR contains an identifier of the application
context that is being proposed by the dialogue initiator or responder.  When
the Application Type is `0' this field \fB\)MUST\fR be formatted as an
\f(CB\)OBJECT IDENTIFIER\fR
.[
asn.1
.]
representing the proposed Application Id.  When the Application Type is `1'
this field \fB\)MUST\fR be formatted as 32-bit unsigned integer value
representing the proposed Application Id.
.sh 4 "User Information"
.pp
The \fI\)User Information\fR parameter contains information which can be
exchanged between TC-Users independently from the Remote Operation Service.
.pp
For a description of the \fR\)User Information\fR parameter, see the ITU
.[
q771
.]
TCAP specifications.
.pp
The \fI\)User Information\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0407          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                          User Information                     /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)User Information\fR parameter can contain the following fields:
.ip "\fB\)User Information field: variable length (bytes)\fR" 2

The internal format of the \fI\)User Information\fR field is opaque to TUA and
to TCAP.  The contents of this field is a string of bytes as they were
provided to the TUA layer by the TC-User in a TC-BEGIN, TC-CONT, or TC-END
primitive.
.sh 4 "Security Context"
.pp
The \fI\)Security Context\fR parameter contains the identifier of the security
context proposed by the dialogue initiator or by the dialogue responder.
.pp
The \fI\)Security Context\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0408          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          Security Type                        |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
\\                                                               \\
/                        Security Identifier                    /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Security Context\fR parameter contains the following fields:
.ip "\fB\)Security Id Type field: 32-bits (unsigned integer)\fR" 2

The \fI\)Security Id Type\fR field indicates the type of Security
Identifier that is present in the Security Identifier field.
Valid values for the Security Id Type are as follows:
.ix +4
.TS
tab(:);
nl.
0:ASN.1 OBJECT IDENTIFIER
1:ASN.1 INTEGER
.TE
.ip "\fB\)Security Identifier field: variable length (bytes)\fR" 2

The \fI\)Security Identifier\fR contains an identifier of the application
context that is being proposed by the dialogue initiator or responder.  When
the Security Type is `0' this field \fB\)MUST\fR be formatted as an
\f(CB\)OBJECT IDENTIFIER\fR
.[
asn.1
.]
representing the proposed Security Id.  When the Security Type is `1' this
field \fB\)MUST\fR be formatted as 32-bit unsigned integer value representing
the proposed Security Id.
.sh 4 "Confidentiality"
.pp
Confidentiality Identifier is coded context specific (in the context of
the dialogue portion sequence), constructor.
.pp
The \fI\)Confidentiality\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0409          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                     Confidentiality Id Type                   |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
\\                                                               \\
/                    Confidentiality Identifier                 /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Confidentiality\fR parameter contains the following fields:
.ip "\fB\)Confidentiality Id Type field: 32-bits (unsigned integer)\fR" 2

The \fI\)Confidentiality Id Type\fR field indicates the type of
Confidentiality
Identifier that is present in the Confidentiality Identifier field.
Valid values for the Confidentiality Id Type are as follows:
.ix +4
.TS
tab(:);
nl.
0:ASN.1 OBJECT IDENTIFIER
1:ASN.1 INTEGER
.TE
.ip "\fB\)Confidentiality Identifier field: variable length (bytes)\fR" 2

The \fI\)Confidentiality Identifier\fR contains an identifier of the application
context that is being proposed by the dialogue initiator or responder.  When
the Confidentiality Type is `0,' this field \fB\)MUST\fR be formatted as an
\f(CB\)OBJECT IDENTIFIER\fR
.[
asn.1
.]
representing the proposed Confidentiality Id.  When the Confidentiality Type
is `1,' this field \fB\)MUST\fR be formatted as 32-bit unsigned integer value
representing the proposed Confidentiality Id.
.sh 4 "Termination"
.pp
The \fI\)Termination\fR parameter indicates the dialogue termination
scenario chosen by the TC-User (prearranged or basic).
.pp
The \fI\)Termination\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x040A          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          Termination                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Termination\fR parameter contains the following fields:
.ip "\fB\)Termination field: 32-bit (unsigned integer)\fR" 2

The \fI\)Termination\fR field indicates the dialogue termination
scenario chosen by the TC-User and can have one of the following values:
.ix +4
.TS
tab(:);
nl.
0:Prearranged
1:Basic
.TE
.sh 4 "Abort Cause"
.pp
The \fI\)Abort Cause\fR parameter is included in the \fI\)TUAB\fR,
\fI\)TPAB\fR, \fI\)TUAB\fR and \fI\)TPAB\fR messages and indicates the
reason for aborting the transaction or dialogue.
.pp
The \fI\)Abort Cause\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x040B          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          Abort Cause                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Abort Cause\fR parameter contains the following fields:
.ip "\fB\)Abort Cause field: 32-bit (unsigned integer)\fR" 2

The \fI\)Abort Cause\fR field indicates the reason for aborting the
dialogue and has a TCAP protocol-variant-specific value.
Example values for ITU
.[
q773
.]
and ANSI
.[
t1.114
.]
are as follows:
.(b L
.TS
tab(;);
cb|lb|lb
n|lw(2.9i)|lw(2.9i).
;ITU-T Description;ANSI Description
_
0;T{
.#v
unrecognized message type
T};\-
1;T{
.#v
unrecognized transaction id
T};T{
.#v
unrecognized package type
T}
2;T{
.#v
badly formatted transaction portion
T};T{
.#v
incorrect transaction portion
T}
3;T{
.#v
incorrect transaction portion
T};T{
.#v
badly structured transaction portion
T}
4;T{
.#v
resource limitation
T};T{
.#v
unassigned responding transaction identifier
T}
5;T{
.#v
L_RESOURCE_LIMIT
T};T{
.#v
permission to release problem
T}
6;T{
.#v
invalid dialogue request
T};T{
.#v
resource unavailable
T}
7;T{
.#v
pending expired
T};T{
.#v
unrecognized dialogue portion identifier
T}
8;T{
.#v
begin expired
T};T{
.#v
badly structured dialogue portion
T}
9;T{
.#v
inactive expired
T};T{
.#v
missing dialogue portion
T}
10;T{
.#v
destination address unknown
T};T{
.#v
inconsistent dialog portion
T}
11;T{
.#v
network error
T};\-
12;T{
.#v
unrecognized dialogue identifier
T};\-
13;T{
.#v
abnormal dialogue portion
T};\-
14;T{
.#v
no common dialogue portion
T};\-
.TE
.)b
.sh 4 "Report Cause"
.pp
The \fI\)Report Cause\fR parameter indicates the reason for the sending
of an TNOT message and reflects the SCCP reason that would be used for
returning a TCAP message.
.pp
The \fI\)Report Cause\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x040C          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          Report Cause                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Report Cause\fR parameter contains the following fields:
.ip "\fB\)Report Cause field: 32-bit (unsigned integer)\fR" 2

The \fI\)Report Cause\fR field indicates the reason that a TC-User
message could not be delivered and has the following values:
.ix +4
.TS
tab(:);
nl.
0:no translation for an address of such nature
1:no translation for this specific address
2:subsystem congestion
3:subsystem failure
4:unequipped user
5:MTP failure
6:network congestion
7:SCCP unqualified
8:error in message transport
9:error in local processing
10:destination cannot perform re-assembly
11:SCCP failure
12:hop counter violation
13:segmentation not supported
14:segmentation failed.
.TE
.sh 4 "Abort Reason"
.pp
The \fI\)Abort Reason\fR parameter indicates whether a dialogue is
aborted because the received application context name is not supported
and no alternative one can be proposed or because of any other user
problem.
.pp
The \fI\)Abort Reason\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x040D          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Abort Reason                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Abort Reason\fR parameter contains the following fields:
.ip "\fB\)Abort Reason field: 32-bits (unsigned integer)\fR" 2

The \fI\)Abort Reason\fR field indicates whether the dialogue was
aborted because the received application context name is not supported
and no alternative can be proposed or because of any other user problem.
The valid values for \fI\)Abort Reason\fR are as follows:
.ix +4
.TS
tab(:);
nl.
0:application context not supported
1:user specific
.TE
.sh 4 "Components"
.pp
The \fI\)Components\fR parameter is used to attach components directly to a
TUA Dialogue Handling (DH) message instead of in separate Component Handling
(CH) massages.
.pp
The \fI\)Components\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x040E          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|         Tag = 0x040F          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                          Component #1                         /
\\                                                               \\
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
\\                              .                                \\
/                               .                               /
\\                              .                                \\
/                                                               /
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|         Tag = 0x040F          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                          Component #n                         /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Components\fR parameter contains the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Component:Conditional:*1
.TE
.ip "Note 1:" 8
The \fI\)Components\fR parameter \fB\)MUST\fR contain at least one
\fI\)Component\fR parameter, but may contain more than one \fI\)Component\fR
parameter.
.sh 4 "Component"
.pp
The \fI\)Component Type\fR field identifies the type of component (CINV, CRES,
CCAN, etc.) that is contained within a \fI\)Component\fR parameter.
.pp
The \fI\)Component Type\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x040F          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Component Type                        |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
\\                                                               \\
/                      Component parameter(s)                   /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Component Type\fR parameter contains the following fields:
.ip "\fB\)Component Type field: 32-bit (unsigned integer)\fR" 2

The \fI\)Component Type\fR field indicates the type of component
contained in the component parameter.  It can take on the following
values: (Note that not all values are supported for interworking with
all TCAP protocol variants.)
.ix +4
.TS
tab(:);
nll.
0:Invoke Last
1:Invoke Not Last
2:Result Last
3:Result Not Last
4:Error
5:Reject (User)
6:Reject (Local)
7:Reject (Remote)
8:Cancel
.TE
.ip "\fB\)Component field: variable length (TLV parameter list)\fR" 2

The \fI\)Component\fR field contains the parameters associated with the
component.  This field may contains the following components, however, the
formatting of the Component field \fB\)MUST\fR be the same as for the
corresponding TUA message as follows:
.ix +4
.TS H
tab(:);
lbscbnb
nl|cn.
Component Type:CH Msg:Section
_
.TH
0:Invoke Last:
_:_:CINV:3.4.2
1:Invoke Not Last:
_
2:Result Last:
_:_:CRES:3.4.3
3:Result Not Last:
_
4:Error:CERR:3.4.4
_
5:Reject (User):
_:_:
6:Reject (Local):CREJ:3.4.5
_:_:
7:Reject (Remote):
_
8:Cancel:CCAN:3.4.6
_
.TE
.sh 4 "Transaction Id"
.pp
The \fI\)Transaction Id\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0410          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Transaction Id                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Transaction Id\fR parameter contains the following fields:
.ip "\fB\)Transaction Id field: 32-bits (unsigned integer)\fR"

The \fI\)Transaction Id\fR field contains the value of the originating or
terminating transaction identifier.
.sh 3 "Parameters used in CH Messages"
.sh 4 "Invoke Id"
.pp
The \fI\)Invoke Id\fR parameter identifies an invoke component.
This identifier is only significant within the scope of a transaction
and need only uniquely identify a dialogue within a transaction in a
given direction (e.g, from SGP to ASP).  The value of the \fI\)Invoke
Id\fR parameter is chosen by the TUA peer sending the Invoke.  As both
the ASP and SGP could be assigning the same values of \fI\)Invoke Id\fR
to invocations in each direction, the \fI\)Invoke Id\fR need only be
unique in one direction.
.pp
The \fI\)Invoke Id\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0411          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                           Invoke Id                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Invoke Id\fR parameter contains the following fields:
.ip "\fB\)Invoke Id field: 32-bit (unsigned integer)\fR" 2

The \fI\)Invoke Id\fR field contains the value of the invoke identifier
for the current component.
.sh 4 "Linked Id"
.pp
The \fI\)Linked Id\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0412          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                           Linked Id                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Linked Id\fR parameter contains the following fields:
.ip "\fB\)Linked Id field: 32-bit (unsigned integer)\fR" 2

The \fI\)Linked Id\fR field contains the value of the linked or
correlation invoke identifier which is related to the current component.
.sh 4 "Component Flags"
.pp
The \fI\)Component Flags\fR parameter is used in the \fI\)CINV\fR and
\fI\)CRES\fR CH messages to indicate whether the contained components
are segmented and whether they represent the last segment in a sequence
of component segments.
.pp
The \fI\)Component Flags\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0413          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          unused                             |N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Component Flags\fR parameter contains the following fields:
.ip "\fB\)Component Flags field: 32-bits\fR" 2

The Component Flags field is used to convey information about the
components in a Component Handling (CH) message.  It contains the
following bit fields:
.ba +2
.ip "\fI\)Bits 0-30: Unused\fR" 2

These bits are reserved and are coded to zero.
.ip "\fI\)Bit 31: Not Last Bit\fR" 2

The Not Last bit is used to indicate whether the component present in
the CH message is the last component of a sequence of segmented
components.  It has the following values:
.ix +4
.TS
tab(:);
nl.
0:Last component in a component sequence.
1:Not the last component in a component sequence.
.TE
.ix -4

To smoothly interwork with TCAP, TUA includes a mechanism whereby
components can be segmented: the CH message with the "Not Last" bit set
in the Component Flags field provides for the initial segments of a
segmented component, whereas the CH message with the "Not Last" bit
clear in the Component Flags field provides for the final (or only)
segment in a sequence of component segments representing the complete
component.  When interworking with TCAP, each component segment may be
sent in a different TCAP package.
.[
q775
.]
.ba -2
.sh 4 "Operation"
.pp
The \fI\)Operation\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0414          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Operation Class                       |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
|                         Operation Type                        |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
\\                                                               \\
/                         Operation Code                        /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Operation\fR parameter contains the following fields:
.ip "\fB\)Operation Class field: 32-bit (unsigned integer)\fR" 2

The \fI\)Operation Class\fR field indicates the operational class of the
invoke in which it appears and has the following values:
.ix +4
.TS
tab(:);
nll.
0::not specified
1:Class 1:both success and failure are reported
2:Class 2:only failure is reported
3:Class 3:only success is reported
4:Class 4:neither success, nor failure is reported
.TE
.ip "\fB\)Operation Type field: 32-bit (unsigned integer)\fR" 2

The \fI\)Operation Type\fR field indicates the type of operation code
and has the following values:
.ix +4
.TS
tab(:);
nll.
1:National TCAP Operation:INTEGER
2:Private TCAP Operation:INTEGER
3:Local TCAP Operation:INTEGER
4:Global TCAP Operation:OBJECT IDENTIFIER
.TE
.ip "\fB\)Operation Code field: variable length (based on type)\fR" 2

The \fI\)Operation Code\fR field contains an identifier of the requested
operation.
When the Operation Type is "National," "Private," or "Local," this field
\fB\)MUST\fR be formatted as 32-bit unsigned integer value representing the
requested operation.
When the Operation Type is "Global," this field \fB\)MUST\fR be formatted as
an \f(CB\)OBJECT IDENTIFIER\fR.
.[
asn.1
.]
representing the requested operation.
The value of this field is TCAP protocol-variant-specific.
.sh 4 "Parameters"
.pp
The \fI\)Parameters\fR parameter identifies the parameter set or
parameter sequence that accompanies an operation invocation or response.
.pp
The \fI\)Parameters\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0415          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Parameters                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Parameters\fR parameter contains the following fields:
.ip "\fB\)Parameters field: variable length (bytes)\fR" 2

The \fI\)Parameters\fR field contains all of the parameters coded
according to the coding
.[
asn.1
.]
for Parameter Sequences or Parameter Sets per the applicable TCAP protocol
specification.  For example, ITU
.[
q773
.]
or ANSI.
.[
t1.114
.]
\*#
.(d
\fB\)IMPLEMENTATION NOTE:\-\fR\  The Signalling Gateway \fB\)MAY\fR, at its
option, segment the \fI\)Parameters\fR field into multiple parameters set to
be send in multiple Invoke (Last/Not Last) or Return Result (Last/Not Last)
components in separate TCAP packages to meet the maximum PDU requirements
imposed by the underlying SCCP transport.  Otherwise, if the Signalling
Gateway finds that the resulting component is too large to fit into an SCCP
UNITDATA message,
.[
q713
.]
the SG \fB\)MAY\fR, at its option, return a TNOT message indicating to the
TC-User that the component was too large.
.)d
.sh 4 "Error"
.pp
The \fI\)Error\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0416          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                           Error Type                          |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Error Code                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Error\fR parameter contains the following fields:
.ip "\fB\)Error Type field: 32-bit (unsigned integer)\fR" 2

The \fI\)Error Type\fR field indicates the level (i.e, local or global)
at which the error was generated.  It has the following values:
.ix +4
.TS
tab(:);
nll.
1:National TCAP Error:INTEGER
2:Private TCAP Error:INTEGER
3:Local TCAP Error:INTEGER
4:Global TCAP Error:OBJECT IDENTIFIER
.TE
.ip "\fB\)Error Code field: variable length (based on type)\fR" 2

The \fI\)Error Code\fR field contains an identifier of the indicated error.
When the Error Type is "National," "Private," or "Local," this field
\fB\)MUST\fR be formatted as a 32-bit signed integer value representing the
indicated error.  When the Error Type is "Global," this field \fB\)MUST\fR be
formatted as an \f(CB\)OBJECT IDENTIFIER\fR
.[
asn.1
.]
representing the indicated error.
The value of this field is TCAP protocol-variant-specific.
.sh 4 "Problem Code"
.pp
The \fI\)Problem Code\fR parameters identifies the reason for
rejecting a component.
.pp
The \fI\)Problem Code\fR parameters is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0417          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          Problem Type                         |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
|                          Problem Code                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Problem Code\fR parameters contains the following fields:
.ip "\fB\)Problem Type field: 32-bit (unsigned integer)\fR" 2

The \fI\)Problem Type\fR field indicates the reason for rejecting a
component and has the following values: (Note that not all problem type
field values are applicable to all TCAP protocol variants.)
.ix +4
.TS
tab(;);
nl.
0;General Problem
1;Problem with Invoke
2;Problem with Return Result
3;Problem with Return Error
4;Problem with Transaction Portion (deprecated)
.TE
.ip "\fB\)Problem Code field: variable length (signed integer)\fR" 2

The \fI\)Problem Code\fR field indicates the specific problem associated
with the Problem Type.  For more information on problem codes, see Q.773
Chapter 4.2.2.6 and ANSI T1.114.3 Chapter 5.16.2.
.ip "\fB\)Problem Code field: 32-bit (signed integer)\fR" 2

The \fI\)Problem Code\fR field indicates the specific problem
associated with the Problem Type.  This is a TCAP protocol-variant-specific
value.  Following are some example values for ITU
.[
q773
.]
and ANSI:
.[
t1.114
.]
.lp
.TS
tab(:);
l1n1lw(2.7i)1lw(2.9i).
::ITU:ANSI
_
General:0:T{
.#v
unrecognized component
T}:\-
Problem:1:T{
.#v
mis-typed component
T}:T{
.#v
unrecognized component type
T}
:2:T{
.#v
badly structured component
T}:T{
.#v
incorrect component portion
T}
:3:\-:T{
.#v
badly structured component portion
T}
_
Invoke:0:T{
.#v
duplicate invoke id
T}:\-
Problem:1:T{
.#v
unrecognized operation
T}:T{
.#v
duplicate invocation
T}
:2:T{
.#v
mis-typed parameter
T}:T{
.#v
unrecognized operation
T}
:3:T{
.#v
resource limitation
T}:T{
.#v
incorrect parameter
T}
:4:T{
.#v
initiating release
T}:T{
.#v
unrecognized correlation id
T}
:5:T{
.#v
unrecognized linked id
T}:\-
:6:T{
.#v
linked response unexpected
T}:\-
:7:T{
.#v
unexpected linked operation
T}:\-
_
Return:0:T{
.#v
unrecognized invoke id
T}:\-
Result:1:T{
.#v
return result unexpected
T}:T{
.#v
unrecognized correlation id
T}
Problem:2:T{
.#v
mis-typed parameter
T}:T{
.#v
unexpected return result
T}
:2:\-:T{
.#v
incorrect parameter
T}
_
Return:0:T{
.#v
unrecognized invoke id
T}:\-
Error:1:T{
.#v
return error unexpected
T}:T{
.#v
unexpected return error
T}
Problem:2:T{
.#v
unrecognized error
T}:T{
.#v
unrecognized error
T}
:3:T{
.#v
unexpected error
T}:T{
.#v
unexpected error
T}
:4:T{
.#v
mis-typed parameter
T}:T{
.#v
incorrect parameter
T}
_
Trans:1:\-:T{
.#v
unrecognized package type
T}
Portion:2:\-:T{
.#v
incorrect transaction portion
T}
Problem:3:\-:T{
.#v
badly structured transaction portion
T}
(depr.):4:\-:T{
.#v
unassigned responding transaction id
T}
:5:\-:T{
.#v
permission to release problem
T}
:6:\-:T{
.#v
resource unavailable
T}
_
.TE
.sh 4 "Timeout"
.pp
The \fI\)Timeout\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0418          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                            Timeout                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Timeout\fR parameter contains the following fields:
.ip "\fB\)Timeout field: 32-bit (unsigned integer)\fR" 2

The \fI\)Timeout\fR field contains the timeout value in seconds that the
sender will wait before an invocation is canceled.
.sh 3 "Other Parameters"
.sh 4 "Subsystem Number"
.pp
The \fI\)Subsystem Number\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0419          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                     Reserved                  |      SSN      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Subsystem Number\fR parameter contains the following fields:
.ip "\fB\)Reserved field: 24-bits (coded zero)\fR" 2

Reserved bits are coded zero.
.ip "\fB\)SSN field: 8-bits (unsigned integer)\fR" 2

The \fI\)SSN\fR field contains the SCCP subsystem number.
.[
q713
.]
.[
t1.112
.]
.sh 4 "Subsystem Multiplicity Indicator"
.pp
The \fI\)Subsystem Multiplicity Indicator\fR is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x041A          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                     Reserved                  |      SMI      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Subsystem Multiplicity Indicator\fR contains the following fields:
.ip "\fB\)Reserved field: 24-bits (coded zero)\fR" 2

Reserved bits are coded zero.
.ip "\fB\)SMI field: 8-bits (unsigned integer)\fR" 2

The \fI\)SMI\fR field contains the SCCP subsystem multiplicity indicator.
Valid values for the \fI\)SMI\fR field are as follows:
.ix +4
.TS
tab(:);
nl.
0:Reserved/Unknown
1:Solitary
2:Duplicated
3:Triplicated
4:Quadruplicated
 ...: ...
255:Unspecified
.TE
.sh 4 "Congestion Level"
.pp
The \fI\)Congestion Level\fR parameter is used to indicate the MTP
network congestion level or SCCP restricted importance level and is used
in the Network Congestion (SCON) message.
.pp
The \fI\)Congestion Level\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x041B          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                        Congestion Level                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Congestion Level\fR parameter contains the following fields:
.ip "\fB\)Congestion Level field: 32-bits (unsigned integer)\fR" 2

The Congestion Level field contains the level at which congestion has
occurred.

When the Congestion Level parameter is included in a SCON message that
corresponds to an N-PCSTATE request indication primitive, the Congestion
Level field indicates the MTP congestion level experienced by the local
or affected signalling point as indicated by the Affected Point Code(s)
also in the SCON message.  In this case, valid values for the Congestion Level
field are as follows:
.ix +4
.TS
tab(:);
nl.
0:No Congestion or Undefined
1:Congestion Level 1
2:Congestion Level 2
3:Congestion Level 3
.TE
.ix -4

When the Congestion Level parameter is included in a SCON message that
corresponds to an N-STATE request or indication primitive, the
Congestion Level field indicates the SCCP restricted importance level
experienced by the local or affected subsystem as indicated by the
Affected Point Code and Subsystem Number also in the SCON message.  In
this case, valid values for the Congestion Level field range from 0
to 7, where 0 indicates the least congested and 7 indicates the most
congested subsystem.
.sh 4 "User/Cause"
.pp
The \fI\)User/Cause\fR parameter is used to report the affected user and
the cause of the unavailability of the user in a \fI\)DUPU\fR message.
.pp
The \fI\)User/Cause\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x041C          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|              Cause            |             User              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)User/Cause\fR parameter contains the following fields:
.ip "\fB\)Cause field: 16-bits (unsigned integer)\fR" 2

The \fI\)Cause\fR field indicates the cause of the unavailability of the
remote user.  Valid \fI\)Cause\fR values are as follows:
.ix +4
.TS
tab(:);
nl.
0: Unknown
1: Unequipped Remote User
2: Inaccessible Remote User
.TE
.ix -4
.ip "\fB\)User field: 16-bits (unsigned integer)\fR" 2

The \fI\)User\fR field contains the SI value of the MTP User
.[
q704
.]
that is being reported unavailable.  For TUA, this is the SI value of
the SCCP (normally SI = 3).  The TC-User \fB\)MAY\fR ignore the
\fI\)User\fR field.
.sh 4 "Network Appearance"
.pp
The \fI\)Network Appearance\fR parameter is used as a parameter in the
Registration Request (REG REQ) message to indicate the network context
in which the remainder of the Routing Key parameters are to be
interpreted.  The \fI\)Network Appearance\fR parameter is also used in
the Error (ERR) message in response to a REG REQ message when a received
Network Appearance parameter contains an invalid value.
.pp
The \fI\)Network Appearance\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x041D          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                        Network Appearance                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Network Appearance\fR parameter can contain the following
fields:
.ip "\fB\)Network Appearance field: 32-bits (unsigned integer)\fR" 2

The Network Appearance field identifies the SS7 network context for the
Routing Key.  The Network Appearance value is of local significance
only, coordinated between the SG and ASP.  Therefore, in the case where
the ASP is connected to more than one SG, the same SS7 Network context
may be identified by a different Network Appearance value depending upon
to which SG the ASP is registering.

In the Routing Key, the Network Appearance identifies the SS7 Point Code
and Global Title Transaction Type format used, and the SCCP, TCAP and
TC-User protocol (type, variant and version) used within the specific
SS7 network.
.sh 4 "Routing Key"
.pp
The \fI\)Routing Key\fR parameter is used in the \fI\)REG REQ\fR message
to list and identify the Routing Keys that are being registered.
.pp
The \fI\)Routing Key\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x041E          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                  Local Routing Key Identifier                 |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
\\                                                               \\
/                        Key parameter(s)                       /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Routing Key\fR parameter can contain the following fields:
.ip "\fB\)Local Routing Key Identifier field: 32-bits (unsigned integer)\fR" 2

The \fI\)Local Routing Key Identifier\fR field is used to uniquely
identify the registration request.  The identifier value is assigned by
the ASP and is used to correlate the response in a REG RSP message with
the original registration request.  The identifier value must remain
unique until the REG RSP (or ERR) message is received.
.ip "\fB\)Key field: variable (TLV parameters)\fR" 2

The key field can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Network Appearance:Conditional:*1
Traffic Mode Type:Optional:
Originating Address:Optional:
Destination Address:Optional:
Address Range:Optional:
Originating Transaction Id:Optional:
Destination Transaction Id:Optional:
Transaction Id Range:Optional:
Application Context Name:Optional:
User Information:Optional:
.TE
.ba +2
.ip "Note 1:" 8
The Network Appearance parameter \fB\)MUST\fR be included in the Routing
Key when the ASP is able to register in multiple SS7 Network contexts.
.ba -2
.sh 4 "Registration Result"
.pp
The \fI\)Registration Result\fR parameter is used to identify and report
the result of the registration request for each Routing Key that was
requested registered in a \fI\)REG REQ\fR message.
.pp
The \fI\)Registration Result\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x041F          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                  Local Routing Key Identifier                 |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
|                       Registration Status                     |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
|                         Routing Context                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Registration Result\fR parameter can contain the following
fields:
.ip "\fB\)Local Routing Key Identifier field: 32-bit (unsigned integer)\fR" 2

The \fI\)Local Routing Key Identifier\fR field contains the same value
as found in the matching Routing Key parameter in the \fI\)REG REQ\fR
message.
.ip "\fB\)Registration Status field: 32-bits (unsigned integer)\fR" 2

The \fI\)Registration Status\fR field indicates the success or the
reason for failure of a registration request.

Its values may be:
.ix +4
.TS
tab(:);
nl.
0:Successfully Registered
1:Error - Unknown
2:Error - Invalid Destination Address
3:Error - Invalid Network Appearance
4:Error - Invalid Routing Key
5:Error - Permission Denied
6:Error - Cannot Support Unique Routing
7:Error - Routing Key not Currently Provisioned
8:Error - Insufficient Resources
9:Error - Unsupported RK parameter field
10:Error - Unsupported/Invalid Traffic Mode Type
.TE
.ip "\fB\)Routing Context field: 32-bits (unsigned integer)\fR" 2

The \fI\)Routing Context\fR field contains the Routing Context value for
the associated Routing Key if the registration was successful.  It is
set to "0" if the registration was not successful.
.sh 4 "Deregistration Result"
.pp
The \fI\)Deregistration Result\fR parameter is used to identify and
report the result of the deregistration request for each Routing Context
that was requested deregistered and a \fI\)DEREG REQ\fR message.
.pp
The \fI\)Deregistration Result\fR parameter contains the deregistration
status for a single Routing Context in a DEREG REQ message.  The number
of results in a DEREG RSP message \fB\)MAY\fR by anywhere from one to
the total number of Routing Context values found in the corresponding
REG REQ message.  Where multiple DEREG RSP messages are used in reply to
a single DEREG REQ message, a specific result \fB\)SHOULD\fR be in only
one DEREG RSP message.
.pp
The \fI\)Deregistration Result\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0420          |            Length = 12        |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Routing Context                       |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
|                      Deregistration Status                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Deregistration Result\fR parameter can contain the following
fields:
.ip "\fB\)Routing Context field: 32-bits (unsigned integer)\fR" 2

The \fI\)Routing Context\fR field contains the Routing Context value of
the matching Routing Key to deregister, as found in the \fI\)DEREG
REQ\fR message.
.ip "\fB\)Deregistration Status field: 32-bits (unsigned integer)\fR" 2

The \fI\)Deregistration Status\fR field indicates the success or the
reason for failure of the deregistration.

Its values may be:
.ix +4
.TS
tab(:);
nl.
0:Successfully Deregistered
1:Error - Unknown
2:Error - Invalid Routing Context
3:Error - Permission Denied
4:Error - Not Registered
5:Error - ASP Currently Active for Routing Context
.TE
.sh 4 "Address Range"
.pp
The \fI\)Address Range\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0421          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                       Address Parameter(s)                    /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Address Range\fR parameter can contain the following fields:
.ip "\fB\)Address field: variable (TLV parameters)\fR" 2

The \fI\)Address\fR field can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Originating Address:Conditional:*1
Destination Address:Conditional:*1
.TE
.ba +2
.ip "Note 1:" 8
The Address field must contain pairs of Originating Addresses or Destination
Addresses and \fB\)MUST\fR contain one and only one pair of addresses; but,
\fB\)MUST NOT\fR mix Originating Addresses with Destination Addresses in the
same Address field.
.ba -2
.sh 4 "Destination Transaction Id"
.pp
The \fI\)Destination Transaction Id\fR parameter is formatted as
follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0422          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                    Destination Transaction Id                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Destination Transaction Id\fR parameter can contain the
following fields:
.ip "\fB\)Destination Transaction Id field: 32-bits (unsigned integer)\fR" 2

The \fI\)Destination Transaction Id\fR field contains the Destination
Transaction Identifier associated with the dialogue.
.sh 4 "Originating Transaction Id"
.pp
The \fI\)Originating Transaction Id\fR parameter is formatted as
follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0423          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                    Originating Transaction Id                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Originating Transaction Id\fR parameter can contain the
following fields:
.ip "\fB\)Originating Transaction Id field: 32-bits (unsigned integer)\fR" 2

The \fI\)Originating Transaction Id\fR field contains the Originating
Transaction Identifier associated with the dialogue.
.sh 4 "Transaction Id Range"
.pp
The \fI\)Transaction Id Range\fR parameter is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0424          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                   Transaction Id Parameter(s)                 /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Transaction Id Range\fR parameter can contains the following
fields:
.ip "\fB\)Transaction Id field: list of 32-bit (unsigned integer)\fR" 2

The \fI\)Transaction Id\fR field can contain the following parameters:
.ix +4
.TS
tab(:);
lbw(2.5i)ss
lilc.
Parameters
_
Originating Transaction Id:Optional:*1
Destination Transaction Id:Optional:*1
.TE
.ba +2
.ip "Note 1:" 8
The Transaction Id field must contain pairs of Originating Transaction
Ids or Destination Transaction Ids and \fB\)MUST\fR contain one and only one
pair of Transaction Id parameters; but, \fB\)MUST NOT\fR mix Originating
Transaction Ids with Destination Transaction Ids in the same Transaction
Id field.
.ba -2
.\"
.sh 4 "Global Title"
.pp
The \fI\)Global Title\fR parameters is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0425          |            Length             |
+- - - - - - - -+- - - - - - - -+- - - -+- - - -+- - - - - - - -+
| Num. Digits   |  Trans. Type  | N Plan| E Sch | Nature of Add |
+- - - - - - - -+- - - - - - - -+- - - -+- - - -+- - - - - - - -+
\\                                                               \\
/                      Global Title Address                     /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Global Title\fR parameters contains the following fields:
.ip "\fB\)Number of Digits field: 8-bits (unsigned integer)\fR" 2

The \fI\)Number of Digits\fR field contains the number of address signals that are
represented in the \fI\)Global Title Address\fR field.
.ip "\fB\)Translation Type field: 8-bits (unsigned integer)\fR" 2

The \fI\)Translation Type\fR field contains the translation type to be
performed on the address information in the \fI\)Global Title\fR parameter.
This is a TCAP protocol-variant-specific value.  Example valid values for ITU
.[
q713
.]
are as follows:
.ix +4
.TS
tab(:);
nw(0.3i)0cw(0.15i)0nw(0.3i)2lw(4.5i).
0:::unknown
1:\-:63:international services
128:\-:254:national network specific
.TE
.ip "\fB\)Numbering Plan field: 4-bits (unsigned integer)\fR" 2

The \fI\)Numbering Plan\fR field contains the numbering plan to which the
address information contained in the \fI\)Global Title Address\fR field
belongs.
This is a TCAP protocol-variant-specific value.  Example valid values for ITU
.[
q713
.]
are as follows:
.ix +4
.TS
tab(:);
nw(0.75i)2lw(4.5i).
0:unknown
1:ISDN/telephony numbering plan (E.163 and E.164)
2:generic numbering plan
3:data numbering plan (X.121)
4:telex numbering plan (F.69)
5:maritime mobile numbering plan (E.210, E.211)
6:land mobile numbering plan (E.212)
7:ISDN/mobile numbering plan (E.214)
14:private network or network-specific numbering plan
.TE
.ip "\fB\)Encoding Scheme field: 4-bits (unsigned integer)\fR" 2

The \fI\)Encoding Scheme\fR field contains the format for the address
information contained in the \fI\)Global Title Address\fR field.
This is a TCAP protocol-variant-specific value.  Example valid values for ITU
.[
q713
.]
are as follows:
.ix +4
.TS
tab(:);
nw(0.75i)2lw(4.5i).
0:unknown
1:BCD, odd number of digits
2:BCD, even number of digits
3:national specific
.TE
.ip "\fB\)Nature of Address field: 8-bits (unsigned integer)\fR" 2

The \fI\)Nature of Address\fR field contains an indication of the nature of
the information represented in the \fI\)Global Title Address\fR field.
This is a TCAP protocol-variant-specific value.  Example valid values for ITU
.[
q713
.]
are as follows:
.ix +4
.TS
tab(:);
nw(0.75i)2lw(4.5i).
0:unknown
1:subscriber number
2:reserved for national use
3:national significant number
4:international number
.TE
.ip "\fB\)Global Title Address field: variable length (bytes)\fR" 2

The \fI\)Global Title Digits\fR field contains the global title address
information.  This information is formatted according to the Encoding Scheme,
belongs to the Numbering Plan, has the Nature of Address, and contains the
Number of Digits.  When the encoding scheme is BCD, the Global Title Digits
field is formatted as follows:
.(b L
.(c
.nf
.sz -2
\fC\
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dig 2 | Dig 1 | Dig 4 | Dig 3 | Dig 6 | Dig 5 | Dig 8 | Dig 7 |
+- - - -+- - - -+- - - -+- - - -+- - - -+- - - -+- - - -+- - - -+
| Dig 10| Dig 9 |  ...  |  ...  |  ...  |  ...  |  ...  |  ...  |
+- - - -+- - - -+- - - -+- - - -+- - - -+- - - -+- - - -+- - - -+
\\                               .                               \\
/                               .                               /
\\                               .                               \\
/                                                               /
+- - - - - - - -+- - - -+- - - -+- - - -+- - - -+- - - -+- - - -+
|               |filler | Dig n |  ...  |  ...  |  ...  |  ...  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
Where each digit is coded as follows:
.ix +4
.TS
tab(:);
cl.
0x0:digit 0
0x1:digit 1
0x2:digit 2
0x3:digit 3
0x4:digit 4
0x5:digit 5
0x6:digit 6
0x7:digit 7
0x8:digit 8
0x9:digit 9
0xA:spare
0xB:code 11
0xC:code 12
0xD:spare
0xE:spare
0xF:ST
.TE
.ix -4
When the Encoding Scheme is not "BCD," both the TUA layer at the ASP and the
TUA layer at the SG should treat the Global Title Address as opaque.
.sh 4 "Point Code"
.pp
The \fI\)Point Code\fR parameters is formatted as follows:
.(b
.(c
.nf
.sz -2
\fC\
 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 = 0x0426          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                          Point Code                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.pp
The \fI\)Point Code\fR parameters contains the following fields:
.ip "\fB\)Point Code field: 32-bits (unsigned integer)\fR" 2

The \fI\)Point Code\fR field contains an SS7 signalling point code.  Point
codes that are less than 32-bits are padded on the left to the 32-bit
boundary.  The following examples show ANSI and ITU-T point codes:
.ba +2
.ip "\fI\)ANSI 24-bit Point Code:\fR" 2
.(b L
.nf
.sz -2
\fC\
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|    Network    |    Cluster    |     Member    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |MSB-----------------------------------------LSB|
.)b
.ip "\fI\)ITU-T 14-bit Point Code:\fR" 2
.(b L
.nf
.sz -2
\fC\
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|Zone |     Region    | SP  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |MSB---------------------LSB|
.)b
.ba -2
.\"
.\"
.\"
.\"
.\"
.\"
.sh 1 "Procedures"
.pp
The TUA layer needs to respond to various local primitives it receives from
other layers as well as the messages that it receives from the peer TUA layer.
This section describes the TUA procedures in response to these events.
.sh 2 "Procedures to Support the TC-User"
.sh 3 "Receipt of Primitives from the TC-User"
.pp
Upon receiving a TC request or response primitive from the upper layer at an
ASP or IPSP, the TUA layer sends a corresponding TUA Dialogue Handling (DH) or
Component Handling (CH) message (see Section 3) to its TUA peer.  The TUA peer
receiving the DH or CH message delivers the corresponding TC primitive to the
TC-User at the IPSP or Nodal Interworking Function at the SG as illustrated in
\fI\)\*(&f\n(&n\fR.  The mapping of TC primitives to TUA DH Messages is listed
in \fI\)Table 2\fR, and the CH Messages in \fI\)Table 3\fR (see Section
1.6.1).
.ie '\*(.T'ps' \{\
.\"'
.(z
.so tua04.pic
.#f "TUA Layer Model"
.)z
.\}
.el \{
.lp
.(b
.(c
.nf
.sz -2
\fC\
  _______________         _______       _______         _______
 |               |       |       |     |       |       |       |
 |    Nodal      |       |       |     |       |       |       |
 | Interworking  |       |TC-User|     |TC-User|       |TC-User|
 |   Function    |       |       |     |       |       |       |
 |  ___________  |       |_______|     |_______|       |_______|
 | |    ___    | |         |   ^         |   ^           |   ^
 | |   |   |   | |         |   |         |   |           |   |
 |_v___|___v___|_|         |   |         |   |           |   |
   |   ^   |   ^           |   |         |   |           |   |
   |   |   |   |  TC-User  |   |         |   |  TC-User  |   |
 - + - + - + - + - - - - - + - + - - - - + - + - - - - - + - + - -
   |   |   |   |  Boundary |   |         |   |  Boundary |   |
  _v___|_ _v___|_         _v___|_       _v___|_         _v___|_
 |       |       |       |       |     |       |       |       |
 |       |       |       |       |     |       |       |       |
 |  TCAP |  TUA  |       |  TUA  |     |  TUA  |       |  TUA  |
 |       |       |       |       |     |       |       |       |
 |_______|_______|       |_______|     |_______|       |_______|
 |       | |   ^           |   ^         |   ^           |   ^
 |       | |   |           |   |         |   |           |   |
 |       | |   |    _      |   |         |   |    _      |   |
 |  SS7  | |   |___/_\\_____|   |         |   |____/_\\____|   |
 |       | |______|___|________|         |_______|___|_______|
 |///////|         \\_/                            \\_/
 |       |         /                              /
 |       |        /                              /
             SCTP Association               SCTP Association

 \\______  ______/        \\___  ___/    \\___  ___/     \\___  ___/
        \\/                   \\/            \\/             \\/
        SG                    ASP         IPSP           IPSP
.)c
.#f "TUA Layer Model"
.)b
.\}
.sh 3 "Receipt of Primitives from TCAP"
.pp
Upon receiving a TC indication or confirmation primitive from TCAP at an SG,
the Nodal Interworking Function passes the primitive to TUA.  The TUA layer
sends a corresponding TUA Dialogue Handling (DH) or Component Handling (CH)
message (see Section 3) to its TUA peer at the ASP.
.pp
The TUA peer receiving the DH or CH message delivers the corresponding TC
primitive to the TC-User at the ASP as illustrated in \fI\)\*(&f\n(&n\fR.  The
mapping of TC primitives to TUA DH Messages is listed in \fI\)Table 2\fR, and
the CH Messages in \fI\)Table 3\fR (see Section 1.6.1).
.pp
The TUA Transaction Mapping Function (see Section)
.pp
For TC-BEGIN indications, the TUA Transaction Mapping Function (TMF)
determines the Application Server (AS) based on comparing the address and
dialogue portion information in the primitive with a provisioned Routing Key.
.pp
From the list of ASPs within an AS table, an ASP in the ASP-ACTIVE state is
selected and a TQRY message is constructed and issued on the corresponding
SCTP association.  The TUA at the SG is also responsible for assigning and
managing a Dialogue Identifier which is sent to the ASP in the TQRY message to
identify the newly created dialogue to the ASP.  Information associated with
the dialogue is stored in the SG in an implementation dependent manner;
however, the SG must be capable of associating further TUA messages with the
correct Dialogue at the SG.  The SG will have to access this stored
information to continue processing the dialogue.
.pp
The TUA Transaction Mapping Function (TMF) determines the Application Server
(AS) based on comparing the information in the primitive with a provisioned
Routing Key.
.pp
.sh 4 "Receipt of Management Primitives from TCAP"
.pp
When TCAP Management indications are received (N-STATE, N-PCSTATE, N-COORD),
TCAP Management determines whether there are concerned local TC-Users.  When
these local TC-Users are in fact Application Servers, serviced by ASPs, TUA
management is transparently informed with the N-STATE, N-PCSTATE, N-COORD
indication primitive upon which it formats and transfers the applicable SSNM
message (DUNA, DAVA, DRST, DUPU or SCON) to the list of concerned ASPs.
.pp
The TUA message distribution function determines the Application Server (AS)
based on comparing the information in the TC-BEGIN, TC-CONTINUE, TC-END, or
TC-ABORT primitive with a provisioned Routing Key.
.pp
From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE state is
selected and Dialogue Handling (DH) and Component Handling (CH) messages are
constructed and issued on the corresponding SCTP association.  If more than
one ASP is in the ASP-ACTIVE state (i.e., traffic is to be load-shared across
more than one ASP), one of the ASPs in the ASP-ACTIVE state is selected from
the list.  (If the ASPs are in Broadcast Mode, all active ASPs will be
selected and the message sent to each of the active ASPs.)  The selection
algorithm is implementation dependent but could, for example, be round robin
or based on the SLS.  The appropriate selection algorithm must be chosen
carefully as it is dependent on application assumptions and understanding of
the degree of state coordination between the ASP-ACTIVE ASPs in the AS.
.pp
In addition, the message needs to be sent on the appropriate SCTP stream,
again taking care to meet the message sequencing needs of the signalling
application.  Dialogue Handling (DH) and Component Handling (CH) messages
\fB\)SHOULD\fR be sent on an SCTP stream other than stream `0'.
.pp
When there is no Routing Key match, or only a partial match, for an incoming
SS7 message, a default treatment \fB\)MAY\fR be specified.  Possible solutions
are to provide a default Application Server at the SGP that directs all
unallocated traffic to a (set of) default ASP(s), or to drop the message and
provide a notification to Layer Management in an M-ERROR indication primitive.
The treatment of unallocated traffic is implementation dependent.
.sh 3 "Receipt of Primitive from the Layer Management"
.pp
On receiving primitives from the local Layer Management, the TUA layer will
take the requested action and provide an appropriate response primitive to
Layer Management.
.pp
An M-SCTP_ESTABLISH request primitive from Layer Management at an ASP or IPSP
will initiate the establishment of an SCTP association.  The TUA layer will
attempt to establish an SCTP association with the remote TUA peer by sending
an SCTP-ASSOCIATE primitive to the local SCTP layer.
.pp
When an SCTP association has been successfully established, the SCTP
will send an SCTP-COMMUNICATION_UP notification primitive to the local TUA
layer.  At the SGP or IPSP that initiated the request, the TUA layer will send
an M-SCTP_ESTABLISH confirm primitive to Layer Management when the association
setup is complete.  At the peer TUA layer, an M-SCTP_ESTABLISH indication
primitive is sent to Layer Management upon successful completion of an
incoming SCTP association setup.
.pp
An M-SCTP_RELEASE request primitive from Layer Management initiates the
shutdown of an SCTP association.  The TUA layer accomplishes a graceful
shutdown of the SCTP association by sending an SCTP-SHUTDOWN primitive to the
SCTP layer.
.pp
When the graceful shutdown of the SCTP association has been accomplished, the
SCTP layer returns an SCTP-SHUTDOWN_COMPLETE notification primitive to the
local TUA layer.  At the TUA Layer that initiated the request, the TUA layer
will send an M-SCTP_RELEASE confirm primitive to Layer Management when the
association shutdown is complete.  At the peer TUA Layer, an M-SCTP_RELEASE
indication primitive is sent to Layer Management upon abort or successful
shutdown of an SCTP association.
.pp
An M-SCTP_STATUS request primitive supports a Layer Management query of the
local status of a particular SCTP association.  The TUA layer simply maps the
M-SCTP_STATUS request primitive to an SCTP-STATUS primitive to the SCTP layer.
When the SCTP responds, the TUA layer maps the association status information
to an M-SCTP_STATUS confirm primitive.  No peer protocol is invoked.
.pp
Similar LM-to-TUA-to-SCTP and SCTP-to-TUA-to-LM primitive mappings can be
described for the various other SCTP Upper Layer primitives in RFC 2960 [2960]
such as INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT, REQUEST HEARTBEAT, GET SRTT
REPORT, SET FAILURE THRESHOLD, SET PROTOCOL PARAMETERS, DESTROY SCTP INSTANCE,
SEND FAILURE, AND NETWORK STATUS CHANGE.  Alternatively, these SCTP Upper
Layer primitives (and Status as well) can be considered for modeling purposes
as a Layer Management interaction directly with the SCTP Layer.
.pp
M-NOTIFY indication and M-ERROR indication primitives indicate to Layer
Management the notification or error information contained in a received TUA
Notify or Error message respectively.  These indications can also be generated
based on local TUA events.
.pp
An M-ASP_STATUS request primitive supports a Layer Management query of the
status of a particular local or remote ASP.  The TUA layer responds with the
status in an M-ASP_STATUS confirm primitive.  No TUA peer protocol is invoked.
An M-AS_STATUS request supports a Layer Management query of the status of a
particular AS.  The TUA responds with an M-AS_STATUS confirm primitive.  No
TUA peer protocol is invoked.
.pp
M-ASP_UP request, M-ASP_DOWN request, M-ASP_ACTIVE request and M- ASP_INACTIVE
request primitives allow Layer Management at an ASP to initiate state changes.
Upon successful completion, a corresponding confirm primitive is provided by
the TUA layer to Layer Management.  If an invocation is unsuccessful, an Error
indication primitive is provided in the primitive.  These requests result in
outgoing ASP Up, ASP Down, ASP Active and ASP Inactive messages to the remote
TUA peer at an SGP or
IPSP.
.sh 2 "Procedures to Support the Management of SCTP Associations"
.sh 3 "Receipt of TUA Peer Management Messages"
.pp
Upon successful state changes resulting from reception of ASP Up, ASP Down,
ASP Active and ASP Inactive messages from a peer TUA, the TUA layer
\fB\)MAY\fR invoke corresponding M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE and
M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-AS_DOWN indication
primitives to the local Layer Management.
.pp
M-NOTIFY indication and M-ERROR indication primitives indicate to Layer
Management the notification or error information contained in a received TUA
Notify or Error message.  These indications can also be generated based on
local TUA events.
.pp
All MGMT, ASPSM, ASPTM and RKM messages, except BEAT and BEAT Ack,
\fB\)SHOULD\fR be sent with sequenced delivery to ensure ordering.  All MGMT,
ASPSM and RKM messages, with the exception of BEAT and BEAT Ack messages
\fB\)MUST\fR be sent on SCTP stream '0'.  ASPTM messages \fB\)MAY\fR be sent
on one of the streams used to carry data traffic related to the Routing
Context(s), to minimize possible message loss.  BEAT and BEAT Ack messages
\fB\)MAY\fR be sent using out-of-order delivery, and \fB\)MAY\fR be sent on
any stream.
.sh 2 "AS and ASP State Maintenance"
.pp
The TUA layer on the SGP maintains the state of each remote ASP, in each
Application Server that the ASP is configured to receive traffic, as input to
the TUA message distribution function.  Similarly, where IPSPs use TUA in a
point-to-point fashion, the TUA layer in an IPSP maintains the state of remote
IPSPs.  For the purposes of the following procedures, only the SGP and ASP
case is described but the SGP side of the procedures also apply to an IPSP
sending traffic to an AS consisting of a set of remote IPSPs.
.sh 3 "ASP States"
.pp
The state of each remote ASP, in each AS that it is configured to operate, is
maintained in the TUA layer in the SGP.  The state of a particular ASP in a
particular AS changes due to events.  The events include:
.bu
reception of messages from the peer TUA layer at the ASP;
.bu
reception of some messages from the peer TUA layer at other ASPs in the AS
(e.g, ASP Active message indicating "Override");
.bu
reception of indications from the SCTP layer; or,
.bu
Local Management intervention.
.ie '\*(.T'ps' \{\
.\"'
.(z
.so tua05.pic
.#f "ASP State Transition Diagram (Per AS)"
.)z
.\}
.el \{
.(z
.(c
.nf
.sz -2
\fC\
                                 +--------------+
                                 |              |
          +----------------------|  ASP-ACTIVE  |
          |      Other   +-------|              |
          |   ASP in AS  |       +--------------+
          |   Overrides  |           ^     |
          |              |    ASP    |     | ASP
          |              |    Active |     | Inactive
          |              |           |     v
          |              |       +--------------+
          |              |       |              |
          |              +------>| ASP-INACTIVE |
          |                      +--------------+
          |                          ^     |
ASP Down/ |                     ASP  |     | ASP Down /
SCTP CDI/ |                     Up   |     | SCTP CDI/
SCTP RI   |                          |     v SCTP RI
          |                      +--------------+
          |                      |              |
          +--------------------->|   ASP-DOWN   |
                                 |              |
                                 +--------------+
.sz +2
.)c
.#f "ASP State Transition Diagram (Per AS)"
.)z
.\}
.pp
The ASP state transition diagram is shown in \fI\*(&f\n(&p\fR.  The possible
states of an ASP are:
.ip "ASP-DOWN:" 14
The remote TUA peer at the ASP is unavailable or the related SCTP association
is down.  Initially all ASPs will be in this state.  An ASP in this state
\fB\)SHOULD NOT\fR be sent any TUA messages, with the exception of Heartbeat,
ASP Down Ack and Error messages.
.ip "ASP-INACTIVE:" 14
The remote TUA peer at the ASP is available (and the related SCTP association
is up) but application traffic is stopped.  In this state, the ASP \fB\)SHOULD
NOT\fR be sent any DH, CH or SSNM messages for the AS for which the ASP is
inactive.
.ip "ASP-ACTIVE:" 14
The remote TUA peer at the ASP is available and application traffic is active
(for a particular Routing Context or set of Routing Contexts).
.ip "SCTP CDI:" 14
The SCTP CDI denotes the local SCTP layer's Communication Down Indication to
the Upper Layer Protocol (TUA) on an SGP.  The local SCTP layer will send this
indication when it detects the loss of connectivity to the ASPs peer SCTP
layer.  SCTP CDI is understood as either a SHUTDOWN_COMPLETE notification or
COMMUNICATION_LOST notification from the SCTP layer.
.ip "SCTP RI:" 14
The local SCTP layer's Restart indication to the upper layer protocol (TUA) on
an SG.  The local SCTP will send this indication when it detects a restart
from the ASPs peer SCTP layer.
.sh 3 "AS States"
.pp
The state of the AS is maintained in the TUA layer on the SGP.  The state of
an AS changes due to events.  These events include:
.bu
ASP state transitions
.bu
Recovery timer triggers
.pp
The possible states of an AS are:
.ip "AS-DOWN:" 14
The Application Server is unavailable.  This state implies that all related
ASPs are in the ASP-DOWN state for this AS.  Initially the AS will be in this
state.  An Application Server is in the AS-DOWN state when it is removed from
a configuration.
.ip "AS-INACTIVE:" 14
The Application Server is available but no application traffic is active
(i.e., one or more related ASPs are in the ASP-INACTIVE state, but none in the
ASP-ACTIVE state).  The recovery timer T(r) is not running or has expired.
.ip "AS-ACTIVE:" 14
The Application Server is available and application traffic is active.  This
state implies that at least one ASP is in the ASP-ACTIVE state.
.ip "AS-PENDING:" 14
An active ASP has transitioned to ASP-INACTIVE or ASP-DOWN and it was the last
remaining active ASP in the AS.  A recovery timer T(r) \fB\)SHOULD\fR be
started and all incoming signalling messages \fB\)SHOULD\fR be queued by the
SGP.  If an ASP becomes ASP-ACTIVE before T(r) expires, the AS is moved to the
AS-ACTIVE state and all the queued messages will be sent to the ASP.
.pp
If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no other
alternative, the SGP may stop queuing messages and discard all previously
queued messages.  The AS will move to the AS-INACTIVE state if at least one
ASP is in ASP-INACTIVE state, otherwise it will move to AS-DOWN state.
.(z
.ie '\*(.T'ps' \{\
.\"'
.so tua06.pic
.\}
.el \{
.(c
.nf
.sz -2
\fC\
     +----------+   one ASP trans to ACTIVE   +-------------+
     |    AS-   |---------------------------->|     AS-     |
     | INACTIVE |                             |   ACTIVE    |
     |          |<---                         |             |
     +----------+    \\                        +-------------+
        ^   |         \\ Tr Expiry,                ^    |
        |   |          \\ at least one             |    |
        |   |           \\ ASP in ASP-INACTIVE     |    |
        |   |            \\                        |    |
        |   |             \\                       |    |
        |   |              \\                      |    |
one ASP |   | all ASP       \\            one ASP  |    | Last ACTIVE
trans   |   | trans to       \\           trans to |    | ASP trans to
to      |   | ASP-DOWN        -------\\   ASP-     |    | ASP-INACTIVE
ASP-    |   |                         \\  ACTIVE   |    | or ASP-DOWN
INACTIVE|   |                          \\          |    | (start Tr)
        |   |                           \\         |    |
        |   |                            \\        |    |
        |   v                             \\       |    v
     +----------+                          \\  +-------------+
     |          |                           --|             |
     | AS-DOWN  |                             | AS-PENDING  |
     |          |                             |  (queuing) |
     |          |<----------------------------|             |
     +----------+    Tr Expiry and no ASP     +-------------+
                     in ASP-INACTIVE state

       Tr = Recovery Timer
.sz +2
.)c
.\}
.#f "AS State Transition Diagram"
.)z
.pp
\fI\*(&f\n(&p\fR shows an example AS state machine for the case where the AS
data is pre-configured.  For other cases where the ASP configuration data is
created dynamically, there would be differences in the state machine,
especially at creation of the AS.
.pp
For example, where the AS configuration data is not created until Registration
of the first ASP, the AS-INACTIVE state is entered directly upon the first
successful REG REQ from an ASP.  Another example is where the AS configuration
data is not created until the first ASP successfully enters the ASP-ACTIVE
state.  In this case the AS-ACTIVE state is entered directly.
.sh 4 "IPSP Considerations"
.pp
The AS state diagram for the AS-SG case is applicable for IPSP communication.
.sh 3 "TUA Management Procedures for Primitives"
.pp
Before the establishment of an SCTP association the ASP state at both the SGP
and ASP is assumed to be in the state ASP-DOWN.
.pp
Once the SCTP association is established (see Section 4.2.1) and
assuming that the local TC-User is ready, the local TUA ASP Maintenance
(ASPM) function will initiate the relevant procedures, using the ASP Up,
ASP Down, ASP Active and ASP Inactive messages to convey the ASP state
to the SGP (see Section 4.3.4).
.pp
If the TUA layer subsequently receives an SCTP-COMMUNICATION_DOWN or
SCTP-RESTART indication primitive from the underlying SCTP layer, it
will inform the Layer Management by invoking the M-SCTP_STATUS
indication primitive.  The state of the ASP will be moved to ASP-DOWN.
.pp
At an ASP, the TC-User will be informed of the unavailability of any affected
SS7 destination through the use of N-PCSTATE indication primitives.
.pp
In the case of SCTP-COMMUNICATION_DOWN, the SCTP client \fB\)MAY\fR try to
re-establish the SCTP association.  This \fB\)MAY\fR be done by the TUA layer
automatically, or Layer Management \fB\)MAY\fR re-establish using the M-
SCTP_ESTABLISH request primitive.
.pp
In the case of an SCTP-RESTART indication at an ASP, the ASP is now considered
by its TUA peer to be in the ASP-DOWN state.  The ASP, if it is to recover,
must begin any recovery with the ASP-Up procedure.
.sh 3 "ASPM Procedures for Peer-to-Peer Messages"
.sh 4 "ASP Up Procedures"
.pp
After an ASP has successfully established an SCTP association to an SGP, the
SGP waits for the ASP to send an ASP Up message, indicating that the ASP TUA
peer is available.  The ASP is always the initiator of the ASP Up message.
This action \fB\)MAY\fR be initiated at the ASP by an M-ASP_UP request
primitive from Layer Management or \fB\)MAY\fR be initiated automatically by
an TUA management function.
.pp
When an ASP Up message is received at an SGP and internally the remote ASP is
in the ASP-DOWN state and not considered locked-out for local management
reasons, the SGP marks the remote ASP in the state ASP-INACTIVE and informs
Layer Management with an M-ASP_Up indication primitive.  If the SGP is aware,
via current configuration data, which Application Servers the ASP is
configured to operate in, the SGP updates the ASP state to ASP-INACTIVE in
each AS that it is a member.
.pp
Alternatively, the SGP may move the ASP into a pool of Inactive ASPs available
for future configuration within Application Server(s), determined in a
subsequent Registration Request or ASP Active procedure.  If the ASP Up
message contains an ASP Identifier, the SGP should save the ASP Identifier for
that ASP.  The SGP \fB\)MUST\fR send an ASP Up Ack message in response to a
received ASP Up message even if the ASP is already marked as ASP-INACTIVE at
the SGP.
.pp
If for any local reason (e.g, management lock-out) the SGP cannot respond with
an ASP Up Ack message, the SGP responds to an ASP Up message with an Error
message with Reason "Refused - Management Blocking".
.pp
At the ASP, the ASP Up Ack message received is not acknowledged.  Layer
Management is informed with an M-ASP_UP confirm primitive.
.pp
When the ASP sends an ASP Up message it starts timer T(ack).  If the ASP does
not receive a response to an ASP Up message within T(ack), the ASP \fB\)MAY\fR
restart T(ack) and resend ASP Up messages until it receives an ASP Up Ack
message.  T(ack) is provisionable, with a default of 2 seconds.
Alternatively, retransmission of ASP Up messages \fB\)MAY\fR be put under
control of Layer Management.  In this method, expiry of T(ack) results in an
M-ASP_UP confirm primitive carrying a negative indication.
.pp
The ASP must wait for the ASP Up Ack message before sending any other TUA
messages (e.g, ASP Active or REG REQ).  If the SGP receives any other TUA
messages before ASPUP message is received (other than ASPDN - see Section
4.3.4.2), the SGP \fB\)SHOULD\fR discard them.
.pp
If an ASP Up message is received and internally the remote ASP is in the
ASP-ACTIVE state, an ASP Up Ack message is returned, as well as an Error
message ("Unexpected Message), and the remote ASP state is changed to
ASP-INACTIVE in all relevant Application Servers.
.pp
If an ASP Up message is received and internally the remote ASP is already in
the ASP-INACTIVE state, an ASP Up Ack message is returned and no further
action is taken.
.sh 5 "TUA Version Control"
.pp
If an ASP Up message with an unsupported version is received, the receiving
end responds with an Error message, indicating the version the receiving node
supports and notifies Layer Management.
.pp
This is useful when protocol version upgrades are being performed in a
network.  A node upgraded to a newer version should support the older versions
used on other nodes it is communicating with.  Because ASPs initiate the ASP
Up procedure it is assumed that the Error message would normally come from the
SGP.
.sh 5 "IPSP Considerations"
.pp
An IPSP may be considered in the ASP-INACTIVE state after and ASPUP or ASPUP
Ack has been received from it.  An IPSP can be considered in the ASP-DOWN
state after an ASPDN or ASPDN Ack has been received from it.  The IPSP may
inform Layer Management of the change in state of the remote IPSP using
M-ASP_UP or M-ASP_DN indication or confirmation primitives.
.pp
Alternatively, an interchange of ASPUP messages from each end can be
performed.  This option follows the ASP state transition diagram.  It would
need four messages for completion.
.pp
If for any local reason (e.g, management lock-out) and IPSP cannot respond to
an ASP Up message with an ASP Up Ack message, it responds to an ASP Up message
with an Error message with Reason "Refused - Management Blocking" and leaves
the remote IPSP in the ASP-DOWN state.
.sh 4 "ASP Down Procedures"
.pp
The ASP will send an ASP Down message to an SGP when the ASP wishes to be
removed from service in all Application Servers that it is a member and no
longer receive any DATA, SSNM or ASPTM messages.  This action \fB\)MAY\fR be
initiated at the ASP by an M-ASP_DOWN request primitive from Layer Management
or \fB\)MAY\fR be initiated automatically by an TUA management function.
.pp
Whether the ASP is permanently removed from any AS is a function of
configuration management.  Whenever the ASP previously used the Registration
procedures (see Section 4.4.1) to register within Application Servers but has
not deregistered from all of them prior to sending the ASP Down message, the
SGP \fB\)MUST\fR consider the ASP as Deregistered in all Application Servers
that it is still a member.
.pp
The SGP marks the ASP as ASP-DOWN, informs Layer Management with an M-ASP_Down
indication primitive, and returns an ASP Down Ack message to the ASP.
.pp
The SGP \fB\)MUST\fR send an ASP Down Ack message in response to a received
ASP Down message from the ASP even if the ASP is already marked as ASP-DOWN at
the SGP.
.pp
At the ASP, the ASP Down Ack message received is not acknowledged.  Layer
Management is informed with an M-ASP_DOWN confirm primitive.  If the ASP
receives an ASP Down Ack without having sent an ASP Down message, the ASP
should now consider itself as in the ASP-DOWN state.  If the ASP was
previously in the ASP-ACTIVE or ASP_INACTIVE state, the ASP should then
initiate procedures to return itself to its previous state.
.pp
When the ASP sends an ASP Down message it starts timer T(ack).  If the ASP
does not receive a response to an ASP Down message within T(ack), the ASP
\fB\)MAY\fR restart T(ack) and resend ASP Down messages until it receives an
ASP Down Ack message.  T(ack) is provisionable, with a default of 2 seconds.
Alternatively, retransmission of ASP Down messages \fB\)MAY\fR be put under
control of Layer Management.  In this method, expiry of T(ack) results in an
M-ASP_DOWN confirm primitive carrying a negative indication.
.sh 4 "ASP Active Procedures"
.pp
Anytime after the ASP has received an ASP Up Ack message from the SGP or IPSP,
the ASP \fB\)MAY\fR send an ASP Active message to the SGP indicating that the
ASP is ready to start processing traffic.  This action \fB\)MAY\fR be
initiated at the ASP by an M-ASP_ACTIVE request primitive from Layer
Management or \fB\)MAY\fR be initiated automatically by an TUA management
function.  Whenever an ASP wishes to process the traffic for more than one
Application Server across a common SCTP association, the ASP Active message(s)
\fB\)SHOULD\fR contain a list of one or more Routing Contexts to indicate for
which Application Servers the ASP Active message applies.  It is not necessary
for the ASP to include all Routing Contexts of interest in a single ASP Active
message, thus requesting to become active in all Routing Contexts at the same
time.  Multiple ASP Active messages \fB\)MAY\fR be used to activate within the
Application Servers independently, or in sets.  Whenever an ASP Active message
does not contain a Routing Context parameter, the receiver must know, via
configuration data, which Application Server(s) the ASP is a member.
.pp
For the Application Servers that the ASP can successfully activate, the SGP or
IPSP responds with one or more ASP Active Ack messages, including the
associated Routing Context(s) and reflecting any Traffic Mode Type values
present in the related ASP Active message.  The Routing Context parameter
\fB\)MUST\fR be included in the ASP Active Ack message(s) if the received ASP
Active message contained any Routing Contexts.  Depending on any Traffic Mode
Type request in the ASP Active message or local configuration data if there is
no request, the SGP moves the ASP to the correct ASP traffic state within the
associated Application Server(s).  Layer Management is informed with an
M-ASP_Active indication.  If the SGP or IPSP receives any Data messages before
an ASP Active message is received, the SGP or IPSP \fB\)MAY\fR discard them.
By sending an ASP Active Ack message, the SGP or IPSP is now ready to receive
and send traffic for the related Routing Context(s).  The ASP \fB\)SHOULD
NOT\fR send Data messages for the related Routing Context(s) before receiving
an ASP Active Ack message, or it will risk message loss.
.pp
Multiple ASP Active Ack messages \fB\)MAY\fR be used in response to an ASP
Active message containing multiple Routing Contexts, allowing the SGP or IPSP
to independently acknowledge the ASP Active message for different (sets of)
Routing Contexts.  The SGP or IPSP \fB\)MUST\fR send an Error message
("Invalid Routing Context") for each Routing Context value that cannot be
successfully activated.
.pp
Whenever an "out-of-the-blue" ASP Active message is received (i.e., the ASP
has not registered with the SG or the SG has no static configuration data for
the ASP), the message \fB\)MAY\fR be silently discarded.
.pp
The SGP \fB\)MUST\fR send an ASP Active Ack message in response to a received
ASP Active message from the ASP, if the ASP is already marked in the
ASP-ACTIVE state at the SGP.
.pp
At the ASP, the ASP Active Ack message received is not acknowledged.  Layer
Management is informed with an M-ASP_ACTIVE confirm primitive.  It is possible
for the ASP to receive Data message(s) before the ASP Active Ack message as
the ASP Active Ack and Data messages from an SG or IPSP may be sent on
different SCTP streams.  Message loss is possible, as the ASP does not
consider itself in the ASP-ACTIVE state until reception of the ASP Active Ack
message.
.pp
When the ASP sends an ASP Active message it starts timer T(ack).  If the ASP
does not receive a response to an ASP Active message within T(ack), the ASP
\fB\)MAY\fR restart T(ack) and resend ASP Active messages until it receives an
ASP Active Ack message.  T(ack) is provisionable, with a default of 2 seconds.
Alternatively, retransmission of ASP Active messages \fB\)MAY\fR be put under
control of Layer Management.  In this method, expiry of T(ack) results in an
M-ASP_ACTIVE confirm primitive carrying a negative indication.
.pp
There are three modes of Application Server traffic handling in the SGP TUA
layer: Override, Load-share and Broadcast.  When included, the Traffic Mode
Type parameter in the ASP Active message indicates the traffic-handling mode
to be used in a particular Application Server.  If the SGP determines that the
mode indicated in an ASP Active message is unsupported or incompatible with
the mode currently configured for the AS, the SGP responds with an Error
message ("Unsupported/Invalid Traffic Handling Mode").  If the traffic-
handling mode of the Application Server is not already known via configuration
data, then the traffic-handling mode indicated in the first ASP Active message
causing the transition of the Application Server state to AS-ACTIVE
\fB\)MAY\fR be used to set the mode.
.pp
In the case of an Override mode AS, reception of an ASP Active message at an
SGP causes the (re)direction of all traffic for the AS to the ASP that sent
the ASP Active message.  Any previously active ASP in the AS is now considered
to be in state ASP-INACTIVE and \fB\)SHOULD\fR no longer receive traffic from
the SGP within the AS.  The SGP or IPSP then \fB\)MUST\fR send a Notify
message ("Alternate ASP Active") to the previously active ASP in the AS, and
\fB\)SHOULD\fR stop traffic to or from that ASP.  The ASP receiving this
Notify \fB\)MUST\fR consider itself now in the ASP-INACTIVE state, if it is
not already aware of this via inter- ASP communication with the Overriding
ASP.
.pp
In the case of a Load-share mode AS, reception of an ASP Active message at an
SGP or IPSP causes the direction of traffic to the ASP sending the ASP Active
message, in addition to all the other ASPs that are currently active in the
AS.  The algorithm at the SGP for load-sharing traffic within an AS to all the
active ASPs is implementation dependent.  The algorithm could, for example, be
round robin or based on information in the Data message (e.g, the SLS or SSN).
.pp
An SGP or IPSP, upon reception of an ASP Active message for the first ASP in a
Load-share AS, \fB\)MAY\fR choose not to direct traffic to a newly active ASP
until it determines that there are sufficient resources to handle the expected
load (e.g, until there are "n" ASPs in state ASP-ACTIVE in the AS).
.pp
All ASPs within a load-sharing mode AS must be able to process any Data
message received for the AS, to accommodate any potential fail-over or
re-balancing of the offered load.
.pp
In the case of a Broadcast mode AS, reception of an ASP Active message at an
SGP or IPSP causes the direction of traffic to the ASP sending the ASP Active
message, in addition to all the other ASPs that are currently active in the
AS.  The algorithm at the SGP for broadcasting traffic within an AS to all the
active ASPs is a simple broadcast algorithm, where every message is sent to
each of the active ASPs.  An SGP or IPSP, upon reception of an ASP Active
message for the first ASP in a Broadcast AS, \fB\)MAY\fR choose not to direct
traffic to a newly active ASP until it determines that there are sufficient
resources to handle the expected load (e.g, until there are "n" ASPs in state
ASP-ACTIVE in the AS).
.pp
Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP
\fB\)MUST\fR tag the first DATA message broadcast in each SCTP stream with a
unique Correlation Id parameter.  The purpose of this Correlation Id is to
permit the newly active ASP to synchronize it's processing of traffic in each
ordered stream with the other ASPs in the broadcast group.
.sh 5 "IPSP Considerations"
.pp
Either of the IPSPs can initiate communication.  When an IPSP receives an ASP
Active, it should mark the peer as ASP-ACTIVE and return an ASP Active Ack
message.  An ASP receiving an ASP Active Ack message may mark the peer as
ASP-Active, if it is not already in the ASP- ACTIVE state.
.pp
Alternatively, an interchange of ASPAC messages from each end can be
performed.  This option follows the ASP state transition diagram and gives the
additional advantage of selecting a particular AS to be activated from each
end.  It is especially useful when an IPSP is serving more than one AS.  It
would need four messages for completion.
.sh 4 "ASP Inactive Procedures"
.pp
When an ASP wishes to withdraw from receiving traffic within an AS, the ASP
sends an ASP Inactive message to the SGP or IPSP.  This action \fB\)MAY\fR be
initiated at the ASP by an M-ASP_INACTIVE request primitive from Layer
Management or \fB\)MAY\fR be initiated automatically by an TUA management
function.  Whenever an ASP is processing the traffic for more than one
Application Server across a common SCTP association, the ASP Inactive message
contains one or more Routing Contexts to indicate for which Application
Servers the ASP Inactive message applies.  Whenever an ASP Inactive message
does not contain a Routing Context parameter, the receiver must know, via
configuration data, which Application Servers the ASP is a member and move the
ASP to the ASP-INACTIVE state in each all Application Servers.  In the case of
an Override mode AS, where another ASP has already taken over the traffic
within the AS with an ASP Active ("Override") message, the ASP that sends the
ASP Inactive message is already considered by the SGP to be in state
ASP-INACTIVE.  An ASP Inactive Ack message is sent to the ASP, after ensuring
that all traffic is stopped to the ASP.
.pp
In the case of a Load-share mode AS, the SGP moves the ASP to the ASP-INACTIVE
state and the AS traffic is re-allocated across the remaining ASPs in the
state ASP-ACTIVE, as per the load-sharing algorithm currently used within the
AS.  A Notify message ("Insufficient ASP resources active in AS") \fB\)MAY\fR
be sent to all inactive ASPs, if required.  An ASP Inactive Ack message is
sent to the ASP after all traffic is halted and Layer Management is informed
with an M-ASP_INACTIVE indication primitive.
.pp
In the case of a Broadcast mode AS, the SGP moves the ASP to the ASP- INACTIVE
state and the AS traffic is broadcast only to the remaining ASPs in the state
ASP-ACTIVE.  A Notify message ("Insufficient ASP resources active in AS")
\fB\)MAY\fR be sent to all inactive ASPs, if required.  An ASP Inactive Ack
message is sent to the ASP after all traffic is halted and Layer Management is
informed with an M-ASP_INACTIVE indication primitive.
.pp
Multiple ASP Inactive Ack messages \fB\)MAY\fR be used in response to an ASP
Inactive message containing multiple Routing Contexts, allowing the SGP or
IPSP to independently acknowledge for different (sets of) Routing Contexts.
The SGP or IPSP sends an Error message ("Invalid Routing Context") message for
each invalid or unconfigured Routing Context value in a received ASP Inactive
message.
.pp
The SGP \fB\)MUST\fR send an ASP Inactive Ack message in response to a
received ASP Inactive message from the ASP and the ASP is already marked as
ASP-INACTIVE at the SGP.
.pp
At the ASP, the ASP Inactive Ack message received is not acknowledged.  Layer
Management is informed with an M-ASP_INACTIVE confirm primitive.  If the ASP
receives an ASP Inactive Ack without having sent an ASP Inactive message, the
ASP should now consider itself as in the ASP-INACTIVE state.  If the ASP was
previously in the ASP-ACTIVE state, the ASP should then initiate procedures to
return itself to its previous state.  When the ASP sends an ASP Inactive
message it starts timer T(ack).  If the ASP does not receive a response to an
ASP Inactive message within T(ack), the ASP \fB\)MAY\fR restart T(ack) and
resend ASP Inactive messages until it receives an ASP Inactive Ack message.
T(ack) is provisionable, with a default of 2 seconds.  Alternatively,
retransmission of ASP Inactive messages \fB\)MAY\fR be put under control of
Layer Management.  In this method, expiry of T(ack) results in a
M-ASP_Inactive confirm primitive carrying a negative indication.
.pp
If no other ASPs in the Application Server are in the state ASP- ACTIVE, the
SGP \fB\)MUST\fR send a Notify message ("AS-Pending") to all of the ASPs in
the AS which are in the state ASP-INACTIVE.  The SGP \fB\)SHOULD\fR start
buffering the incoming messages for T(r) seconds, after which messages
\fB\)MAY\fR be discarded.  T(r) is configurable by the network operator.  If
the SGP receives an ASP Active message from an ASP in the AS before expiry of
T(r), the buffered traffic is directed to that ASP and the timer is canceled.
If T(r) expires, the AS is moved to the AS-INACTIVE state.
.sh 5 "IPSP Considerations"
.pp
An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP after an
ASP Inactive or ASP Inactive Ack message has been received from it.
.pp
Alternatively, an interchange of ASPIA messages from each end can be
performed.  This option follows the ASP state transition diagram and gives the
additional advantage of selecting a particular AS to be deactivated from each
end.  It is especially useful when an IPSP is serving more than one AS.  It
would need four messages for completion.
.sh 4 "Notify Procedures"
.pp
A Notify message reflecting a change in the AS state \fB\)MUST\fR be sent to
all ASPs in the AS, except those in the ASP-DOWN state, with appropriate
Status Information and any ASP Identifier of the failed ASP.  At the ASP,
Layer Management is informed with an M- NOTIFY indication primitive.  The
Notify message must be sent whether the AS state change was a result of an ASP
failure or reception of an ASP State management (ASPSM) or ASP Traffic
Management (ASPTM) message.  In the second case, the Notify message
\fB\)MUST\fR be sent after any ASP State or Traffic Management related
acknowledgments messages (e.g, ASP Up Ack, ASP Down Ack, ASP Active Ack, or
ASP Inactive Ack).
.pp
Whenever a Notify ("AS-PENDING") message is sent by an SGP that now has no
ASPs active to service the traffic, or where a Notify ("Insufficient ASP
resources active in AS") message \fB\)MUST\fR be sent in the Load-share or
Broadcast mode, the Notify message does not explicitly compel the ASP(s)
receiving the message to become active.  The ASPs remain in control of what
(and when) traffic action is taken.
.pp
Whenever a Notify message does not contain a Routing Context parameter, the
receiver must know, via configuration data, of which Application Servers the
ASP is a member and take the appropriate action in each AS.
.sh 5 "IPSP Considerations (NTFY)"
.pp
Notify works in the same manner as in the SG-AS case.  One of the IPSPs can
send this message to any remote IPSP that is not in the ASP-DOWN state.
.sh 4 "Heartbeat Procedures"
.pp
The optional Heartbeat procedures \fB\)MAY\fR be used when operating over
transport layers that do not have their own heartbeat mechanism for detecting
loss of the transport association (i.e., other than SCTP).
.pp
Either TUA peer may optionally send Heartbeat messages periodically, subject
to a provisionable timer T(beat).  Upon receiving a Heartbeat message, the TUA
peer \fB\)MUST\fR respond with a Heartbeat Ack message.
.pp
If no Heartbeat Ack message (or any other TUA message) is received from the
TUA peer within 2*T(beat), the remote TUA peer is considered unavailable.
Transmission of Heartbeat messages is stopped and the signalling process
\fB\)SHOULD\fR attempt to re-establish communication if it is configured as
the client for the disconnected TUA peer.
.pp
The Heartbeat message may optionally contain an opaque Heartbeat Data
parameter that \fB\)MUST\fR be echoed back unchanged in the related Heartbeat
Ack message.  The sender, upon examining the contents of the returned
Heartbeat Ack message, \fB\)MAY\fR choose to consider the remote TUA peer as
unavailable.  The contents and format of the Heartbeat Data parameter is
implementation-dependent and only of local interest to the original sender.
The contents may be used, for example, to support a Heartbeat sequence
algorithm (to detect missing Heartbeats), or a time-stamp mechanism (to
evaluate delays).
.pp
Note: Heartbeat related events are not shown in Figure 4 "ASP state transition
diagram".
.sh 2 "Routing Key Management Procedures"
.sh 3 "Registration"
.pp
An ASP \fB\)MAY\fR dynamically register with an SGP as an ASP within an
Application Server using the REG REQ message.  A Routing Key parameter in the
REG REQ message specifies the parameters associated with the Routing Key.
.pp
The SGP examines the contents of the received Routing Key parameter and
compares it with the currently provisioned Routing Keys.  If the received
Routing Key matches an existing SGP Routing Key entry, and the ASP is not
currently included in the list of ASPs for the related Application Server, the
SGP \fB\)MAY\fR authorize the ASP to be added to the AS.  Or, if the Routing
Key does not currently exist and the received Routing Key data is valid and
unique, an SGP supporting dynamic configuration \fB\)MAY\fR authorize the
creation of a new Routing Key and related Application Server and add the ASP
to the new AS.  In either case, the SGP returns a Registration Response
message to the ASP, containing the same Local-RK-Identifier as provided in the
initial request, and a Registration Result "Successfully Registered".  A
unique Routing Context value assigned to the SGP Routing Key is included.  The
method of Routing Context value assignment at the SGP is implementation
dependent but must be guaranteed to be unique for each Application Server or
Routing Key supported by the SGP.   If the SGP determines that the received
Routing Key data is invalid, or contains invalid parameter values, the SGP
returns a Registration Response message to the ASP, containing a Registration
Result "Error - Invalid Routing Key", "Error
- Invalid DPC", "Error - Invalid Network Appearance" as appropriate.
.pp
If the SGP does not support the registration procedure, the SGP returns an
Error message to the ASP, with an error code of "Unsupported Message Type".
.pp
If the SGP determines that a unique Routing Key cannot be created, the SGP
returns a Registration Response message to the ASP, with a Registration Status
of "Error - "Cannot Support Unique Routing." An incoming signalling message
received at an SGP should not match against more than one Routing Key.
.pp
If the SGP does not authorize the registration request, the SGP returns a REG
RSP message to the ASP containing the Registration Result "Error - Permission
Denied".
.pp
If an SGP determines that a received Routing Key does not currently exist and
the SGP does not support dynamic configuration, the SGP returns a Registration
Response message to the ASP, containing a Registration Result "Error - Routing
Key not Currently Provisioned".
.pp
If an SGP determines that a received Routing Key does not currently exist and
the SGP supports dynamic configuration but does not have the capacity to add
new Routing Key and Application Server entries, the SGP returns a Registration
Response message to the ASP, containing a Registration Result "Error -
Insufficient Resources".
.pp
If an SGP determines that one or more of the Routing Key parameters are not
supported for the purpose of creating new Routing Key entries, the SGP returns
a Registration Response message to the ASP, containing a Registration Result
"Error - Unsupported RK parameter field".  This result \fB\)MAY\fR be used if,
for example, the SGP does not support RK Address parameter.
.pp
A Registration Response "Error - Unsupported Traffic Handling Mode" is
returned if the Routing Key in the REG REQ contains a Traffic Handling Mode
that is inconsistent with the presently configured mode for the matching
Application Server.
.pp
An ASP \fB\)MAY\fR register multiple Routing Keys at once by including a
number of Routing Key parameters in a single REG REQ message.  The SGP
\fB\)MAY\fR respond to each registration request in a single REG RSP message,
indicating the success or failure result for each Routing Key in a separate
Registration Result parameter.  Alternatively the SGP \fB\)MAY\fR respond with
multiple REG RSP messages, each with one or more Registration Result
parameters.  The ASP uses the Local-RK-Identifier parameter to correlate the
requests with the responses.
.pp
An ASP \fB\)MAY\fR modify an existing Routing Key by including a Routing
Context parameter in the REG REQ.  If the SGP determines that the Routing
Context applies to an existing Routing Key, the SG \fB\)MAY\fR adjust the
existing Routing Key to match the new information provided in the Routing Key
parameter.  A Registration Response "Routing Context Registration Refused" is
returned if the SGP does not accept the modification of the Routing Key.
.pp
Upon successful registration of an ASP in an AS, the SGP can now send related
SS7 Signalling Network Management messaging, if this did not previously start
upon the ASP transition to state ASP-INACTIVE
.sh 3 "Deregistration"
.pp
An ASP \fB\)MAY\fR dynamically deregister with an SGP as an ASP within an
Application Server using the DEREG REQ message.  A Routing Context parameter
in the DEREG REQ message specifies which Routing Keys to deregister.  An ASP
\fB\)SHOULD\fR move to the ASP-INACTIVE state for an Application Server before
attempting to deregister the Routing Key (i.e., deregister after receiving an
ASP Inactive Ack).  Also, an ASP \fB\)SHOULD\fR deregister from all
Application Servers that it is a member before attempting to move to the
ASP-Down state.
.pp
The SGP examines the contents of the received Routing Context parameter and
validates that the ASP is currently registered in the Application Server(s)
related to the included Routing Context(s).  If validated, the ASP is
deregistered as an ASP in the related Application Server.
.pp
The deregistration procedure does not necessarily imply the deletion of
Routing Key and Application Server configuration data at the SGP.  Other ASPs
may continue to be associated with the Application Server, in which case the
Routing Key data \fB\)MUST NOT\fR be deleted.  If a Deregistration results in
no more ASPs in an Application Server, an SGP \fB\)MAY\fR delete the Routing
Key data.
.pp
The SGP acknowledges the deregistration request by returning a DEREG RSP
message to the requesting ASP.  The result of the deregistration is found in
the Deregistration Result parameter, indicating success or failure with cause.
.pp
An ASP \fB\)MAY\fR deregister multiple Routing Contexts at once by including a
number of Routing Contexts in a single DEREG REQ message.  The SGP \fB\)MAY\fR
respond to each deregistration request in a single DEREG RSP message,
indicating the success or failure result for each Routing Context in a
separate Deregistration Result parameter.
.sh 3 "IPSP Considerations (REG/DEREG)"
.pp
The Registration and Deregistration procedures work in the IPSP cases in the
same way as in AS-SG cases.  An IPSP may register an RK in the remote IPSP.
An IPSP is responsible for deregistering the RKs that it has registered.
.sh 2 "Procedures to Support Point Code and Subsystem State"
.sh 3 "At an SGP"
.pp
On receiving an N-STATE, N-PCSTATE, N-COORD indication primitive from the
nodal inter-working function at an SGP, the SGP TUA layer will send a
corresponding SS7 Signalling Network Management (SSNM) DUNA, DAVA, DUPU, DRST
or SCON message (see Section 3) to the TUA peers at concerned ASPs.  The TUA
layer must fill in various fields of the SSNM messages consistently with the
information received in the primitives.
.pp
SSNM messages \fB\)SHOULD NOT\fR be sent on stream "0" and \fB\)MAY\fR use
ordered delivery.
.sh 3 "At an ASP"
.sh 4 "Single SG Configurations"
.pp
At an ASP, upon receiving an SS7 Signalling Network Management (SSNM) message
from the remote TUA Peer, the TUA layer invokes the appropriate primitive
indications to the resident TC-Users.  Local management is informed.
.pp
Whenever a local event has caused the unavailability or congestion status of
SS7 destinations, user parts or subsystems, the TUA layer at the ASP
\fB\)SHOULD\fR pass up appropriate indications in the primitives to the TUA
User, as though equivalent SSNM messages were received.  For example, the loss
of an SCTP association to an SGP may cause the unavailability of a set of SS7
destinations, user parts or subsystems.  N-PCSTATE indication primitives to
the TUA User are appropriate.
.sh 4 "Multiple SG Configurations"
.pp
At an ASP, upon receiving a SS7 Signalling Network Management (SSNM) message
from the remote TUA Peer, the TUA layer updates the status of the affected
route(s) via the originating SG and determines, whether or not the overall
availability or congestion status of the effected destination(s) or
subsystem(s) has changed.  If so, the TUA layer invokes the appropriate
primitive indications to the resident TC-Users \*#.
.(d
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR\  To accomplish the handling of SSNM messages
from multiple SGs in a multiple SG configuration, the TUA layer at an ASP
maintains the status of routes via each SG.
.)d
Local management is informed.
.sh 3 "ASP Auditing"
.pp
An ASP may optionally initiate an audit procedure to inquire of an SG the
availability and, if the national congestion method with multiple congestion
levels and message priorities is used, congestion status of an SS7 destination
or set of destinations.  In addition, the ASP may inquire of an SG the
availability and congestion status of a subsystem.  A Destination Audit (DAUD)
message is sent from the ASP to the SGP requesting the current availability
and congestion status of one or more SS7 destinations or subsystems.
.pp
The DAUD message \fB\)MAY\fR be sent with unordered delivery.  The ASP
\fB\)MAY\fR send the DAUD in the following cases:
.ip "- Periodic:" 14
A Timer originally set upon reception of a DUNA, SCON or DRST message has
expired without a subsequent DAVA, DUNA, SCON or DRST message updating the
availability and congestion status of the affected destinations or subsystems.
The Timer is reset upon issuing a DAUD.  In this case the DAUD is sent to the
SGP that originally sent the SSNM message \*#.
.ip "- Isolation:" 14
The ASP is newly ASP-ACTIVE or has been isolated from an SG for an extended
period.  The ASP \fB\)MAY\fR request the availability and congestion status of
one or more SS7 destinations or subsystems to which it expects to communicate.
.(d
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR\  In the case of a Periodic audit, the auditing
procedure might not be invoked for the case of a received SCON message
containing a congestion level value of "no congestion" or undefined" (i.e.,
congestion Level = "0").  This is because the value indicates either
congestion abatement or that the ITU MTP3 international congestion method is
being used.  In the international congestion method, the MTP3 layer at the SGP
does not maintain the congestion status of any destinations and therefore the
SGP cannot provide any congestion information in response to the DAUD.  For
the same reason, in the second of the cases above a DAUD message cannot reveal
any congested destination(s).
.)d
.pp
The SGP \fB\)MUST\fR either respond to a DAUD messages with SSNM messages
indicating the availability and congestion status of the destination or
subsystem, or \fB\)MUST\fR respond with an ERR ("Destination Status Unknown")
or ERR ("Subsystem Status Unknown") message for each destination or subsystem
requested in the DAUD message.
.pp
The status of each SS7 destination or subsystem requested is indicated in a
DUNA message (if unavailable), a DAVA message (if available), or a DRST (if
restricted and the SGP supports this feature).  If the SS7 destination or
subsystem is available and congested, the SGP responds with an SCON message in
addition to the DAVA message.  If the SS7 destination is restricted and
congested, the SGP responds with an SCON message in addition to the DRST.  If
the SGP cannot return information on the availability or congestion status of
the SS7 destination or subsystem, the SGP responds with an ERR ("Destination
Status Unknown") or ERR ("Subsystem Status Unknown") with a list of all the
destinations and subsystems for which the SGP cannot provide information.
.pp
In some cases, the SGP \fB\)MAY\fR chose not to respond to a DAUD message or a
component of a DAUD message on the basis of policy \*#.
.(d
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR\  For example, an SGP may chose to not respond
to a request for the destination or subsystem status of a specific point code
in the DAUD message because the ASP that issued the DAUD message is not
authorized to obtain information concerning the status of the destination as
requested.
.)d
.pp
Any DUNA or DAVA message in response to a DAUD message \fB\)MAY\fR contain a
list of Affected Point Codes.
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.sh 3 "TCAP \- TUA Interworking at the SG"
.pp
On the SG, the TCAP routing or interworking function determines that the
message must be sent to an AS via the TUA stack, based on information in the
incoming message.  The TUA outgoing mapping function identifies the
appropriate Application Server (AS) and selects an active ASP from the list of
ASPs servicing this AS.  The appropriate ASP can be determined based on the
routing information in the incoming message, local load sharing information,
etc.  The appropriate TUA message is then constructed and sent to the
appropriate endpoint, via the correct SCTP association and stream.
.sh 4 "Primitives received from the local TC-User"
.pp
These support the TUA transport of TC-User boundary primitives.  The same
services as supported by TCAP are to be provided by TUA.  The TC-users at
the SG should be able to use the same primitive interface to TCAP/TUA without
any changes.  The TCAP-TUA interworking function takes care of selecting the
appropriate stack.
.pp
The TUA needs to setup and maintain the appropriate SCTP association to the
selected endpoint.  TUA also manages the usage of SCTP streams.  The address
information passed by the TUA-user at an ASP must contain: .np a valid SS7
address to reach a destination in the SS7 network via the appropriate SCTP
association to a SG .np a valid IP address or host name to reach another ASP in
the IP network via the appropriate SCTP association.
.sh 4 "Segmenting and Reassembly of Components"
.pp
When it is expected that TCAP signalling messages will not fit into the
maximum PDU size of the underlying transport (e.g, SCCP, MTP), then
segmentation and reassembly \fB\)SHOULD\fR be performed by the TC-User.  In
the event that the SG receives a TQRY, TCNV and TRSP message with included or
associated components that exceed the maximum PDU size of the underling
transport, the SGP will respond with a TNOT message with "Segmentation Not
Supported" or "Segmentation Failed" or "Destination cannot perform reassembly"
indicated in the \fI\)Report Cause\fR within the TNOT message considering
local SG SCCP procedures \*#.
.(d
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR\  Typically a TC-User is responsible for
performing the segmentation and reassembly of components.
.)d
.\"j.sh 3 "Distribution of Dialogues over Application Servers"
.\"j.pp
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.sh 1 "Examples of TUA Procedures"
.sh 2 "Establishment of Association and Traffic between SGPs and ASPs"
.sh 4 "Single ASP in an Application Server (""1+0"" sparing)"
.pp
This scenario shows the example TUA message flows for the establishment
of traffic between an SG and an ASP, where only one ASP is configured
within an AS (no backup).  It is assumed that the SCTP association is
already set-up.
.(b
.(c
.nf
.sz -2
\fC\
SG                              ASP
 |                                |
 |<-------------ASP Up------------|
 |-----------ASP-Up Ack---------->|
 |                                |
 |<------- ASP Active-------------|
 |-----ASP Active Ack------------>|
 |                                |
.sz +2
.)c
.)b
.sh 4 "Two ASPs in Application Server (""1+1"" sparing)"
.pp
This scenario shows the example TUA message flows for the establishment
of traffic between an SG and two ASPs in the same Application Server,
where ASP1 is configured to be "active" and ASP2 a "standby" in the
event of communication failure or the withdrawal from service of ASP1.
ASP2 may act as a hot, warm, or cold standby depending on the extent to
which ASP1 and ASP2 share call or transaction state or can communicate
call state under failure or withdrawal events.  The example message flow
is the same whether the ASP-Active messages are Override or Load-share
mode although typically this example would use an Override mode.
.(b
.(c
.nf
.sz -2
\fC\
SG                       ASP1                       ASP2
 |                         |                          |
 |<--------ASP Up----------|                          |
 |-------ASP-Up Ack------->|                          |
 |                         |                          |
 |<-----------------------------ASP Up----------------|
 |-----------------------------ASP-Up Ack------------>|
 |                         |                          |
 |                         |                          |
 |<-------ASP Active-------|                          |
 |------ASP-Active Ack---->|                          |
 |                         |                          |
.sz +2
.)c
.)b
.sh 4 "Two ASPs in an Application Server (""1+1"" sparing, load-sharing case)"
.pp
This scenario shows the example TUA message flows for the establishment
of traffic between an SG and two ASPs in the same Application Server,
where the two ASPs are brought to "active" and load-share the traffic
load.  In this case, one ASP is sufficient to handle the total traffic
load.
.(b
.(c
.nf
.sz -2
\fC\
SG                       ASP1                       ASP2
 |                         |                          |
 |<---------ASP Up---------|                          |
 |--------ASP-Up Ack------>|                          |
 |                         |                          |
 |<------------------------------ASP Up---------------|
 |-----------------------------ASP Up Ack------------>|
 |                         |                          |
 |                         |                          |
 |<--ASP Active -----------|                          |
 |-----ASP-Active Ack----->|                          |
 |                         |                          |
 |<----------------------------ASP Active ------------|
 |-------------------------------ASP-Active Ack------>|
 |                         |                          |
.sz +2
.)c
.)b
.sh 4 "Three ASPs in an Application Server (""n+k"" sparing, load-sharing case)"
.pp
This scenario shows the example TUA message flows for the establishment
of traffic between an SG and three ASPs in the same Application Server,
where two of the ASPs are brought to "active" and share the load.  In
this case, a minimum of two ASPs are required to handle the total
traffic load (2+1 sparing).
.(b
.(c
.nf
.sz -2
\fC\
SG                  ASP1                 ASP2                ASP3
 |                    |                   |                   |
 |<------ASP Up-------|                   |                   |
 |-----ASP-Up Ack---->|                   |                   |
 |                    |                   |                   |
 |<--------------------------ASP Up-------|                   |
 |-------------------------ASP-Up Ack---->|                   |
 |                    |                   |                   |
 |<---------------------------------------------ASP Up--------|
 |---------------------------------------------ASP-Up Ack---->|
 |                    |                   |                   |
 |                    |                   |                   |
 |<--ASP Act ---------|                   |                   |
 |----ASP-Act Ack---->|                   |                   |
 |                    |                   |                   |
 |<--------------------ASP Act  ----------|                   |
 |-----------------------ASP-Act Ack----->|                   |
 |                    |                   |                   |
.sz +2
.)c
.)b
.sh 3 "ASP Traffic Fail-over Examples"
.sh 4 "(1+1 Sparing, withdrawal of ASP, Back-up Override)"
.pp
ASP1 withdraws from service:
.(b
.(c
.nf
.sz -2
\fC\
SG                       ASP1                       ASP2
 |                         |                          |
 |<-----ASP Inactive-------|                          |
 |----ASP Inactive Ack---->|                          |
 |-----------------------NTFY(ASP-Inact.)(Optional)-->|
 |                         |                          |
 |<------------------------------ ASP Active----------|
 |------------------------------ASP-Active Ack------->|
 |                                                    |
.sz +2
.)c
.)b
.ip "Note:" 6
If the SG detects loss of the TUA peer (TUA heartbeat loss or detection
of SCTP failure), the initial SG-ASP1 ASP Inactive message exchange
would not occur.
.sh 4 "(1+1 Sparing, Back-up Override)"
.pp
ASP2 wishes to override ASP1 and take over the traffic:
.(b
.(c
.nf
.sz -2
\fC\
SG                       ASP1                       ASP2
 |                         |                          |
 |<------------------------------ ASP Active----------|
 |-------------------------------ASP-Active Ack------>|
 |----NTFY(Alt ASP-Act)--->|
 |                         |                          |
.sz +2
.)c
.)b
.sh 4 "(n+k Sparing, Load-sharing case, withdrawal of ASP)"
.pp
ASP1 withdraws from service:
.(b
.(c
.nf
.sz -2
\fC\
SG                  ASP1                 ASP2                 ASP3
 |                    |                   |                   |
 |<----ASP Inact.-----|                   |                   |
 |---ASP-Inact Ack--->|                   |                   |
 |                    |                   |                   |
 |---------------------------------NTFY(Ins. ASPs)(Optional)->|
 |                    |                   |                   |
 |<-----------------------------------------ASP Act ----------|
 |-------------------------------------------ASP Act (Ack)--->|
 |                    |                   |                   |
.sz +2
.)c
.)b
.pp
The Notify message to ASP3 is optional, as well as the ASP-Active from
ASP3.  The optional Notify can only occur if the SG maintains knowledge
of the minimum ASP resources required - for example if the SG knows that
"n+k" = "2+1" for a load-share AS and "n" currently equals "1".
.ip "Note:" 6
If the SG detects loss of the ASP1 TUA peer (TUA heartbeat loss or
detection of SCTP failure), the first SG-ASP1 ASP Inactive message
exchange would not occur.
.sh 3 "TCAP/TC-User Service Translation Examples"
.pp
When the TUA layer on the ASP has a DH message to send to the SG, it
will do the following:
.np
Determine the correct SGP
.np
Find the SCTP association to the chosen SGP
.np
Determine the correct stream in the SCTP association based on the DID
.np
Build the DH message, fill TUA Message Header, fill Common Header
.np
Send the DH message to the remote TUA peer in the SG, over the SCTP
association
.pp
When the TUA layer on the SG has a DH message to send to the ASP, it
will do the following:
.np
Determine the AS
.np
Determine the Active ASP (SCTP association) within the AS
.np
Determine the correct stream in the SCTP association based on the DID
.np
Build the DH message, fill in TUA Message Header, fill in Common Header
.np
Send the DH message to the remote TUA peer in the ASP, over the SCTP
association
.pp
An example of the message flows for establishing a dialogue service is
shown below.  An active association between ASP and SG is established
(Section 5.1) prior to the following message flows.
.(b
.(c
.nf
.sz -2
\fC\
           SG                             ASP

                      <----------- Invoke Request
                      <----------- Query(Begin) Request

Conversation(Continue)
    Indication        ---------->
Result Indication     ---------->

                      <----------- Invoke Request
                      <----------- Conversation(Continue) Request
                          .
                          .
                          .
End(response)Indication ----------->

    Result Indication ----------->
.fi
.sz +2
.)c
.)b
.pp
An example of the message flows for a failed attempt to establish a
dialogue on the signalling channel is shown below.  In this case, the
gateway has a problem with its physical connection , so it cannot
establish a dialogue on the signalling channel.
.(b
.(c
.nf
.sz -2
\fC\
      SG                             ASP

                   <----------- Invoke Request
                   <----------- Query(Begin) Request

Abort Indication   ---------->
.fi
.sz +2
.)c
.)b
.sh 2 "IP-IP Architecture"
.pp
The sequences below outline logical steps for a variety of scenarios
within an IP-IP architecture.  Please note that these scenarios cover a
Primary/Backup configuration.  Where there is a load-sharing
configuration then the AS can declare availability when 1 ASP issues
ASPAC but can only declare unavailability when all ASPs have issued
ASPIA.
.sh 3 "Establishment of TUA connectivity"
.pp
The following shows an example establishment of TUA connectivity.  In
this example, each IP SP consists of a Management Instance (MI) and two
ASPs.  The Management Instance handles the address mapping mechanisms
and monitors the states of the remote peer.  For simplicity, the
Management Instances and ASPs are considered as a separate entity.  This
is not a requirement, as they can be collocated with an ASP.
.pp
The following must be established before TUA traffic can flow.  A
connection-less flow is shown for simplicity.
.pp
Each node is configured (via MIB, for example) with the connections that
need to be setup
.(l
.(c
.nf
.sz -2
\fC\
IP SEP A                                                  IP SEP B
ASP-a1     ASP-a2     MI a             MI b       ASP-b2    ASP-b1
(Primary) (Backup)                               (Backup) (Primary)

            Establish SCTP Connectivity

                      |-- Est. SCTP Ass.--|

|------ Establish SCTP Association -------|
|------------- Establish SCTP Association -------------|
|------------------ Establish SCTP Association ------------------|

           |--- Establish SCTP Assoc. ----|
           |------- Establish SCTP Association --------|
           |------------ Establish SCTP Association -------------|

                      |-- Establish SCTP Association -|
                      |------- Establish SCTP Association ------|

            Establish TUA Connectivity

+---------------ASP Up------------------->
<---------------ASP Up Ack---------------+

           +------------ASP Up----------->
           <------------ASP Up Ack-------+

                     <--------------ASP Up-------------+
                     +--------------ASP Up Ack--------->

                     <----------------ASP Up---------------------+
                     +----------------ASP Up Ack----------------->

+---------------ASP Act------------------>
<---------------ASP Act Ack--------------+

                     <----------------ASP Act--------------------+
                     +----------------ASP Act Ack---------------->

Traffic can now flow directly between ASPs.

+-------------------------------TCAP_User Message------------------>
.fi
.sz +2
.)c
.)l
.sh 3 "Fail-over scenarios"
.pp
The following sequences address fail-over of ASP
.sh 4 "Successful ASP Fail-over scenario"
.pp
The following is an example of a successful fail-over scenario, where
there is a fail-over from ASP-a1 to ASP-a2, i.e, Primary to Backup.
Since data transfer passes directly between peer ASPs, ASP-b1 is
notified of the fail-over of ASP-a1 and must buffer outgoing data
messages until ASP-a2 becomes available.
.(b
.(c
.nf
.sz -2
\fC\
IP SEP A                                                  IP SEP B
ASP-a1     ASP-a2     MI a             MI b       ASP-b2    ASP-b1
(Primary) (Backup)                               (Backup) (Primary)
+--------------ASP Inact----------------->
<--------------ASP Inact Ack-------------+

           <----NTFY (ASP-a1 Inactive)---+

           +----------ASP Act------------>
           <----------ASP Act Ack--------+
.fi
.sz +2
.)c
.)b
.sh 4 "Unsuccessful ASP Fail-over scenario"
.pp
The sequence is the same as 5.2.2.1 except that, since the backup fails
to come in then, the Notify messages declaring the availability of the
backup are not sent.
.\"
.\"
.sh 1 "Security"
.sh 2 "Introduction"
.pp
TUA is designed to carry signalling messages for telephone services.  As
such, TUA involves the security needs of several parties: the end users
of the services; the network providers and the applications involved.
Additional security requirements may come from local regulation.  While
having some overlapping security needs, any security solution should
fulfill all of the different parties' needs.
.sh 2 "Threats "
.pp
There is no quick fix, one-size-fits-all solution for security.  As a
transport protocol, TUA has the following security objectives:
.bu
Availability of reliable and timely user data transport.
.bu
Integrity of user data transport.
.bu
Confidentiality of user data.
.pp
TUA runs on top of SCTP.  SCTP provides certain transport related
security features, such as:
.bu
Blind Denial of Service Attacks
.bu
Flooding
.bu
Masquerade
.bu
Improper Monopolization of Services
.pp
When TUA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network include
an appropriate security policy framework.  The "Site Security Handbook"
[2196] should be consulted for guidance.
.pp
When the network in which TUA runs in involves more than one party, it
may not be reasonable to expect that all parties have implemented
security in a sufficient manner.  End-to-end security should be the
goal; therefore, it is recommended that IPSEC be used to ensure
confidentiality of user payload.  Consult [2409] for more information on
configuring IPSEC services.
.sh 2 "Protecting Confidentiality"
.pp
Particularly for mobile users, the requirement for confidentiality may
include the masking of IP addresses and ports.  In this case application
level encryption is not sufficient; IPSEC ESP should be used instead.
Regardless of which level performs the encryption, the IPSEC ISAKMP
service should be used for key management.
.sh 1 "IANA Considerations"
.sh 2 "SCTP Payload Protocol ID"
.pp
IANA has assigned a TUA value for the Payload Protocol Identifier in the
SCTP DATA chunk.  The following SCTP Payload Protocol Identifier is
registered:
.ba +12n
.pp
TUA "4"
.ba -12n
.pp
The SCTP Payload Protocol Identifier value "4" \fB\)SHOULD\fR be
included in each SCTP DATA chunk, to indicate that the SCTP is carrying
the TUA protocol.  The value "0" (unspecified) is also allowed but any
other values \fB\)MUST NOT\fR be used.  This Payload Protocol Identifier
is not directly used by SCTP but \fB\)MAY\fR be used by certain network
entities to identify the type of information being carried in a DATA
chunk.
.pp
The User Adaptation peer \fB\)MAY\fR use the Payload Protocol
Identifier, as a way of determining additional information about the
data being presented to it by SCTP.  A request will be made to IANA to
assign CTP Payload Protocol IDs.
.sh 2 "Port Number"
.pp
IANA has registered SCTP Port Number 14001 for TUA.  It is recommended
that SGPs use this SCTP port number for listening for new connections.
SGPs \fB\)MAY\fR also use statically configured SCTP port numbers
instead.

.sh 2 "Protocol Extensions "
.pp
This protocol may also be extended through IANA in three ways:
.bu
Through definition of additional message classes.
.bu
Through definition of additional message types.
.bu
Through definition of additional message parameters.
.pp
The definition and use of new message classes, types and parameters is
an integral part of SIGTRAN adaptation layers.  Thus, these extensions
are assigned by IANA through an IETF Consensus action as defined in.
.[
RFC 2434
.]
.pp
The proposed extension \fB\)MUST\fR in no way adversely affect the
general working of the protocol.
.pp
A new registry will be created by IANA to allow
.sh 3 "IETF Defined Message Classes"
.pp
The documentation for a new message class \fB\)MUST\fR include the
following information:
.np
A long and short name for the message class;
.np
A detailed description of the purpose of the message class.
.sh 3 "IETF Defined Message Types"
.pp
Documentation of the message type \fB\)MUST\fR contain the following
information:
.np
A long and short name for the new message type;
.np
A detailed description of the structure of the message.
.np
A detailed definition and description of intended use of each field
within the message.
.np
A detailed procedural description of the use of the new message type
within the operation of the protocol.
.np
A detailed description of error conditions when receiving this message
type.
.pp
When an implementation receives a message type which it does not
support, it \fB\)MUST\fR respond with an Error (ERR) message, with an
Error Code = Unsupported Message Type.
.sh 3 "IETF-defined TLV Parameter Extension"
.pp
Documentation of the message parameter \fB\)MUST\fR contain the
following information:
.np
Name of the parameter type.
.np
Detailed description of the structure of the parameter field.  This
structure \fB\)MUST\fR conform to the general type-length-value format
described earlier in the document.
.np
Detailed definition of each component of the parameter value.
.np
Detailed description of the intended use of this parameter type, and an
indication of whether and under what circumstances multiple instances of
this parameter type may be found within the same message type.
.sh 1 "Acknowledgments"
.pp
The authors would like to thank
Jianxing Hou, Min Lin
for their original input to this document, and to
the authors of M2UA, M3UA and SUA
for the large sections of text which apply also to TUA and was included here.
.sh 1 "Author's Addresses"
.lp
.TS
expand tab(;);
lr.
Brian Bidulock;Phone: +1-972-839-4489
OpenSS7 Corporation;Email: bidulock@openss7.org
4701 Preston Park Boulevard;URL: http://www.openss7.org/
Suite 424;
Plano, TX  75093;
USA;
.TE
.bl 3
.lp
This draft expires July 2002.
.bp
.nr ii 0.5i
.uh "End Notes"
.pd
.de ]<
.uh "References"
.rm (f )f
..
.[
$LIST$
.]
.bp
.uh "Appendices"
.nr $1 0
.af $1 A
.sh 1 "Operational Considerations"
.sh 2 "Signalling Network Architecture"
.pp
A Signalling Gateway is used to support the transport of TC-User signalling
traffic received from the SS7 network to multiple distributed ASPs (e.g., MGCs
and IP Databases).  Clearly, the TUA protocol is not designed to meet the
performance and reliability requirements for such transport by itself.
However, the conjunction of distributed architecture and redundant networks
provides support for reliable transport of signalling traffic over IP.  The
TUA protocol is flexible enough to allow its operation and management in a
variety of physical configurations, enabling Network Operators to meet their
performance and reliability requirements.
.pp
To meet the stringent SS7 signalling reliability and performance requirements
for carrier grade networks, Network Operators might require that no single
point of failure is present in the end-to-end network architecture between an
SS7 node and an IP-based application.  This can typically be achieved through
the use of redundant SGPs or SGs, redundant hosts, and the provision of
redundant QOS-bounded IP network paths for SCTP Associations between SCTP End
Points. Obviously, the reliability of the SG, the MGC and other IP-based
functional elements also needs to be taken into account.  The distribution of
ASPs and SGPs within the available Hosts MAY also be considered.  As an
example, for a particular Application Server, the related ASPs could be
distributed over at least two Hosts.
.pp
One example of a physical network architecture relevant to SS7 carrier-grade
operation in the IP network domain is shown in \fI\*(&f\n(&n\fR.
.(z
.ie '\*(.T'ps' \{
.\"'
.so tua07.pic
.\}
.el \{
.(c
.nf
.sz -2
\fC\
        SGs                                     MGCs
       ..............                          ..............
Host#1 :   ______   :                          :   ______   : Host#3
       :  |      |__:__________________________:__|      |  :   =
       :  |SGP1.1|__:_____      _______________:__| ASP1 |  :  MGC1
       :  |______|  :     \\    /               :  |______|  :
       :  |      |__:______\\__/________________:__|      |  :
       :  |SGP2.1|__:_______\\/______      _____:__| ASP2 |  :
       :  |______|  :       /\\      |    |     :  |______:  :
       :   __:___   :  o   /  \\     |    |  o  :   ___:__   :
       :  |      |  :  o  /    \\    |    |  o  :  |      |  :
       :  | SGPn |  :  o  |    |    |    |  o  :  | ASPn |  :
       :  |______|  :     |    |    |    |     :  |______|  :
       :............:     |    |    |    |     :............:
       ..............     |    |    \\    /     ..............
Host#2 :   ______   :     |    |     \\  /      :   ______   : Host#4
       :  |      |__:_____|    |______\\/_______:__|      |  :   =
       :  |SGP1.2|__:_________________/\\_______:__| ASP1 |  :  MGC2
       :  |______|  :                /  \\      :  |______|  :
       :  |      |__:_______________/    \\_____:__|      |  :
       :  |SGP2.2|__:__________________________:__| ASP2 |  :
       :  |______|  :                          :  |______|  :
       :   __:___   :  o    SCTP            o  :   ___:__   :
       :  |      |  :  o    Associations    o  :  |      |  :
       :  | SGPn |  :  o                    o  :  | ASPn |  :
       :  |______|  :                          :  |______|  :
       :............:                          :............:

 SGP1.1 and SGP1.2 are part of SG1
 SGP2.1 and SGP2.2 are part of SG2
.fi
.sz +2
.)c
.\}
.#f "Physical Model"
.)z
.pp
In this model, each host MAY have many application processes.  In the case of
the MGC, an ASP may provide service to one or more Application Servers, and is
identified as an SCTP end point. One or more Signalling Gateway Processes make
up a single Signalling Gateway.
.pp
This example model can also be applied to IPSP-IPSP signalling.  In this case,
each IPSP MAY have its services distributed across 2 hosts or more, and may
have multiple server processes on each host.
.pp
In the example above, each signalling process (SGP, ASP or IPSP) is the end
point to more than one SCTP association, leading to more than one other
signalling processes.  To support this, a signalling process must be able to
support distribution of TUA messages to many simultaneous active
associations.  This message distribution function is based on the status of
provisioned Routing Keys, the status of the signalling routes to signalling
points in the SS7 network , and the redundancy model (override, loadsharing,
broadcast) of the remote signalling processes.
.pp
For carrier grade networks, the failure or isolation of a particular
signalling process should not cause transactions to be lost.  This implies
that signalling processes need, in some cases, to share the transaction state
or be able to pass the transaction state information between each other.
However, this sharing or communication of transaction state information is
outside the scope of this document.
.pp
This model serves as an example.  TUA imposes no restrictions as to the exact
layout of the network elements, the message distribution algorithms and the
distribution of the signalling processes.  Instead, it provides a framework
and a set of messages that allow for a flexible and scalable signalling
network architecture, aiming to provide reliability and performance.
.sh 2 "Redundancy Models"
.sh 3 "Application Server Redundancy"
.pp
At the SGP, an Application Server list contains active and inactive ASPs to
support ASP broadcast, loadsharing and override procedures.  The list of ASPs
within a logical Application Server is kept updated in the SGP to reflect the
active Application Server Processes.
.pp
For example, in the network shown in \fI\*(&f\n(&p\fR, all messages to SSN x
could be sent to ASP1 in Host3 or ASP1 in Host4.  The AS list at SGP1 in Host
1 might look like the following:
.ix +4
.TS
tab(:);
lsss
ll1c1l.
Routing Key {SSN=x) - "Application Server #1"
:ASP1/Host3:-:State = Active
:ASP1/Host4:-:State = Inactive
.TE
.pp
In this "1+1" redundancy case, ASP1 in Host3 would be sent any incoming
message with SSN=x.  ASP1 in Host4 would normally be brought to the "active"
state upon failure of, or loss of connectivity to, ASP1/Host1.
.pp
The AS List at SGP1 in Host1 might also be set up in loadshare mode:
.ix +4
.TS
tab(:);
lsss
ll1c1l.
Routing Key {SSN=x) - "Application Server #1"
:ASP1/Host3:-:State = Active
:ASP1/Host4:-:State = Active
.TE
.pp
In this case, both the ASPs would be sent a portion of the traffic.  For
example the two ASPs could together form a database, where incoming queries
may be sent to any active ASP.
.pp
Care might need to be exercised by a Network Operator in the selection of the
routing information to be used as the Routing Key for a particular AS.
.pp
For example, where Application Servers are defined using ranges of GT Address
values, the Operator is implicitly splitting up control of the related address
groups.  Some GT address value range assignments may interfere with TCAP
subsystem management procedures.
.pp
In the process of failover, it is recommended that in the case of ASPs that
transactions do not fail.  For example, the two ASPs may share transaction
state via shared memory, or may use an ASP to ASP protocol to pass transaction
state information.  Any ASP-to-ASP protocol to support this function is
outside the scope of this document.
.sh 3 "Signalling Gateway Redundancy"
.pp
Signalling Gateways may also be distributed over multiple hosts.  Much like
the AS model, SGs may comprise one or more SG Processes (SGPs), distributed
over one or more hosts, using an override, loadshare or broadcast model.
Should an SGP lose all or partial SS7 connectivity and other SGPs exist, the
SGP may terminate the SCTP associations to the concerned ASPs or send an
unsolicited ASPIA ACK for the concerned Application Servers.
.pp
It is possible for an ASP to route signalling messages destined to the SS7
network using more than one SGP.  In this model, a Signalling Gateway is
deployed as a cluster of hosts acting as a single SG.  An override redundancy
model is possible, where the unavailability of the SCTP association to a
primary SGP could be used to reroute affected traffic to an alternate
SGP.  A loadsharing model is possible, where the signalling messages are
loadshared between multiple SGPs.  A broadcast model is also possible, where
signalling messages are sent to each active SGP in the SG. The distribution of
the TC-user messages over the SGPs should be done in such a way to minimize
message missequencing, as required by the SS7 User Parts.
.pp
It may also be possible for an ASP to use more than one SG to access a
specific SS7 end point, in a model that resembles an SS7 STP mated pair.
Typically, SS7 STPs are deployed in mated pairs, with traffic loadshared
between them.  Other models are also possible, subject to the limitations of
the local SS7 network provisioning guidelines.
.pp
From the perspective of the TUA layer at an ASP, a particular SG is capable of
transferring traffic to a provisioned SS7 destination, subsystem or
application X if an SCTP association with at least one SGP of the SG is
established, the SGP has returned an acknowledgement to the ASP to indicate
that the ASP is actively handling traffic for that destination, subsysstem or
application X, and the SGP has not indicated that the destination, subsystem or
application X is inaccessible.  When an ASP is configured to use multiple SGPs
for transferring traffic to the SS7 network, the ASP must maintain knowledge
of the current capability of the SGPs to handle traffic to destinations,
subsystems and applications of interest.  This information is crucial to
the overall reliability of the service, for override, loadsharing and
broadcast models, in the event of failures, recovery and maintenance
activities.  The ASP TUA may also use this information for congestion
avoidance purposes.  The distribution of the TC-user messages over the SGPs
should be done in such a way to minimize message missequencing, as required by
the some TCAP applications.
.\"
.bp
.ce 1
.uh "List of Tables"
.(l I
.xp 3
.)l
.ce 1
.uh "List of Illustrations"
.(l I
.xp 2
.)l
.ce 1
.uh "Table of Contents"
.(l I
.xp 0
.)l
.bp
.uh "Copyright Statement"
.lp
\fB\)\
Copyright (C) The Internet Society (2002).  All Rights Reserved.
.pp
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedure for copyrights defined in the Internet
Standards process must be followed, or as required to translate into
languages other than English.
.pp
The limited permission granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
.pp
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MECHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
