.\" -*- nroff -*-
.\" =========================================================================
.\"
.\" @(#) $Id: draft-bidulock-tsvwg-linuxsctp-00.me,v 1.2 2002/05/20 05:12:24 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).
.\"
.\" -------------------------------------------------------------------------
.\"
.\" $Name: Prerelease2-14 $($Revision: 1.2 $) modified $Date: 2002/05/20 05:12:24 $ by $Author: 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 4n
.nr pi 3n
.\".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.25i
.\".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 "Endnotes for Section \\\\n($1"
.pd
.\}
..
.ds a \a
.bp
.he 'Internet Draft'Linux SCTP'May 14, 2002'
.TS
expand tab(;);
l c r.
Network Working Group;;Brian Bidulock
INTERNET-DRAFT;;OpenSS7 Corporation
.bl 2
Expires in six months;;November 14, 2002
.bl 2
.TE
.(l C
\fB\
Stream Control Transmission Protocol (SCTP)
Implementation for Linux NET4
<draft-bidulock-tsvwg-linuxsctp-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 provides information for the Internet Community concerning
the OpenSS7 Linux NET4 SCTP implementation of the Stream Control Transmission
Protocol (SCTP).
.[
rfc 2960
.]
OpenSS7 Linux SCTP implements the socket library interface for Stream Control
Transmission Protocol (SCTP)
.[
rfc 2960
.]
with some minor modifications which are compatible with the BSD,
.[
BSD
.]
OG XNS 5.2
.[
XNS
.]
and POSIX interfaces.
.\"
.\"
.bp
.sh 1 "Introduction"
.sh 2 "Scope"
.pp
This Internet-Drafts provides information for the Internet Community regarding
the OpenSS7 Linux SCTP implementation of Stream Control Transmission Protocol
(SCTP)
.[
rfc 2960
.]
Although largely consistent with the sockets interface proposed in the TSV
Working Group of the IETF,
.[
sctpsocket-03
.]
this implementation maintains compatibility with BSD,
.[
BSD
.]
OG/XNS 5.2
.[
XNS
.]
and POSIX
standards.
.sh 1 "Implementation API Reference"
.sh 2 "Socket Calls"
.sh 3 "socket()"
.lp
.(b L
.nf
.sz -2
\f(CB\)#include <sys/socket.h>\f(CR\)
\f(CB\)#include <netinet/in.h>\f(CR\)

\f(CB\)int socket(int \f(CI\)domain\f(CB\), int \f(CI\)type\f(CB\), int \f(CI\)protocol\f(CB\));\fR\)

\f(CB\)sctp_socket = socket(PF_INET, SOCK_SEQPACKET, 0);\f(CR\)
\f(CB\)sctp_socket = socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);\f(CR\)
\f(CB\)sctp_socket = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP);\f(CR\)
\f(CB\)sctp_socket = socket(PF_INET, SOCK_RDM, IPPROTO_SCTP);\f(CR\)
.sz +2
.fi
.)b

.sh 3 "bind()"
.lp
.(b L
.nf
.sz -2
\f(CB\)#include <sys/types.h>\f(CR\)
\f(CB\)#include <sys/socket.h>\f(CR\)

\f(CB\)int bind(int \f(CI\)sockfd\f(CB\), struct sockaddr * \f(CI\)my_addr\f(CB\), socklen_t \f(CI\)addrlen\f(CB\));\fR\)
.sz +2
.fi
.)b
.pp
The socket library \fB\)bind\fR\)(2) call has the normal semantics as for
TCP or UDP.  The differences in the use of \fB\)bind\fR\)(2) call for use with
SCTP are as follows:
.np
\fI\)my_addr\fR\) can point to more than one socket address rather than a
single socket address.  Socket addresses are of type \fI\)struct
sockaddr_in\fR\) just as with TCP or UDP; there can simply be more than one
included in the \fI\)addrlen\fR).
.np
\fI\)addrlen\fR\) is the length of the entire address array.
.lp
The other normal semantics of \fB\)bind\fR(2) apply.
.lp
This approach to the \fB\)bind\fR\)(2) call is compatible with existing socket
semantics.  LinuxSCTP does does not implement the \fB\)bindx\fR\) call
described in the current sockets draft,
.[
sctpsocket-03
.]
as it is incompatible with the standard socket interface specifications.
.lp
Linux permits up to 8 \fI\)struct sockaddr_in\fR\) address to be provided in
the \fB\)bind\fR\)(2) call.  If additional addresses are required, they can be
added using \fB\)setsocketopt\fR\)(2).
.lp
LinuxSCTP provides the correct XNS
.[
XNS
.]
semantics for binding to a socket address with address family
\fB\)AF_UNSPEC\fR\).  In this case, the socket will be unbound from all
transport addresses and is ready to be bound anew with another call to
\fB\)bind\fR\)(2).
.lp
LinuxSCTP also permits SCTP sockets to be bound to \fB\)INADDR_ANY\fR\).
When so bound, the actual transport addresses to which the connection will be
bound are determined at the time that a connection is formed.  The bound
transport addresses for the connection will be the list of all available host
addresses.
.sh 3 "listen()"
.lp
.(b L
.nf
.sz -2
\f(CB\)#include <sys/socket.h>\f(CR

\f(CB\)int listen(int \f(CI\)sockfd\f(CB\), int \f(CI\)backlog\f(CB\));\f(CR
.sz +2
.fi
.)b
.pp
The socket library \fB\)listen\fR(2) call has the same semantics and operation
as it does for TCP or UDP.
.sh 3 "accept()"
.lp
.(b L
.nf
.sz -2
\f(CB\)#include <sys/types.h>\f(CR
\f(CB\)#include <sys/socket.h>\f(CR

\f(CB\)int accept(int \f(CI\)sockfd\f(CB\), struct sockaddr * \f(CI\)addr\f(CB\), socklen_t * \f(CI\)addrlen\f(CB\));\f(CR
.sz +2
.fi
.)b
.pp
In addition to the normal TCP semantics for \fB\)accept\fR\)(2), when an SCTP
association is accepted, the returned \fI\)addr\fR\) structure contains an
array of \fB\)struct sockaddr_in\fR\) structures which represent the IP
addresses associated with the connecting endpoint.  The first address in the
array is always the primary IP address which was used to form the association.
.sh 3 "connect()"
.lp
.(b L
.nf
.sz -2
\f(CB\)#include <sys/types.h>\f(CR
\f(CB\)#include <sys/socket.h>\f(CR

\f(CB\)int connect(int \f(CI\)sockfd\f(CB\), struct sockaddr * \f(CI\)serv_addr\f(CB\), socklen_t \f(CI\)addrlen\f(CB\));\f(CR
.sz +2
.fi
.)b
.pp
In addition to the normal TCP semantics for \fB\)connect\fR\)(2), multiple
IP addresses can be specified in \fI\)serv_addr\fR\) as an array of
\fB\)struct sockaddr_in\fR\) structures representing addresses to which to
attempt to connect in a reliable connection fashion.  (See \fI\)Advanced
Features\fR\).)
.lp
LinuxSCTP also supports calling \fB\)connect\fR\)(2) with socket address with
the address family \fB\)AF_UNSPEC\fR\).  When this is performed, an existing
connection is released.

