.\" -*- nroff -*-
.\" =========================================================================
.\"
.\" @(#) draft-bidulock-sigtran-sginfo-00.me,v 0.8 2002/04/02 08:10:54 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:54 by brian
.\"
.\" =========================================================================
.R1
abbreviate A
label L
no-default-database
no-accumulate
database ../idrefs
annotate X lp
move-punctuation
discard YZ
join-authors ", " ", " " and "
et-al " et al" 2 3
search-truncate 10
separate-label-second-parts ""
bracket-label " [" "]" ", "
# abbreviate-label-ranges "..."
# sort A+
# 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.0'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 6n
.\".nr pi 4n
.nr pi 0
.nr po 3n
.nr bi 2n
.nr qi 4n
.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.5i
.\".nr pi 0.5i
.nr pi 0
.nr po 0.25i
.nr bi 0.5i
.nr hi 0.5i
.nr qi 0.5i
.nr pp 10
.nr qp 9
.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
\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 "End Notes for Section \\\\n($1"
.pd
.\}
..
.ds a \a
.bp
.he 'Internet Draft'UA SGINFO'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\
Signalling Gateway (SG) Information (SGINFO) Support
for
Signalling User Adaptation Layers
<draft-bidulock-sigtran-sginfo-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 Internet-Draft describes \fB\)Signalling Gateway (SG) Information
(SGINFO)\fR for Signalling User Adaptation Protocols,
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
which permits supporting Signalling Gateways (SG) to convey additional
Application Server (AS) support information to Application Server Processes
(ASPs) activating for AS on the SG.  This additional AS support information
consists of information pertaining to the underlying SS7 Signalling Provider
that otherwise would have to be statically configured at the Application
Server Process (ASP) or exchanged between SG and ASP using a non-IETF defined
protocol.
.sh 1 "Introduction"
.sh 2 "Scope"
.pp
This Internet-Draft provides parameters and procedures in extension to the
parameters and procedures of the Signalling User Adaptation Layers
(UAs),
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
for the purpose of supporting the transfer of SG-specific information of
interest to an Application Server during the ASP Active procedure.
.pp
UA implementations with \fB\)SGINFO\fR are intended to be compatible with UA
implementations not supporting this configuration.
.sh 2 "Terminology"
.pp
\fB\)SGINFO\fR adds the following terms to the terminology presented
in the UA documents: \*#
.(d
.ip \*#
See, for example, Section 1.2 of M3UA, SUA or TUA.
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
.)d
.lp
\fI\)Signalling User Adaptation Layer (UA)\fR \-
.ix +\n(iiu
one or more of the Stream Control Transmission Protocol (SCTP)
.[
sctp
.]
SS7 Signalling User Adaptation Layers
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
supporting the concept of a \fI\)ASP Management\fR.
.sh 2 "Overview"
.pp
There is a need to provide extensions for the Signalling User Adaptation Layer
protocols to permit a Signalling Gateway (SG) to provide Application Server
(AS) specific information pertaining to the SG's ability to support the
Application Server.
.pp
For example, the "Maximum SIF Length" of MTP3
.[
q.704
.]
is a value that an MTP-User at an AS needs to reference to avoid sending MSU
data in excess of these MTP-PDU length restrictions.  The "Maximum SIF
Length"; however, can change due to SS7 Network failures or reconfiguration at
the SG that cannot be handled purely by static configuration information at an
ASP.
.pp
Additional examples exist for SCCP
.[
q.711
.]
and TCAP
.[
q.771
.]
and the need for these protocol limits at the Application Server is evidenced
by the requirements for these values in the OSI/ISO NSD
.[
x.213
.]
Compliant NPI,
.[
npi
.]
and the OSI/ISO TSD
.[
x.214
.]
and the OSI/ISO ROSE
.[
x.219
.]
Compliant TPI,
.[
tpi
.]
and the ACSE
.[
iso 8649
.]
.[
iso 8650
.]
compliant mOSI extensions to the XNS.
.[
xns
.]
.pp
\fB\)SGINFO\fR provides parameters and procedures that allow
Signalling Gateway Processes (SGPs) to inform Application Server Processes
(ASPs) of the SG parameters, as well as provides procedures to update these
parameters in an active AS.
.sh 3 "Existing Information Management"
.ds #u \*#
.pp
While there is a mandate to provide MIBs to support UA configuration, the
existing UA procedures\*#
.(d
.ip \*#
See, for example, Section 4 of M3UA, SUA or TUA.
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
.)d
and MIBs
make no provisions for the management of dynamic operational information at a
Signalling Gateway that is of specific concern to a UA-User at an Application
Server (AS).
.pp
For example, if an Signalling Gateway changes an operation parameter of
necessary to an UA-User at an Application Server (AS), such as the "Maximum SIF
Length", there is no mechanism for the SG to communicate this information to
the concerned Application Server (AS).
.pp
While the
existing UA procedures\*(#u provide for the SG giving an indication of a
"Protocol Error" or "Invalid Parameter Value" as a result of an operational
parameter being exceeded, there are no procedures for the Application Server
to discover the operational parameters when they are dynamic.
.pp
The lack of an IETF procedure for managing operational parameter information
represents a deficiency of the existing UA procedures\*(#u that detracts from
interoperability between separate implementations of SGP and ASP.
.sh 3 "SGINFO Information Management"
.pp
To remedy these deficiencies, \fB\)SGINFO\fR provides support for the
following:
.bu
Support for an SG indicating operational parameters to an Application Server
(AS).
.bu
Support for an SG changing operational parameter for an active Application
Server (AS).
.bu
Support for interworking between SGPs supporting \fB\)SGINFO\fR and ASPs not
supporting \fB\)SGINFO\fR.
.sh 1 "Conventions"
.pp
The keywords \fB\)MUST\fR, \fB\)MUST NOT\fR, \fB\)REQUIRED\fR, \fB\)SHALL\fR,
\fB\)SHALL NOT, \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.
.[
key words
.]
.sh 1 "Protocol Elements"
.ds #w \*#
.pp
\fB\)SGINFO\fR provides the following parameters and the messages in which
they are included in addition to the parameters of the UAs.\*#
.(d
.ip \*#
See, for example, Section 3 of the M3UA, SUA or TUA.
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
.)d
.sh 2 "Parameters"
.pp
\fB\)SGINFO\fR provides the following parameters in addition to the parameters
defined for the UAs.\*(#w
.sh 3 "Protocol Limits"
.pp
The \fI\)Protocol Limits\fR parameter is a common parameter used in the
\fB\)ASPAC ACK\fR message to indicate the protocol data unit size limitations
presented by a Signalling Gateway to an Application Server.
.pp
The \fI\)Protocol Limits\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 = 0xXXXX          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                        Maximum SDU Size                       |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
|                        Optimal SDU Size                       |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
|              Maximum Connect Data Size (optional)             |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
|             Maximum Disconnect Data Size (optional)           |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
|                  Maximum ESDU Size (optional)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.(q
.#v
\fB\)EDITOR'S NOTE:\-\fR\  The parameter tag values shown as \f(CB\)0xXXXX\fR
above will be assigned by IANA within the common parameter range of the
SIGTRAN UAs and may change its value in further versions of this document.
.)q
.pp
The \fI\)Protocol Limits\fR parameter contains the following fields:
.ip "\fB\)Maximum SDU Size field: 32-bits (signed integer)\fR" 2

