draft-averson-sigtran-m3pa-00.me

.\" -*- nroff -*-
.\" =========================================================================
.\"
.\" @(#) $Id$
.\"
.\" -------------------------------------------------------------------------
.\"
.\" 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 successor regulations) or, in the
.\" cases of NASA, in paragraph 18.52.227-86 of the NASA Supplement to the
.\" FAR (or any successor regulations).
.\"
.\" -------------------------------------------------------------------------
.\"
.\" $Name$($Revision$) modified $Date$ by $Author$
.\"
.\" =========================================================================
.R1
abbreviate A
label L
no-default-database
no-accumulate
no-annotate
database idrefs
annotate X lp
move-punctuation
discard Y
join-authors ", " ", " " and "
et-al " et al" 1 2
search-truncate 32
search-ignore T
separate-label-second-parts ""
bracket-label " [" "]" ", "
abbreviate-label-ranges ".."
sort Z
sort-adjacent-labels
reverse A
.R2
.de $0
.if \\$3>0 \{\
.if \\$3<4 \{\
.(x 0
.ie '\\$2'' \\$1
.el \\$2 \\$1
.\"'
.)x
.\}
.\}
..
.if '\*(.T'ascii' \{\
.\"'
.fo 'T. Averson'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 3n
.nr pi 3n
.nr po 3n
.nr bi 2n
.nr qi 4n
.nr ps 1v
.de #v
.ad l
.hy 0
..
.\}
.if '\*(.T'ps' \{\
.\"'
.fo 'T. Averson'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.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 "Endnotes for Section \\\\n($1"
.pd
.\}
..
.ds a \a
.bp
.he 'Internet Draft'M3PA'\\\\*(td'
.TS
expand tab(;);
lcr.
Network Working Group;;Tolga Averson (ed.)
INTERNET-DRAFT;;SS8 Networks Inc.
;;Brian Bidulock
;;OpenSS7 Corporation
.bl 2
Expires in six months;;\*(td
.bl 2
.TE
.(l C
\fB\
SS7 MTP3-User Peer-to-Peer Adpatation Layer Procedures (M3PA)
for
SS7 MTP3-User Adaptation Layer (M3UA)
.bl
<draft-averson-sigtran-m3pa-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 SS7 MTP3-User Peer-to-Peer Adaptation Layer
Procedures (M3PA) to support peer-to-peer operation for SS7 MTP3-User
Adaptation Layer
.[
m3ua12
.]
in support of MTP3
.[
q704
.]
users in an all IP network.  These procedures permit the seamless operation of
SS7 MTP3-User in an all-IP environment, while not requiring (but allowing)
interworking to the SS7 network.  This permits the implementation of all-IP
solutions for SS7 signalling between MTP3-Users.
.sh 1 "Introduction"
.sh 2 "Scope"
.pp
The Internet-Draft describes \fB\)SS7 MTP3-User Peer-to-Peer Adaptation Layer
(M3PA)\fR procedures to support peer-to-peer SS7 MTP signalling between IP
nodes in an IP network in extension to the messages and procedures provided
for SS7 MTP3-User Adaptation Layer.
.[
m3ua12
.]
These extensions provide seamless operation of the MTP3-User interface
.[
q704
.]
between M3UA endpoints (SGP and ASP) across an IP network.  Interworking
between \fB\)M3PA\fR endpoints supporting these procedures and SS7 SGs is also
provided.
.pp
In addition, this I-D describes extension messages and procedures which are
required to permit \fB\)M3PA\fR endpoints to act as relay points to other
\fB\)M3PA\fR nodes, providing the Signalling Transfer Point (STP)
.[
q705
.]
capabilities contained within an IP network.
.pp
M3UA implementations providing the \fB\)M3PA\fR extension procedures and
messages are intended to be compatible with M3UA implementations not
supporting these extensions; however, the full benefits acheived by
\fB\)M3PA\fR procedures will not be realized unless implementations at both
endpoints implement \fB\)M3PA\fR\).
.sh 2 "Terminology"
.pp
\fB\)M3PA\fR\) supplements the terminology used in M3UA
.[
m3ua12
.]
by adding the following terms:
.lp
\fI\)Changeover\fR\) \-
.ix +\n(iiu
.lp
\fI\)Changeback\fR\) \-
.ix +\n(iiu
.lp
\fI\)Controlled Rerouting\fR\) \-
.ix +\n(iiu
.lp
\fI\)Forced Rerouting\fR\) \-
.ix +\n(iiu
.lp
\fI\)Signalling Endpoint (SEP)\fR\) \-
.ix +\n(iiu
in this document, a \fI\)Signalling Enpoint\fR\) is an SS7 SEP
.[
q.700
.]
or an Application Server.
.lp
\fI\)Signalling Peer Process (SPP)\fR\) \-
.ix +\n(iiu
refers to an ASP, SGP or IPSP.
.lp
\fI\)Time-controlled Changeover\fR\) \-
.ix +\n(iiu
the MTP3
.[
q704
.]
procedure for diverting signalling traffic from a failed primary linkset to an
alternate linkset where sequence number information cannot be exchanged
between signalling points or where it is undesirable to use the normal
changeover procedures.
.sh 2 "Overview"
.pp
The purpose of \fB\)M3PA\fR\) protocol is to increase inter-IP {Tolga: or
intra-IP?} communication capabilities of M3UA peers and to allow SS7
signalling backhauling between SS7 nodes over IP.
.lp
.(z L
.hl
.(c
.nf
.sz -2
\fC\
     -----              -----
   //     \\\\          //     \\\\
  |  ASP    |        |  ASP    |
  |  Cloud 1|        |  Cloud 2|
   \\\\     //          \\\\     //
     --+--              --+--
       |                  |
       |                  |
    +--+--+            +--+--+
    | SG1 +------------+ SG2 |
    +--+--+            +--+--+
       |                  |
       |                  |
       |                  |
       |     +-----+      |
       +-----+ SG3 +------+
             +--+--+
                |
                |
              --+--
            //     \\\\
           |  ASP    |
           |  Cloud 2|
            \\\\     //
              -----
.sz +2
.)c
.#f "Inter-IP communication useing \fB\)M3PA\fR\)"
.hl
.)z
.pp
In the configuration in \fI\*(&f\n(&p\fR SGs act as transfer points between
ASP clouds. Their functionality is similar to the STP functionality in SS7
network. The communication between ASPs and SGs is as defined in M3UA.
.lp
.(z L
.hl
.(c
.nf
.sz -2
\fC\
+---------+              +---------+
|   SG1   +--------------+   SG2   |
+----+----+              +----+----+
     |                        |
     |                        |
+----+----+              +----+----+
|SS7 node1|              |SS7 node2|
+---------+              +---------+
.sz +2
.)c
.#f "SS7 Signalling Backhauling with \fB\)M3PA\fR\)"
.hl
.)z
.pp
In the configuration in \fI\*(&f\n(&p\fR SGs act again as transfer points, but
this time for SS7 nodes.
.pp
\fB\)M3PA\fR\) management is based mainly on SSNM as defined in M3UA, with
some additional messages to handle startup {Tolga: another term might be
better}, changeover and congestion as defined in MTP3 [Q.704].
.pp
Communication of peers using \fB\)M3PA\fR\) is on PC granularity.
.sh 2 "Sample Configurations"
.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.
.[
rfc2119
.]
.sh 1 "Functional Areas"
.sh 2 "Signalling Point Code Representation"
.pp
SGs should control SPMCs as a whole. When a SPMC becomes unavailable, SG will
broadcast DUNA to all SGs, it has an association with. Similarly when a SPMC
becomes available DAVA and when a SPMC becomes restricted DRST will be sent.
.sh 2 "Routing Context and Routing Keys"
.pp
Unlike M3UA, there is no Routing Context/Routing Key concept present in
\fB\)M3PA\fR\).
.sh 2 "Network Appearance"
.pp
NA is not used in \fB\)M3PA\fR\). So, one SCTP association should carry
traffic belonging to one specific network only and this should be coordinated
among peers via configuration.
.sh 2 "SCTP Association Establishment"
.pp
There is no client/server relationship between peers in \fB\)M3PA\fR\). SCTP
associations might be initiated from any side.
.pp
After a SCTP association is established, SGs will exchange SSNM to update the
remote peer about the status of the PCs, which are by configuration declared
as reachable via them. Unless a corresponding message is received, all PCs are
assumed as accessible via the remote peer. Each SG will send DUNA for not
available PCs and DRST for restricted PCs after the establishment of the
association. The end of this unavailable/restricted PC announcement procedure
is marked with a TAL(Traffic Allowed) {Tolga: This is the message
corresponding to TRA} message. A SG should not start sending DATA to a peer,
unless TAL is received.
.sh 1 "Protocol Elements"
.pp
The following subsections describe the parameters which are added by this
extension, their format and the message in which they are used.
.sh 2 "Parameters"
.pp
\fB\)M3PA\fR\) supplements the following parameters:
.sh 3 "Concerned Destination"
.pp
\fB\)M3PA\fR\) supplements the \fI\)Concerned Destination\fR\) parameter of
M3UA
.[
m3ua12
.]
by allowing the parameter to be included in the \fB\)DUPU\fR message.  When
the \fI\)Concerned Destination\fR parameter is included in the \fB\)DUPU\fR
message it is used to indicate the Signalling End Point (SEP) to which the
indication of User Part Unavailability needs to be given.  When included in
the \fB\)SCON\fR message, the interpretation of the \fI\)Concerned
Destination\fR parameter is as given in M3UA.
.[
m3ua12
.]
.lp
The \fI\)Concerned Destination\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 = 0x0206          |         Length = 8          |
+- - - - - - - -+- - - - - - - - -+- - - - - - - - - - - - - - -+
|   reserved    |               Concerned DPC                   |
+---------------+-----------------+-----------------------------+
.sz +2
.)c
.)b
.lp
The \fI\)Concerned Destination\fR parameter contains the following fields:
.ip "\fB\)Reserved: 8-bits\fR" 2
Reserved bits are reserved for future use and MUST be coded all zeroes (0).
.ip "\fB\)Concerned DPC field: 24-bits\fR" 2
The \fI\)Concerned DPC\fR field is a three-octet parameter to allow for 14-,
16- and 24-bit binary formatted SS7 Point Codes.  A \fI\)Concerned DPC\fR that
is less than 24-bits is padded to the left to the 24-bit boundary.