.sh 3 "shutdown()"
.lp
.(b L
.nf
.sz -2
\f(CB\)#include <sys/socket.h>\f(CR

\f(CB\)int shutdown(int \f(CI\)sockfd\f(CB\), int \f(CI\)how\f(CB\));\f(CR
.sz +2
.fi
.)b
.sh 3 "close()"
.lp
.(b L
.nf
.sz -2
\f(CB\)#include <unistd.h>\f(CR

\f(CB\)int connect(int \f(CI\)sockfd\f(CB\));\f(CR
.sz +2
.fi
.)b

.sh 2 "Advanced Features"
.sh 3 "bind()"
.pp
Binding to \fB\)INADDR_ANY\fR will also automatically mark the socket as being
eligible for the automatic \fB\)ADD-IP\fR extension to SCTP.  This causes the
automatic addition of an IP address to active connections when an interface is
added to the host, and the automatic deletion of IP addresses from the active
connection when an interface is removed from the host.
.sh 3 "listen()"
.pp
LinuxSCTP permits listening on the same port number to disjoint sets of IP
addresses.  If a host is equipped with IP addresses
\fI\)IP-A\fR\), 
\fI\)IP-B\fR\), 
\fI\)IP-C\fR\) and
\fI\)IP-D\fR\), 
one socket can bind to an listen on a port number (e.g. 10000) on addresses
\fI\)IP-A\fR\) and
\fI\)IP-B\fR\); 
another socket, on addresses
\fI\)IP-C\fR\) and
\fI\)IP-D\fR\). 
When a client connects to address
\fI\)IP-A\fR\) or
\fI\)IP-B\fR\),
an association is formed between the client and the one socket.  The \fB\)INIT-ACK\fR
message will contain the IP addresses
\fI\)IP-A\fR\) and
\fI\)IP-B\fR\). 
When a client connects to address
\fI\)IP-C\fR\) or
\fI\)IP-D\fR\),
an association is formed between the client and the other socket.  The \fB\)INIT-ACK\fR
message will contain the IP addresses
\fI\)IP-C\fR\) and
\fI\)IP-D\fR\). 
.sh 3 "connect()"
.pp
LinuxSCTP permits multiple IP addresses to be specified in a
\fB\)connect\fR\)(2) call.  This causes the underlying implementation to send
\fB\)INIT\fR\) messages successively to each IP address in turn until an
\fB\)INIT-ACK\fR\) for the connection has been successfully received.  This
increases the reliability with which an SCTP association can be formed to a
multi-homed host.  It is also possible for the user to make successive
attempts to each IP address in separate calls to \fB\)connect\fR\); however,
waiting for each address to time out in a long list of addresses may delay the
overall connection process to unacceptable lengths.



.sh 2 "Terminology"
.pp
\fB\)CORID\fR supplements the terminology used in the UA
documents
.[
m2ua-11
.]
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
by adding the following terms:
.lp
\fI\)Changeback\fR \-
.ix +\n(iiu
the MTP3
.[
q.704
.]
procedure for redirecting signalling traffic back to a primary linkset from an
alternate linkset.
.lp
\fI\)Changeover\fR \-
.ix +\n(iiu
the MTP3
.[
q.704
.]
procedure for diverting signalling traffic from a failed primary linkset to an
alternate linkset.
.lp
\fI\)Lossless Fail-Over\fR \-
.ix +\n(iiu
is mechanism for fail-over between SCTP
.[
RFC 2960
.]
associations (i.e, between ASPs, IPSPs, SGPs or SGs) that provides for the
elminitation of duplication or loss of UA-User messages between SG and AS.
.lp
\fI\)Message Duplication\fR \-
.ix +\n(iiu
a situation where multiple copies of a UA-User message arrives at a Signalling
Endpoint.
.lp
\fI\)Message Loss\fR \-
.ix +\n(iiu
a situation where instances of a UA-User message is lost in transit between
Signalling Endpoints.
.lp
\fI\)Message Mis-sequencing\fR \-
.ix +\n(iiu
a situation where UA-User messages that are intended to arrive in sequence,
arrive at a terminating Signalling Endpoint in an order other than the order
in which the messages were transmitted at the originating Signalling Endpoint.
.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\)Signalling User Adaptation Layer (UA)\fR \-
.ix +\n(iiu
one or more of the Stream Control Transmission Protocol (SCTP)
.[
RFC 2960
.]
SS7 Signalling User Adaptation Layers
.[
m2ua-11
.]
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
supporting the \fI\)Correlation Id\fR parameter and the \fB\)BEAT\fR message.
.lp
\fI\)Time-controlled Changeover\fR \-
.ix +\n(iiu
the MTP3
.[
q.704
.]
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 existing UA
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
procedures do not include procedures to avoid loss or duplication of messages
when a UA peer must fail-over between SCTP
.[
RFC 2960
.]
associations between diverse Application Server Processes (ASPs), Signalling
Gateway Processes (SGPs), Signalling Gateways (SGs), and IP Signalling
Processes (IPSPs).
.pp
\fB\)CORID\fR provides procedures to eliminate message loss, duplication or
mis-sequencing under all failure, deactivation, recovery and activation
scenarios.
\fB\)CORID\fR provides the following capabilities that are
not provided for in the existing UA specifications:
.bu
Support for elimintating mis-sequencing of UA-User messages at signalling
endpoints (Application Servers or SS7 SEPs) when diverting messages between
ASPs, SGPs, SGs, or IPSPs by supporting \fB\)BEAT\fR procedures analogous to
the MTP3
.[
q.704
.]
Changeback procedure.

.bu
Support for eliminating duplication of UA-User messages at signalling
endpoints (Application Servers or SS7 SEPs) or SS7 endpoints across fail-over
between ASPs, SGPs, SGs, or IPSPs.