The \fI\)Maximum SDU Size\fR field
contains the maximum number of bytes in the Protocol Data parameter that the
Signalling Gateway can support to the specific Application Server.
.ba +2
.ip "M3UA"
For M3UA
.[
m3ua-10
.]
the \fI\)Maximum SDU Size\fR field
provides the limit on the maximum size of the data payload of the Protocol Data field.
The maximum size is the largest maximum data payload size that can be transferred across
the SS7 network by the SG for the specific Application Server.
For example, for an SG supporting both an SIF Maximum Size
.[
q.704
.]
of 3094 bytes on a primary links and 272 bytes on secondary links, this size
would be 3094.
.ip "SUA"
For SUA
.[
sua-09
.]
the \fI\)Maximum SDU Size\fR field
provides the limit on the maximum size of the User Data field for a normal
(non-expedited) data transfer.
The maximum size is the largest data payload size that can be
transferred across the SS7 network for the specific Application Server (and
associated Protocol Class) considering segmentation.  If there is
no limit on the NSDU size for an SCCP provider at an SG, this field will be
set to a value of -1.
.ip "TUA"
For TUA
.[
tua-01
.]
the \fI\)Maximum SDU Size\fR field
provide the limit on the maximum size of the Components field for a
TC-CONTINUE data transfer.
The maximum size is the largest component size that can be
transferred across the SS7 network for the specific Application Server (and
associated Operation Class) considering segmentation.  If there is no
limit on the component size for a TCAP provider at the SG, this field will be
set to a value of -1.
.ba -2
.ip "\fB\)Optimal SDU Size field: 32-bits (signed integer)\fR" 2