The format of the 14-bit point code is as follows:
.(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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   reserved    |0 0 0 0 0 0 0 0 0 0|      14-bit Point Code    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.fi
.sz +2
.)b
The format of the 16-bit point code is as follows:
.(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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   reserved    |0 0 0 0 0 0 0 0|        16-bit Point Code      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.fi
.sz +2
.)b
The format of the 24-bit point code is as follows:
.(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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   reserved    |                24-bit Point Code              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.fi
.sz +2
.)b
.sh 2 "Messages"
.pp
\fB\)M3PA\fR\) uses DATA and SSNM messages as defined in M3UA. RC and NA
fields in messages are not used,i.e. they MUST not be filled.
.sh 3 "Destination User Part Unavailable (DUPU)"
.pp
\fB\)M3PA\fR\) supplements the \fB\)DUPU\fR\) message by permitting the
following optional parameters the included in the message:
.ix +4
.TS
tab(:);
lbss
lw(2.5i)lc.
Extension Parameters
_
Concerned Destination:Optional:
.TE
.ix -4
.ip
The format of the resulting \fI\)DUPU\fR\) message is as follows: \*(#u
.lp
.(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 = 0x0200          |           Length            |
+- - - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
|                        Network Appearance                     |
+---------------------------------+-----------------------------+
|           Tag = 0x0006          |           Length            |
+- - - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
\\                                                               \\
/                          Routing Context                      /
\\                                                               \\
+---------------------------------+-----------------------------+
|           Tag = 0x0012          |         Length = 8          |
+- - - - - - - -+- - - - - - - - -+- - - - - - - - - - - - - - -+
|   Mask = 0    |                 Affected PC                   |
\f(CB\
+---------------+-----------------+-----------------------------+
|           Tag = 0x0206          |         Length = 8          |
+- - - - - - - -+- - - - - - - - -+- - - - - - - - - - - - - - -+
|   reserved    |               Concerned DPC                   |
+---------------+-----------------+-----------------------------+
\f(CR\
|           Tag = 0x0204          |         Length = 8          |
+- - - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
|              Cause              |             User            |
+---------------------------------+-----------------------------+
|           Tag = 0x0004          |          Length             |
+- - - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
\\                                                               \\
/                            Info String                        /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.fi
.sz +2
.)c
.)b
.ip "\fB\)Concerned Destination: 32-bits\fR\)" 2

The optional \fI\)Concerned Destination\fR\) parameter is used if the SCON
message is sent from and IPSP with the relay capability.  The Concerned
Destination parameter contains one Concerned Destination Point Code field, a
three-octet parameter to allow for 14-, 16- and 24-bit binary formatted SS7
Point Codes.  A \fI\)Concerned Point Code\fR\) that is less that 24-bits is
padded to the left to the 24-bit boundary.
.pp
A new field is introduced to DUPU.
.pp
Concerned PC: Destination PC, which has caused DUPU to be generated. This
parameter is mandatory.
.pp
The format for DUPU message parameters is as follows:
.ba +2
.(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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Tag = 0x0200          |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                      Network Appearance                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Tag = 0x0006           |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\\                                                               \\
/                       Routing Context                         / 
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Tag = 0x0012          |          Length = 8           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Mask = 0    |                  Affected PC                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Tag = 0x0206          |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    reserved   |                 Concerned DPC                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Tag = 0x0204          |          Length = 8           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Cause             |            User               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Tag = 0x0004          |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\\                                                               \\
/                          INFO String                          /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.sh 3 "Congestion Test Message (CGT)"
.pp
<TBD>
.sh 3 "Traffic Allowed (TAL)"
.pp
<TBD>
.sh 3 "Changeover Mechanism Related Messages"
.lp
.(z L
.hl
.(c
.nf
.sz -2
\fC\
+-----+            +-----+
|STP1 +-----X------+ SG2 |
+--+--+            +--+--+
   |                  |
   |                  |
   |                  |
   |                  |
   |     +-----+      |
   +-----+ SG1 +------+
         +-----+
.sz +2
.)c
.#f "SG1 relaying changeover messages"
.hl
.)z
.pp
<TBD>
.sh 1 "Procedures"
.pp
\fB\)M3PA\fR provides for a set of procedures which are suited to peer-to-peer
operation which are based on the procedures of M3UA.
.[
m3ua12
.]
\fB\)M3PA\fR provide supplementary use of the \fI\)Concerned Destination\fR
parameter in the \fB\)DUPU\fR message, as well as providing additional
procedures for M3UA
.[
m3ua12
.]
messages.
.sh 2 "Establishment of SCTP Associations"
.pp
An SCTP
.[
rfc2960
.]
Association between two IPSPs is treated as equivalent to a "Signalling Route"
as defined in the MTP specifications \*#.
.(d
.ip \*#
For a definition of \fI\)"Signalling Route"\fR\), see the pertinent MTP
specifications, such as the ITU specifications.
.[
q704
.]
.)d
Therefore, an SCTP
.[
rfc2960
.]
Association form a signalling relation between two ISPSs acting as Signalling
Points.
.pp
Whenever an SCTP
.[
rfc2960
.]
Association is formed between two IPSPs, and the IPSPs have exchanged ASPUP
and ASPUP Ack messages, the signalling relation is deemed to be available
between the two IPSPs.  Whether messages can be transferred between the IPSPs
is then determined by the exchange of SNMM messages between the IPSPs.\*#
.(d
.ip \*#
\fB\)NOTE:-\fR
In contrast to the procedures and messages of M3UA
.[
m3ua12
.]
there is no need for IPSPs to exchange ASPTM or RKM messages.  These are
backhaul messages and there is no need to use them for peer-to-peer operation.
IPSPs exchange SNMM messages to query or indicate the availability, congestion
and restriction status of both adjacent and remote destinations.
.)d
.sh 2 "Routing of Messages"
.pp
An IPSPs MAY be componsed of multiple SPPs.  There MAY be more than one SCTP
Association between two IPSPs, but there MUST only one SCTP association
between two SPPs.  Each IPSP MUST represent one or more SPMCs (Signalling
Point Management Clusters) identified by a unique Signalling Point Code.
.pp
For each DATA message which is sent by an IPSP, the sending IPSP selects the
outgoing SCTP Association on the basis of the Destination Point Code (DPC) and
the Signalling Link Selection (SLS) in the message.  The Destination Point
Code (DPC) is used to identify the destination of the message and is used to
select the next hop IPSP which has a route to the indicated destination or a
final hop to the destination IPSP.  The Signalling Link Seletion (SLS) field
in the DATA message is used to select one of multiple SCTP Associations that
may exist between the sending IPSP and the next or final hop IPSP.