.bu
Support for elimination of message loss of UA-User messages between Signalling
Gateways (SGs) and Application Servers (ASs) across fail-over between ASPs,
SGPs, SGs, or IPSPs.
.\"
.\"
.\"
.\"
.sh 3 "Configuration"
.pp
For carrier-class operation, the SS7 Signalling User Adaptation Layers
recommend that Signalling Gateways and Application Servers be configured such
that there is no single point of failure within the SG/AS architecture or in
the intervening network.  The SS7 UAs also recommend that no Application
Server be configured for less than two (2) Application Server Processes.
.pp
All of the UAs describe an override, loadsharing and broadcast traffic mode.
The UA protocols place no restrictions on the distribution algorithm which is
used for distributing traffic over multiple Signalling Processes.
Additional traffic distribution proposals have been put forward for Load Selection
.[
loadsel
.]
and Load Grouping
.[
loadgrp
.]
.pp
Fail-over between Application Server Processes (ASPs) and Signalling Gateway
Processes (SGPs) is not detailed in the UA protocols,
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
but it is clear that when an SCTP association fails and the ASP transitions to
the ASP-DOWN state from the perspective of the SGP peer, the traffic which the
associated ASP was previously responsible needs to be diverted to an
alternative ASP (if available) in the same Application Server pool.
.sh 3 "Conditions at Fail-Over"
.pp
The details of this diversion of traffic is not specified, however, a
dichotomy exists when such fail-over occurs as a result of the loss of an SCTP
association between these Signalling Peer Processes (SPPs).  When an SPP loses its
SCTP association with another SPP, and diverts traffic towards another SPP,
there exists the possibility that messages previously destined to the peer SPP
exist in several categories, as follows:
.ip "Category (1) \-" 15
Queued in the sending SPP process,
.ip "Category (2) \-" 15
queued for transmission, but not yet transmitted by the transport provider
(SCTP),
.ip "Category (3) \-" 15
queued for retransmission, but not yet acknowledged by the peer transport
provider (SCTP), and,
.ip "Category (4) \-" 15
acknowledged by the peer transport provider (SCTP) and deleted from the
sending transport provider's (SCTP's) retransmission queue.
.lp
.(z L
.hl
.(c
.nf
.sz -2
\fC\
   Signalling   |    Stream Control               |        
   Peer              Transmission Protocol                 
   Process      |    (RFC 2960)                   |       
                                   First Transmission     
                |               +-----------------|------------->
  ___ _ _         ___ _ _       | ___ _ _                 
     | | | __   |    | | | __   |    | | | __     |       
     | | |/  \\       | | |/  \\  |    | | |/  \\ Retransmission
---->| | |    |-|--->| | |    |-+--->| | |    |---|------------->
     | | |\\__/       | | |\\__/       | | |\\__/            
  ___|_|_|      | ___|_|_|      | ___|_|_|        |       
                                                           
  Category (1)  | Category (2)  | Category (3)    | Category (4)
  ------------    ------------    ------------      ------------
   Queued in    |  Queued for   |  Queued for     | Acked and
   Signalling      Transmission    Acknowledgment   Deleted
   Peer Process |               |                 |        
.sz +2
.)c
.#f "Buffer Categories at SCTP Association Failure"
.hl
.)z
.pp
These categories are illustrated in \fI\*(&f\n(&p\fR.
Note that to retransmit categories (2) and (3) (and perhaps categories (1)) on
another link requires sent data acknowledgment or buffer retrieval capability
by the underlying transport provider.
.pp
As there is no SPP peer-to-peer acknowledgement, messages in Categories (3)
and (4), the message might or might not have been delivered to the peer SPP.
Therefore, at the time of failure of an SCTP association between two
Signalling Peer Processes (SPPs), it is not possible for either SPP to
determine which of the messages in categories (3) and (4) above (transmitted,
but not yet acknowledged; transmitted and acknowledged) were successfully
received by the peer before failure.  Without information concerning which
messages in this category were successfully received by the peer, the SPP
either risks message loss or message duplication when it diverts traffic from
the failed association.
.sh 3 "Sources of Message Loss and Duplication"
.pp
If the messages from category (3) or (4) are retransmitted on an alternative
association, the SPP diverting the traffic risks message duplication.  This is
because some messages of the category might possibly have been successfully
received by the peer before fail-over.
.pp
If the messages from category (3) and (4) are discarded before diverting
messages from categories (1) and (2) and then new traffic on an alternative
association, the SPP risks message loss.  This is because some of the messages
in category (3) and (4) might possibly have \fInot\fR been received by the
peer SPP before the association failed.
.pp
This is the dychotomy: regardless of the nature of a policy concerning the
disposition of messages at an SPP experiencing failure to its peer, without
information concerning messages successfully received by the peer, the SPP
risks message loss or duplication.
.pp
It should be possible to induce such a system to demonstrate message loss or
duplication.
.pp
Because SS7 performance requirements
.[
ss7perf
.]
have more stringent requirements against duplication of messages than loss of
messages, the only policy is to discard messages in category (3).
.pp
To avoid loss of messages to meet SS7 performance requirements
.[
ss7perf
.]
in consideration of this dichotomy, implementation cost may be driven higher than
would be the case if a procedure were established to exchange information
between the Signalling Processes on either side of a failed association.
.pp
This Internet-Draft provides Correlation Id and Heartbeat procedures
for fail-over for the SS7 signalling UAs which will remove the possibility of
message loss or duplication in the event that an SCTP association failure
while communication between the Application Server and Signalling Gateway is
still possible.
.sh 3 "Conditions at Recovery"
.lp
.(z L
.hl
.(c
.nf
.sz -2
\fC\
Signalling                          Application
Gateway               (X)           Server
.sp
/----------\\__________/____________/----------\\
|          |_________  /  _________|          |
|   SGP1   |...      \\   /      ...|   ASP1   |
|          |_____     \\ /     _____|          |
\\----------/     \\     X     /     \\----------/
                  \\   / \\   /
/----------\\_______\\_/   \\_/_______/----------\\
|          |________\\_____/________|          |
|   SGP2   |...      \\   /      ...|   ASP2   |
|          |________  \\ /  ________|          |
\\----------/        \\  X  /        \\----------/
                     \\/ \\/
     .               /\\ /\\  SCTP         .
     .              /  X  \\ Associations .
     .             /  / \\  \\             .
                  /  /   \\  \\
/----------\\_____/  /     \\  \\_____/----------\\
|          |_______/       \\_______|          |
|   SGPn   |...                 ...|   ASPn   |
|          |_______________________|          |
\\----------/                       \\----------/
.sz +2
.)c
.#f "Example (A) Configuration of ASPs and SGPs"
.hl
.)z
.pp
\fI\*(&f\n(&p\fR illustrates an example (A) configuration of ASPs and SGPs.
In this example, the ASP and SGP are interconnected with a full-mesh
arrangement of SCTP Associations.  Each ASP is interconnected to each SGP by
an association.
.pp
When a failure of the SCTP assocation occurs, it is, for example, between
`SGP1' and `ASP1' as indicated by the (X) in the \fI\*(&f\n(&p\fR.  When a
recovery occurs, it is also the SCTP association between `SGP1' and `ASP1'
that recovers.
.pp
The normal procedure for dealing with such a failure\*#
.(d
.#v
.ip \*#
As described in the UA documents.
.)d
is for SGPn to mark ASPn in the ASP-DOWN state and to redirect traffic over
the remaining ASPs in the Application Server\*#.
.(d
.#v
.ip \*#
For illustration purposes only, all ASPs in \fI\*(&f\n(&p\fR are members of
the one Application Server which is represented at all of the SGPs.
.)d
.ds #u \*#
.pp
When the SCTP association between ASP1 and SGP1 recovers and ASP1 succesfully
activates for the AS using the ASP Active Procedures\*#,
.(d
.#v
.ip \*#
See Section 4.3.4.3 of M3UA, SUA or TUA.
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
.)d
once ASP1 has entered the ASP-ACTIVE state for the AS, message mis-sequencing
can occur if traffic is immediately applied on the newly active association.
.pp
The UA procedures\*(#u provide no detail concerning the restarting of traffic
to recovering ASPs in the AS.
.sh 3 "Sources of Message Mis-Sequencing"
.pp
Because the SGPs can be experiencing different loads and other local factors
each SGP may differ, restoring a traffic flow to a newly active SGP without
first ensuring that messages are purged through the old path before the
diversion can result in message mis-sequencing.  This is illustrated in
\fI\*(&f\n(&n\fR.
.lp
.(z L
.hl
.(c
.nf
.sz -2
\fC\
    _____
   /     \\      SGPx
  |       |________________
  |       |        ______  |
  |       |    __ |X|X|    |
  |       |___/  \\|X|X|____|_____
  |       |   \\__/|X|X|    |     |
  |       |       |X|X|__  |     |            ASP1
  |       |________________|    \\|       _______________
  |       |                    ( \\      |       _____   |
  |  NIF  |                    (  \\     |   __ | | |    |
  |       |                    (   \\____|__/  \\| | |____|___
  |       |     SGP1                    |  \\__/| | |    |
  |       |________________      |      |      |_|_|_   |
  |       |        ______  |     |      |_______________|
  |       |    __ | | |    |     |
  |       |___/  \\| | |____|_____|
  |       |   \\__/| | |    |
  |       |       |_|_|__  |
  |       |________________|
  |       |
   \\_____/
.fi
.sz +2
.)c
.#f "Restoration of a Traffic Flow"
.hl
.)z
.pp
Before switching traffic back to SGP1 from SGPx, SGPx is queueing traffic
from ASP1 to the SS7 network.  If the traffic flow from ASP1 is switched
rapidly to SGP1, a race condition exists between messages in SGPx's queue and
messages in SGP1's queue.  A rapid switch can result in mis-sequencing.
.pp
As SGPx and SGP1 do not necessarily have to belong to the same SG, close
queue synchornization between SGPx and SGP1 cannot be expected.
.pp
\fB\)CORID\fR provides both a time-controlled and a Heartbeat procedure for
restoration of traffic to avoid mis-sequencing during restoration.
.sh 2 "Functional Areas"
.pp
The \fB\)CORID\fR procedures to avoid message loss, duplication and
mis-sequencing under these types of scenarios requires a protocol parameters
that provide a clear identification of the independent traffic flows involved.
Then, procedures are required to control the fail-over and restoration of the
identified traffic flows to avoid message loss.
.pp
The SS7 MTP3
.[
q.704
.]
provide an excellent example of the types of procedures that can be applied to
the problem of switching traffic flows across redundant processes\*#.
.(d
.#v
.ip \*#
See, for example, Clause 5 "Changeover", Clause 6 "Changeback", Clause 7
"Forced Rerouting" and Clause 8 "Controlled Rereouting" of the MTP3
specifications.
.[
q.704
.]
.)d
.sh 3 "Identification of Traffic Flows"
.pp
Traffic flows between Server Processes in the UAs are managed on the basis of
the Application Server to which the traffic flows correspond.  Traffic flows
from SG to AS are identified by the Routing Key or Routing Context to which
they correspond\*#.
.(d
.#v
.ip \*#
This is true for all User Adaptation layers with the exception of M2UA.
.[
m2ua-11
.]
In M2UA, the Application Server and traffic flows are identified by an
equivalent of the Routing Context: the Interface Identifier.  An Application
Server may also represent multiple Interface Identifiers.
.)d
.pp
An Application Server Process can be active and handling traffic for any
number or combination of traffic flows.  That is, the ASP can be actively
handling traffic for any number of Application Servers.
.pp
When an SCTP
.[
RFC 2960
.]
association fails, it is necessary to identify both the sequence of the last
message succesfully received and processed by the Signalling Process, as well
as the traffic flow within which that sequence applies.
.pp
Therefore, this document identifies a message in a traffic flow by the Routing
Context, Load Id, Stream Id and the sequence number within that flow as
identified by the Correlation Identifier.  The Correlation Identifier is a
combination of traffic flow identifier and correlation number which is applied
to all divertable traffic.
.pp
For details on the assignment of Traffic Flow Identifiers and Correlation
numbers, see Section 4.1.2 "Correlation".
.sh 4 "SGP Starting New SGP-to-ASP Traffic"
.pp
When traffic is orignally started for a traffic flow the first divertable
message in the traffic flow is assigned a correlation number of one (1) by the
sending Signalling Process.  Subsequent divertable messages within the routing
context are given the Correlation Id number of two (2), three (3), and so on.
.pp
Because SCTP is a sequenced reliable transport,
.[
RFC 2960
.]
it is only necessary to communicate this Correlation Id number between SPP
peers for the intial message which is sent to the peer.  Each Signalling
Peer Process \fB\)MUST\fR be capable of counting the messages which have been
sent or received on the SCTP association, and assigning each subsequent
message the next sequential Correlation Id number.
.sh 4 "SPP Diverting peer SPP Traffic"
.pp
Should, for example,  the association fail between the SGP and the ASP, the
SGP will recover whatever buffers from categories (1), (2), (3) and (4), and
immediately restart traffic, in sequence, on another active ASP within the AS.
When the SGP restarts traffic on this alternate ASP, if the messages belong to
Category (4) or (3) (i.e, they were transmitted on but not acknowledged by the
underlying transport, or transmitted and acknowledged), it will label the
initial message sent with the Correlation Id of the message at the time that
it was originally sent.  When the SGP sends tmessages from Category (2), (1)
and newly arriving traffic, the SGP will not tag the messages with a
Correlation Id, but instead will label them internally with the next
sequential correlation numbers for the traffic flow.
.pp
Thus, the alternate Signalling Peer Process which is receiving diverted
traffic will be able to distinguish the problematic Category (3) and (4)
messages from those which follow.  When an tagged message is received, the
Signalling Peer Process is now aware that the messages were previously sent to
the primary SPP to which the SCTP association was lost.  When an untagged
message arrives, the receiving Signalling Peer Process is aware that this and
subsequent messages within the traffic flow represent previously unsent
traffic.
.pp
(Detailed procedures for the tagging of messages are described in Section
4.1.3 and 4.1.5.2.1; for diversion, Sections 4.2.2, 4.2.3 and 4.1.6.)
.sh 4 "SPP Receiving Diverted Traffic"
.pp
At the Signalling Process receiving the diverted traffic for the Routing
Context, three actions are possible (or, variations on the three):
.np 1
Ignore the Correlation Id and process the messages blind at the risk that
message duplication will occur,
.np
discard all messages tagged with a Correlation Id at the risk of increased
message loss, or,
.np
perform the procedures described in Section 4.1.5.2.2 minimizing the message
duplication and loss resulting from the diversion.
.pp
.sh 4 "SPP Restoring Traffic"
.pp
Should, for example, the association recover between the SGP and ASP, the ASP
will need to rebalance the load across the available SGPs and the newly
available SGP.  As discussed, if the ASP switches traffic immediately, message
mis-sequencing can occur.  Two procedures are provided by \fB\)CORID\fR for
restoring traffic without message mis-sequencing: a Heartbeat procedure and a
timer procedure.
.pp
The Heartbeat procedure withholds traffic from the SGP currently active for
the traffic flow and sends a \fB\)BEAT\fR message on the flow.  Once the
\fB\)BEAT ACK\fR is received by the ASP, the ASP is assured that there is no
traffic pending on the SGP and the traffic flow can be switched to the
recovered SGP.
The Heartbeat procedure is applicable to recovery between SGPs in the same
SG.
.pp
The Timer procedure witholds traffic from the SGP currently active for the
traffic flow and waits until a timer expires.  Once the timer expires, the ASP
is resonably assured that there is no traffic pending on the SGP and the
traffic flow can be switched to the recovered SGP.
The Timer procedure is applicable to recovery between SGPs in different SGs.
.pp
Restoration of traffic is described in detail in Sections 4.2.3 and 4.1.6.
.sh 2 "Sample Configurations"
.lp
.(z L
.hl
.(c
.nf
.sz -2
\fC\
                 |
   SS7                           IP
   Network       |               Network
             _________________                ________     _____
            |    |    ________|        ______|        |   /     \\
            |        |        |_______|  ____|  ASP1  |  |       |
 B/D-Links  |    |   |  SGP1  |________  |   |________|  |       |
 ___________| STP SG1|________|        | |    ________   |       |
           /|    |   |        |__   o  | | __|        |  |  AS1  |
          / |        |  SGP2  |__   o  | | __|  ASP2  |  |       |
   \\     /  |    |   |________|     o  | |   |________|  |       |
    \\   /   |_________________|        | |    ________   |       |
     \\ / C-   |                     o  | | __|        |   \\_____/
      X  Links|  |                  o  | | __|  ASP3  |    _____
     / \\     _|_______________      o  | |   |________|   /     \\
    /   \\   |    |    ________|        | |    ________   |       |
   /     \\  |        |        |__   o  | | __|        |  |       |
          \\ |    |   |  SGP3  |__   o  | | __|  ASP4  |  |       |
 __________\\| STP SG2|________|     o  | |   |________|  |  AS2  |
            |    |   |        |________|_|    ________   |       |
            |        |  SGP4  |_______ |_____|        |  |       |
            |    |   |________|       |______|  ASP5  |  |       |
            |_________________| SCTP         |________|   \\_____/
                 |              Associations

                 |
.fi
.sz +2
.)c
.#f "Example (B) Sample Multiple-SG Configuration"
.hl
.)z
.pp
A typical Example (B) configuration multiple Signalling Gateways is
illustrated in \fI\)\*(&f\n(&p\fR.  In this configuration a number of Application
Server Processes (ASPs) serving a number of Application Servers (ASs) are connected
to two Signalling Gateways (SGs).  The SGs appear as mated SS7 Signalling
Transfer Points (STPs)
.[
q.705
.]
to the SS7 Network.  Traffic originating at Signalling Endpoints (SEP) in the
SS7 network and directed toward SEP in the IP network (i.e., Application
Servers) is loadshared over the STPs by the Signalling Link Selection (SLS)
.[
q.704
.]
value associated with each message.  Traffic originating at the SEP in the IP
network (i.e, AS) is loadshared over the SGs in the same fashion.
.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"
The following protcol element definitions are provided by \fB\)CORID\fR in
extension to the existing protocol element definitions for the UAs.
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
.sh 2 "Parameters"
.pp
The following subsections describe the parameters used for \fB\)CORID\fR,
their format and the message in which they are used.
.sh 3 "Correlation Id"
.pp
The \fI\)Correlation Id\fR parameter is used in the \fB\)ASPAC\fR, \fB\)ASPAC
ACK\fR, and UA-User data messages.  It is used to identify data messages sent
to a peer SPP.
.lp
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 = 0x0019          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                      Correlation Id #1                        |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
|                      Correlation Id #2                        |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
\\                               .                               \\
/                               .                               /
\\                               .                               \\
/                                                               /
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
|                      Correlation Id #n                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.lp
The \fI\)Correlation Id\fR parameter contains one or more of the following
field:
.ip "\fB\)Correlation Id field: 8-bytes\fR" 2

The \fI\)Correlation Id\fR field is formatted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Correlation Number                       |
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
|                       Traffic Flow Id                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.ip "\fB\)Correlation Number field: 32-bits (unsigned integer)\fR" 2