The \fI\)Optimal SDU Size\fR field
contains the optimal number of bytes in the Protocol Data parameter that the
Signalling Gateway can support to the specific Application Server.
.ba +2
.ip "M3UA"
For M3UA
.[
m3ua-10
.]
the \fI\)Optimal SDU Size\fR field
provides the limit on the optimal size of the data payload of the Protocol Data field.
The optimal size is the smallest maximum data payload size that can be transferred across
the SS7 network by the SG for the specific Application Server.
For example, for an SG supporting both an SIF Maximum Size
.[
q.704
.]
of 3094 bytes on a primary links and 272 bytes on secondary links, this size
would be 272.
.ip "SUA"
For SUA
.[
sua-09
.]
the \fI\)Optimal SDU Size\fR field
provides the limit on the optimal size of the User Data field for a normal
(non-expedited) data transfer.
The optimal size is the largest data protocol size that can be
transferred across the SS7 network for the specific Application Server (and
associated Protocol Class) without segmentation.
.ip "TUA"
For TUA
.[
tua-01
.]
the \fI\)Optimal SDU Size\fR field
provides the limit on the optimal size of the Components field for a
TC-CONTINUE data transfer.
The optimal size is the largest component size that can be
transferred across the SS7 network for the specific Application Server (and
associated Operation Class) without segmentation.
.ba -2
.ip "\fB\)Maximum Connect Data Size field: 32-bits (signed integer)\fR" 2

The \fI\)Maximum Connect Data Size\fR field
contains the maximum number of bytes in the Data parameter that the
Signalling Gateway can support to the specific Application Server upon
connection or transaction dialogue establishment.
.ba +2
.ip "M3UA"
For M3UA
.[
m3ua-10
.]
the \fI\)Maximum Connect Data Size\fR field
does not apply and
is not included in the \fI\)Protocol Limits\fR parameter.
.ip "SUA"
For SUA
.[
sua-09
.]
the \fI\)Maximum Connect Data Size\fR field
provides a limit on the maximum size of the User Data field that can be
included in CORE and COAK messages.
For Connection-less operation, this field does not apply and is not included in
the \fI\)Protocol Limits\fR parameter.
.ip "TUA"
For TUA
.[
tua-01
.]
the \fI\)Maximum Connect Data Size\fR field
provides the limit on the maximum size of the User Information and Components
that can be included in a TQRY or initial TCNV message.
For Operation Class 4, this field does not apply and is not included in the
\fI\)Protocol Limits\fR parameter.
.ba -2
.ip "\fB\)Maximum Disconnect Data Size field: 32-bits (signed integer)\fR" 2

The \fI\)Maximum Disconnect Data Size\fR field
contains the maximum number of bytes in the Data parameter that the
Signalling Gateway can support to the specific Application Server upon
disconnection or transaction dialogue abort.
.ba +2
.ip "M3UA"
For M3UA
.[
m3ua-10
.]
the \fI\)Maximum Disconnect Data Size\fR field
does not apply and
is not included in the \fI\)Protocol Limits\fR parameter.
.ip "SUA"
For SUA
.[
sua-09
.]
the \fI\)Maximum Disconnect Data Size\fR field
provides a limit on the maximum size of the User Data field that can be
included in a RELRE message.
For Connection-less operation, this field does not apply and is not included in
the \fI\)Protocol Limits\fR parameter.
.ip "TUA"
For TUA
.[
tua-01
.]
the \fI\)Maximum Disconnect Data Size\fR field
provides the limit on the maximum size of the User Abort Information
that can be included in a TUAB message.
For Operation Class 4, this field does not apply and is not included in the
\fI\)Protocol Limits\fR parameter.
.ba -2
.ip "\fB\)Maximum ESDU Size field: 32-bits (signed integer)\fR" 2