.sh 2 "IPSP State"

\".sh 2 "AS and ASP State Maintenance"
\".sh 3 "ASP State"
\".sh 3 "AS State"
\".sh 3 "ASP Up Procedures"
\".sh 3 "ASP Down Procedures"
\".sh 3 "ASP Active Procedures"
\".sh 3 "ASP Inactive Procedures"
\".sh 3 "Notify Procedures"
.sh 1 "Examples"
.sh 1 "Security"
.sh 1 "IANA Considerations"
.uh "Acknowledgments"
.pp
The authors would like to thank
<TBD>
for their valuable comments and suggestions.
.nr ii 0.5i
.uh "Notes"
.pd
.de ]<
.uh "References"
.rm (f )f
..
.[
$LIST$
.]
.(b
.uh "Author's Addresses"
.lp
.TS
expand tab(;);
lr.
Tolga Averson;Phone:
SS8 Networks Inc.;Email: tolga.averson@ss8.com
;URL: http//www.ss8.com/
.bl
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 Internet draft expires November, 2002.
.)b
.bp
.\".ce 1
.\".uh "List of Tables"
.\".(l I
.\".xp 3
.\".)l
.(b
.ce 1
.uh "List of Illustrations"
.(l I
.xp 2
.)l
.)b
.(b
.ce 1
.uh "Table of Contents"
.(l I
.xp 0
.)l
.)b
.bp
.uh "Copyright Statement"
.lp
\fBCopyright \(co The Internet Society (2002).  All Rights Reserved.\fR
.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 \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.