The \fI\)Correlation Number\fR field identifies a particular message within a
traffic flow.  When the \fI\)Correlation Id\fR parameter is included in the
\fB\)ASPAC (ACK)\fR message, this field identifies the last sent message for
the indicated traffic flow.  When the \fI\)Correlation Id\fR parameter is
included a UA-User data message, this field identifies the correlation number
of the message in which it is contained.
.ip "\fB\)Traffic Flow Id field: 32-bits (unsigned integer)\fR" 2

The \fI\)Traffic Flow Id\fR field identifies a particular indepdently
sequenced traffic flow to which the \fI\)Correlation Number\fR field value
applies.
For details on \fI\)Traffic Flow Id\fR assignment, see Section 4.1.2.2.
This field is formatted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Load Id           |          Stream Id            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.ip "\fB\)Load Id field: 16-bits (unsigned integer)\fR" 2

The \fI\)Load Id\fR field identifies a load range associated with an SPP.
When used for tagging messages or in the \fB\)ASPAC (ACK)\fR message for an
Load Selection,
.[
loadsel
.]
Loadshare AS or Load Group,
.[
loadgrp
.]
the \fI\)Load Id\fR field must identify an SPP (and Load Selector) within an
Application Server.
For an Override or Broadcast AS, the Load Id is not required and
\fB\)SHOULD\fR be coded zero (0).
For details on the assignment of \fI\)Load Ids\fR, see Section 4.1.2.2.
.ip "\fB\)Stream Id field: 16-bits (unsigned integer)\fR" 2