The \fI\)Maximum ESDU Size\fR field
contains the maximum number of bytes in the Data parameter that the
Signalling Gateway can support to the specific Application Server when data is
expedited on a connection.
.ba +2
.ip "M3UA"
For M3UA
.[
m3ua-10
.]
the \fI\)Maximum ESDU Size\fR field
does not apply and
is not included in the \fI\)Protocol Limits\fR parameter.
.ip "SUA"
For SUA
.[
sua-09
.]
the \fI\)Maximum ESDU Size\fR field
provides a maximum number of bytes in the User Data field for an expedited
data transfer.
The maximum size is the largest expedited data payload size that can be transferred
across the SS7 network for the specific Application Server.
For Connection-less or Protocol Class 2 operation, this field does not apply
and is not included in the \fI\)Protocol Limits\fR parameter.
.ip "TUA"
For TUA
.[
tua-01
.]
the \fI\)Maximum ESDU Size\fR field
does not apply and
is not included in the \fI\)Protocol Limits\fR parameter.
.ba -2
.\"
.\"
.\"
.\"
.\"
.sh 2 "Messages"
.pp
\fB\)SGINFO\fR extends the following messages defined for the UAs.\*(#w
.sh 3 "ASP Active Acknowledgment (ASPAC ACK)"
.pp
\fB\)SGINFO\fR supplements the \fB\)ASPAC ACK\fR message by permitting
the following optional parameters to be included in the message:
.ix +4
.TS
tab(:);
lbss
lw(2.5i)lc.
Extension Parameters
_
Protocol Limits:Optional:
.TE
.pp
The format of the resulting \fB\)ASPAC ACK\fR message is 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                        /
\\                                                               \\
\f(CB\
+-------------------------------+-------------------------------+
|         Tag = 0xXXXX          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                        Protocol Limits                        /
\\                                                               \\
+-------------------------------+-------------------------------+
\f(CR\
|         Tag = 0x0004          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Info String                         /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.(q
.#v
\fB\)EDITOR'S NOTE:\-\fR\  The parameter tag values shown as \f(CB\)0xXXXX\fR
above will be assigned by IANA within the common parameter range of the
SIGTRAN UAs and may change its value in further versions of this document.
.)q
.pp
No other changes to the \fB\)ASPAC ACK\fR message format are provided by this
extension.
.pp
To indicate restrictions on the maximum sizes for transfer of data, the SGP and
IPSP \fB\)MUST\fR include the \fI\)Protocol Limits\fR parameter in the
\fB\)ASPAC ACK\fR message.
.sh 1 "Procedures"
.pp
The following procedures are provided in extension to the UA procedures by
\fB\)SGINFO\fR.
.sh 2 "ASP Management Procedures"
.sh 3 "ASP Active Procedures"
.pp
In extension of the "ASP Active Procedures" of the UAs\*(#u, \fB\)SGINFO\fR
provides the following procedures:
.pp
Whenever an SGP, as a part of the normal UA procedures, sends an ASP Active
Acknowledgment (ASPAC ACK) to an ASP, it \fB\)MAY\fR include the \fI\)Protocol
Limits\fR parameter indicating the protocol data size limits that apply to the
Application Server associated with the Routing Context(s) specified or implied
in the \fB\)ASPAC ACK\fR message.  Where the protocol limits only apply to one
Application Server, the SGP \fB\)SHOULD NOT\fR include more than one Routing
Context in the \fB\)ASPAC ACK\fR response.  That is, in response to an
\fB\)ASPAC\fR message containing multiple Routing Contexts, the SGP
\fB\)SHOULD\fR send a separate \fB\)ASPAC ACK\fR reply for each Routing
Context for which it includes the \fI\)Protocol Limits\fR parameter.
.pp
If an SG discovers that the protocol data size limits has changed due to an
event, (such as a failure in the SS7 network), the SGP \fB\)MAY\fR send an
unsolicited \fB\)ASPAC ACK\fR message containing the new protocol limits.
.pp
Whenever an ASP receives an \fB\)ASPAC ACK\fR message as part of the normal
UA procedures, or receives an unsolicited \fB\)ASPAC ACK\fR for an active
Application Server (AS), the ASP will apply the new protocol data size limits
to the Application Server.
.sh 2 "Interworking"
.pp
Whenever an SGP receives an \fB\)ERR\fR("Invalid Parameter") message
indicating the \fI\)Protocol Limits\fR parameter in response to a sent
\fB\)ASPAC ACK\fR message containing a \fI\)Protocol Limits\fR parameter, the
SGP \fB\)SHOULD\fR re-attempt by sending the \fB\)ASPAC ACK\fR without a
\fI\)Protocol Limits\fR parameter.
.pp
.sh 1 "Examples"
.sh 2 "ASP and SGP both supporting Protocol Limits"
.pp
An example of an
ASP and SGP both supporting Protocol Limits
is illustrated in \fI\)\*(&f\n(&n\fR.
.(z
.(c
.nf
.sz -2
\fC\
          SGP                             ASP
           |            ASPUP              |
           |<------------------------------|
           |          ASPUP ACK            |
   (1)     |------------------------------>|
           |                               |
           |            ASPAC              |
   (2)     |<------------------------------|
           |                               |
           |   ASPAC ACK(Protocol Limits)  |
   (3)     |------------------------------>|
           |                               |
           .                               .
           .                               .
           .                               .
           |   ASPAC ACK(Protocol Limits)  |
   (4)     |------------------------------>|
           |                               |
.sz +2
.)c
.#f "ASP and SGP both supporting Protocol Limits"
.)z
.pp
As illustrated in \fI\)\*(&f\n(&p\fR, the sequence of events for this example
are as follows:
.np
An Application Server at an ASP begins in the AS-DOWN or AS-INACTIVE state.
.np
The ASP activates an Application Server by sending an \fB\)ASPAC\fR message.
.np
The SGP responds with an \fB\)ASPAC ACK\fR message containing the current
protocol limits in the \fI\)Protocol Limits\fR parameter.
The ASP applies these protocol limits to the Application Server upon
activation.
.np
Later, when the SGP notes a change to protocol limits, the SGP sends an
unsolicited \fB\)ASPAC ACK\fR message containing the updated \fI\)Protocol
Limits\fR.
The ASP applies these updated protocol limits to the Application Server upon
receipt.
.sh 2 "SGP only supporting Protocol Limits"
.sh 3 "ASP ignores Protocol Limits"
.pp
An example of an
SGP only supporting Protocol Limits
where the ASP ignores the \fI\)Protocol Limits\fR parameter
is illustrated in \fI\)\*(&f\n(&n\fR.
.(z
.(c
.nf
.sz -2
\fC\
          SGP                             ASP
           |            ASPUP              |
           |<------------------------------|
           |          ASPUP ACK            |
   (1)     |------------------------------>|
           |                               |
           |            ASPAC              |
   (2)     |<------------------------------|
           |                               |
           |   ASPAC ACK(Protocol Limits)  |
   (3)     |------------------------------>|
           |                               |
           .                               .
           .                               .
           .                               .
           |   ASPAC ACK(Protocol Limits)  |
   (4)     |------------------------------>|
           |                               |
.sz +2
.)c
.#f "ASP and SGP both supporting Protocol Limits"
.)z
.pp
As illustrated in \fI\)\*(&f\n(&p\fR, the sequence of events for this example
are as follows:
.np
An Application Server at an ASP begins in the AS-DOWN or AS-INACTIVE state.
.np
The ASP activates an Application Server by sending an \fB\)ASPAC\fR message.
.np
The SGP responds with an \fB\)ASPAC ACK\fR message containing the current
protocol limits in the \fI\)Protocol Limits\fR parameter.
The ASP ignores the \fI\)Protocol Limits\fR parameter and, instead, relies
upon internal configuration data to determine protocol limits.
.np
Later, when the SGP notes a change to protocol limits, the SGP sends an
unsolicited \fB\)ASPAC ACK\fR message containing the updated \fI\)Protocol
Limits\fR.
The ASP ignores the \fI\)Protocol Limits\fR parameter and, instead, relies
upon internal configuration data to determine protocol limits.
.sh 3 "ASP refuses Protocol Limits"
.pp
An example of an
SGP only supporting Protocol Limits
where the ASP refuses the \fI\)Protocol Limits\fR parameter
is illustrated in \fI\)\*(&f\n(&n\fR.
.(z
.(c
.nf
.sz -2
\fC\
          SGP                             ASP
           |            ASPUP              |
           |<------------------------------|
           |          ASPUP ACK            |
   (1)     |------------------------------>|
           |                               |
           |            ASPAC              |
   (2)     |<------------------------------|
           |                               |
           |   ASPAC ACK(Protocol Limits)  |
   (3)     |------------------------------>|
           |                               |
           |    ERR("Invalid Parameter")   |
   (4)     |<------------------------------|
           |                               |
           |          ASPAC ACK            |
   (5)     |------------------------------>|
           |                               |
           .                               .
           .                               .
           .                               .
           |                               |
   (6)     |                               |
           |                               |
.sz +2
.)c
.#f "ASP and SGP both supporting Protocol Limits"
.)z
.pp
As illustrated in \fI\)\*(&f\n(&p\fR, the sequence of events for this example
are as follows:
.np
An Application Server at an ASP begins in the AS-DOWN or AS-INACTIVE state.
.np
The ASP activates an Application Server by sending an \fB\)ASPAC\fR message.
.np
The SGP responds with an \fB\)ASPAC ACK\fR message containing the current
protocol limits in the \fI\)Protocol Limits\fR parameter.
.np
The ASP refuses the \fB\)ASPAC ACK\fR message and responds with an
\fB\)ERR\fR("Invalid Parameter") message indicating the \fI\)Protocol
Limits\fR parameter as invalid.
.np
The SGP re-attempts and sends the \fB\)ASPAC ACK\fR message without the
\fI\)Protocol Limits\fR parameter and marks the ASP as incapable of processing
protocol limits.
.np
When a subsequent change in the protocol limits at the SGP occurs, the SGP
does nothing (the ASP is marked as incapable of handling protocol limits).
.sh 2 "ASP only supporting Protocol Limits"
.pp
An example of an
ASP only supporting Protocol Limits
is illustrated in \fI\)\*(&f\n(&n\fR.
.(z
.(c
.nf
.sz -2
\fC\
          SGP                             ASP
           |            ASPUP              |
           |<------------------------------|
           |          ASPUP ACK            |
   (1)     |------------------------------>|
           |                               |
           |            ASPAC              |
   (2)     |<------------------------------|
           |                               |
           |          ASPAC ACK            |
   (3)     |------------------------------>|
           |                               |
           |                               |
   (4)     |                               |
           |                               |
.sz +2
.)c
.#f "ASP and SGP both supporting Protocol Limits"
.)z
.pp
As illustrated in \fI\)\*(&f\n(&p\fR, the sequence of events for this example
are as follows:
.np
An Application Server at an ASP begins in the AS-DOWN or AS-INACTIVE state.
.np
The ASP activates an Application Server by sending an \fB\)ASPAC\fR message.
.np
The SGP responds with an \fB\)ASPAC ACK\fR message not containing the
\fI\)Protocol Limits\fR parameter.
.np
The ASP receiving the \fB\)ASPAC ACK\fR with no \fI\)Protocol Limits\fR
parameter relies upon internal configuration data to determine protocol
limits.
.sh 1 "Security"
.pp
\fB\)SGINFO\fR does not introduce any new security risks or
considerations that are not already inherent in the UA
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
Please see the "Security" sections of
M3UA,
.[
m3ua-10
.]
SUA
.[
sua-09
.]
and TUA,
.[
tua-01
.]
for security considerations and recommendations that are applicable to each of
these UAs.
.sh 1 "IANA Considerations"
.sh 2 "Protocol Extensions"
.pp
\fB\)SGINFO\fR provides an additional \fI\)Protocol Limits\fR message
parameter to the common parameter range of the SIGTRAN UAs:
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
.af $p a
.np
The parameter is named the \fI\)Protocol Limits\fR parameter.
.np
The structure of the \fI\)Protocol Limits\fR parameter field conforms to the UA
general TLV format and is described in detail in Section 3.1.1.
.np
The detailed definition of each component of the \fI\)Protocol Limits\fR
parameter values is described in Section 3.1.1.
.np
This document also provides a detailed description of the intended use of the
\fI\)Protocol Limits\fR parameter, and in which messages the \fI\)Protocol
Limits\fR parameter should appear, how many times, and when.
.lp
.(q
.#v
\fB\)EDITOR'S NOTE:\-\fR\  The \fI\)Protocol Limits\fR parameter tag value
shown throughout this document as \f(CB\)0xXXXX\fR will be assigned by IANA
within the common parameter range of the SIGTRAN UAs and may change its value
in further versions of this document.
.)q
.\".uh "Acknowledgments"
.\".pp
.\"The authors would like to thank
.\"for their valuable comments and suggestions.
.nr ii 0.5i
.if \n($d>1 \{\
.uh "End Notes"
.pd
.\}
.de ]<
.rm (f )f
..
.uh "References"
.[
$LIST$
.]
.(b
.uh "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.
.)b
.bp
.\".ce 1
.\".uh "List of Tables"
.\".(l I
.\".xp 3
.\".)l
.(b I
.(c
.ce 1
.uh "List of Illustrations"
.lp
.xp 2
.)c
.)b
.(b I
.(c
.ce 1
.uh "Table of Contents"
.lp
.xp 0
.)c
.)b
.bp
.uh "Copyright Statement"
.lp
\fBCopyright \(co The Internet Society (2002).  All Rights Reserved.\fR
.lp
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.
.lp
The limited permission granted above are perpetual and will not be revoked by
the Internet Society or its successors or assigns.
.lp
This document and the information contained herein is provided on an "AS IS"
basis and \fB\)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.