The \fI\)Stream Id\fR field contains the SCTP Stream Identifier
.[
rfc 2960
.]
on which the message or referenced message was sent.
.ba -2
.ba -2
.lp
When the \fI\)Correlation Id\fR parameter is included in the \fB\)ASPAC\fR,
\fB\)ASPAC ACK\fR, and UA-User data messages, only one Routing Context
representing a single Application Server \fB\)MUST\fR be associated (specified
or implied) with the message.
.sh 2 "Messages"
.sh 3 "ASP Active (ASPAC)"
.pp
\fB\)CORID\fR supplements the \fB\)ASPAC\fR mesage by permitting the following
optional parameters to be included in the message:
.ix +4
.TS
tab(:);
lbss
lw(2.5i)lc.
Extension Parameters
_
Correlation Id:Mandatory:
.TE
.lp
The format of the resulting \fB\)ASPAC\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 = 0x000b          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Traffic Mode Type                     |
+-------------------------------+-------------------------------+
|         Tag = 0x0006          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Routing Context                       |
+-------------------------------+-------------------------------+
|         Tag = 0x0019          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                         Correlation Id                        /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0004          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Info String                         /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.lp
No other changes to the \fB\)ASPAC\fR message format are provided by this
extension.
.lp
The \fI\)Correlation Id\fR parameter is used by the ASP in the \fB\)ASPAC\fR
message to indicate the correlation identifier for the first UA-User message
to be transmitted in each traffic flow from the Application Server being
activated to the Signalling Gateway.  The Application Servers for which the
\fI\)Correlation Id\fR apply is either indicated in the \fB\)ASPAC\fR message
by providing the associated \fI\)Routing Contexts\fR, or, if there is no
\fI\)Routing Context\fR parameter in the message, the associated Application
Servers are implied by the SGP and ASP configuration data.
.lp
When the \fI\)Correlation Id\fR parameter is present in the \fB\)ASPAC\fR
message, the message \fB\)SHOULD\fR only contain one \fI\)Routing Context\fR
in the \fI\)Routing Context\fR parameter.  When the \fI\)Correlation Id\fR
parameter is not present, but required by the SGP, the value of the
correlation id is assumed to be zero (0).
.lp
The \fB\)ASPAC\fR message \fB\)MAY\fR contain additional extension parameters
provided for by other extensions.
.sh 3 "ASP Active Acknowledgement (ASPAC ACK)"
.pp
\fB\)CORID\fR supplements the \fB\)ASPAC ACK\fR mesage by permitting the
following optional parameters to be included in the message:
.ix +4
.TS
tab(:);
lbss
lw(2.5i)lc.
Extension Parameters
_
Correlation Id:Mandatory:
.TE
.lp
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 = 0x000b          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Traffic Mode Type                     |
+-------------------------------+-------------------------------+
|         Tag = 0x0006          |            Length = 8         |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
|                         Routing Context                       |
+-------------------------------+-------------------------------+
|         Tag = 0x0019          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                         Correlation Id                        /
\\                                                               \\
+-------------------------------+-------------------------------+
|         Tag = 0x0004          |            Length             |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\\                                                               \\
/                           Info String                         /
\\                                                               \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.sz +2
.)c
.)b
.lp
No other changes to the \fB\)ASPAC ACK\fR message format are provided by this
extension.
.lp
The \fI\)Correlation Id\fR parameter is used by the SGP in the \fB\)ASPAC
ACK\fR message to indicate the correlation identifier for the first UA-User
message to be transmitted from the Signalling Gateway to the Application
Server being activated for each traffic flow.  The Application Servers for
which the \fI\)Correlation Id\fR apply is either indicated in the \fB\)ASPAC
ACK\fR message by providing the associated \fI\)Routing Contexts\fR, or, if
there is no \fI\)Routing Context\fR parameter in the message, the associated
Application Servers are implied by the SGP and ASP configuration data.
.lp
When the \fI\)Correlation Id\fR parameter is present in the \fB\)ASPAC ACK\fR
message, the message \fB\)SHOULD\fR only contain one \fI\)Routing Context\fR
in the \fI\)Routing Context\fR parameter.  When the \fI\)Correlation Id\fR
parameter is not present, but required by the ASP, the value of the
correlation id is assumed to be zero (0).
.lp
The \fB\)ASPAC ACK\fR message \fB\)MAY\fR contain additional extension
parameters provided for by other extensions.
.sh 1 "Procedures"
.af $p i
.sh 2 "Traffic Handling"
.sh 3 "Classification"
.pp
Divertable messages are any UA-User messages destined for an Application
Server.  Divertable messages are UA-User data and some management (non-ASP
management) messages that have an explicit or implied Routing Context and have
strict requirements preventing loss, duplication or mis-sequencing.
SNMM messages do not quality as divertable because they can apply to more than
on Application Server.  UA-User messages that qualify as divertable messages
are listed in \fI\)\*(&t\n(&a\fR.  Although some messages in some message
classes might be considered as non-divertable, all messages in the message
classes listed in \fI\)\*(&t\n(&a\fR \fB\)SHALL\fR be treated as divertable.
.(b
.#t "Divertable Messages by UA"
.TS
center box tab(:);
lb|lb|lb|lb
l|l|l|l.
 UA:Class:Msg:Description
_
 M3UA:Transfer:DATA
_
:Connection-:CLDT:Marked
:less:CLDR:Return on Error
:_:_:_
:Connection-:CORE
 SUA:Oriented:COAK
::CODT
::RESRE
::RESCO
::RELRE
_
:Dialogue:TUNI:w/o components
:Handling:TQRY:or
::TCNV:marked
::TRSP:Return on Error
::_:_
::TUAB
::TPAB
 TUA::TNOT
:_:_:_
:Component:CINV:Operation
:Handling:CRES:Class 1, 2 or 3
::_:_
::CERR:
::CREJ:
::CCAN:
.TE
.)b
.sh 3 "Correlation"
.pp
Each independent traffic flow for a given Application Server as identified by
a Routing Context \fB\)MUST\fR be correlated using a Correlation Id.  The
Correlation Id consists of a correlation number and a traffic flow identifier.
The correlation number is used to number each message within the given traffic
flow.
.sh 4 "Assignment of Correlation Ids"
.pp
To accomodate all combinations of traffic modes at AS and SG, divertable
messages are correlated by independent traffic flow.  That is, each sent
divertable message is labelled with a traffic flow identifier and a
correlation number for the AS that is incremented for each message sent for
the traffic flow.  In the same fashion, each received divertable message is
labelled with the identity of the traffic flow on which it was received and a
correlation number for the AS that is incremented for each message received on
that traffic flow.
.pp
An SPP maintains two correlation counters for each traffic flow for each AS:
for each traffic flow, one counter tracks the correlation number of messages
sent to the AS and the other tracks the correlation number of messages
received from the AS.  Before traffic is started for an AS on a traffic flow,
these counters are set to zero (0).  The first divertable message for the AS
on the flow \fB\)MUST\fR then be assigned a coorrelation number of one (1);
and subsequent divertable messages, the correlation number of two (2), three
(3), and so forth.
.pp
Whenever traffic is started for the AS (using the ASP Active Procedures), the
correlation counters \fB\)SHALL\fR be synchronized by exchanging correlation
numbers and traffic flow identifiers in the \fB\)Correlation Id\fR parameter
in the \fB\)ASPAC\fR and \fB\)ASPAC ACK\fR messages.  For new traffic, the
correlation number \fB\)MUST\fR zero (0); for restarting traffic, it is
\fB\)SHOULD\fR be the correlation number of the last message transferred.
(See Section 4.2.3.)
.sh 4 "Assignment of Traffic Flow Ids"
.pp
Traffic flow identifiers \fB\)SHALL\fR consist of two components:
.np
A \fI\)Load Id\fR component that identifies a switchable traffic load pattern
within an Application Server.  This component \fB\)SHALL\fR be assigned by the
peer SPP.
.np
A \fI\)Stream Id\fR component that identifies the SCTP stream upon which a
message is sent or received.  This component \fB\)SHALL\fR be assigned by the
sending SPP and \fB\)MUST\fR correspond to the SCTP Stream upon which the
message was sent.
.pp
Load Ids \fB\)SHALL\fR assigned by an SPP and \fB\)MUST\fR be communicated to
the peer SPP in an \fB\)ASPAC\fR or \fB\)ASPAC ACK\fR message.  For traffic
distributions that do not loadshare (i.e, Override and Broadcast), the load
flow identifier is not required and \fB\)MAY\fR be set to zero (0).  Following
are rules for the assignment of load identifiers at an SPP:
.np
If an SPP belongs to a regular Override or Broadcast AS, no Load Id need be
assigned or included by the SPP in the \fI\)Correlation Id\fR parameter.
.np
If an SPP belongs to a regular Loadshare AS, a Load Id is assigned and
included in the \fI\)Correlation Id\fR parameter.  The Load Id assigned
\fB\)MUST\fR unambiguously identify the SPP within the AS.
.np
If an SPP belongs to a Load Selector,
.[
loadsel
.]
a Load Id is assigned and included in the \fI\)Correlation Id\fR
parameter regardless of the Traffic Mode Type of the AS.  The Load Id
assigned \fB\)MUST\fR unambiguously identify the SPP and the Load Selector
within the AS.
.np
If an SPP belongs to a Load Group,
.[
loadgrp
.]
a Load Id is assigned and included in the \fI\)Correlation Id\fR for a
Loadshare AS or Load Group.  An assigned Load Id \fB\)MUST\fR
unambiguously identify the SPP and the Load Selector within the AS.  For a
non-loadshare AS and Load Group, no Load Id need be assigned or included in
the \fI\)Correlation Id\fR parameter.
.sh 3 "Tagging"
.pp
Each sent or received message for an AS is labelled when it is first sent or
received.  The message is labelled with the traffic flow id associated with
the SPP to or from which the message was sent or received, and the correlation
number assigned within the traffic flow (see Section 4.1.2.1).
.pp
Tagged messages contain a \fI\)Correlation Id\fR parameter: an untagged
message is tagged by adding a \fI\)Correlation Id\fR parameter to the message.
When a message is tagged, it \fB\)SHALL\fR be tagged with the same values of
the traffic flow id (if required) and correlation number with which it was
originally labelled.
.pp
Although each message is labelled with a traffic flow id and correlation
number, the message is not necessarily tagged with the \fI\)Correlation Id\fR
parameter when the message is sent.  Messages for an AS that are sent for the
first time \fB\)MUST NOT\fR be tagged.  Messages retransmitted \fB\)MUST\fR be
tagged.
.pp
.sh 3 "Buffering"
.sh 4 "SPP witholding unsent messages"
.pp
\fB\)CORID\fR procedures require that an SPP at times withhold AS traffic.  To
perform this, the SPP allocates a diversion buffer and places in the buffer
all subsequent messages that would otherwise be sent to the SPP for the AS
into the buffer.
.sh 4 "Local copies of sent messages"
.pp
To reduce loss of messages, an SPP \fB\)SHOULD\fR buffer messages until it can
be assured that the peer SPP has received and processed the message.  When a
message is sent to an SPP supporting \fB\)CORID\fR a local copy of the message
\fB\)MUST\fR be kept until it is discarded in accordance with a \fB\)CORID\fR
procedure.\*#
.(d
.#v
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR  A simple way to meet the requirements for
keeping local copies of messages is to keep a local copy of all messages sent
to an SPP supporting \fB\)CORID\fR until a fixed buffer allocation is
exceeded, or until the local copy lifetime expires.  T(lifetime) and buffer
capacity can then be adjusted to ensure that local copies of messages are not
discarded too early resulting in message loss during fail-over.
.)d
.np
A local copy \fB\)SHOULD NOT\fR be discarded when it is acknowledged by the
peer SCTP.
.np
a local copy \fB\)SHOULD NOT\fR be discarded until the sending SPP is
confident that the peer SPP has received and processed the message.
.np
To ensure that stale messages do not propagate through the system, an SPP
\fB\)SHOULD NOT\fR keep local copies of sent messages for longer than a
maximum lifetime T(lifetime).  Any local coppies of sent messages that are older
(measured from the moment at which they were sent to the peer SPP) than
T(lifetime) \fB\)SHOULD\fR be discarded.
.sh 3 "Message Handling"
.sh 4 "Untagged Messages"
.sh 5 "SPP sending untagged messages"
.pp
An SPP sends untagged messages to a peer SPP whenever the message is being
sent for an Application Server for the first time.  All divertable messages
which have been transmitted for the first time \fB\)MUST NOT\fR be sent
tagged.
.pp
Local copies of untagged messages awaiting acknowledgement or expiry are
labelled with the Routing Context for the Application Server to which they
were sent, the traffic flow id of the SPP to which they were sent, and the
correlation number of the message.  The correlation number with which a
message is labelled \fB\)MUST\fR be the next sequential correlation number for
the AS and traffic flow.  These labels can be used later to tag a message that
is marked for diversion.
.sh 5 "SPP receiving untagged messages"
.pp
When an SPP receives an untagged message, it associated with the message the
next sequential correlation number for the Routing Context and traffic flow id
for which the message was received.  Untagged messages are received in order
and \fB\)MAY\fR be processed when received.  The SPP \fB\)SHOULD\fR keep track
of the Correlation Ids that have been processed for the AS.
.sh 4 "Tagged Messages"
.sh 5 "SPP sending tagged messages"
.pp
An SPP sends tagged traffic whenever it sends traffic that is marked for
diversion.  That is, whenever an SPP sends divertable messages to an SPP other
than the original SPP for which those messages were labelled, the SPP
\fB\)MUST\fR tag the message with the \fI\)Correlation Id\fR parameter that
contains the labelled traffic flow id (if required) and correlation number.
.pp
In addition, when a ASP becomes active for a Broadcast AS, an SGP \fB\)MUST\fR
tag the first message in each traffic flow towards the ASP to allow the ASP to
synchronize its entry into the Broadcast AS.
.sh 5 "SPP receiving tagged messages"
.pp
The handling of tagged messages is the mechanism that provides for the
reduction of message loss, duplication and mis-sequencing.  An SPP receiving
divertable messages containing a \fI\)Correlation Id\fR parameter
\fB\)SHALL\fR perform the following actions:
.np
The SPP determines (by implementation-dependent means \*#)
.(d
.#v
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR  Determining which messages have already been
processed for the AS may require some ASP-to-ASP or SGP-to-SGP synchronization
that is outside the scope of the UA documents
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
and also outside the scope of this document.

If the received traffic flow id matches that of the SPP on which the message
was received, this might be a simple matter of comparing the correlation
number of the message to the correlation number of the last message processed
for the Application Server.
.)d
whether the message has already been processed for the AS.
.np
If the message has not already been processed for the AS, it is processed as normal.
.np
If the message has already been processed for the AS, it is discarded.
.np
If, as a result of some failure, the SPP cannot determine with any certainly
whether the tagged message has been processed  for the AS, or not, the SPP
\fB\)MUST\fR discard the message\*#.
.(d
.#v
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR  The reason for discarding tagged messages at
the receiver for which it cannot be determined with any certainty whether the
message was processed for the AS or not is because, for SS7, message loss is
preferrable to message duplication.
.[
q.706
.]
.)d
.sh 3 "Diversion"
.sh 4 "SPP diverting traffic from a failed, deactivated or overridden peer SPP"
.sh 5 "Alternate SPP in same AS or SG, or No Alternate SPP"
.pp
When an SPP diverts AS traffic away from a failed, deactivated or overridden
peer SPP to an alternate peer SPP in the same AS or SG, the SPP \fB\)SHALL\fR
perform the following actions:
.np
The SPP tags (see Section 4.1.3) each untagged message that is marked for
diversion.
.np
If an alternate SPP is available (active for the AS), the SPP sends the
messages marked for divertion to the alternate SPP.
.np
If no alternate SPP exists (the AS is AS-PENDING), the SPP buffers the marked
messages in a buffer used for buffering messages while the AS is in the
AS-PENDING state.
.np
The SPP then diverts AS traffic, beginning with traffic withheld for the AS,
to the alternate SPP or AS-PENDING buffer.
.pp
This procedure corresponds to the Sequenced Changeover procedure used by the
SS7 MTP.
.[
q.704
.]
.sh 5 "Alternate SPP in different AS or SG"
.pp
When an SPP diverts AS traffic away from a failed or deactivated peer SPP to
an alternate peer SPP in a different AS or SG, the SPP \fB\)SHALL\fR perform the following
actions:
.np
The SPP starts timer T(divert) and continues buffering AS traffic until the
timer expires.
.np
When T(divert) expires, and the failed or deactivated SPP has not recovered,
the SPP continues with the following actions:
.np
The SPP discards all tagged messages and messages marked for diversion.
.np
The SPP starts AS traffic, beginning with the contents of the diversion
buffer, to the alternate SPP.
.pp
This procedure corresponds to the Time-Controlled Changeover procedure used by
the SS7 MTP.
.[
q.704
.]
.sh 4 "SPP diverting traffic from an active peer SPP"
.pp
When an SPP wishes to divert AS traffic away from an active peer SPP, the SPP
\fB\)SHALL\fR perform the following actions:
.np
The SPP witholds and buffers AS traffic for the SPP from which the traffic
is being diverted.
.np
The SPP sends a \fB\)BEAT\fR message with a unique identifier\*# in the
\fI\)Heartbeat Data\fR parameter on the same SCTP stream(s) on which the
traffic being withheld for diversion was previously sent.
.(d
.#v
.ip \*#
\fB\)IMPLEMENTATION NOTE:\-\fR  Although the unique identifier placed in the
\fI\)Heartbeat Data\fR is implementation dependent, a useful identifier would
be the tuple formed by the Routing Context, Correlation Id corresponding to
the last message sent to the SPP from which traffic is to be diverted.
.)d
.np
The SPP starts a timer T(restore).
.np
If the SPP receives the \fB\)BEAT ACK\fR message(s) that contain the unique
identifier(s) in the \fI\)Heartbeat Data\fR parameter before timer T(restore)
expires, the SPP diverts the traffic, beginning with the withheld traffic,
to the target SPP and cancels the T(restore) timer.
.np
If the timer T(restore) expires, the diverting SPP diverts traffic, beginning
with the withheld traffic, to the target SPP.
.np
If an SPP receives a \fB\)BEAT ACK\fR message containing a unique identifier
for which the timer T(restore) has already expired, the SPP ignores the
message.
.pp
The purpose of this \fB\)BEAT\fR procedure is to avoid mis-sequencing by
ensuring that all messages sent for the AS to the old SPP arrives before
messages are sent to the new SPP.  This avoids races between (and possible
mis-sequencing of) messages sent on the old SPP and messages sent on the new
SPP.
.pp
This procedure corresponds to the Changeback procedure used by the SS7 MTP.
.[
q.704
.]
.sh 2 "ASP Management Procedures"
.sh 3 "ASP Down Procedures"
.sh 4 "SPP detecting loss of SCTP association"
.pp
When an SPP receives an SCTP COMMUNICATION LOST or RESTART indication and
there are Application Servers active for the association, the SPP
\fB\)SHALL\fR perform the
following actions with regard to active AS traffic for the association:
.np
The SPP witholds AS traffic for the peer SPP in a diversion buffer.
.np
The SPP marks for diversion all local copies of AS messages already sent to
the peer SPP.
.np
The SPP then \fB\)SHALL\fR perform the actions described in Section 4.1.6.1.
.sh 4 "ASP sending ASPDN"
.pp
An ASP \fB\)MUST NOT\fR send an \fB\)ASPDN\fR message until it has completed
the ASP Inactive Procedures with the intended SGP for every AS.
.sh 4 "SGP or IPSP receiving ASPDN"
.pp
An SGP or IPSP, upon rreceiving an \fB\)ASPDN\fR message from an ASP-ACTIVE
ASP, \fB\)MUST\fR perform the ASP Inactive Procedures with regard to
\fB\)CORID\fR (see Section 4.2.2.2) for every AS for which the ASP is
ASP-ACTIVE and then complete the \fB\)ASPDN\fR procedures.
.sh 4 "ASP receiving ASPDN ACK"
.pp
An SGP or IPSP, upon receiving an unsolicited \fB\)ASPDN ACK\fR message from
an active SGP, \fB\)MUST\fR perform the ASP Inactive Procedures with regard to
\fB\)CORID\fR (see Section 4.2.2.3) for every AS for which the ASP is
ASP-ACTIVE and then complete the \fB\)ASPDN ACK\fR procedures.
.sh 3 "ASP Inactive Procedures"
.sh 4 "ASP sending ASPIA"
.pp
When an ASP wishes to deactivate an Application Server with an SGP, the ASP
\fB\)SHALL\fR perform the following actions for traffic pertaining to the AS:
.np
The ASP withholds sending AS traffic to the SGP or IPSP.
.np
The ASP stops processing AS traffic recevied from the SGP or IPSP.  Any
messages received for the Application Server after the last processed message
\fB\)MAY\fR be discarded.
.np
The ASP starts a T(divert) timer.
.ds #u \*#
.np
The ASP \fB\)SHALL\fR perform the applicable UA ASP Inactive Procedures\*(#u.
.(d
.#v
.ip \*#
For the "ASP Inactive Procedures", see Section 4.3.4.4 of M3UA, SUA, and
TUA.\ 
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
.)d
.sh 4 "SGP receiving ASPIA or sending ASPIA ACK"
.pp
An SGP receiving an \fB\)ASPIA\fR message for an AS, or wishing to send an
unsolicited \fB\)ASPIA ACK\fR to deactivate an AS, \fB\)SHALL\fR perform the following
actions for the traffic pertaining to each AS for which deactivation is
performed:
.np
The SGP withholds sending AS traffic to the ASP.
.np
The SGP stops processing AS traffic received from the ASP.  Any messages
received for the AS at the SGP after receiving the \fB\)ASPIA\fR message
\fB\)MUST\fR be discarded.
.np
The SGP marks for diversion all local copies of AS messages sent to the ASP.
.np
The SGP then \fB\)SHALL\fR perform the actions described in Section 4.1.6.1.
.np
The ASP \fB\)SHALL\fR perform the applicable UA ASP Inactive Procedures\*(#u.
.sh 4 "ASP receiving ASPIA ACK"
.pp
Upon receiving an \fB\)ASPIA ACK\fR message the ASP \fB\)SHALL\fR perform the following
actions for the traffic pertaining to the AS identified by the \fI\)Routing
Context\fR in the received \fB\)ASPIA ACK\fR message or implied by the SCTP
association on which the \fB\)ASPIA ACK\fR message was received:
.np
The T(divert) timer is cancelled (if running).
.np
The ASP marks for diversion any local copies of AS messages sent to the SGP.
.np
The ASP then \fB\)SHALL\fR perform the actions described in Section 4.1.6.1.
.np
The ASP \fB\)SHALL\fR perform the applicable UA ASP Inactive Procedures\*(#u.
.sh 4 "T(divert) timer expiry"
.pp
If the T(divert) timer expires before receiving an \fB\)ASPIA ACK\fR for the
AS, the ASP \fB\)SHALL\fR perform the actions described in Section 4.2.2.3.
.sh 3 "ASP Active Procedures"
.sh 4 "ASP sending ASPAC"
.pp
When an ASP wishes to activate an Application Server for an SGP, the ASP
\fB\)SHALL\fR perform the following actions for traffic pertaining to the AS:
.np
The ASP determines the correlation id of the last message sent to
this SGP for the AS for each traffic flow.
.np
If the ASP has not sent a message to the SGP for the traffic flow, the
correlation id zero (0) is used.
.np
If the ASP has sent messages to the SGP for the traffic flow, but cannot
determine the correlation id of the last message sent due to local failure,
the correlation id zero (0) is used.
.np
The ASP includes the correlation id(s) determined above in the
\fI\)Correlation Id\fR parameter in the \fB\)ASPAC\fR message used to active
the AS.  (See Section 3.1.1.)
.ds #w \*#
.np
The ASP \fB\)SHALL\fR perform the applicable UA ASP Active Procedures\*(#w.
.(d
.#v
.ip \*#
For the "ASP Active Procedures", see Section 4.3.4.3 of M3UA, SUA, and
TUA.\ 
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
.)d
.sh 4 "SGP receiving ASPAC"
.pp
When an SGP receives an \fB\)ASPAC\fR message for an Application Server, the
SGP \fB\)SHALL\fR perform the following actions with regard to traffic for the
AS:
.np
The SGP sets the correlation id of the next received message from the ASP for
each traffic flow to the value, contained in the \fI\)Correlation Id\fR
parameter in the \fB\)ASPAC ACK\fR message, plus one (1).
.np
The SGP determines the correlation id of the last message sent to
this SGP for each traffic flow.
.np
If the SGP has not sent a message to the ASP for a traffic flow, the
correlation id zero (0) is used.
.np
If the SGP has sent messages to the ASP for a traffic flow, but cannot
determine the correlation id of the last message sent due to local failure,
the correlation id zero (0) is used.
.np
The SGP includes the correlation id(s) determined above in the
\fI\)Correlation Id\fR parameter in the \fB\)ASPAC ACK\fR message used to
acknowledge activation of the AS.  (See Section 3.1.1.)
.np
The ASP \fB\)SHALL\fR perform the applicable UA ASP Active Procedures\*(#w, including the
sending of \fB\)ASPIA ACK\fR.
.np
The ASP then \fB\)SHALL\fR perform the actions described in Section 4.1.7.2.

.sh 4 "ASP receiving ASPAC ACK"
.pp
When an ASP receives an expected \fB\)ASPAC ACK\fR message for an Application
Server, the ASP \fB\)SHALL\fR perform the following actions with regard to AS
traffic:
.np
The ASP sets the correlation id of the next received message from the SGP for
each traffic flow to the value, contained in the \fI\)Correlation Id\fR
parameter in the \fB\)ASPAC ACK\fR message, plus one (1).
.np
The ASP \fB\)SHALL\fR perform the applicable UA ASP Active Procedures\*(#w.
.np
The ASP then \fB\)SHALL\fR perform the actions described in Section 4.1.7.2.
.pp
If an ASP receives an unexpected \fB\)ASPAC ACK\fR (i.e, one for which no
ASPAC was sent and the ASP is already in the ASP-ACTIVE state for the AS),
then the ASP \fB\)SHALL\fR ignore the message for the purposes of
\fB\)CORID\fR.  The ASP \fB\)SHALL\fR, however, perform the applicable UA ASP
Active Procedures\*(#w.
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.\"
.sh 2 "Interworking Procedures"
.pp
Because the \fB\)CORID\fR procedures provided here rely upon close
synchronization of correlation identifiers between SPP, if one of the SPP does
not support these \fB\)CORID\fR procedures, neither SPP is able to
take advantage of the full benefits of the procedures.  The SPP supporting
\fB\)CORID\fR \fB\)MAY\fR fall back to the interworking procedures provided in
this section, or to procedures based on the original (non-\fB\)CORID\fR) UA
procedures.
.pp
A peer SPP that does not support the \fB\)CORID\fR procedures can either be
identified by local configuration information, the ASP Extenstions
.[
aspext
.]
procedure, or at ASP Activation time.  The lack of support for \fB\)CORID\fR
can be determined at ASP Activation time when the peer SPP does not place a
\fB\)Correlation Id\fR parameter (as it \fB\)MUST\fR if both peers support
\fB\)CORID\fR) in the \fB\)ASPAC (ACK)\fR message.
.pp
When interworking to an SPP that does not support \fB\)CORID\fR, the SPP
supporting \fB\)CORID\fR \fB\)SHALL\fR perform all of the procedures as though the peer
SPP supported \fB\)CORID\fR with the following exceptions:
.np
The SPP \fB\)MUST NOT\fR send messages marked for diversion and tagged to the
peer SPP not supporting \fB\)CORID\fR.  All such messages \fB\)MAY\fR be
discarded.
.np
When diverting traffic between a failed, deactivated or overriden peer SPP and
an alternate peer SPP not supporting \fB\)CORID\fR, the actions described in
Section 4.1.6.1.2 \fB\)MUST\fR always be used instead of the procedures in
Section 4.1.6.1.1, except when there is no alternate SPP.
.np
The SPP \fB\)MUST NOT\fR place a \fI\)Correlation Id\fR parameter in the
\fB\)ASPAC\fR or \fB\)ASPACK ACK\fR.  So, the actions described in Sections
4.2.3.1(i)-(iv), 4.2.3.2(i)-(v) and 4.2.3.3(i)-(ii) do not apply.
.sh 1 "Examples"
.af $p 1
.sh 2 "Example Configuration"
.sh 2 "Initialization"
.pp
\fI\*(&f\n(&n\fR illustrates the initialization sequence that is used for all
of the examples .
.lp
.(b
.(c
.nf
.sz -2
\fC\
    SGP1  SGP2                          ASP1 ASP2 ASP3 ASP4    AS1
     :     :                             :    :    :    :       :
(1)  :<----:-Establish Association------>:    :    :    :       :
     :<----:-ASPUP-----------------------:    :    :    :       :
     :-----:-ASPUP ACK------------------>:    :    :    :       :
     :     :                             :    :    :    :       :
(2)  :<----:-Establish Association-------:--->:    :    :       :
     :<----:-ASPUP-----------------------:----:    :    :       :
     :-----:-ASPUP ACK-------------------:--->:    :    :       :
     :     :                             :    :    :    :       :
(3)  :<----:-Establish Association-------:----:--->:    :       :
     :<----:-ASPUP-----------------------:----:----:    :       :
     :-----:-ASPUP ACK-------------------:----:--->:    :       :
     :     :                             :    :    :    :       :
(4)  :<----:-Establish Association-------:----:----:--->:       :
     :<----:-ASPUP-----------------------:----:----:----:       :
     :-----:-ASPUP ACK-------------------:----:----:--->:       :
     :     :                             :    :    :    :       :
(5)  :     : (Same message exchange for SGP2) :    :    :       :
     :     :                             :    :    :    :       :
.fi
.sz +2
.)c
.#f "Example \- Starting Traffic"
.)b
.pp
The sequence of events in the exmaple illustrated in \fI\*(&f\n(&p\fR is as
follows:
.np
ASP1 establishes an SCTP association to SG1 and zents
.np
.np
.np
.sh 2 "Starting Traffic"
.pp
\fI\*(&f\n(&n\fR illustrates
.lp
.(b
.(c
.nf
.sz -2
\fC\
    SGP1  SGP2                          ASP1 ASP2 ASP3 ASP4    AS1
     :     :                             :    :    :    :       :
(1)  :<----:-Establish Association------>:    :    :    :       :
     :<----:-ASPUP-----------------------:    :    :    :       :
     :-----:-ASPUP ACK------------------>:    :    :    :       :
     :     :                             :    :    :    :       :
(2)  :<----:-Establish Association-------:--->:    :    :       :
     :<----:-ASPUP-----------------------:----:    :    :       :
     :-----:-ASPUP ACK-------------------:--->:    :    :       :
     :     :                             :    :    :    :       :
(3)  :<----:-Establish Association-------:----:--->:    :       :
     :<----:-ASPUP-----------------------:----:----:    :       :
     :-----:-ASPUP ACK-------------------:----:--->:    :       :
     :     :                             :    :    :    :       :
(4)  :<----:-Establish Association-------:----:----:--->:       :
     :<----:-ASPUP-----------------------:----:----:----:       :
     :-----:-ASPUP ACK-------------------:----:----:--->:       :
     :     :                             :    :    :    :       :
     :     : (Same message exchange for SGP2) :    :    :       :
     :     :                             :    :    :    :       :
.fi
.sz +2
.)c
.#f "Example \- Starting Traffic"
.)b
.pp
The sequence of events in the exmaple illustrated in \fI\*(&f\n(&p\fR is as
follows:
.np
.np
.np
.np
.np
.np
.np
.sh 3 "Initial Startup"
.sh 3 "Joining a Broadcast"
.sh 2 "Fail-Over"
.sh 3 "Assocation Failure \- Override"
.sh 3 "Deactivation \- Loadshare"
.sh 3 "Management Blocking \- Override"
.sh 2 "Recovery"
.sh 3 "Association Recovery \- Loadshare"
.sh 3 "AS-Pending Recovery"
.sh 2 "Interworking"
.sh 3 "ASP does not Support CORID"
.sh 1 "Security"
.pp
\fB\)CORID\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, SUA and TUA
.[
m3ua-10
.]
.[
sua-09
.]
.[
tua-01
.]
for security considerations and recommendations that are applicable to each of
these UAs.
.sh 1 "IANA Considerations"
.pp
\fB\)CORID\fR redefines the format of the \fI\)Correlation Id\fR parameter for
M3UA, SUA and TUA.  \fB\)CORID\fR also redifines the \fB\)ASPAC\fR and
\fB\)ASPAC ACK\fR messages to include the \fI\)Correlation Id\fR parameter as
a mandatory parameter of those messages.
.sh 1 "Timers"
.lp
Following are the \fB\)RECOMMENDED\fR timer values:
.ix +4
.TS
tab(:);
ll.
T(divert):0.5-2 seconds
T(restore):0.5-2 seconds
.TE
.uh "Acknowledgments"
.pp
The authors would like to thank
Ken Morneault,
Greg Sidebottom,
John Loughney,
Sandeep Mahajan,
Barry Nagelberg,
and
Nitin Vairagare
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"
.pp
.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
.pp
This draft expires July, 2002.
.)b
.bp
.ba +2
.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
\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.
